Datainmatning är det första steget i varje datapipeline. Det hänvisar till processen att samla in data från källsystem och flytta den till ett lager, en sjö eller en analysplattform där den kan efterfrågas.

När datainmatning misslyckas får du föråldrade inpaneler, trasiga avstämningar och maskininlärningsmodeller tränade på ofullständiga data. Ännu värre är att dåliga data kan påverka din vinst. Över 25 % av organisationerna rapporterade att de förlorar 5 miljoner USD eller mer årligen på grund av dålig datakvalitet.

Nedan ska vi titta närmare på vad datainmatning är, de huvudsakliga datainmatningsmönstren, de användningsfall som driver flest pipeline-investeringar och de utmaningar som team står inför.

Viktiga punkter

• Datainmatning flyttar data från källsystem till en destination där den kan lagras och efterfrågas. Det mönster som ett företag väljer avgör hur färska dessa data är.

• Tillförlitlig inmatning beror på två saker: fullständighet (dvs. alla poster som ska finnas där finns där) och aktualitet (dvs. data landar innan den första personen behöver den).

• En modern betalleverantör kan synkronisera data direkt till destinationer som Snowflake, Redshift och Amazon S3. Detta ger företag åtkomst till hela sin transaktionshistorik utan anpassad teknik eller tredjepartsanslutningar.

Datainmatning är processen att hämta data från källsystem och ladda in den i en destination där den kan lagras, efterfrågas och användas. Det matar in data i datalager, datasjöar och analysplattformar.

I ett betalningssammanhang kan datainmatning innebära att man samlar in data från olika källor, inklusive POS-system, webbplatser för e-handel och betalningsgateways.

Vilka är de huvudsakliga typerna av datainmatning?

Hur färska dina data behöver vara – och hur gamla data kan vara innan de slutar vara användbara – avgör vilken typ av datainmatningsmetod som är bäst för ditt företag.

Detta är de huvudsakliga metoderna att överväga.

Batch-inmatning

Batch-inmatning drar data enligt ett schema och flyttar det i bulk. Latens är timmar eller dagar, vilket är okej för många arbetsbelastningar. Ekonomistängningar, veckovisa chefsrapporter och historisk trendanalys (t.ex. bortfallsanalys) kan vanligtvis använda denna typ av data.

Strömmande inmatning

Strömmande inmatning behandlar händelser när de produceras, vilket sänker latensen till sekunder eller mindre. Infrastrukturen är mer krävande – du arbetar vanligtvis med system som Apache Kafka eller molnbaserade motsvarigheter – och dina konsumentapplikationer behöver hantera oordnade händelser och leverans minst en gång. Det är generellt det rätta valet när värdet av data kräver bedrägerisignaler, liveinventering och realtidspersonalisering.

Capture av dataändringar

Change data capture (CDC) läser av en källdatabas transaktionslogg och skickar endast ut det som ändrats, vilket landar inom minuters latens utan den extra belastningen av upprepade läsningar av hela tabeller. Det ligger mellan batch och strömmande när det gäller både komplexitet och färskhet, och det är särskilt användbart när du behöver noggrannhet i nästan realtid från ett relationellt system.

Vilka är de vanligaste användningsfallen för datainmatning?

Datainmatning finns för att tjäna någon process nedströms. Det mönster du väljer beror starkt på hur uppgifterna används.

Här är de vanligaste användningsfallen för datainmatning:

• Business Intelligence-rapportering (BI): Intäkter, konvertering, kundbortfall och supportvolym matar kontrollpaneler som teamen kontrollerar dagligen. Inmatningsfärskhet avgör hur aktuella dessa uppgifter är.

• Finansiell rapportering: Månads- och kvartalsbokslut är beroende av att fullständiga, korrekta transaktionsdata landar i ett lager där ekonomiavdelningen kan köra sina sökningar. Fullständighet är lika viktigt som färskhet här.

• Kund- och produktanalys: Beteendehändelsedata i kombination med CRM- (Customer Relationship Management) och transaktionsdata ger produkt- och tillväxtteamen en helhetsbild. Inmatning är det som kopplar samman dessa källsystem och gör det kombinerade datasetet möjligt att efterfråga.

• Övervakning av bedrägeri: Ett beslut som fattas på 12 timmar gamla uppgifter är ofta ett beslut som fattas på irrelevanta uppgifter. Bedrägeridetektering är ett av de fall där strömmande eller nästan realtids-CDC är värt den extra ansträngningen.

• Maskininlärning: Träningspipelines behöver historiska data i bulk; slutledningspipelines behöver färska funktioner. Inmatning tjänar båda: batch-inmatning kan användas för träningsuppsättningar och mönster med lägre latens kan användas för funktionslager.

Hur ser bra datainmatning ut?

När uppgifterna anländer både fullständiga och i tid kan analytikerna sluta tvivla på sina siffror och köra avstämningskontroller före varje rapport.

