Designa inmatningslogik och konfiguration av datakälla

När du utformar inmatningslogik måste du fatta viktiga beslut om hur data flyttas från källsystem till Azure Databricks. Dessa beslut påverkar datas färskhet, bearbetningseffektivitet och systemets tillförlitlighet. Innan du väljer verktyg eller skriva kod måste du förstå egenskaperna för dina datakällor och definiera extraheringsstrategier som överensstämmer med dina affärskrav.

I den här lektionen utforskar du de viktigaste designövervägandena för datainmatningslogik och konfiguration av datakällor i Azure Databricks. Fokus här ligger på konceptuell logik och designmönster – specifika verktygsval och implementeringsinformation beskrivs i senare enheter.

Förstå extraheringstyper

Extraheringstypen bestämmer hur du samlar in data från källsystem och påverkar både datapipelinens aktualitet och effektivitet . Azure Databricks har stöd för tre primära extraheringsmönster som var och en passar för olika scenarier.

Fullständig extrahering

Fullständig extrahering hämtar hela datamängden från källsystemet under varje inmatningskörning.

Den här metoden fungerar bra när:

• Källsystem stöder inte ändringsspårning
• Datavolymerna är tillräckligt små för att bearbetas effektivt
• Du måste återskapa måltabeller från grunden med jämna mellanrum
• Datarelationer är komplexa och inkrementell logik skulle vara felbenägen

Fullständig extrahering blir opraktisk när datavolymerna växer. Bearbetning på nytt av miljontals poster när bara några tusen har ändrats slösar beräkningsresurser och fördröjer efterföljande konsumenter.

Inkrementell extrahering

Inkrementell extrahering bearbetar endast nya eller ändrade poster sedan den senaste inmatningskörningen. Motorn spårar vilka data som har bearbetats och frågar endast efter uppdateringar.

Det här mönstret kräver:

• En tillförlitlig ändringsindikator i källdata (tidsstämpel, sekvensnummer eller versionskolumn)
• Tillståndshantering för att spåra den senast bearbetade positionen
• Logik för att hantera poster som inkommer sent eller inte är i ordning

Inkrementell extrahering förbättrar avsevärt effektiviteten för stora datamängder. I stället för att läsa miljontals rader kan du bara bearbeta tusentals ändringar per körning.

Extrahering av direktuppspelning

Strömningsextrahering ger datainsamling i nästan realtid genom kontinuerlig bearbetning. I stället för att köras enligt ett schema förblir strömmande jobb aktiva och bearbetar poster när de anländer.

Överväg att strömma när:

• Affärsprocesser kräver data färskhet mätt i sekunder eller minuter
• Källsystem publicerar händelser till meddelandebussar eller ändringsflöden
• Du måste reagera på händelser när de inträffar

Extrahering av direktuppspelning kräver en infrastruktur som alltid finns men ger den lägsta svarstiden för datatillgänglighet.

Design för insamling av ändringsdata

CDC (Change Data Capture ) är ett specialiserat extraheringsmönster som samlar in enskilda ändringar på radnivå, inklusive infogningar, uppdateringar och borttagningar. CDC skiljer sig från enkel inkrementell extrahering eftersom den bevarar åtgärdstypen för varje ändring.

När du utformar för CDC bör du tänka på hur källsystemet skapar ändringsposter:

• Databastransaktionsloggar: Databaser som SQL Server kan exponera ändringar på radnivå med hjälp av dess transaktionsloggbaserade CDC-funktion. Underordnade system som Azure Databricks kan sedan läsa dessa ändringar och bearbeta dem som en del av inmatningspipelinen.
• Ändra dataflöden: Deltatabeller och vissa databaser som Azure Cosmos DB tillhandahåller inbyggd ändringsspårning som visar radändringar med metadata.
• Periodiska ögonblicksbilder: Vissa system stöder inte kontinuerlig CDC, vilket kräver att du jämför ögonblicksbilder för att fastställa ändringar.

