De huidige manier van aanbieden van datadiensten met datalakes leidt tot sterk gespecialiseerde silo-teams van data-engineers en businessanalisten. Gevolg is complexiteit, beperkte flexibiliteit en lange time-to-market van dataproducten. Dit voorkom je door decentrale devops-teams business-gedreven functionaliteit te laten ontwikkelen boven op centrale datadiensten. Data-mesh zorgt dat je maximaal gebruikmaakt van de flexibiliteit van devops-teams en domain driven data design boven op een betrouwbare data-infrastructuur. Welk concreet probleem data-mesh oplost leg ik hieronder uit.
Gebruikers verwachten dat de data continu beschikbaar en actueel is en voldoet aan de eisen van security en gegevensbescherming. Gebruikelijk slaan we onze bedrijfsdata op in een datawarehouse voor een gestructureerde analyse en rapportage. De omvang en complexiteit van de data maakt dat de grenzen van deze oplossing bereikt zijn. Een datawarehouse is een eenvoudige bevraging op vooraf gestructureerde data. Binnenkomende data worden voorbewerkt in deze structuur en bij grotere hoeveelheden data met een complexe structuur kost dat veel meer verwerkingscapaciteit. Bij de verhuizing naar de cloud verschuift het probleem naar de kostenkant door een hoge consumptie van rekenkracht.
Een datawarehouse is geschikt om vanuit een specifiek businessdomein vragen te beantwoorden. De wens om data over domeinen heen te combineren, zorgt voor een grotere hoeveelheid en complexiteit van data. Een datalake-platform is het antwoord hierop. Met een dergelijk platform ontstaan er echter drie silo’s, te weten bronteams (bieden operationele data aan), dataplatformteams (voor verwerking) en domein-gedreven businessteams (die de data gebruiken). Doorvoeren van een wijziging in een dergelijke structuur is ingewikkeld en vergt veel afstemming.
Nieuwe benadering
Een nieuwe benadering werkt met platformteams en business-devops-teams. Platformteams leveren het dataplatform. De business-devops-teams bestaan uit experts van de operationele systemen, data engineers en businessanalisten. Zij bouwen domein-specifieke dataproducten. Hiermee kan je snel en flexibel inspelen op de veranderingen in de operationele systemen en de vragen van de business. Een agile business-gedreven werkwijze is essentieel voor het succes van deze aanpak. Deze mix is ook wel bekend onder de term data-mesh. Ik wens u veel waarde uit uw data.
Auteur: Robbrecht van Amerongen, head of internet of things en api-integratie Conclusion
doe zo mn best het te begrijpen.
Je hebt dus datawarehouse met gestructureerde data vooraf bewerkt.
Dat ken ik : OLAP vs OLTP met elk hun voor en nadelen.
OLAP voor DWH voor en OLTP voor operationele bewerkingen.
OLAP is wel snel maar niet flexibel en het vergt extra resources, naast die van OLTP. Dit terwijl ze grotendeels dezelfde brondata gebruiken.
De OLTP data wordt periodiek in batch naar OLAP ge-etl-ed. Dat kost extra resources. Maar daarna kun je analysis maken met de OLAP, snel en onafhankelijk van de productie OLTP. Want ze delen wel dezelfde brondata maar niet dezelfde data. Zelfde geldt voor de hardware.
Allerlei teams voor nodig natuurlijk.
Maar waarom zouden die datalake en die devops teams beter zijn ? Hoe kun je daarmee nou “snel en flexibel inspelen op de veranderingen in de operationele systemen en de vragen van de business”.
Het woord “silo” wordt hier verkeerd gehanteerd door de auteur. In BI betekent silo(s) dat het gaat om een of meerdere beperkte domeinen van data, bijvoorbeeld de data van een enkele business unit. Dat heeft tot gevolg dat er geen “single source of truth” is binnen een bedrijf omdat een integraal overzicht over alle silo’s ontbreekt.
In de tekst heeft het woord silo echter betrekking op de 3 teams (bronteam, dataplatformteam, domein-gedreven businessteams) die nodig zijn om van een datalake-platform iets te maken. Dat is verwarrend.
De nieuwere benadering is echter nog verwarrender, want daar worden “domein-specifieke dataproducten” gebouwd. Maar het hebben van specifieke domeinen was nu juist het probleem!