Gegevens transformeren

Dit artikel bevat een inleiding en een overzicht van het transformeren van gegevens met Azure Databricks. Het transformeren van gegevens of het voorbereiden van gegevens is een belangrijke stap in alle data engineering-, analyse- en ML-workloads.

De voorbeeldpatronen en aanbevelingen in dit artikel zijn gericht op het werken met lakehouse tables, dat wordt ondersteund door Delta Lake. Omdat Delta Lake de ACID-garanties van een Databricks Lakehouse biedt, kunt u verschillende gedragingen observeren bij het werken met gegevens in andere indelingen of gegevenssystemen.

Databricks raadt aan om gegevens in een lakehouse in een onbewerkte of bijna onbewerkte staat op te nemen en vervolgens transformaties en verrijking toe te passen als een afzonderlijke verwerkingsstap. Dit patroon staat bekend als de medaille-architectuur. Zie Wat is de medaille-lakehouse-architectuur?

Als u weet dat de gegevens die u moet transformeren nog niet in een lakehouse zijn geladen, raadpleegt u Gegevens opnemen in een Databricks Lakehouse. Als u lakehouse-gegevens zoekt om transformaties te schrijven, raadpleegt u Gegevens ontdekken.

Alle transformaties beginnen met het schrijven van een batch- of streamingquery op basis van een gegevensbron. Zie Querygegevens als u niet bekend bent met het uitvoeren van query's op gegevens.

Nadat u getransformeerde gegevens hebt opgeslagen in een Delta-table, kunt u die table gebruiken als functie table voor ML. Zie Functie-engineering en -bediening.

Notitie

Artikelen hier bespreken transformaties in Azure Databricks. Azure Databricks biedt ook ondersteuning voor connections voor veel algemene platformen voor gegevensvoorbereiding. Zie Verbinding maken met gegevensvoorbereidingspartners met behulp van Partner Connect.

Spark-transformaties versus lakehouse-transformaties

Dit artikel is gericht op het definiëren van tranformaties die betrekking hebben op de T in ETL of ELT. Het Apache Spark-verwerkingsmodel maakt ook gebruik van de woordtransformatie op een gerelateerde manier. Kort gezegd: in Apache Spark worden alle bewerkingen gedefinieerd als transformaties of acties.

• Transformaties: voeg enkele verwerkingslogica toe aan het plan. Voorbeelden hiervan zijn het lezen van gegevens, joins, aggregaties en typecasting.
• Acties: verwerkingslogica activeren om een resultaat te evalueren en uit te voeren. Voorbeelden zijn schrijfbewerkingen, het weergeven of bekijken van resultaten, handmatig opslaan in cache of het ophalen van het aantal rijen.

Apache Spark maakt gebruik van een luie uitvoeringsmodel , wat betekent dat geen van de logica die is gedefinieerd door een verzameling bewerkingen wordt geëvalueerd totdat een actie wordt geactiveerd. Dit model heeft een belangrijk gevolg bij het definiëren van gegevensverwerkingspijplijnen: gebruik alleen acties om resultaten weer op te slaan in table-doel.

Omdat acties een verwerkingsknelpunt vormen voor het optimaliseren van logica, heeft Azure Databricks talloze optimalisaties toegevoegd bovenop de optimalisaties die al aanwezig zijn in Apache Spark om een optimale uitvoering van logica te garanderen. Deze optimalisaties beschouwen alle transformaties die door een bepaalde actie tegelijk worden geactiveerd en vinden het optimale plan op basis van de fysieke indeling van de gegevens. Het handmatig opslaan van gegevens in cache of het retourneren van preview-resultaten in productiepijplijnen kan deze optimalisaties onderbreken en leiden tot aanzienlijke toename van de kosten en latentie.

Daarom kunnen we een lakehouse-transformatie definiëren elke verzameling bewerkingen die worden toegepast op een of meer lakehouse-tables die resulteren in een nieuw lakehouse-table. Hoewel transformaties zoals joins en aggregaties afzonderlijk worden besproken, kunt u veel van deze patronen combineren in één verwerkingsstap en de optimalisaties in Azure Databricks vertrouwen om het meest efficiënte plan te vinden.