CDC möjliggör användningsfall som enkel inkrementell extrahering inte kan stödja. Du kan replikera borttagningar korrekt, underhålla spårningsloggar och bearbeta uppdateringar som ändrar nyckelkolumner.

Identifiera egenskaper för källfilstyp

När data tas emot som filer i stället för från transaktionssystem påverkar filformatet din inmatningsdesign. Varje format har distinkta egenskaper som påverkar bearbetningen.

Textbaserade format

CSV - och JSON-filer är vanliga källformat eftersom de är läsbara och stöds i stor utsträckning. De utgör dock utmaningar för effektiv bearbetning:

• Schemavariationer: Filer kan ha inkonsekventa kolumnordningar, fält som saknas eller datatypvariationer
• Ingen komprimeringseffektivitet: Textformat förbrukar vanligtvis mer lagring än binära alternativ
• Parsningsoverhead: Varje värde kräver text-till-typ-konvertering under läsprocesser

Använd textbaserade format när källsystem bara kan producera dessa format eller när datavolymerna är tillräckligt små för att effektivitetsproblem inte ska gälla.

Kolumnformat

Parquet - och ORC-filer lagrar data i kolumnformat, vilket möjliggör effektiva analysfrågor. Dessa format erbjuder:

• Komprimering: Columnar Storage ger bättre komprimeringsförhållanden genom att gruppera liknande värden
• Kolumntrimning: Frågeoperationer läser bara de kolumner de behöver, vilket minskar I/O
• Inbäddat schema: Filen innehåller metadata som beskriver kolumnnamn och typer

Utforma inmatningen för att gynna kolumnformat när du har kontroll över hur överordnade system exporterar data.

Halvstrukturerade format

XML- och kapslade JSON-filer representerar hierarkiska data som inte passar en platt tabellstruktur. Vid inmatning av halvstrukturerade data:

• Planera för extrahering eller definition av schema.
• Fastställ om strukturen ska plattas ut eller bevaras.
• Ta hänsyn till varierande dokumentstrukturer inom samma källa.

Överväganden vid anslutning till datakälla

Konfiguration av datakälla definierar hur Azure Databricks ansluter till och autentiserar med källsystem. Din design måste hantera anslutningssäkerhet, hantering av autentiseringsuppgifter och åtkomstmönster.

Lagringskällor för molnobjekt

Molnlagring (Azure Data Lake Storage, Amazon S3 eller Google Cloud Storage) fungerar som den vanligaste landningszonen för inmatning. När du konfigurerar lagringsanslutningar:

• Använd externa platser i Unity Catalog för att styra åtkomsten till lagringssökvägar.
• Konfigurera lämpliga autentiseringsmetoder (hanterad identitet, tjänstens huvudnamn eller autentiseringsuppgifter för lagring).
• Utforma mappstrukturer som stöder effektiv inkrementell bearbetning.

Mappstrukturen påverkar avsevärt hur effektivt Azure Databricks kan identifiera och bearbeta nya filer. Tänk på följande mönster:

Datumbaserad partitionering: Ordna filer efter datumhierarki för att aktivera partitionsrensning under inkrementella läsningar:

/data/sales/year=2025/month=11/day=28/
/data/sales/year=2025/month=11/day=29/

Den här strukturen gör att frågor endast kan söka igenom relevanta datumpartitioner i stället för att visa alla filer.

Källbaserad organisation: När du matar in från flera källor separerar du data efter källsystem för att förenkla bearbetningslogik:

/landing/erp/orders/
/landing/crm/customers/
/landing/web/clickstream/

Bearbetningstillståndsmappar: Använd separata mappar för att spåra filbearbetningsstatus:

/incoming/     # New files arrive here
/processing/   # Files currently being processed
/archive/      # Successfully processed files
/failed/       # Files that failed processing

När du utformar mappstrukturer bör du tänka på:

• Omkostnader för filidentifiering: Platta strukturer med tusentals filer som saktar ned listningsåtgärder. Partitionerade strukturer minskar de filer som Azure Databricks måste räkna upp.
• Kompatibilitet med automatisk inläsning: Azure Databricks Auto Loader spårar effektivt nya filer i molnlagring. Strukturera mappar för att anpassa till hur Auto Loader upptäcker och hanterar kontrollpunkterna för filer.
• Extrahering av partitionskolumner: Använd Partitionering i Hive-format (key=value) så att Azure Databricks automatiskt kan extrahera partitionsvärden som kolumner utan att parsa filinnehållet.

Databaskällor

Anslutning till transaktionsdatabaser kräver andra överväganden än molnlagring:

• Nätverksanslutning mellan Azure Databricks och databasservern.
• Autentiseringsuppgifter lagras på ett säkert sätt (med hemligheter i stället för hårdkodade värden).
• Anslutningspoolning och fråge-pushdown funktioner.
• Påverkan på källsystemprestanda under extrahering.

Strömmande källor

Meddelandebussar och händelseströmmar (till exempel Azure Event Hubs eller andra vanliga meddelandeplattformar) kräver:

• Brokeranslutning och autentisering.
• Konfiguration av konsumentgrupper för parallell bearbetning.
• Offset-hantering för att följa förbrukningsläget.
• Schemaregisterintegrering för validering av meddelandeformat.

SaaS-programkällor

Företagsprogram som Salesforce, ServiceNow eller SAP exponerar data via API:er med unika egenskaper:

• API-hastighetsbegränsningar som begränsar extraheringsdataflödet.
• Sidnumreringsstrategier för stora resultatuppsättningar.
• Autentiseringsflöden (OAuth, API-nycklar eller certifikatbaserade).
• Tillgängliga funktioner för ändringsspårning eller webhook.

Tillämpa ett kravbaserat designramverk

Effektiv inmatningsdesign börjar med att analysera krav innan du väljer extraheringstyper eller filformat. Använd följande repeterbara ramverk för att vägleda dina designbeslut.

Steg 1: Samla in krav

Besvara följande viktiga frågor innan du fattar några tekniska beslut:

Kravkategori	Frågor att besvara
Datavolym	Hur mycket data finns i källan? Hur mycket ändras mellan körningar? Vad är tillväxttakten?
Krav på svarstid	Hur färska måste data vara för nedströmskonsumenter? Finns det serviceavtal att träffa?
Källkapaciteter	Stöder källan ändringsspårning, CDC eller endast fullständig extrahering? Vilka filformat kan den skapa?
Datakvalitet	Hur tillförlitliga är källdata? Vilken validering eller rensning krävs?
Nätverksbegränsningar	Vilken bandbredd finns mellan källan och Azure Databricks? Finns det brandväggs- eller VPN-krav?
Kostnadskonsekvenser	Vilka är kostnaderna för beräkning, lagring och dataöverföring av olika tillvägagångssätt?

Steg 2: Mappa krav för extraheringstyp

Använd din kravanalys för att välja lämpligt extraheringsmönster:

Om dina krav indikerar...	Välj sedan...
Liten datavolym (< 100 000 rader), ingen tillgänglig ändringsspårning, enkel återskapande acceptabel	Fullständig utdrag
Stora datavolymer, tillförlitlig ändringsindikator finns (tidsstämpel/sekvens), tillräcklig färskhet varje timme eller dag	Inkrementell extrahering
Realtids- eller nästan realtidsuppdatering krävs, källan publicerar händelser, tillgänglig strömningsinfrastruktur	Strömningsextraktion
Behöver samla in borttagningar och åtgärdstyper, spårningslogg krävs, källan stöder transaktionslogginsamling	CDC-extrahering

Steg 3: Välj källfilformat

När du styr källformatet eller behöver välja ett landningszonformat matchar du formatet efter dina behov:

Om ditt scenario omfattar...	Då föredrar du...
Stora analytiska datamängder, kolumnfrågor, behöver komprimering	Parquet
Samverkan med många system, mänsklig läsbarhet krävs	CSV eller JSON
Hierarkiska eller kapslade datastrukturer	JSON eller XML
Högfrekvent strömning med schemautveckling	Avro med schemaregister

