En datapipeline är ett automatiserat system som flyttar data från källsystem till en destination för analys. Det löser ett vanligt problem för företag som drivs av data: hur man ska behandla och analysera användbar information som är utspridd över många olika system. Pipelinen kan flytta datan pålitligt och upprepade gånger.

Nedan kommer vi att förklara vad en datapipeline är, hur den fungerar, hur batch- och strömningsmetoder skiljer sig åt, och hur betalningsdata passar in i en pipeline-konfiguration.

Viktiga punkter

• En datapipeline ersätter manuella exporter och ad hoc-processer som bryter samman under tryck.

• Valet mellan batch- och strömningspipelines beror på hur färsk din data behöver vara. Ekonomi- och analysarbetsbelastningar körs vanligtvis bekvämt på batch.

• Betalningsdata kräver särskild omsorg i en pipeline-konfiguration. En inbyggd synkronisering från din betalleverantör förbättrar säkerheten och tillförlitligheten.

Vad är en datapipeline?

En datapipeline är en automatiserad sekvens av steg som extraherar data från en eller flera källor, eventuellt transformerar den, och laddar den till en destination där den kan analyseras eller användas för att köra operationer. Destinationen är vanligtvis ett datalager, en datasjö eller molnlagring.

Varför spelar datapipelines roll för rapportering och beslutsfattande?

Värdet av en datapipeline är vad som blir möjligt när din data är någonstans där du kan använda den. Datapipelines skapar följande fördelar:

• Minskade datasilos: När din data är uppdelad över system – till exempel om intäkter finns hos din betalleverantör, kunddata finns i ditt CRM-system (Customer Relationship Management), och supportdata finns i din helpdesk – kan du inte enkelt svara på frågor som korsar dessa gränser. En pipeline som centraliserar dessa källor gör tvärfunktionell analys möjlig.

• Konsekventa definitioner: Pipelines upprätthåller struktur. Om varje team drar från samma lagertabeller, som beräknas på samma sätt, definieras mätvärden som månatliga återkommande intäkter (MRR) konsekvent över rapporter – och det uppstår ingen diskussion om vems siffror som är rätt.

• Upprepbara, reviderbara processer: Pipelines producerar jämförbara resultat dag in och dag ut. Den upprepbarheten gör det möjligt att spåra mätvärden över tid och undersöka avvikelser när de uppstår.

• Snabbare rapporteringscykler: Ekonomiteam som tidigare ägnat dagar åt att extrahera och stämma av data kan avsevärt förkorta cykeln när datan redan finns i lagret, rensad och strukturerad.

Vilka är kärnkomponenterna i en datapipeline?

Många pipelines, oavsett komplexitet, byggs från samma uppsättning byggstenar. Dessa är komponenterna som betyder något:

• Källor: Var datan har sitt ursprung, inklusive databaser, API:er (Application Programming Interfaces) för SaaS (Software-as-a-Service), händelseströmmar och platta filer. Ju fler källor en pipeline drar från, desto viktigare blir det att spåra var och ens schema och tillförlitlighet, och hur ofta källan ändras.

• Inhämtning: Mekanismen för att extrahera data från källor in i pipelinen. Detta kan innebära schemalagda databasfrågor, en prenumeration på en webhook-ström, eller en tredjepartsanslutning. Inhämtning är ofta där pipelines går sönder (t.ex. att API:er ändras, inloggningsuppgifter löper ut, källor misslyckas) så bra inhämtningslager byggs för att upptäcka och återhämta sig från fel.

• Transformationer: Steget som omformar rådata till en form som är analytiskt användbar. Till exempel rensar transformationer poster och tar bort dubbletter, slår ihop data från flera källor, beräknar härledda fält, eller upprätthåller ett konsekvent schema över system som inte delar ett inbyggt.

• Orkestrering: Lagret som hanterar beroenden och schemaläggning. Om Tabell B är beroende av att Tabell A är fulladdad måste orkestreringslagret veta detta och upprätthålla ordningen. Verktyg som Apache Airflow, Prefect och dbt (data build tool) kan hantera den här typen av beroendehantering.

• Destinationer: Var behandlad data landar. Detta är vanligtvis ett molndatalager som Snowflake eller Redshift, eller molnlagring som S3 eller Google Cloud Storage (GCS). Valet av destination formar vilken typ av analys som är möjlig nedströms.