God datainmatning utlovar fullständighet. Alla poster som borde finnas där finns där. Ett väl utformat inmatningslager hanterar deduplicering, återfyllning av luckor och fångar upp sena poster innan de blir rapporteringsfel.

Uppgifterna kommer också fram när de behövs. Det betyder inte alltid så snabbt som möjligt: det betyder att uppgifterna landar innan användaren behöver dem.

Vilka är de största utmaningarna för datainmatning?

Inmatning ser okomplicerat ut tills du kör det över flera källsystem. Följande utmaningar för datainmatning orsakar ständigt problem.

Säkerhet och dataexponering

Att flytta känsliga data (t.ex. finansiella transaktioner, identifierbara personuppgifter, betalningsuppgifter) genom inmatningsinfrastruktur skapar exponering vid varje hopp. Team som dirigerar betalningsuppgifter genom en tredjepartsanslutning för extrahera, transformera, ladda (ETL) ger den leverantören tillgång till hela sin transaktionshistorik. Huruvida det är acceptabelt beror på leverantörskontrakt, krav på efterlevnad och risktolerans.

Skalbarhet

Volym ökar med tiden. Schemaändringar i källsystem kan bryta pipelines på sätt som inte alltid märks omedelbart. Partitioneringsstrategier, inkrementella inläsningar och hantering av schemaevolution är tekniska problem som kräver övervägande innan de blir incidenter.

Fragmentering

I många organisationer är inmatning oorganiserad snarare än ett system som utformats medvetet. Låt oss säga att datateamet byggde en anslutning för Salesforce, medan teknikteamet byggde en separat för produktionsdatabasen, och ekonomiavdelningen har en CSV-export som någon laddar upp varje måndag. Resultatet är dubbletter, inkonsekventa datapipelines som är svåra att övervaka och ännu svårare att lita på.

Kvalitetsfel

Pipelines går ibland sönder på ett uppenbart sätt: ett jobb misslyckas eller en kontrollpanel blir tom. Men fel kan också vara dolda. Till exempel kan en schemaändring uppströms släppa en kolumn, och sedan börjar nedströmstabeller sakna data, eller en frekvensbegränsning i ett API kan orsaka partiella inläsningar som ser fullständiga ut. Utan övervakning som kontrollerar radantal, värdeintervall och referensintegritet vet du inte förrän något går sönder tillräckligt allvarligt för att märkas.

Hur skiljer sig dataintag från ETL och ELT?

Dataintag, ETL och ELT beskriver överlappande delar av samma pipeline, men de betyder olika saker.

• Dataintag: Detta är handlingen att flytta data från en källa till ett målsystem. Det handlar om transport och leverans. Det tar inte hänsyn till om datan ändras under överföringen.
  
• Extract, transform, load (ETL): Detta är en arkitektur där data extraheras från källan, transformeras i mitten – historiskt sett i ett dedikerat transformationsverktyg eller en iscensättningsserver – och laddas in i destinationen i sin slutgiltiga form som är redo för frågor. Transformationen sker innan datan anländer.
  
• Extract, load, transform (ELT): Detta är samma arkitektur men med de två sista stegen omvända. Rådata hamnar i datalagret först, och transformationen sker där med hjälp av structured query language (SQL) eller verktyg som data build tool (dbt). Detta blev praktiskt när molnlager blev tillräckligt billiga och kraftfulla för att köra tunga transformationer i stor skala, och det är nu det dominerande mönstret för moderna datastackar.
  

Hur hjälper en betalleverantör till med datainmatning?

Stripe Data Pipeline är en direkt synkronisering från Stripe till ditt lager eller molnlagringsdestination utan en mellanhand. Det är tillgängligt för befintliga Stripe-användare och ansluter till destinationer som Snowflake, Redshift och Databricks. Konfigurationen kräver ingen kodning eller konfiguration av anslutningar.

Så här hjälper Stripe Data Pipeline till med datainmatning:

• Datafärskhet: Synkroniseringar körs kontinuerligt, och de flesta data är tillgängliga inom några timmar efter den underliggande händelsen.

• Historiska data: När du ansluter får du åtkomst till hela din Stripe-historik, snarare än bara data från anslutningsdatumet och framåt.

• Datakompletthet: Stripe Data Pipeline inkluderar förbyggda finansiella rapporter, såsom avstämning av utbetalningar och saldosammanfattning, tillsammans med utvalda dataset för vanliga användningsfall såsom månatliga återkommande intäkter (MRR) och analys av bedrägeri. Tredjepartsleverantörer kan inte synkronisera dessa datakällor och kräver manuella exporter eller återskapande av data.

• Minskad leverantörsexponering: Eftersom synkroniseringen sker direkt från Stripe till ditt lager, passerar inte dina betalningsuppgifter genom en tredjepartsleverantörs infrastruktur.