Een datapipeline is een geautomatiseerd systeem dat gegevens van bronsystemen naar een bestemming verplaatst voor analyse. Het lost een veelvoorkomend probleem op voor ondernemingen die op gegevens draaien: hoe je nuttige informatie die over veel verschillende systemen is verspreid, kunt verwerken en analyseren. De pipeline kan de gegevens betrouwbaar en herhaaldelijk verplaatsen.

Hieronder leggen we uit wat een datapipeline is, hoe het werkt, hoe de batch- en streamingbenaderingen verschillen en hoe betaalgegevens in de configuratie van een pipeline passen.

Hoogtepunten

• Een datapipeline vervangt handmatige exports en ad-hocprocessen die onder druk bezwijken.

• De keuze tussen batch- en streaming-pipelines is afhankelijk van hoe recent de gegevens moeten zijn. Financiële en analytische workloads draaien doorgaans probleemloos in batches.

• Betaalgegevens vereisen specifieke zorg bij de configuratie van een pipeline. Een systeemeigen synchronisatie van je betaaldienstverlener verbetert de beveiliging en betrouwbaarheid.

Wat is een datapipeline?

Een datapipeline is een geautomatiseerde reeks stappen die gegevens uit een of meer bronnen extraheert, deze optioneel transformeert en in een bestemming laadt waar ze kunnen worden geanalyseerd of gebruikt om bewerkingen uit te voeren. De bestemming is meestal een datawarehouse, een datalake of cloudopslag.

Waarom zijn datapipelines belangrijk voor rapportage en besluitvorming?

De waarde van een datapipeline is wat er mogelijk wordt wanneer je gegevens zich op een plek bevinden waar je ze kunt gebruiken. Datapipelines bieden de volgende voordelen:

• Verminderde datasilo's: Wanneer de gegevens zijn verspreid over systemen (inkomstengegevens bevinden zich bijvoorbeeld bij de betaaldienstverlener, klantgegevens in het customer relationship management (CRM)-systeem en supportgegevens in de helpdesk), kun je vragen die deze grenzen overschrijden niet eenvoudig beantwoorden. Een pipeline die deze bronnen centraliseert, maakt cross-functionele analyse mogelijk.

• Consistente definities: Pipelines dwingen structuur af. Als elk team tabellen uit hetzelfde datawarehouse haalt met een pull, die op dezelfde manier worden berekend, worden metrics zoals maandelijks terugkerende inkomsten (MRR) consistent gedefinieerd in alle rapporten. En dan is er geen discussie over wiens cijfers kloppen.

• Herhaalbare, controleerbare processen: Pipelines leveren dag in, dag uit vergelijkbare resultaten op. Die herhaalbaarheid maakt het mogelijk om metrics in de loop van de tijd te volgen en onregelmatigheden te onderzoeken wanneer deze zich voordoen.

• Snellere rapportagecycli: Financiële teams die voorheen dagen besteedden aan het extraheren en afstemmen van gegevens, kunnen de cyclus aanzienlijk verkorten wanneer de gegevens al in het datawarehouse staan, opgeschoond en gestructureerd.

Wat zijn de kerncomponenten van een datapipeline?

Veel pipelines, ongeacht hun complexiteit, zijn opgebouwd uit dezelfde set bouwstenen. Dit zijn de componenten die belangrijk zijn:

• Bronnen: Waar de gegevens vandaan komen, waaronder databases, application programming interfaces (API's) voor software-as-a-service (SaaS), eventstreams en platte bestanden. Hoe meer bronnen een pipeline via een pull ophaalt, hoe belangrijker het wordt om het schema en de betrouwbaarheid van elke bron bij te houden, en hoe vaak de bron verandert.

• Invoer: Het mechanisme om gegevens uit bronnen te extraheren en naar de pipeline te verplaatsen. Dit kan gaan om geplande database-query's, een abonnement op een webhook-stream of een connector van derden. Bij de invoer gaan pipelines vaak kapot (bijv. API's veranderen, inloggegevens verlopen, bronnen falen), dus goede invoerlagen zijn gebouwd om storingen te detecteren en te herstellen.

• Transformaties: De stap die ruwe gegevens omzet in een vorm die analytisch bruikbaar is. Transformaties schonen bijvoorbeeld records op en verwijderen duplicaten, voegen gegevens uit meerdere bronnen samen, berekenen afgeleide velden of dwingen een consistent schema af over systemen die van nature niet hetzelfde schema delen.

• Orkestratie: De laag die afhankelijkheden en planning beheert. Als Tabel B afhankelijk is van het volledig laden van Tabel A, moet de orkestratielaag dit weten en de volgorde afdwingen. Tools zoals Apache Airflow, Prefect en de data build tool (dbt) kunnen dit soort afhankelijkheidsbeheer aan.

• Bestemmingen: Waar de verwerkte gegevens terechtkomen. Dit is meestal een cloud-datawarehouse zoals Snowflake of Redshift, of cloudopslag zoals S3 of Google Cloud Storage (GCS). De keuze van de bestemming bepaalt welk type analyse verderop in het proces mogelijk is.

