Ontwerpopnamelogica en configuratie van gegevensbron

Voor het ontwerpen van opnamelogica moet u kritieke beslissingen nemen over de verplaatsing van gegevens van bronsystemen naar Azure Databricks. Deze beslissingen zijn van invloed op de versheid van gegevens, de verwerkingsefficiëntie en de betrouwbaarheid van het systeem. Voordat u hulpprogramma's selecteert of code schrijft, moet u de kenmerken van uw gegevensbronnen begrijpen en extractiestrategieën definiëren die overeenkomen met uw bedrijfsvereisten.

In deze les verkent u de belangrijkste ontwerpoverwegingen voor gegevensopnamelogica en configuratie van gegevensbronnen in Azure Databricks. De focus hier ligt op conceptuele logica en ontwerppatronen. Specifieke hulpprogrammaselectie- en implementatiedetails worden behandeld in latere eenheden.

Meer informatie over extractietypen

Het extractietype bepaalt hoe u gegevens van bronsystemen vastlegt en invloed heeft op zowel de tijdigheid als de efficiëntie van uw gegevenspijplijn. Azure Databricks ondersteunt drie primaire extractiepatronen, die elk geschikt zijn voor verschillende scenario's.

Volledige extractie

Bij volledige extractie wordt de volledige gegevensset uit het bronsysteem gelezen tijdens elke opnameuitvoering.

Deze aanpak werkt goed wanneer:

• Bronsystemen bieden geen ondersteuning voor het bijhouden van wijzigingen
• Gegevensvolumes zijn klein genoeg om efficiënt opnieuw te verwerken
• U moet doeltabellen periodiek opnieuw samenstellen
• Gegevensrelaties zijn complex en incrementele logica is foutgevoelig

Volledige extractie wordt onpraktisch naarmate de gegevensvolumes toenemen. Het opnieuw verwerken van miljoenen records wanneer slechts enkele duizenden zijn gewijzigd verspilt rekenresources en vertraagt afnemers stroomafwaarts.

Incrementele extractie

Incrementele extractie verwerkt alleen nieuwe of gewijzigde records sinds de laatste verwerkingsronde. De engine houdt bij welke gegevens zijn verwerkt en voert alleen zoekopdrachten uit voor updates.

Voor dit patroon is het volgende vereist:

• Een betrouwbare wijzigingsindicator in de brongegevens (tijdstempel, volgnummer of versiekolom)
• Statusbeheer om de laatst verwerkte positie bij te houden
• Logica voor het verwerken van records die te laat binnenkomen of buiten de order vallen

Incrementele extractie verbetert de efficiëntie voor grote gegevenssets aanzienlijk. In plaats van miljoenen rijen te lezen, kunt u per uitvoering slechts duizenden wijzigingen verwerken.

Streaming-extractie

Streamingextractie biedt bijna realtime gegevensopname via continue verwerking. In plaats van volgens een planning uit te voeren, blijven streamingtaken actief en worden records verwerkt zodra ze binnenkomen.

Overweeg streaming wanneer:

• Voor bedrijfsprocessen is de versheid van gegevens in seconden of minuten vereist
• Bronsystemen publiceren gebeurtenissen naar berichtenbussen of wijzigingsfeeds
• U moet reageren op gebeurtenissen wanneer deze zich voordoen

Streaming-extractie vereist always-on-infrastructuur, maar levert de laagste latentie voor gegevensbeschikbaarheid.

Ontwerpen voor het vastleggen van gegevens wijzigen

Change Data Capture (CDC) is een speciaal extractiepatroon waarmee afzonderlijke wijzigingen op rijniveau worden vastgelegd, waaronder invoegingen, updates en verwijderingen. CDC verschilt van eenvoudige incrementele extractie omdat het bewerkingstype voor elke wijziging behouden blijft.

Houd bij het ontwerpen voor CDC rekening met de wijze waarop uw bronsysteem wijzigingsrecords produceert:

• Databasetransactielogboeken: databases zoals SQL Server kunnen wijzigingen op rijniveau beschikbaar maken met behulp van de CDC-functie op basis van transactielogboeken. Downstreamsystemen zoals Azure Databricks kunnen deze wijzigingen lezen en verwerken als onderdeel van de opnamepijplijn.
• Gegevensfeeds wijzigen: Delta-tabellen en sommige databases zoals Azure Cosmos DB bieden ingebouwde wijzigingsregistratie, waarmee rijwijzigingen met metadata worden weergegeven.
• Periodieke momentopnamen: sommige systemen bieden geen ondersteuning voor continue CDC, waarbij u momentopnamen moet vergelijken om wijzigingen te bepalen.