Hur skiljer sig batch- och strömningspipelines åt?

För dataförflyttning har både strömning och batching legitima användningsområden. Rätt val beror på hur gammal din data kan vara innan det orsakar ett verkligt problem.

Batch-pipelines

Dessa flyttar data enligt ett schema (t.ex. varje timme, natt, vecka). De är väl lämpade för arbetsbelastningar där latens inte är viktigt, såsom månatlig ekonomisk rapportering, veckovis kohortanalys av kunder, och nattliga synkroniseringar till ett datalager. Batchbehandling är generellt enklare att bygga och driva. Och för många analysanvändningsfall är det exakt vad du behöver.

Strömningspipelines

Dessa behandlar data kontinuerligt, allt eftersom händelser inträffar, med latens mätt i sekunder eller millisekunder snarare än timmar. De är byggda för användningsfall där agerande på gammal data medför verkliga kostnader, såsom bedrägeriupptäckt, lagerspårning i realtid och instrumentpaneler i realtid.

Innan du väljer denna väg för dataförflyttning bör du bedöma ditt teams kapacitet. Strömningsinfrastruktur är dyrare och svårare att felsöka. Om ditt datateam är litet kan omkostnaderna för en strömningspipeline uppväga latensfördelarna.

Hur förhåller sig datapipelines, ETL och ELT till varandra?

Medan en datapipeline är ett automatiserat system som flyttar data från en källa till en destination, är extrahera, transformera och ladda (ETL) samt extrahera, ladda och transformera (ELT) två mönster som strukturerar den rörelsen. Så här fungerar de.

ETL

ETL innebär att data transformeras innan den laddas till destinationen. Transformationen sker i ett mellanlager så att endast de rensade, formade utdata når lagret. Detta var det dominerande mönstret när lagring var dyrt och lager inte var väl lämpade för att hantera rådata i stor skala.

ELT

Med ELT är de senare stegen omvända. Rådata extraheras och laddas till lagret, och transformationen sker där med hjälp av strukturerat frågespråk (SQL) eller ett verktyg som dbt. Moderna molnlager är tillräckligt billiga för att lagra rådata och tillräckligt kraftfulla för att transformera den vid frågetillfället eller som ett schemalagt jobb. ELT har blivit det vanligare mönstret för analysarbetsbelastningar, delvis för att det bevarar rådata för ombearbetning och gör transformationer enklare att revidera, versionshantera och modifiera.

Inte varje pipeline passar prydligt in i någon av kategorierna. Vissa flyttar data med nästan ingen transformation; de synkroniserar råa händelseloggar från ett API till molnlagring för senare behandling. Terminologin är användbar som en förkortning för arkitektonisk avsikt snarare än som en exakt taxonomi.

Hur passar en betalleverantör in i en datapipeline-konfiguration?

Betalningsdata tenderar att vara bland den mest värdefulla och komplicerade datan i ett företags lager. Team går i allmänhet igenom samma utveckling när de försöker hantera den.

Exportering av kommaseparerade värden (CSV)

Många team börjar med CSV-exporter. De laddar ner rapporter, rensar dem och laddar upp dem till lagret. Men exporter går sönder, scheman ändras, eller så glömmer någon att köra processen. Och historisk data saknas ofta eller är inkonsekvent som ett resultat.

ETL-anslutningar från tredje part

Därefter vänder de sig till verktyg som drar data från ett betalnings-API och laddar den i ett lager enligt ett schema. Dessa är rimligt pålitliga, men de introducerar en leverantör till ett känsligt dataflöde. Om ett team har finansiell data som passerar genom ett ytterligare tredjepartssystem kommer det att utöka dess attackyta, skapa överväganden kring efterlevnad och producera data som kan skilja sig något från vad dess betalleverantör har.

Inbyggd synkronisering via Stripe Data Pipeline

Stripe Data Pipeline möjliggör en direkt synkronisering till Stripe som flyttar data till ett lager eller molnlagringsdestination utan en tredjepartsanslutning. Konfigurationen tar bara några klick, det finns ingen kod att skriva, och pipelinen innehåller historisk data från en användares Stripe-konto. Den innehåller också utvalda syntetiserade rapporter och kuraterade dataset, såsom strukturerade finansiella sammanfattningar och analysklara tabeller för att analysera MRR, bedrägeri och mer. Dessa genereras av Stripes egna system och kan inte replikeras av en generisk anslutning.