Streamingtabellen

Een streamingtabel is een Delta-tabel met extra ondersteuning voor streaming of incrementele gegevensverwerking. Een streamingtabel kan worden gericht op een of meer stromen in een pijplijn.

Zie Wat zijn pijplijnen? voor richtlijnen over wanneer u streamingtabellen gebruikt in plaats van gematerialiseerde weergaven of weergaven.

Streamingtabellen zijn een goede keuze voor gegevensopname om de volgende redenen:

• Elke invoerrij wordt slechts één keer verwerkt, waarmee het overgrote deel van de gegevensinvoertaken wordt gemodelleerd (dat wil zeggen door rijen aan een tabel toe te voegen of bij te werken).
• Ze kunnen grote hoeveelheden alleen toevoegbare gegevens verwerken.

Streamingtabellen zijn ook een goede keuze voor streamingtransformaties met lage latentie, omdat ze kunnen redeneren over rijen en tijdvensters, grote hoeveelheden gegevens kunnen verwerken en verwerking met lage latentie kunnen bieden.

In het volgende diagram ziet u hoe stromen uit streamingbronnen lezen en incrementeel naar een streamingtabel in een pijplijn schrijven.

Bij elke update lezen de stromen die zijn gekoppeld aan een streamingtabel de gewijzigde informatie in een streamingbron en voegen nieuwe gegevens toe aan die tabel.

Streamingtabellen zijn eigendom van en worden bijgewerkt door één datapijplijn. U definieert expliciet streamingtabellen in de broncode van de pijplijn. Tabellen die zijn gedefinieerd door een pijplijn, kunnen niet worden gewijzigd of bijgewerkt door een andere pijplijn. U kunt meerdere stromen definiëren die moeten worden toegevoegd aan één streamingtabel.

Azure Databricks maakt interne tabellen ter ondersteuning van verwerking van streamingtabellen. Deze tabellen worden weergegeven in system.information_schema.tables, maar zijn niet zichtbaar in Catalog Explorer of andere gebruikersinterface van de werkruimte.

Zie Incrementeel gegevens laden en verwerken met Lakeflow-pijplijnstromen voor meer informatie over stromen.

Streamingtabellen voor gegevensinvoer

Streamingtabellen zijn ontworpen voor gegevensbronnen die alleen toevoegingen toelaten en verwerken invoer slechts één keer. Dit maakt ze geschikt voor opnameworkloads waarbij gegevens continu binnenkomen en betrouwbaar moeten worden vastgelegd zonder bestaande records opnieuw te verwerken. Azure Databricks ondersteunt het opnemen van gegevens in streamingtabellen vanuit cloudobjectopslag (met behulp van Auto Loader) en vanuit streamingberichtbussen zoals Apache Kafka, Azure Event Hubs en Google Pub/Sub. Voor handleidingen en codevoorbeelden voor het opnemen van gegevens, zie Gegevens laden in pijplijnen.

Het volgende diagram illustreert hoe append-only streaming-tabellen werken.

Een rij die al is toegevoegd aan een streamingtabel, zal niet opnieuw worden uitgevraagd bij latere updates van de pijplijn. Als u de query wijzigt (bijvoorbeeld van SELECT LOWER (name) naar SELECT UPPER (name)), worden bestaande rijen niet bijgewerkt naar hoofdletters, maar zullen nieuwe rijen in hoofdletters zijn. U kunt een volledige vernieuwingsoperatie starten om alle eerdere gegevens opnieuw op te halen uit de brontabel, en zo alle rijen in de streamingtabel bij te werken.

Streamingtabellen en streaming met lage latentie

Streamingtabellen zijn ontworpen voor streaming met lage latentie over gebonden toestand. Streamingtabellen maken gebruik van controlepuntbeheer, waardoor ze geschikt zijn voor streaming met lage latentie. Ze verwachten echter streams die van nature begrensd zijn of voorzien van een watermerk.

Een natuurlijk gebonden stroom wordt geproduceerd door een streaminggegevensbron met een goed gedefinieerd begin en einde. Een voorbeeld van een natuurlijk gebonden stroom is het lezen van gegevens uit een map met bestanden waarin geen nieuwe bestanden worden toegevoegd nadat een eerste batch bestanden is geplaatst. De stroom wordt beschouwd als gebonden omdat het aantal bestanden eindig is en de stroom eindigt nadat alle bestanden zijn verwerkt.

U kunt ook een watermerk gebruiken om een stroom te binden. Een watermerk in Structured Streaming is een mechanisme waarmee late gegevens kunnen worden verwerkt door op te geven hoe lang het systeem moet wachten op vertraagde gebeurtenissen voordat het tijdvenster als voltooid wordt overwogen. Een niet-gebonden stroom die geen watermerk heeft, kan ertoe leiden dat een pijplijn mislukt vanwege geheugendruk.

Voor operationele workloads die de laagst mogelijke latentie nodig hebben, kunt u de pijplijn in realtime uitvoeren om records te verwerken met een end-to-end latentie van sub seconde.

Voor meer informatie, zie:

• Realtimemodus gebruiken in Lakeflow-pijplijnen
• Optimaliseer statusvolle verwerking met watermarks

Beperkingen voor streaming-tabellen

Streamingtabellen hebben de volgende beperkingen:

• Beperkte evolutie: U kunt de query wijzigen zonder de volledige gegevensset opnieuw te compileren. Zonder een volledige vernieuwing ziet een streamingtabel slechts één keer elke rij, zodat verschillende query's verschillende rijen hebben verwerkt. Als u bijvoorbeeld UPPER() toevoegt aan een veld in de query, worden alleen rijen die na de wijziging worden verwerkt, in hoofdletters weergegeven. Dit betekent dat u rekening moet houden met alle eerdere versies van de query die worden uitgevoerd op uw gegevensset. Voor het opnieuw verwerken van bestaande rijen die vóór de wijziging zijn verwerkt, is een volledige vernieuwing vereist.
• Statusbeheer: Streamingtabellen hebben een lage latentie en vereisen streams die natuurlijk begrensd zijn of afgebakend zijn met een watermark. Zie Stateful verwerking optimaliseren met watermerken voor meer informatie.
• Joins worden niet herberekend: Joins in streamingtabellen worden niet herberekend wanneer dimensies veranderen. Dit kenmerk kan goed zijn voor "snel-maar-fout"-scenario's. Als u wilt dat uw weergave altijd juist is, kunt u een gerealiseerde weergave gebruiken. Gerealiseerde weergaven zijn altijd correct omdat ze joins automatisch opnieuw compileren wanneer dimensies veranderen. Voor meer informatie, zie gerealiseerde weergaven. Zie Stream-statische joins voor een voorbeeld van het samenvoegen van een stream naar een statische dimensietabel.
• Geen CLONE ondersteuning: streaming-tabellen kunnen niet worden gebruikt als bron of doel van een diepe of oppervlakkige kloon. Zie Beperkingen voor andere niet-ondersteunde opdrachten.
• REFRESH vereist recht om de pijplijn te bekijken: Als u de pijplijn wilt bekijken die ten grondslag ligt aan een streamingtabel, heeft een niet-admin-gebruiker naast machtigingen voor de pijplijn ook het recht REFRESH op de streamingtabel nodig. Zie Wie een pijplijn en de uitvoer kan bekijken?

Aanvullende bronnen

• Gegevens laden in pijplijnen
• Volledig vernieuwen voor streamingtabellen