CDC maakt gebruiksvoorbeelden mogelijk die eenvoudige incrementele extractie niet kunnen ondersteunen. U kunt verwijderingen nauwkeurig repliceren, audittrails onderhouden en updates verwerken die belangrijke kolommen wijzigen.

Kenmerken van bronbestandstype identificeren

Wanneer gegevens binnenkomen als bestanden in plaats van van transactionele systemen, is de bestandsindeling van invloed op uw opnameontwerp. Elke indeling heeft verschillende kenmerken die van invloed zijn op de verwerking.

Op tekst gebaseerde indelingen

CSV- en JSON-bestanden zijn veelgebruikte bronindelingen omdat ze door mensen kunnen worden gelezen en algemeen worden ondersteund. Ze zijn echter uitdagingen voor efficiënte verwerking:

• Schemavariabele: Bestanden kunnen inconsistente kolomvolgordes, ontbrekende velden of variaties van gegevenstypen hebben
• Geen compressie-efficiëntie: tekstindelingen verbruiken doorgaans meer opslagruimte dan binaire alternatieven
• Parse overhead: elke waarde vereist een conversie van tekst naar type tijdens het lezen

Gebruik op tekst gebaseerde indelingen wanneer bronsystemen alleen deze indelingen kunnen produceren of wanneer gegevensvolumes klein genoeg zijn en er geen efficiëntieproblemen van toepassing zijn.

Kolomindelingen

Parquet - en ORC-bestanden slaan gegevens op in kolomindeling, waardoor efficiënte analytische query's mogelijk zijn. Deze indelingen bieden:

• Compressie: Kolomopslag bereikt betere compressieverhoudingen door vergelijkbare waarden te groeperen
• Kolomsnoeien: query's lezen alleen de kolommen die ze nodig hebben, waardoor I/O wordt verminderd
• Ingesloten schema: het bestand bevat metagegevens die kolomnamen en -typen beschrijven

Ontwerp uw gegevensverwerking om kolomvormige bronindelingen te verkiezen als u controle heeft over hoe upstreamsystemen gegevens exporteren.

Semi-gestructureerde indelingen

XML- en geneste JSON-bestanden vertegenwoordigen hiërarchische gegevens die niet passen bij een platte tabellaire structuur. Bij het opnemen van semi-gestructureerde gegevens:

• Plannen voor schema-extractie of -definitie.
• Bepaal of u de structuur wilt platmaken of nesten wilt behouden.
• Houd rekening met verschillende documentstructuren in dezelfde bron.

Overwegingen voor gegevensbronverbindingen

De configuratie van de gegevensbron definieert hoe Azure Databricks verbinding maakt met en verifieert met bronsystemen. Uw ontwerp moet betrekking hebben op verbindingsbeveiliging, referentiebeheer en toegangspatronen.

Opslagbronnen voor cloudobjecten

Cloudopslag (Azure Data Lake Storage, Amazon S3 of Google Cloud Storage) fungeert als de meest voorkomende landingszone voor opname. Bij het configureren van opslagverbindingen:

• Gebruik externe locaties van Unity Catalog om toegang tot opslagpaden te beheren.
• Configureer de juiste verificatiemethoden (beheerde identiteit, service-principals of opslagreferenties).
• Ontwerp mapstructuren die de efficiënte incrementele verwerking ondersteunen.

Mapstructuur is van invloed op hoe efficiënt Azure Databricks nieuwe bestanden kan identificeren en verwerken. Houd rekening met deze patronen:

Op datum gebaseerde partitionering: organiseer bestanden op datumhiërarchie om partities te verwijderen tijdens incrementele leesbewerkingen:

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

Met deze structuur kunnen query's alleen relevante datumpartities scannen in plaats van alle bestanden weer te geven.

Organisatie op basis van bron: Wanneer u gegevens uit meerdere bronnen opneemt, scheidt u gegevens door het bronsysteem om de verwerkingslogica te vereenvoudigen:

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

Statusmappen verwerken: gebruik afzonderlijke mappen om de verwerkingsstatus van bestanden bij te houden:

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

Overweeg bij het ontwerpen van mapstructuren het volgende:

• Overhead voor bestandsdetectie: Platte structuren met duizenden bestanden vertragen het opsommen van bestanden. Gepartitioneerde structuren verminderen de bestanden die Azure Databricks moet inventariseren.
• Compatibiliteit met automatische laadprogramma's: Met Azure Databricks Auto Loader worden nieuwe bestanden efficiënt bijgehouden in cloudopslag. Structureer mappen om uit te lijnen met de wijze waarop automatisch laadprogramma bestanden detecteert en controlepunten detecteert.
• Partitiekolomextractie: Gebruik Partitionering in Hive-stijl (key=value) zodat Azure Databricks automatisch partitiewaarden als kolommen kan extraheren zonder bestandsinhoud te parseren.

Databasebronnen

Voor het maken van verbinding met transactionele databases zijn andere overwegingen vereist dan cloudopslag:

• Netwerkconnectiviteit tussen Azure Databricks en de databaseserver.
• Verificatiereferenties veilig opgeslagen (met gebruik van geheime gegevens in plaats van hardcoded waarden).
• Mogelijkheden voor groepsgewijze verbindingen en query's voor pushdown .
• Invloed op de prestaties van het bronsysteem tijdens extractie.

Streamingbronnen

Berichtenbussen en gebeurtenisstromen (zoals Azure Event Hubs of andere veelvoorkomende berichtensystemen) vereisen:

• Brokerverbindingsdetails en verificatie.
• Configuratie van consumentengroepen voor parallelle verwerking.
• Offsetbeheer om de verbruikspositie bij te houden.
• Schemaregisterintegratie voor validatie van berichtindeling.

SaaS-toepassingsbronnen

Bedrijfstoepassingen zoals Salesforce, ServiceNow of SAP maken gegevens beschikbaar via API's met unieke kenmerken:

• API-frequentielimieten waarmee de doorvoer voor extractie wordt beperkt.
• Pagineringsstrategieën voor grote resultatensets.
• Verificatiestromen (OAuth, API-sleutels of op basis van certificaten).
• Beschikbare mogelijkheden voor wijzigingen bijhouden of webhook.

Een ontwerpframework op basis van vereisten toepassen

Effectief opnameontwerp begint met het analyseren van vereisten voordat u extractietypen of bestandsindelingen selecteert. Gebruik het volgende herhaalbare framework om uw ontwerpbeslissingen te begeleiden.

Stap 1: Vereisten verzamelen

Voordat u technische beslissingen neemt, beantwoordt u deze belangrijke vragen:

Vereistecategorie	Vragen om te beantwoorden
gegevensvolume	Hoeveel gegevens bestaan er in de bron? Hoeveel verandert er tussen uitvoeringen? Wat is het groeipercentage?
Latentievereisten	Hoe nieuw moeten gegevens zijn voor downstreamgebruikers? Zijn er SLA's om te voldoen?
Bronmogelijkheden	Ondersteunt de bron het bijhouden van wijzigingen, CDC of alleen volledige extractie? Welke bestandsindelingen kunnen worden geproduceerd?
Gegevenskwaliteit	Hoe betrouwbaar zijn de brongegevens? Welke validatie of reiniging is nodig?
Netwerkbeperkingen	Welke bandbreedte bestaat er tussen de bron en Azure Databricks? Zijn er firewall- of VPN-vereisten?
Kostenimplicaties	Wat zijn de kosten voor berekening, opslag en gegevensoverdracht van verschillende benaderingen?

Stap 2: Vereisten in kaart brengen voor extractietype

Gebruik uw vereistenanalyse om het juiste extractiepatroon te selecteren:

Als uw vereisten aangeven...	Kies vervolgens...
Klein gegevensvolume (< 100.000 rijen), geen wijzigingen bijhouden beschikbaar, eenvoudig herbouwen acceptabel	Volledige extractie
Groot gegevensvolume, betrouwbare wijzigingsindicator bestaat (tijdstempel/volgorde), elke uur of dagelijkse verversing is voldoende	Incrementele extractie
Realtime of bijna realtime versheid vereist, bron publiceert gebeurtenissen, streaming-infrastructuur beschikbaar	Streaming-extractie
Noodzaak om verwijderingen en bewerkingstypen vast te leggen, audittrail vereist, bron ondersteunt het vastleggen van transactielogboeken	CDC-extractie

Stap 3: Selecteer de bronbestandsindeling

Wanneer u de bronindeling bepaalt of een landingszone-indeling moet kiezen, moet u de indeling aan uw behoeften aanpassen:

Als uw scenario betrekking heeft op...	Geef dan de voorkeur aan...
Grote analytische gegevenssets, kolomquery's, hebben compressie nodig	Parquet
Interoperabiliteit met veel systemen, menselijke leesbaarheid nodig	CSV of JSON
Hiërarchische of geneste gegevensstructuren	JSON of XML
Streaming met hoge frequentie met schemaontwikkeling	Avro met schemaregister

Stap 4: Uw ontwerp valideren

Controleer voordat u het ontwerp implementeert of uw ontwerp deze overwegingen adresseert:

• Het extractietype voldoet aan de latentievereisten. Als dat niet het probleem is, ontvangen downstreamgebruikers verouderde gegevens, wat mogelijk onjuiste zakelijke beslissingen of SLA-schendingen veroorzaakt.

• De benadering is schaalbaar om de verwachte groei van gegevens te beheersen. Als dat niet het gevolg is, kunnen pijplijnen die vandaag werken mislukken of onbetaalbaar traag worden naarmate de gegevensvolumes toenemen.

• De mogelijkheden van het bronsysteem ondersteunen het gekozen patroon. Zo niet, dan mislukt de pijplijn tijdens runtime of vereist dure tijdelijke oplossingen die complexiteit toevoegen.

• Kostenramingen vallen binnen budgetbeperkingen. Zo niet, dan kan de oplossing technisch goed, maar financieel onhoudbaar zijn voor productiegebruik.

• Gegevenskwaliteitscontroles zijn gepland voor de pijplijn. Zo niet, ongeldige of beschadigde gegevens worden doorgegeven aan downstreamsystemen, wat fouten of onjuiste analyses veroorzaakt.

Het framework toepassen: een praktisch voorbeeld

Een e-commerceplatform moet ordergegevens opnemen. Orders worden opgeslagen in een PostgreSQL-database en het bedrijf vereist elk uur rapportage.

Stap 1: vereisten verzamelen:

• Volume: dagelijks 50.000 nieuwe orders, 2 miljoen rijen, 15% jaarlijkse groei.
• Latentie: nieuwheid van één uur acceptabel voor rapportage.
• Bron: PostgreSQL ondersteunt query's op basis van tijdstempels, maar geen systeemeigen CDC.
• Kwaliteit: brongegevens worden gevalideerd bij invoer; minimale reiniging nodig.
• Netwerk: Directe connectiviteit via Azure Private Link.
• Kosten: rekengebruik minimaliseren; opslagkosten zijn secundair.

Stap 2: toewijzen aan extractietype:

Groot volume met betrouwbare tijdstempelkolom en vereiste voor latentie per uur → Incrementele extractie.

Waarom niet de anderen?

• Volledige extractie: 2 miljoen rijen per uur opnieuw verwerken verspilt rekenkracht, aangezien er slechts ongeveer 2.000 bestellingen per uur veranderen.
• Streaming: latentie van één uur rechtvaardigt niet de kosten van een always-on-streaming-infrastructuur.
• CDC: PostgreSQL biedt geen native CDC voor transactielogboeken en de use-case vereist geen tracering van verwijderingen of typen operaties.

Stap 3: selecteer de bestandsindeling:

Gegevens komen terecht in Azure Data Lake Storage voor verwerking → Parquet voor efficiënte kolomopslag. Datum-gepartitioneerde indeling voor incrementele detectie → /landing/orders/year=2025/month=11/day=28/.

Waarom niet de anderen?

• CSV/JSON: Grotere bestandsgrootten, geen compressievoordelen en tragere queryprestaties voor analytische workloads.
• Avro: Beter geschikt voor streaming met schemaontwikkeling; Batchopname heeft geen streaminggeoriënteerde functies nodig.
• XML: Voegt parseringscomplexiteit toe zonder voordelen voor gestructureerde tabellaire ordergegevens.

Stap 4: ontwerp valideren:

• ✓ Uurlijkse incrementele update voldoet aan de latentievereiste van één uur.
• ✓ Het verwerken van alleen veranderingen schaalt efficiënt met de groei.
• ✓ PostgreSQL-kolom order_updated_at maakt incrementele query's mogelijk.
• ✓ Het verwerken van duizenden versus miljoenen rijen vermindert de rekenkosten.

Definitieve beslissing: Incrementele extractie met behulp van de order_updated_at tijdstempelkolom, gepland per uur, landingsgegevens als Parquet-bestanden in Azure Data Lake Storage.

Op basis van deze vereistengestuurde basis bent u klaar om de specifieke hulpprogramma's en laadmethoden te evalueren die uw opnameontwerp implementeren.