Wat is Lakeflow Spark-declaratieve pijplijnen?

Lakeflow Spark Declarative Pipelines (SDP) is een declaratief framework voor het bouwen van batch- en streaminggegevenspijplijnen in SQL en Python. De kernconcepten zijn pipelines, flows, streamingtabellen, gematerialiseerde weergaven en sinks, die samenwerken om gegevens te verwerken met automatische orkestratie en incrementele updates.

Wat is SDP?

Lakeflow Spark-declaratieve pijplijnen is een declaratief framework voor het ontwikkelen en uitvoeren van pijplijnen voor batch- en streaminggegevens in SQL en Python. Lakeflow SDP breidt uit en werkt samen met Apache Spark-declaratieve pijplijnen, terwijl deze wordt uitgevoerd op de voor prestaties geoptimaliseerde Databricks Runtime, en de declaratieve Pijplijn-API flows van Lakeflow Spark maakt gebruik van dezelfde DataFrame-API als Apache Spark en Structured Streaming.

Veelvoorkomende gebruiksvoorbeelden voor SDP zijn:

• Incrementele gegevensopname van bronnen zoals cloudopslag (Amazon S3, Azure ADLS Gen2 en Google Cloud Storage) en berichtbussen (Apache Kafka, Amazon Kinesis, Google Pub/Sub, Azure EventHub en Apache Pulsar).
• Incrementele batch- en streamingtransformaties met stateless en stateful operators.
• Realtime streamverwerking tussen transactionele opslagsystemen zoals berichtenbussen en databases.

Zie Procedureel versus declaratieve gegevensverwerking in Databricks voor meer informatie over declaratieve gegevensverwerking.

Wat zijn de voordelen van SDP?

De declaratieve aard van SDP biedt de volgende voordelen ten opzichte van het ontwikkelen van gegevensprocessen met de Apache Spark en Spark Structured Streaming-API's en het uitvoeren ervan met de Databricks Runtime met behulp van handmatige orkestratie via Lakeflow Jobs.

• Automatische indeling: SDP organiseert de verwerkingsstappen (ook wel 'stromen' genoemd) automatisch om de juiste uitvoeringsvolgorde en het maximale parallelle uitvoeringsniveau voor optimale prestaties te garanderen. Daarnaast proberen pijplijnen automatisch en efficiënt tijdelijke fouten opnieuw. Het proces voor opnieuw proberen begint met de meest gedetailleerde en rendabele eenheid: de Spark-taak. Als het opnieuw proberen op taakniveau mislukt, gaat SDP door met het opnieuw proberen van de stroom en wordt indien nodig de volledige pijplijn geprobeerd.
• Declaratieve verwerking: SDP biedt declaratieve functies die honderden of zelfs duizenden regels met handmatige Spark- en Structured Streaming-code tot slechts enkele regels kunnen verminderen. De SDP AUTO CDC API vereenvoudigt de verwerking van CDC-gebeurtenissen (Change Data Capture) met ondersteuning voor zowel SCD-type 1 als SCD-type 2. Het elimineert de noodzaak van handmatige code voor het afhandelen van out-of-ordergebeurtenissen en vereist geen inzicht in streaming-semantiek of concepten zoals watermerken.
• Incrementele verwerking: SDP biedt een incrementele verwerkingsengine voor gerealiseerde weergaven. Als u deze wilt gebruiken, schrijft u uw transformatielogica met batch-semantiek en verwerkt de engine alleen waar mogelijk nieuwe gegevens en wijzigingen in de gegevensbronnen. Incrementele verwerking vermindert inefficiënte herverwerking wanneer nieuwe gegevens of wijzigingen in de bronnen plaatsvinden en elimineert de noodzaak van handmatige code voor het afhandelen van incrementele verwerking.

Belangrijke concepten

In het onderstaande diagram ziet u de belangrijkste concepten van Lakeflow Spark-declaratieve pijplijnen.

Datasets

Een pijplijn produceert drie typen gegevenssets, elk met verschillende semantiek voor verwerking:

Een streamingtabel is een vorm van beheerde Unity Catalog-tabel die ook een streamingdoel is. Een streamingtabel kan een of meer streamingstromen (Toevoegen, AUTO CDC) bevatten die erin zijn geschreven. U kunt streamingstromen expliciet en afzonderlijk definiëren van de doelstreamingtabel, of impliciet als onderdeel van een definitie van een streamingtabel.

Een gerealiseerde weergave is ook een vorm van beheerde tabel in Unity Catalog en is een batchdoel. Een gematerialiseerde weergave kan een of meer gematerialiseerde weergave-flows bevatten die erin zijn opgenomen. Gerealiseerde weergaven verschillen van streamingtabellen omdat u de stromen altijd impliciet definieert als onderdeel van de gerealiseerde weergavedefinitie.

Zie streamingtabellen en gematerialiseerde weergaven voor details.

Wanneer u weergaven, gematerialiseerde weergaven en streamingtabellen gebruikt

Wanneer u pijplijnquery's implementeert, kiest u het gegevenssettype dat het beste past bij uw use-case.

Overweeg een weergave te gebruiken voor:

• Een grote of complexe query opsplitsen in eenvoudiger te beheren query's.
• Valideer tussenliggende resultaten met behulp van verwachtingen.
• Verlaag de opslag- en rekenkosten voor resultaten die u niet hoeft te behouden. Omdat tabellen worden gematerialiseerd, zijn extra reken- en opslagbronnen vereist.

