Inleiding

Dit document beschrijft de voorgestelde referentie-architectuur voor een generiek en herbruikbaar data platform voor ETL-processen. De architectuur is ontworpen met als uitgangspunt dat meerdere organisaties dezelfde ETL-oplossingen kunnen gebruiken, ongeacht of deze worden uitgevoerd in een on-premise omgeving, private cloud of publieke cloud. De architectuur maakt onderscheid tussen een lichte ontwikkelomgeving voor ontwikkelaars en een schaalbare productieomgeving voor het uitvoeren van geautomatiseerde dataverwerkingen.

Belangrijkste ontwerpkeuzes

Scheiding tussen development en productie

De ontwikkelomgeving is bewust eenvoudig gehouden en draait op Docker Compose. Hierdoor kunnen ontwikkelaars ETL-processen lokaal ontwikkelen, testen en debuggen op een laptop of virtuele machine zonder afhankelijk te zijn van Kubernetes. De productieomgeving gebruikt Kubernetes voor orchestratie en uitvoering van workloads. Hierdoor ontstaat een schaalbare en platformonafhankelijke oplossing die zowel on-premise als in cloudomgevingen kan worden ingezet.

Container-first architectuur

Alle ETL-processen worden verpakt als Docker-images. Hierdoor:

• Zijn ETL's reproduceerbaar en overdraagbaar.
• Kan dezelfde image worden gebruikt in development, test en productie.
• Wordt afhankelijkheid van specifieke infrastructuur beperkt.
• Kunnen ETL-processen eenvoudig worden gedeeld tussen organisaties.

Scheiding tussen compute en data

ETL-processen worden uitgevoerd in tijdelijke containers die uitsluitend verantwoordelijk zijn voor verwerking van data. De opslag van gegevens vindt plaats in persistente opslag waardoor:

• Data behouden blijft onafhankelijk van containers.
• ETL-containers veilig kunnen worden verwijderd na uitvoering.
• Schaalbaarheid en herstelbaarheid worden verbeterd.

CI/CD en centrale registry

Nieuwe ETL-versies worden via een centrale repository en build pipeline gebouwd en gepubliceerd naar een container registry. Hierdoor:

• Is versiebeheer van ETL-processen geborgd.
• Worden wijzigingen centraal beheerd.
• Kunnen organisaties dezelfde ETL-images hergebruiken.

Hoofdcomponenten

Development omgeving De ontwikkelomgeving bestaat uit:

• Python
• Docker Compose
• PostgreSQL
• RustFS
• Dagster
• ETL containers
• Persistente volumes

De ontwikkelomgeving dient uitsluitend voor ontwikkeling, testen en validatie van ETL-processen.

CI/CD & Registry

De CI/CD-omgeving bestaat uit:

• Broncode repository
• Build pipeline
• Container registry

Deze omgeving verzorgt het bouwen, testen en publiceren van ETL-images.

Productieomgeving

De productieomgeving bestaat uit:

• Kubernetes cluster
• Dagster
• Kubernetes Pod Operator
• ETL containers
• RustFS
• PostgreSQL
• Persistente data volumes

De orchestrator bepaalt welke ETL-processen uitgevoerd moeten worden en wanneer. Kubernetes is verantwoordelijk voor het opstarten en uitvoeren van de containers.

Toekomstige uitbreidingen

De huidige architectuur plaat richt zich primair op de uitvoering van ETL-processen. Een aantal aanvullende voorzieningen is nog niet uitgewerkt en zal in een latere fase nader worden onderzocht:

Conclusie

Met deze architectuur ontstaat een platformonafhankelijke oplossing waarin ETL-processen lokaal ontwikkeld kunnen worden en vervolgens zonder functionele wijzigingen kunnen worden uitgevoerd in een productieomgeving op Kubernetes. Door gebruik te maken van containers, CI/CD en persistente opslag ontstaat een flexibele, schaalbare en herbruikbare basis die geschikt is voor samenwerking tussen meerdere organisaties.