Data engineering

Actuele data
zonder productie te belasten

Betrouwbare datapipelines vormen de basis waarop uw rapportage, analytics en alle onderliggende systemen rusten. Wij ontwerpen en bouwen change data capture pipelines die uw warehouse minuten achter de bron houden, zonder dat analytische queries ooit de database raken waar uw organisatie op draait.

Bespreek een dataopdracht

Wat we doen

Pipeline engineering

Log-based capture vanuit Oracle, SQL Server, PostgreSQL, DB2 en MySQL, doorlopend geland en samengevoegd in uw warehouse. HVR waar de licentie zichzelf terugverdient, eigen tooling op de changemechanismen van uw database waar dat niet zo is.

Ontlasting van bronsystemen

Rapportagequeries verhuizen naar een replica die bedoeld is om bevraagd te worden. Log-based capture leest de transactielog in plaats van de tabellen, dus de bron draagt alleen nog het schrijfpad. Uw applicatieteam beoordeelt niet langer elk verzoek voor een nieuw dashboard.

ETL- en ELT-ontwikkeling

Ingestie en transformatie op Glue, Data Factory, Dataflow, Snowflake en Databricks, met of zonder CDC eronder. Incrementeel als uitgangspunt, idempotente stappen, en orkestratie met echte afhankelijkheidsafhandeling in plaats van aan elkaar geknoopte schedules.

Datakwaliteit en reconciliatie

Rijaantallen, checksums en vergelijkingen op business keys tussen bron en doel, doorlopend in plaats van eenmalig bij livegang. Wijken de twee ooit af, dan weet u het voordat uw gebruikers het merken.

Monitoring en alerting

Replicatievertraging, mislukte stappen en schemawijzigingen komen naar boven als bruikbare alerts. Een pipeline die stil omvalt en verouderde cijfers in een dashboard laat staan is het faalpatroon dat wij het vaakst zien, dus daar bouwen wij tegen.

Documentatie en overdracht

Elke opdracht eindigt met vastgelegde runbooks en een doorloopsessie met de engineers die de pipelines daarna beheren. Het doel is dat u ons bij de volgende niet nodig heeft.

Van ruwe wijzigingen naar betrouwbare rapportage

Vrijwel elke omgeving begint met extractie via queries. Een geplande job selecteert uit de bron, schrijft naar het doel, en dat werkt goed zolang de tabellen klein zijn.

Vervolgens gebeuren er twee dingen. De extractie wordt zwaarder naarmate de data groeit, dus hij concurreert met de applicatie om precies de resources die de applicatie het hardst nodig heeft, op precies het drukste moment. En het schema rekt op, want een volledige herlaadslag is het enige dat betrouwbaar een correct doel oplevert, en die wordt elk kwartaal trager. Teams reageren door hem minder vaak te draaien, waardoor de data verder veroudert, wat het tegenovergestelde is van wat iedereen wilde.

Change data capture haalt die afweging weg. In plaats van de bron steeds opnieuw te vragen wat hij nu bevat, leest u de transactielog die de database toch al schrijft en past u alleen toe wat gewijzigd is. De belasting op de bron daalt en schaalt niet langer mee met het datavolume, de actualiteit gaat van uren naar minuten, en de volledige herlaadslag wordt een herstelmiddel in plaats van de dagelijkse routine.

Wij hebben dit werk opgeleverd in gereguleerde financiele dienstverlening, waar de rapportageomgeving het schrijfpad van productie niet mocht raken en elke toegepaste wijziging achteraf verantwoord moest kunnen worden.

Change data capture pipelines

Het technische werk zit vooral in de details die pas onder belasting zichtbaar worden.

Wij beginnen bij wat uw bronnen daadwerkelijk ondersteunen. Log-based capture vereist dat de database ervoor is ingericht, supplemental logging op Oracle, een passende replicatie-instelling op PostgreSQL, en dat antwoord bepaalt wat mogelijk is voordat er een tool gekozen wordt. Daarna: welke tabellen werkelijk gerepliceerd moeten worden in plaats van allemaal, hoe wijzigingen worden geland en samengevoegd in het doel, wat er met deletes gebeurt, en hoe ver het doel mag achterlopen voordat iemand een melding krijgt.

De eigenschappen waar wij op bouwen zijn herstartbaarheid vanaf een bekend punt na elke onderbreking, idempotente toepassing zodat opnieuw afspelen niet dubbel telt, bewuste afhandeling van schemawijzigingen, en reconciliatie die doorlopend draait in plaats van eenmalig bij livegang.

Specifiek over HVR. Waar het zijn kosten terugverdient is heterogene capture op volume, meerdere verschillende brondatabaseplatformen onder een operationeel model, met volwassen afhandeling van de lastige onderdelen. Het wordt ook regelmatig verkocht aan omgevingen die net zo goed geholpen zouden zijn met een native connector voor een fractie van de prijs. Wij vertellen u welke van beide u bent, en wij hebben geen commercieel belang bij het antwoord.

Waar een licentie niet te rechtvaardigen is, doet eigen tooling op de changemechanismen van de database zelf hetzelfde werk, en daarna is het van u.

ETL-pipelines op cloudplatformen

Niet elke pipeline heeft CDC eronder nodig, en een flink deel van dit werk is gewone pipelineontwikkeling.