Steg 4: Verifiera din design

Innan du implementerar bör du kontrollera att designen åtgärdar följande problem:

• Extraheringstypen uppfyller svarstidskraven. Om inte får nedströmskonsumenter inaktuella data, vilket kan orsaka felaktiga affärsbeslut eller SLA-överträdelser.

• Metoden skalar för att hantera beräknad datatillväxt. Annars kan pipelines som fungerar i dag misslyckas eller bli oöverkomligt långsamma när datavolymerna ökar.

• Källsystemfunktioner stöder det valda mönstret. Annars misslyckas pipelinen under körning eller kräver kostsamma temporära lösningar som ökar komplexiteten.

• Kostnadsuppskattningar ligger inom budgetbegränsningar. Annars kan lösningen vara tekniskt sund men ekonomiskt ohållbar för produktionsanvändning.

• Datakvalitetskontroller planeras för rörledningen. Om inte sprids ogiltiga eller skadade data till underordnade system, vilket orsakar fel eller felaktig analys.

Tillämpa ramverket: Ett praktiskt exempel

En e-handelsplattform måste mata in orderdata. Beställningar lagras i en PostgreSQL-databas och verksamheten kräver rapportering varje timme.

Steg 1 – Samla in krav:

• Volym: 50 000 nya beställningar dagligen, totalt 2 miljoner rader, 15% årlig tillväxt.
• Svarstid: En timmes färskhet accepteras för rapportering.
• Källa: PostgreSQL stöder tidsstämpelbaserade frågor men ingen intern CDC.
• Kvalitet: Källdata verifieras vid inmatning; minimal rengöring krävs.
• Nätverk: Direktanslutning via Azure Private Link.
• Kostnad: Minimera beräkningsanvändning; lagringskostnader är sekundära.

Steg 2 – Mappa till extraheringstyp:

Stor volym med tillförlitlig tidsstämpelkolumn och krav på svarstid varje timme → inkrementell extrahering.

Varför inte de andra?

• Fullständig extrahering: Omprocessning av 2 miljoner rader per timme slösar beräkningskraft när bara cirka 2 000 beställningar förändras per timme.
• Direktuppspelning: En timmes svarstid motiverar inte kostnaden för en infrastruktur för strömning som alltid är på.
• CDC: PostgreSQL exponerar inte den interna transaktionsloggen CDC och användningsfallet kräver inte spårningsborttagningar eller åtgärdstyper.

Steg 3 – Välj filformat:

Data hamnar i Azure Data Lake Storage för bearbetning → Parquet för effektiv kolumnlagring. Datumpartitionerad layout för inkrementell upptäckning → /landing/orders/year=2025/month=11/day=28/.

Varför inte de andra?

• CSV/JSON: Större filstorlekar, inga komprimeringsfördelar och långsammare frågeprestanda för analytiska arbetsbelastningar.
• Avro: Passar bättre för strömning med schemautveckling; batch-inmatning behöver inte dess direktuppspelningsorienterade funktioner.
• XML: Lägger till parsningskomplexitet utan fördelar för strukturerade tabellordningsdata.

Steg 4 – Verifiera design:

• ✔ Inkrementellt varje timme uppfyller kravet på en timmes svarstid.
• √ Bearbetningen av ändringar skalas endast effektivt med tillväxt.
• √ PostgreSQL-kolumnen order_updated_at aktiverar inkrementella frågor.
• √ Bearbetning av tusentals jämfört med miljontals rader minskar beräkningskostnaderna.

Slutgiltigt beslut: Inkrementell extrahering med hjälp av tidsstämpelkolumnen order_updated_at, schemalagd varje timme, med data som landar som Parquet-filer i Azure Data Lake Storage.

Med den här kravdrivna grunden är du redo att utvärdera de specifika verktyg och inläsningsmetoder som implementerar din inmatningsdesign.