Overweeg om een gerealiseerde weergave te gebruiken wanneer:

• Meerdere downstreamquery's gebruiken de tabel. Omdat weergaven op aanvraag worden berekend, wordt een weergave telkens opnieuw berekend wanneer er query's worden uitgevoerd.
• Andere pijplijnen, taken of queries gebruiken de tabel. Omdat weergaven niet worden gematerialiseerd, kunnen ze alleen binnen dezelfde pipeline worden gebruikt.
• U wilt de resultaten van een query controleren tijdens de ontwikkeling. Omdat tabellen worden gerealiseerd en kunnen worden opgevraagd buiten de pijplijn, kan het gebruik van tabellen tijdens de ontwikkeling helpen bij het valideren van de juistheid van berekeningen. Na het valideren converteert u query's waarvoor geen materialisatie is vereist in weergaven.

Overweeg het gebruik van een streamingtabel wanneer:

• Een query wordt gedefinieerd op basis van een gegevensbron die continu of incrementeel groeit.
• Queryresultaten moeten incrementeel worden berekend.
• De pijplijn heeft een hoge doorvoer en lage latentie nodig.

Flows

Een stroom is het basisconcept voor gegevensverwerking in SDP dat ondersteuning biedt voor zowel streaming- als batch-semantiek. Een stroom leest gegevens uit een bron, past door de gebruiker gedefinieerde verwerkingslogica toe en schrijft het resultaat naar een doel. SDP deelt hetzelfde type streamingstroom (toevoegen, bijwerken, voltooien) als Spark Structured Streaming. (Op dit moment worden alleen de stromen Toevoegen en Bijwerken weergegeven.) Zie de uitvoermodi in Structured Streaming voor meer informatie.

Lakeflow Spark-declaratieve pijplijnen biedt ook aanvullende stroomtypen:

• AUTO CDC is een unieke streamingstroom in Lakeflow SDP die out-of-order CDC-gebeurtenissen afhandelt en zowel SCD-type 1 als SCD-type 2 ondersteunt. Auto CDC is niet beschikbaar in declaratieve Apache Spark-pijplijnen.
• Gerealiseerde weergave is een batchstroom in SDP die waar mogelijk alleen nieuwe gegevens en wijzigingen in de brontabellen verwerkt.

Zie Incrementeel gegevens laden en verwerken met Lakeflow Spark Declarative Pipelines-stromen voor meer informatie.

Sinks

Een sink is een streamingdoel voor een pijplijn en ondersteunt Delta-tabellen, Apache Kafka-onderwerpen, Azure EventHubs-onderwerpen en aangepaste Python-gegevensbronnen. Een sink kan een of meer streamingstromen (toevoegen, bijwerken) bevatten die erin zijn geschreven.

Zie Sinks in Lakeflow Spark Declarative Pipelines voor meer informatie.

Pipelines

Een pijplijn is de eenheid van ontwikkeling en uitvoering in declaratieve Pijplijnen van Lakeflow Spark en is de container voor de stromen, streamingtabellen, gerealiseerde weergaven en sinks die u definieert. U gebruikt SDP door deze objecten in uw pijplijnbroncode te definiëren en vervolgens de pijplijn uit te voeren. Terwijl uw pijplijn wordt uitgevoerd, worden de afhankelijkheden van uw gedefinieerde objecten geanalyseerd en de volgorde van uitvoering en parallelle uitvoering automatisch ingedeeld.

Zie Wat zijn pijplijnen? voor meer informatie.

U kunt ook zelfstandige gerealiseerde weergaven en streamingtabellen buiten een pijplijn definiëren, waarbij Azure Databricks de pijplijn voor u beheert. Zie Zelfstandige pijplijnen versus Lakeflow Spark-declaratieve pijplijnen om de twee benaderingen te vergelijken.

Gegevensopname

Pijplijnen ondersteunen alle gegevensbronnen die beschikbaar zijn in Azure Databricks. Databricks raadt het gebruik van streamingtabellen aan voor de meeste toepassingen voor data-inname. Voor bestanden in cloud-objectopslag zorgt Auto Loader voor incrementeel en idempotent laden. Voor streaminggegevens kunnen pijplijnen rechtstreeks vanuit berichtenbussen zoals Apache Kafka, Azure Event Hubs, Amazon Kinesis en Google Pub/Sub opnemen. Zie Gegevens laden in pijplijnen.

Gegevenskwaliteit

Verwachtingen zijn optionele componenten voor gegevenssets die gegevens valideren terwijl deze door de pijplijn stromen. U definieert een verwachting als een SQL-booleaanse beperking en geeft aan wat er gebeurt wanneer een record mislukt: waarschuwen, de record verwijderen of de update mislukken. Zie Gegevenskwaliteit beheren met pipelineverwachtingen.

Delta-integratie

Alle tabellen die door pijplijnen worden gemaakt en beheerd, zijn Delta-tabellen. Ze hebben dezelfde garanties als Delta Lake, inclusief ACID-transacties, time travel en schemahandhaving. Pijplijnen voegen extra tabeleigenschappen toe en voeren automatisch onderhoud uit met behulp van voorspellende optimalisatie, inclusief OPTIMIZE en VACUUM bewerkingen. Bekijk wat is Delta Lake in Azure Databricks?

Aanvullende bronnen

• Zelfstudie: Een ETL-pijplijn bouwen met behulp van change data capture
• Wat zijn pijplijnen?
• Beperkingen voor pijplijnen
• Handleiding voor pipeline-ontwikkelaars