Dela via


Strömmande tabeller

En strömningstabell är en Delta-tabell med ytterligare stöd för direktuppspelning eller inkrementell databearbetning. En strömningstabell kan riktas mot en eller flera flöden i en ETL-pipeline.

Strömmande tabeller är ett bra val för datainmatning av följande skäl:

  • Varje indatarad hanteras bara en gång, vilket modellerar de allra flesta inmatningsarbetsbelastningar (dvs. genom att lägga till eller utöka rader till en tabell).
  • De kan hantera stora mängder data som endast kan läggas till.

Strömningstabeller är också ett bra alternativ för strömningstransformer med låg latens av följande skäl:

  • Resonera över rader och tidsintervall
  • Hantera stora mängder data
  • Låg svarstid

Följande diagram visar hur strömmande tabeller fungerar.

diagram som visar hur strömmande tabeller fungerar

Vid varje uppdatering läser de flöden som är associerade med en strömningstabell den ändrade informationen i en strömmande källa och lägger till ny information i tabellen.

Strömmande tabeller definieras och uppdateras av en enda pipeline. Du definierar explicit strömmande tabeller i pipelinens källkod. Tabeller som definieras av en pipeline kan inte ändras eller uppdateras av någon annan pipeline. Du kan definiera flera flöden för att lägga till i en enda direktuppspelningstabell.

Anmärkning

När du skapar en strömningstabell utanför en pipeline med Databricks SQL skapar Azure Databricks en pipeline som används för att uppdatera tabellen. Du kan se pipelinen genom att välja Jobb & Pipelines i det vänstra navigeringsfältet i din arbetsyta. Du kan lägga till kolumnen Pipelinetyp i vyn. Strömmande tabeller som skapats i Lakeflow Deklarativa Pipelines har en typ av ETL. Strömmande tabeller som skapats i Databricks SQL har en typ av MV/ST.

För mer information om flöden, se Läsa in och bearbeta data stegvis med Lakeflow-deklarativa pipelines-flöden.

Strömmande tabeller för inmatning

Strömmande tabeller är utformade för datakällor där data endast läggs till och bearbetar indatan endast en gång.

I följande exempel visas hur du använder en strömmande tabell för att mata in nya filer från molnlagring.

python

from pyspark import pipelines as dp

# create a streaming table
@dp.table
def customers_bronze():
  return (
    spark.readStream.format("cloudFiles")
     .option("cloudFiles.format", "json")
     .option("cloudFiles.inferColumnTypes", "true")
     .load("/Volumes/path/to/files")
  )

När du använder spark.readStream funktionen i en datamängdsdefinition gör det att Lakeflow Deklarativa pipelines behandlar datamängden som en ström, och den tabell som skapas är en strömmande tabell.

SQL

-- create a streaming table
CREATE OR REFRESH STREAMING TABLE customers_bronze
AS SELECT * FROM STREAM read_files(
  "/volumes/path/to/files",
  format => "json"
);

Mer information om hur du läser in data i en strömmande tabell finns i Läsa in data med Deklarativa pipelines för Lakeflow.

Följande diagram visar hur strömmande tabeller som enbart tillåter tillägg fungerar.

diagram som visar hur direktuppspelningstabeller med endast tillägg fungerar

En rad som redan har lagts till i en strömmande tabell kommer inte att efterfrågas igen med senare uppdateringar av pipelinen. Om du ändrar sökfrågan (till exempel från SELECT LOWER (name) till SELECT UPPER (name)) kommer befintliga rader inte att uppdateras till versaler, men nya rader kommer att bli versaler. Du kan utlösa en fullständig uppdatering för att hämta alla tidigare data från källtabellen för att uppdatera alla rader i den strömmande tabellen.

Streamingtabeller och streaming med låg fördröjning

Strömningstabeller är utformade för strömning med låg latens över begränsat tillstånd. Strömningstabeller använder kontrollpunktshantering, vilket gör dem väl lämpade för strömning med låg fördröjning. De förväntar sig dock strömmar som är naturligt avgränsade eller avgränsade med en vattenstämpel.