Waarin verschillen batch- en streaming-pipelines?

Voor het verplaatsen van gegevens hebben zowel streaming als batching hun legitieme toepassingen. De juiste keuze hangt af van hoe verouderd de gegevens mogen zijn voordat dit een echt probleem vormt.

Batch-pipelines

Deze verplaatsen gegevens volgens een schema (bijv. elk uur, 's nachts, wekelijks). Ze zijn zeer geschikt voor workloads waarbij latentie niet belangrijk is, zoals maandelijkse financiële rapportages, wekelijkse cohortanalyse van klanten en nachtelijke synchronisaties naar een datawarehouse. Batchverwerking is over het algemeen eenvoudiger te bouwen en te bedienen. En voor veel analysegebruiksscenario's is het precies wat je nodig hebt.

Streaming-pipelines

Deze verwerken gegevens continu, naarmate er gebeurtenissen plaatsvinden, met een latentie die wordt gemeten in seconden of milliseconden in plaats van uren. Ze zijn gebouwd voor gebruiksscenario's waarbij het handelen op basis van verouderde gegevens echte kosten met zich meebrengt, zoals fraudedetectie, het realtime volgen van de voorraad en realtime dashboards.

Voordat je deze route kiest voor het verplaatsen van gegevens, moet je de capaciteit van je team bepalen. Streaming-infrastructuur is duurder en lastiger te debuggen. Als je datateam klein is, wegen de overheadkosten van een streaming-pipeline mogelijk niet op tegen de latentievoordelen.

Hoe verhouden datapipelines, ETL en ELT zich tot elkaar?

Terwijl een datapipeline elk geautomatiseerd systeem is dat gegevens van een bron naar een bestemming verplaatst, zijn extract, transform and load (ETL) en extract, load and transform (ELT) twee patronen die deze verplaatsing structureren. Dit is hoe ze werken.

ETL

ETL betekent dat gegevens worden getransformeerd voordat ze in de bestemming worden geladen. De transformatie vindt plaats in een tussenlaag, zodat alleen de opgeschoonde, gevormde uitvoer het datawarehouse bereikt. Dit was het dominante patroon toen opslag duur was en datawarehouses niet goed geschikt waren om ruwe gegevens op grote schaal te verwerken.

ELT

Bij ELT zijn de laatste stappen omgedraaid. Ruwe gegevens worden geëxtraheerd en in het datawarehouse geladen, en de transformatie vindt daar plaats met behulp van structured query language (SQL) of een tool zoals dbt. Moderne cloud-datawarehouses zijn goedkoop genoeg om ruwe gegevens op te slaan en krachtig genoeg om deze te transformeren tijdens een query of als een geplande taak. ELT is het meer gangbare patroon geworden voor analytische workloads, deels omdat het ruwe gegevens bewaart voor herverwerking en transformaties gemakkelijker te controleren, te versioneren en aan te passen maakt.

Niet elke pipeline past netjes in een van beide categorieën. Sommige verplaatsen gegevens met vrijwel geen transformatie; ze synchroniseren ruwe eventlogboeken van een API naar cloudopslag voor latere verwerking. De terminologie is nuttig als een kortere weg voor architecturale intenties en niet zozeer als een precieze taxonomie.

Hoe past een betaaldienstverlener in de configuratie van een datapipeline?

Betaalgegevens behoren vaak tot de meest waardevolle en complexe gegevens in het datawarehouse van een bedrijf. Teams doorlopen over het algemeen dezelfde stappen wanneer ze deze proberen te beheren.

Exports van door komma's gescheiden waarden (CSV)

Veel teams beginnen met CSV-exports. Ze downloaden rapporten, schonen deze op en uploaden ze naar het datawarehouse. Maar exports mislukken, schema's veranderen of iemand vergeet de procedure uit te voeren. En daardoor ontbreken historische gegevens vaak of zijn deze inconsistent.

ETL-connectors van derden

Vervolgens stappen ze over op tools die gegevens volgens een schema via een pull uit een API voor betalingen halen en deze in een datawarehouse laden. Deze zijn redelijk betrouwbaar, maar ze introduceren een leverancier in een gevoelige gegevensstroom. Als een team financiële gegevens heeft die via een extra extern systeem lopen, vergroot dat het aanvalsoppervlak, creëert het compliance-overwegingen en levert het gegevens op die mogelijk net even anders zijn dan wat de betaaldienstverlener heeft.

Systeemeigen synchronisatie via Stripe Data Pipeline

Stripe Data Pipeline maakt een directe synchronisatie met Stripe mogelijk die gegevens naar een datawarehouse of cloudopslag verplaatst zonder een connector van derden. De configuratie vergt slechts enkele klikken, je hoeft geen code te schrijven en de pipeline bevat historische gegevens van het Stripe-account van een gebruiker. Het omvat ook geselecteerde gesynthetiseerde rapporten en samengestelde datasets, zoals gestructureerde financiële overzichten en voor analyse geschikte tabellen om MRR, fraude en meer te analyseren. Deze worden gegenereerd door de eigen systemen van Stripe en kunnen niet worden gerepliceerd door een generieke connector.