Wij bouwen ingestie en transformatie op AWS (Glue, Redshift, S3), Azure (Data Factory, Synapse, Fabric), GCP (BigQuery, Dataflow) en richting Snowflake en Databricks, evenals naar databaseservers die u zelf beheert. Het platform bepaalt de uitvoering, maar de eigenschappen veranderen niet: incrementeel in plaats van volledig herladen, idempotente stappen zodat opnieuw uitvoeren veilig is, orkestratie met echte afhankelijkheidsafhandeling in plaats van jobs die aan elkaar hangen op starttijd en goede hoop, en storingen die opduiken als bruikbare alerts.

Dat laatste punt weegt zwaarder dan het klinkt. Een pipeline die luid omvalt is een ongemak. Een pipeline die stil omvalt en de cijfers van gisteren laat staan in een dashboard waar iemand beslissingen op baseert is een andere categorie probleem, en het is het faalpatroon dat wij het vaakst zien in omgevingen die zonder review zijn gegroeid.

Voor wie dit bedoeld is

Passend als uw rapportage wordt beperkt door een batchvenster dat niet meer past, of uw productiedatabases analytische belasting dragen waar ze nooit voor bedoeld waren, en u wilt dat het team dat de pipelines daarna beheert betrokken was bij het bouwen.

Niet passend als u iemand zoekt die uw dataplatform voor onbepaalde tijd overneemt. Wij bouwen, documenteren en dragen over. Heeft u een vast datateam nodig, dan is dat aannemen het betere antwoord en meestal ook het goedkopere.

Documentatie en overdracht

Wij schrijven uitgebreide technische documentatie als onderdeel van de oplevering, omdat een opdracht die uw team afhankelijk van ons achterlaat gefaald heeft in precies datgene wat u inkocht. Elke opdracht eindigt met een doorloopsessie met de engineers die de pipelines daarna beheren.

Wat het kost

Wordt bepaald na een kort gesprek. Dit werk loopt te ver uiteen in bronplatform, wijzigingsvolume en het aantal betrokken systemen om een gepubliceerde prijs eerlijk te laten zijn, en een korte inventarisatie bepaalt doorgaans of de bouw twee weken of twee maanden is.

Advies en kleiner afgebakend werk gaat tegen EUR 100 per uur. Alle prijzen zijn exclusief btw.

Veelgestelde vragen

Hoe actueel blijft het doel?
Doorgaans seconden tot enkele minuten achter de bron, afhankelijk van het wijzigingsvolume en de afstand die de data aflegt. De werkelijke beperking zit zelden in de capture zelf, maar in het samenvoegen in het doel. Een warehouse dat slecht omgaat met veel kleine schrijfacties bepaalt hoe vaak u wijzigingen kunt toepassen. Wij stemmen dat af op wat uw rapportage werkelijk nodig heeft, want een dashboard dat een keer per ochtend wordt bekeken rechtvaardigt de kosten van actualiteit op secondeniveau niet.
Welke belasting legt capture op onze productiedatabase?
Log-based capture leest de transactielog in plaats van de tabellen te bevragen, dus de overhead op de bron is klein en, belangrijker, hij concurreert niet met uw applicatie om dezelfde locks en buffers. Dat is precies de reden om het te verkiezen boven extractie via queries, die juist zwaarder wordt op het moment dat de database het al druk heeft.
Hebben wij HVR nodig, of is dat overdreven?
Het verdient zijn licentie terug wanneer u vanuit meerdere heterogene databases met hoge wijzigingsvolumes captured en daar een enkel operationeel model over wilt. Bij een enkele PostgreSQL-bron, een bescheiden wijzigingssnelheid of een doelplatform dat zelf al een degelijke connector levert is eigen tooling of de native dienst meestal het betere antwoord. Wij stellen vast welke van beide van toepassing is voordat iemand een licentie tekent, en wij hebben geen resellerrelatie die het antwoord kleurt.
Wat gebeurt er als het bronschema verandert?
Dat is de meest voorkomende manier waarop deze pipelines omvallen, dus het wordt ontworpen in plaats van ontdekt. Toevoegingen lopen automatisch mee. Destructieve wijzigingen leggen de pipeline bewust stil in plaats van stilletjes een kolom verderop te laten verdwijnen, want een pipeline die doordraait terwijl hij data verliest is erger dan een die stopt.
Op welke cloudplatformen bouwt u?
AWS, Azure en GCP, plus Snowflake en Databricks als doel, en databaseservers die u zelf beheert. Het platform bepaalt de uitvoering en het kostenmodel, maar de technische eigenschappen waar wij op bouwen veranderen niet.
Bouwt u de pipelines of adviseert u alleen?
Allebei kan. De meeste opdrachten zijn bouwwerk met uw engineers ernaast, zodat de mensen die de pipelines onderhouden ze hebben zien ontstaan. Een review van een bestaand ontwerp kan ook, en dat is een aanzienlijk goedkopere manier om te ontdekken dat iets niet gaat schalen.
Kunt u ook werken aan pipelines zonder CDC?
Ja. Een flink deel van het werk is gewone batch-ETL en ELT, bestanden en APIs naar een warehouse, transformatielagen, orkestratie. CDC is een van meerdere ingestiepatronen, en het toepassen waar het niet nodig is voegt vooral kosten en bewegende delen toe.

Gerelateerde diensten

Klaar voor een gesprek?

Onafhankelijke data engineering consultants voor change data capture pipelines met HVR en eigen tooling, en ETL-pipelines op AWS, Azure, GCP, Snowflake en Databricks.

Neem contact op