Utvecklingen av datapipelines

Tidigare, när data behövde uppdateras, matade operatörerna in dem manuellt i en datatabell. Detta ledde till fel vid manuell inmatning och tidsfördröjningar. Eftersom detta huvudsakligen skedde i omgångar, oftast som en daglig uppgift, uppstod en betydande fördröjning från det att händelsen inträffade till dess att den rapporterades. Beslutsfattarna var tvungna att leva med denna tidsfördröjning och fattade ofta beslut baserade på inaktuella data.

Idag har vi realtidsuppdateringar och insikter som är vanliga krav. Syftet med att bygga datapipelines var i huvudsak att flytta data från ett lager (transaktions- eller händelsekällor) till datalager eller datalake där insikter kunde härledas.

Frågan är: med dessa ökade krav på realtidsinsikter och andra kvalitetskrav – är vi verkligen effektiva om vi använder traditionella arkitekturer eller de vanliga ETL-metoderna? Låt oss ta reda på det!

Datapipelines är viktiga för alla produktdigitaliseringsprogram. Under den senare halvan av detta decennium har vi sett ett enormt fokus på digital arkitektur och införandet av digitala tekniker. Att införandet av mikrotjänster och containerisering visar en stark tillväxtbana bekräftar detta faktum. Vi ser också att tekniska framsteg tillämpas, men att de är begränsade till traditionell ”OLTP” eller kärntjänster/affärslogik.

Situationen ser dock något annorlunda ut när man granskar mönstren i datapipelines eller ”OLAP”-sidan av saken. Vi ser en begränsad anpassning till den tekniska utvecklingen jämfört med vad som sker inom kärntjänsterna. De vanligaste datapipelinerna byggs antingen med traditionella ETL- eller ELTL-arkitekturer. Dessa är populära de facto-metoder inom branschen. Även om dessa löser det övergripande problemet, det vill säga att härleda användbara insikter, medför de också vissa begränsningar. Låt oss undersöka några av dessa utmaningar:

Siloartade team: ETL-processen kräver expertis eller kompetens inom dataextrahering eller -migrering. Detta kan innebära att det tekniska teamet är uppdelat i lager eller strukturerat för att hantera processens tekniska nyanser. Exempel: En ETL-ingenjör är ofta omedveten om vilka insikter som utvinns och hur de används av slutanvändarna.

Begränsad anpassning: Implementeringsteamet försöker nu anpassa alla önskade användningsfall till den fastställda strukturen eller mallen. Även om detta inte alltid är ett problem eller fel, kan det ibland leda till ineffektivitet. Exempel: Hur extraherar man data från en ostrukturerad källa och hanterar modelleringen av det mellanliggande lagringsschemat?

Fördröjning: Den tid det tar att bearbeta, extrahera, omvandla och ladda data medför ofta fördröjningar. Denna fördröjning kan bero på att data bearbetas i batcher eller på de nödvändiga mellanliggande laddningsstegen för att lagra preliminära resultat. I vissa affärsscenarier är detta inte acceptabelt.  Exempel: Dataströmmar som härrör från en IoT-tjänst lagras och batchbearbetas vid en senare schemalagd tidpunkt. Detta medför en fördröjning från datagenerering till uppdaterade insikter på instrumentpaneler.

I takt med att vi ser framsteg inom allmän programvaruarkitektur, såsom mikrotjänster, servicemesh och så vidare, finns det ett behov av liknande modernisering. En viktig strategi som växer fram är att distribuera datapipeline för domänerna istället för en centraliserad datapipeline, vilket bidrar till att bygga flera sådana objekt och resulterar i Data Mesh. Data Mesh syftar till att hantera dessa utmaningar genom att anta en annan strategi:

• Team eller poddar som är inriktade på leverans av funktionella funktioner
• Behandla data som en produkt (upptäckbar, fristående och säker)
• Polyglott lagring och kommunikation underlättas via Mesh

En första introduktion till Data Mesh finns här.

Data Mesh kan implementeras på olika sätt. Ett effektivt mönster är att använda ett händelsestyrt tillvägagångssätt och event storming för att skapa dataprodukter. En domän kan bestå av en eller flera dataprodukter. Detta innebär också att data kan vara redundanta och lagras i ett eller flera datalager. Detta kallas polyglott lagring. Slutligen konsumeras dessa dataprodukter via Mesh-API:er som utformats utifrån varje domäns krav.

Andra arkitekturstilar inkluderar Data Lake, Data Hub och datavirtualisering. En kort jämförelse av dessa finns här.

Några andra överväganden som man bör ta hänsyn till:

• Underlätta enkel datatillgång när som helst genom att använda standardgränssnitt som SQL. Teknik som Snowflake, DBT och Materialize möjliggör sådana realtidssammanslagningar som inte bara möjliggör BI, utan också underlättar den grundläggande strukturen i pipelinen
• Utforma datapipelines så att de är robusta och feltoleranta, t.ex. genom att skapa kontrollpunkter för delresultat där det krävs för vidare analys
• Utnyttja distribuerade, löst kopplade bearbetningsenheter som är skalbara för att använda polyglotta tekniker, t.ex. Spark-jobb eller Python-modeller
• Använd datavirtualisering för att minska flaskhalsar, t.ex. för att förkorta ledtiden för datatillgänglighet
• Använd DataOps effektivt för att spåra och utvärdera prestandan i din datapipeline

Avslutningsvis vill jag lägga till en ansvarsfriskrivning. Syftet med denna artikel är inte att avfärda befintliga arkitekturer kopplade till ETL. För vissa användningsfall, såsom batchjobb, är ETL faktiskt fortfarande ett mycket bra alternativ. Syftet här är snarare att belysa vad man bör ha i åtanke utifrån de varierande kraven och utforska ytterligare arkitekturer som kan passa väl för behovet. I den här artikeln har vi tittat på några sådana arkitekturer, såsom Data Mesh, och relaterade områden som man behöver beakta.

Lämnagärna kommentarer, synpunkter och frågor om den här artikeln – jag ska försöka besvara dem så snart jag har möjlighet.