Wat zijn de verschillen tussen streaming en batchverwerking?

Hoewel streaming en batchverwerking veel van dezelfde syntaxis gebruiken in Azure Databricks, hebben ze elk hun eigen specifieke semantiek.

Met batchverwerking kunt u expliciete instructies definiëren voor het verwerken van een vaste hoeveelheid statische, niet-veranderende gegevens als één bewerking.

Met stroomverwerking kunt u een query definiëren op basis van een niet-gebonden, continu groeiende gegevensset en vervolgens gegevens verwerken in kleine, incrementele batches.

Batchbewerkingen in Azure Databricks maken gebruik van Spark SQL of DataFrames, terwijl stroomverwerking gebruikmaakt van Structured Streaming.

U kunt batch-Apache Spark-opdrachten onderscheiden van Structured Streaming door lees- en schrijfbewerkingen te bekijken, zoals wordt weergegeven in de volgende table:

	Apache Spark	Gestructureerd streamen
Lezen	spark.read.load()	spark.readStream.load()
Schrijven	spark.write.save()	spark.writeStream.start()

Gerealiseerde views voldoen over het algemeen aan garanties voor batchverwerking, hoewel, indien mogelijk, Delta Live Tables wordt gebruikt om resultaten incrementeel te berekenen. De resultaten die worden geretourneerd door een gerealiseerde weergave, zijn altijd gelijk aan batchevaluatie van logica, maar Azure Databricks probeert deze resultaten incrementeel te verwerken wanneer dat mogelijk is.

Streaming tables berekent altijd resultaten incrementeel. Omdat veel streaminggegevensbronnen alleen records gedurende een periode van uren of dagen bewaren, wordt in het verwerkingsmodel dat wordt gebruikt door streaming tables ervan uitgegaan dat elke batch records uit een gegevensbron slechts één keer wordt verwerkt.

Azure Databricks biedt ondersteuning voor het gebruik van SQL voor het schrijven van streamingquery's in de volgende gebruiksscenario's:

• Streaming-tables definiëren in Unity Catalog met behulp van Databricks SQL.
• Broncode definiëren voor Delta Live Tables-pijplijnen.

Notitie

U kunt streaming-tables ook declareren in Delta Live Tables met behulp van Python Structured Streaming-code.

Batchtransformaties

Batch-transformaties worden uitgevoerd op een goed gedefinieerde set van gegevensbestanden op een bepaald moment. Batchtransformaties kunnen eenmalige bewerkingen zijn, maar maken vaak deel uit van geplande taken of pijplijnen die regelmatig worden uitgevoerd om productiesystemen up-to-date te houden.

Incrementele transformaties

Incrementele patronen gaan er over het algemeen van uit dat de gegevensbron alleen aan gegevens toevoegt en een stabiele schemaheeft. De volgende artikelen bevatten details over nuances van incrementele transformaties in tables die worden geüpdatet, verwijderd of waarbij schema wijzigingen optreden:

• API's voor WIJZIGINGEN TOEPASSEN: vereenvoudig het vastleggen van wijzigingen met Delta Live Tables
• Delta Lake-wijzigingenfeed gebruiken in Azure Databricks
• Update Delta Lake tableschema
• Delta table lees- en schrijfbewerkingen

Realtime transformaties

Delta Lake biedt bijna realtime toegang tot grote hoeveelheden gegevens voor alle gebruikers en toepassingen die query's uitvoeren op uw Lakehouse, maar vanwege de overhead met het schrijven van bestanden en metagegevens naar cloudobjectopslag, kan echte realtime latentie niet worden bereikt voor veel workloads die naar Delta Lake-sinks schrijven.

Voor zeer lage latentie streamingtoepassingen raadt Databricks aan om bron- en sinksystemen te kiezen die zijn ontworpen voor realtime workloads zoals Kafka. U kunt Azure Databricks gebruiken om gegevens te verrijken, waaronder aggregaties, joins over stromen en het samenvoegen van streaminggegevens met langzaam veranderende dimensiegegevens die zijn opgeslagen in lakehouse.