En naturligt avgränsad dataström skapas av en strömmande datakälla som har en väldefinierad start och slut. Ett exempel på en naturligt avgränsad dataström är att läsa data från en katalog med filer där inga nya filer läggs till efter att en första batch med filer har placerats. Strömmen anses vara begränsad eftersom antalet filer är begränsat och sedan avslutas strömmen när alla filer har bearbetats.

Du kan också använda en vattenstämpel för att begränsa en datastream. En vattenstämpel i Spark Structured Streaming är en mekanism som hjälper till att hantera sena data genom att ange hur länge systemet ska vänta på fördröjda händelser innan tidsfönstret betraktas som slutfört. En obunden ström som inte har en vattenstämpel kan orsaka att en pipeline misslyckas på grund av minnesbelastning.

Mer information om tillståndskänslig dataströmbearbetning finns i Optimera tillståndskänslig bearbetning i Lakeflow Deklarativa Pipelines med vattenstämplar.

Strömögonblicksbildanslutningar

Strömögonblickskopplingar är kopplingar mellan en ström och en dimension som ögonblicksbilderas när strömmar startas. Dessa kopplingar omberäknas inte om dimensionen ändras när strömmen har startats, eftersom dimensionstabellen behandlas som en ögonblicksbild i tid, och ändringar i dimensionstabellen efter att strömmen startar återspeglas inte om du inte läser in eller uppdaterar dimensionstabellen igen. Det här är ett rimligt beteende om du kan acceptera små avvikelser i en koppling. Till exempel är en ungefärlig koppling acceptabel när antalet transaktioner är många storleksordningar större än antalet kunder.

I följande kodexempel förenar vi en dimensionstabell, kunder, med två rader från en ständigt ökande datamängd, transaktioner. Vi materialiserar en koppling mellan dessa två datauppsättningar i en tabell med namnet sales_report. Observera att om en extern process uppdaterar kundtabellen genom att lägga till en ny rad (customer_id=3, name=Zoya) kommer den nya raden INTE att finnas i kopplingen eftersom den statiska dimensionstabellen ögonblicksbilderades när strömmar startades.

from pyspark import pipelines as dp

@dp.temporary_view
# assume this table contains an append-only stream of rows about transactions
# (customer_id=1, value=100)
# (customer_id=2, value=150)
# (customer_id=3, value=299)
# ... <and so on> ...
def v_transactions():
  return spark.readStream.table("transactions")

# assume this table contains only these two rows about customers
# (customer_id=1, name=Bilal)
# (customer_id=2, name=Olga)
@dp.temporary_view
def v_customers():
  return spark.read.table("customers")

@dp.table
def sales_report():
  facts = spark.readStream.table("v_transactions")
  dims = spark.read.table("v_customers")

  return facts.join(dims, on="customer_id", how="inner")

Begränsningar för strömmande tabeller

Strömmande tabeller har följande begränsningar:

  • Begränsad utveckling: Du kan ändra frågan utan att omberäkna hela datamängden. Utan en fullständig uppdatering ser en strömmande tabell bara varje rad en gång, så olika frågor har bearbetat olika rader. Om du till exempel lägger till UPPER() i ett fält i frågan, kommer bara rader som bearbetas efter ändringen att vara skrivna med stora bokstäver. Det innebär att du måste vara medveten om alla tidigare versioner av frågan som körs på din datauppsättning. För att bearbeta befintliga rader som bearbetades före ändringen krävs en fullständig uppdatering.
  • Tillståndshantering: Strömningstabeller har låg latens, så du måste se till att strömmarna de använder är naturligt avgränsade eller avgränsade med vattenmärke. Mer information finns om att optimera tillståndskänslig bearbetning i Lakeflow deklarativa pipelines med vattenstämplar.
  • Kopplingar beräknas inte om: Kopplingar i strömmande tabeller beräknas inte om när dimensionerna ändras. Den här egenskapen kan vara bra för "snabba men fel"-scenarier. Om du vill att vyn alltid ska vara korrekt kanske du vill använda en materialiserad vy. Materialiserade vyer är alltid korrekta eftersom de automatiskt omkomplerar kopplingar när dimensionerna ändras. Mer information finns i Materialiserade vyer.