Hantera lakehouse-data med synkroniserade tabeller

Med synkroniserade tabeller kan du hantera lakehouse-data via Lakebase Postgres. Unity Catalog-tabeller synkroniseras med Postgres så att program kan fråga lakehouse-data direkt med låg svarstid. Den här processen kallas ofta omvänd ETL. lakehouse är optimerat för analys och berikning, medan Lakebase är utformat för operativa arbetsbelastningar som kräver snabba sökningar och transaktionskonsekvens.

Arkitekturdiagram som visar dataflöde från lakehouse till Lakebase till program

Vad är synkroniserade tabeller?

Med synkroniserade tabeller kan du hantera analysdata från Unity Catalog via Lakebase Postgres, vilket gör dem tillgängliga för program som behöver frågor med låg svarstid och fullständiga ACID-transaktioner. De överbryggar klyftan mellan analytisk lagring och driftsystem genom att hålla dina data redo att användas i realtidsprogram.

Källor som stöds

Synkroniserade tabeller stöder följande Unity Catalog-källtyper:

  • Hanterade och externa Delta-tabeller
  • Administrerade och externa isbergstabeller
  • Vyer och materialiserade vyer

Så här fungerar det

Databricks-synkroniserade tabeller skapar en hanterad kopia av dina Unity Catalog-data i Lakebase. När du skapar en synkroniserad tabell får du:

  1. En synkroniserad tabell i Unity Catalog som refererar till synkroniseringspipelinen
  2. En Postgres-tabell i Lakebase (skrivskyddad, kan frågor ställas mot den av dina program)

Diagram som visar relationen med tre tabeller i synkroniserade tabeller

Du kan till exempel synkronisera guldtabeller, konstruerade funktioner eller ML-utdata från analytics.gold.user_profiles till en ny synkroniserad tabell analytics.gold.user_profiles_synced. I Postgres blir schemanamnet för Unity Catalog postgres-schemanamnet, så det här visas som gold.user_profiles_synced:

SELECT * FROM gold.user_profiles_synced WHERE user_id = 12345;

Program ansluter med postgres-standarddrivrutiner och frågar efter synkroniserade data tillsammans med sitt eget drifttillstånd.

Synkroniseringspipelines använder hanterade Lakeflow-pipelines för att kontinuerligt uppdatera både den synkroniserade tabellen i Unity Catalog och Postgres-tabellen med ändringar från källtabellen. Varje synkronisering kan använda upp till 16 anslutningar till din Lakebase-databas.

Lakebase Postgres stöder upp till 1 000 samtidiga anslutningar med transaktionsgarantier, så att program kan läsa berikade data samtidigt som de hanterar infogningar, uppdateringar och borttagningar i samma databas.

Varning

Även om det är möjligt att ändra en synkroniserad tabell direkt i Postgres rekommenderar Azure Databricks att du endast kör läsfrågor för att skydda dataintegriteten med källan. Åtgärder som stöds i synkroniserade tabeller finns i Åtgärder som tillåts för synkroniserade tabeller i Postgres.

Accelererad synkronisering med LTAP Direct Writes

LTAP Direct Writes är en beta-funktion i LTAP-arkitekturen som snabbar upp stora belastningar. Den är avstängd som standard och du väljer per synkad tabell genom att välja LTAP Direct Writes under Synkroniseringsinställningar i dialogen Skapa synkad tabell . När den är aktiverad skriver den data direkt till lagringslagret som stöder din Lakebase-gren istället för att routa bulkskrivningen genom den levande beräkningsendpointen, så att lastarna blir klara snabbare och inte lägger till frågebelastning till endpointen medan de körs.

Vad LTAP Direct Writes accelererar beror på synkroniseringsläget:

  • Alla lägen: Den initiala laddningen. Varje synkroniserad tabell börjar med att ladda en fullständig kopia av källkoden, och den första laddningen använder LTAP Direct Writes.
  • Snapshot: Vid varje efterföljande synkronisering, eftersom Snapshot-läget kör en fullständig uppdatering varje gång.
  • Utlöst och kontinuerligt: Endast den initiala laddningen. Senare uppdateringar tillämpas inkrementellt via Change Data Feed, inte som massinläsningar.

Anmärkning

LTAP Direct Writes stöds för Lakebase-projekt som kör Postgres 16, 17 eller 18. Du väljer den när du skapar en synkroniserad tabell, så du kan inte lägga till den i en befintlig synkad tabell. För att använda LTAP Direct Writes med en befintlig synkad tabell, ta bort den synkade tabellen och skapa en ny.

Synkroniseringslägen

Välj rätt synkroniseringsläge baserat på dina programbehov:

Läge Beskrivning När det bör användas Prestanda
Snapshot Engångskopia av alla data Källan ändrar >10 % av raderna per cykel 10 x effektivare om du >ändrar 10% av källdata
Utlöst Schemalagda uppdateringar som körs på begäran eller med intervall Källrader ändras på en känd takt. Infogningar, uppdateringar och borttagningar sprids varje uppdatering. Bra balans mellan kostnad och fördröjning. Dyrt om du kör <intervall på 5 minuter
Kontinuerlig Realtidsströmning med sekunder av svarstid Ändringar måste visas i Lakebase nästan i realtid Lägsta fördröjning, högsta kostnad. Minsta intervall på 15 sekunder

I dialogen Skapa synkad tabell är Snapshot och Triggered båda On-demand-synkroniseringslägen , tillgängliga under Avancerade inställningar, medan Kontinuerligt är ett separat läge.

Källkravet beror på synkroniseringsläget:

  • Snapshot kopierar all data vid varje synk, så källan behöver bara stödja SELECT *.
  • Triggered och Continuous tillämpar ändringar på radnivå stegvis, så källan måste tillhandahålla ett dataflöde för ändringar. Aktivera skrivtidsändringsdataflödet på källan, eller använd automatiskt ändringsdataflöde. Om en Triggered- eller Continuous-källa saknar ändringsdataflöde visar gränssnittet en varning med det exakta kommandot ALTER TABLE som ska köras.

Automatiskt ändringsdataflöde beräknar radnivåändringar vid lästid istället för att kräva skrivtidsändringsdataflöde på källkoden. Detta innebär att fler källtyper, inklusive Apache Iceberg-tabeller, kan synkroniseras i Triggered- eller Continuous-läge. För de källtyper som automatiskt ändringsdataflöde stödjer, se dokumentationen för automatisk ändring av dataflöde .

Exempel på användningsfall

Du kan använda synkroniserade tabeller för användningsfall för dataservering, till exempel:

  • Personanpassningsmotorer som hanterar nya användarprofiler till Databricks-appar
  • Program som hanterar modellförutsägelser eller funktionsvärden som beräknas i lakehouse
  • Kundriktade instrumentpaneler som hanterar KPI:er i realtid
  • Tjänster för bedrägeriidentifiering som ger riskpoäng för omedelbara åtgärder
  • Supportverktyg som hanterar berikade kundposter från lakehouse-data

Skapa en synkroniserad tabell

Förutsättningar

Du behöver:

  • En Databricks-arbetsyta med Lakebase aktiverat.
  • Ett Lakebase-projekt (se Skapa ett projekt).
  • En Unity Catalog-tabell som ska synkroniseras.
  • Behörigheter för att skapa synkroniserade tabeller. Du behöver USE_SCHEMA och CREATE_TABLE på alla scheman som du använder. För att ge dessa privilegier, se Hantera privilegier i Unity Catalog.

För Triggered eller Continuous lägen måste källan tillhandahålla ett ändringsdataflöde. Antingen aktivera äldre ändringsdataflöde i en berättigad källtabell i Delta Lake, eller använd automatiskt ändringsdataflöde för källor som Apache Iceberg-tabeller.

För att aktivera skrivtidsändringsdataflöde på en Delta-källtabell, kör:

ALTER TABLE your_catalog.your_schema.your_table
SET TBLPROPERTIES (delta.enableChangeDataFeed = true)

Information om kapacitetsplanering och datatypskompatibilitet finns i Datatyper och kompatibilitet och Kapacitetsplanering.

Användargränssnitt (UI)

  1. I Lakehouse, gå till Katalog i arbetsytans sidofält och välj den Unity-katalogtabell du vill synka.

    Katalogutforskaren som visar en vald tabell

  2. Klicka på Skapa>synkroniserad tabell från tabellinformationsvyn.

    Listrutan Skapa knapp som visar alternativet Synkroniserad tabell

  3. I dialogen Skapa synkad tabell , konfigurera följande avsnitt och klicka sedan på Skapa:

    Destination

    • Namn: Välj katalog och schema för den synkroniserade tabellen och ange sedan ett tabellnamn. Detta skapar både en synkroniserad Unity Catalog-tabell och en Postgres-tabell som du kan fråga efter. Katalog- och schemalistorna inkluderar endast Unity Catalog-scheman där du har USE_SCHEMA- och CREATE_TABLE-privilegier. Om du inte ser något schema som du förväntar dig bekräftar du dina behörigheter med katalogadministratören.
    • Lakebase Postgres Database: Ange Databastyp till Autoscaling och välj sedan ditt projekt, din gren och din Postgres-databas.

    Synkroniseringsinställningar

    • Synkroniseringsläge: Välj On-demand eller Kontinuerligt. För På begäran öppnar du Avancerade inställningar och väljer Ögonblicksbild eller Utlöst. Se synkroniseringslägen för vägledning.

    Pipeline-inställningar

    • Pipeline: Välj Create new för att skapa en pipeline för denna synkroniserade tabell, eller Använd befintliga för att återanvända en.
    • Serverless usage policy: (Valfritt) Välj en serverless usage policy för synkroniseringspipelinen.

    Schema

    • Primärnyckel: Verifiera primärnyckeln (vanligtvis auto-upptäckt). Låt Unik vara vald om varje primärnyckelvärde är unikt i källan. Om primärnyckelvärden kan upprepas, avmarkera Unik och sätt en tidsserienyckel.

      Viktigt!

      Kolumner i primärnyckeln kan inte vara null i den synkroniserade tabellen. Rader med null-värden i primärnyckelkolumner undantas från synkroniseringen.

    • Tidsserienyckel: (Valfritt) När primärnyckelvärden kan upprepas i källkoden, välj en kolumn för att konfigurera deduplicering. Den synkroniserade tabellen innehåller då endast raden med det senaste tidsserienyckelvärdet för varje primärnyckel. Information om felläget utan en tidsserienyckel finns i Duplicera nycklar.

    • Anpassa kolumntyper: (Valfritt) Ange hur källkolumner ska mappas till Postgres-datatyper. Se Anpassade typmappningar.

    Om du valde Utlöst eller Kontinuerlig och inte har aktiverat ändringsdataflöde än, visas en varning med det exakta kommandot som du ska köra. Information om kompatibilitetsfrågor för datatyper finns i Datatyper och kompatibilitet.

  4. Övervaka den synkroniserade tabellen i katalogen. Fliken Översikt visar synkroniseringsstatus, konfiguration, pipelinestatus och tidsstämpel för senaste synkronisering. Använd Synkronisera nu för manuell uppdatering.

CLI

databricks postgres create-synced-table my-catalog.sales.orders \
  --json '{
    "spec": {
      "source_table_full_name": "main.sales.orders",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["order_id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true
    }
  }'

Positionsargumentet SYNCED_TABLE_ID använder formatet catalog.schema.table. I Postgres skapas tabellen {table} i schemat {schema}, inuti den databas som du angav med postgres_database (här, mydb). Kommandot väntar på att åtgärden ska slutföras som standard. Alla tillgängliga alternativ finns i databricks postgres create-synced-table.

Python SDK

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.postgres import (
    SyncedTable,
    SyncedTableSyncedTableSpec,
    SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy,
)

w = WorkspaceClient()

synced_table = w.postgres.create_synced_table(
    synced_table=SyncedTable(spec=SyncedTableSyncedTableSpec(
        source_table_full_name="main.sales.orders",
        branch="projects/my-project/branches/production",
        primary_key_columns=["order_id"],
        scheduling_policy=SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy.SNAPSHOT,
        postgres_database="mydb",
        create_database_objects_if_missing=True,
    )),
    synced_table_id="my-catalog.sales.orders",
).wait()

print(f"Synced table created: {synced_table.name}")

synced_table_id Använder formatet catalog.schema.table och blir det synkroniserade tabellnamnet för Unity Catalog. I Postgres skapas tabellen {table} i schemat {schema}, inuti den databas som du angav med postgres_database (här, mydb).

Java SDK

import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.service.postgres.*;
import java.util.List;

WorkspaceClient w = new WorkspaceClient();

SyncedTable syncedTable = w.postgres().createSyncedTable(
    new CreateSyncedTableRequest()
        .setSyncedTableId("my-catalog.sales.orders")
        .setSyncedTable(new SyncedTable()
            .setSpec(new SyncedTableSyncedTableSpec()
                .setSourceTableFullName("main.sales.orders")
                .setBranch("projects/my-project/branches/production")
                .setPrimaryKeyColumns(List.of("order_id"))
                .setSchedulingPolicy(SyncedTableSyncedTableSpecSyncedTableSchedulingPolicy.SNAPSHOT)
                .setPostgresDatabase("mydb")
                .setCreateDatabaseObjectsIfMissing(true))))
    .waitForCompletion();

System.out.println("Synced table created: " + syncedTable.getName());

lockig

curl -X POST "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables?synced_table_id=my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "source_table_full_name": "main.sales.orders",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["order_id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true
    }
  }'

Detta returnerar en tidskrävande åtgärd. Kontrollera det returnerade name-fältet tills done: true. Se Tidskrävande åtgärder. Autentiseringskonfiguration finns i Autentisering.

Schemalägga eller utlösa efterföljande synkroniseringar

Den första "snapshoten" körs automatiskt vid skapandet. För Snapshot-läge och Trigger-läge måste efterföljande synkroniseringar utlösas explicit. Kontinuerligt läge är självhanterande.

Pipelineuppgift för synkronisering av databastabell

Pipelineaktiviteten Databastabellsynkronisering i Lakeflow-jobb kör en synkroniserad tabells pipeline som ett arbetsflödessteg. Konfigurera jobbet med en tabelluppdateringsutlösare eller ett schema.

Utlösare för källtabelluppdateringar

Jobbet utlöses när den Unity Catalog-källtabellen uppdateras. I Triggad läge tillämpas endast nya ändringar stegvis, vilket ger uppdatering i nära realtid utan kostnaden för Kontinuerligt läge.

  1. På arbetsytan klickar du på Arbetsflöden-ikonen.Jobb och pipelines i sidofältet.
  2. Klicka på Skapa jobb eller öppna ett befintligt jobb.
  3. På fliken Uppgifter klickar du på + Lägg till en annan aktivitetstyp.
  4. Under Inmatning och transformering väljer du Pipeline för databastabellsynkronisering.
  5. I fältet Pipeline väljer du den pipeline som är associerad med den synkroniserade tabellen.
  6. Under Scheman och utlösare klickar du på Lägg till utlösare.
  7. Välj Tabelluppdatering som utlösartyp.
  8. Under Tabeller väljer du den unity catalog-källtabell som ska övervakas.
  9. Klicka på Spara.

Aktivera på ett schema

Kör synkroniseringen med en fast takt. Passar bra för läget Ögonblicksbild , där en hel uppdatering varje natt eller vecka vanligtvis är det mest effektiva mönstret.

  1. Följ steg 1–5 ovan för att lägga till en Database Table Sync pipeline-uppgift i ett jobb.
  2. Under Scheman och utlösare klickar du på Lägg till utlösare.
  3. Välj Schemalagd som utlösartyp.
  4. Ange cron-schemat och tidszonen och klicka sedan på Spara.

Kontrollera synkroniseringsstatus

Så här kontrollerar du aktuellt tillstånd och senaste synkroniseringstid för en synkroniserad tabell:

Anmärkning

Under en synkronisering utför pipelinen all sin databehandling medan den rapporterar händelsen INITIALIZING . En stor synk kan rapportera INITIALIZING för hela körningen. Detta är väntat och betyder inte att pipelineen har fastnat.

Användargränssnitt (UI)

I Katalog navigerar du till den synkroniserade tabellen och väljer fliken Översikt . Den visar aktuellt synkroniseringstillstånd, pipelinestatus och tidsstämpel för senaste synkronisering.

Python SDK

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

table = w.postgres.get_synced_table("synced_tables/my-catalog.sales.orders")
print(f"State: {table.status.detailed_state}")
print(f"Last sync: {table.status.last_sync_time}")
print(f"Message: {table.status.message}")

Java SDK

import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.service.postgres.SyncedTable;

WorkspaceClient w = new WorkspaceClient();

SyncedTable table = w.postgres().getSyncedTable("synced_tables/my-catalog.sales.orders");
System.out.println("State: " + table.getStatus().getDetailedState());
System.out.println("Last sync: " + table.getStatus().getLastSyncTime());
System.out.println("Message: " + table.getStatus().getMessage());

lockig

curl "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables/my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Datatyper och kompatibilitet

Unity Catalog-datatyper mappas till Postgres-typer när du skapar synkroniserade tabeller. Komplexa typer (ARRAY, MAP, STRUCT) lagras som JSONB i Postgres.

Källkolumntyp Postgres-kolumntyp
BIGINT BIGINT
BINARY BYTEA
Boolean Boolean
DATE DATE
DECIMAL(p,s) NUMERISK
Dubbel Dubbel precision
FLOAT Äkta
INT INTEGER
INTERVAL INTERVAL
SMALLINT SMALLINT
STRING Textmeddelande
TIMESTAMP TIDSSTÄMPEL MED TIDSZON
TIMESTAMP_NTZ TIDSSTÄMPEL UTAN TIDSZON
tinyint SMALLINT
ARRAY-elementtyp<> JSONB
KARTA<nyckeltyp,värdetyp> JSONB
STRUCT<fältNamn:fältTyp[, ...]> JSONB

Anmärkning

Typerna GEOGRAPHY, GEOMETRY, VARIANT och OBJECT stöds inte.

Anpassade typmappningar

När du skapar en synkroniserad tabell kan du åsidosätta standardmappningen för Delta-till-Postgres-typ för specifika kolumner med type_overrides.

Anmärkning

vector- och halfvec-typerna kräver ett vektortillägg i destinationsdatabasen. Att skapa den synkroniserade tabellen installerar inte tillägg, så installera en innan du skapar den synkade tabellen. Använd lakebase_vector, som lägger till ANN-vektorsökning via Lakebase Search och installerar pgvector som beroende:

CREATE EXTENSION IF NOT EXISTS lakebase_vector CASCADE;

För att använda vector och halfvec typerna utan Lakebase Search, installera pgvector själv med CREATE EXTENSION IF NOT EXISTS vector;. Typen varchar kräver ingen förlängning.

Källkolumntyp Postgrestyp Size Definition (pg_type) Exempel på användningsfall
ARRAY<FLOAT>, ARRAY<DOUBLE> vector(n) Inbäddningsdimension PG_SPECIFIC_TYPE_VECTOR Lagra embeddings som en vector istället för JSONB, redo för likhetssökning med lakebase_vector
ARRAY<FLOAT>, ARRAY<DOUBLE> halfvec(n) Inbäddningsdimension PG_SPECIFIC_TYPE_HALFVEC Halvprecisionsinbäddningar vid ungefär hälften av lagringskapaciteten vector
STRING varchar(n) Maxlängden PG_SPECIFIC_TYPE_VARCHAR Mappa till en längdbegränsad varchar i stället för standarden TEXT

Anmärkning

size krävs för varje typ i denna tabell. Giltiga intervall är:

  • vector och halfvec: 1 till 16 000, antalet inbäddningsdimensioner.
  • varchar: 1 till 10 485 760, den maximala teckenlängden.

Anpassade typmappningar kan konfigureras via API, CLI och Databricks SDK:er när du skapar en synkroniserad tabell.

För en källtabell main.docs.chunks(id BIGINT, title STRING, embedding ARRAY<FLOAT>) mappar följande title till varchar(256) och embedding till vector(1024) i Postgres:

databricks postgres create-synced-table main.docs.chunks_pg \
  --json '{
    "spec": {
      "source_table_full_name": "main.docs.chunks",
      "branch": "projects/my-project/branches/production",
      "primary_key_columns": ["id"],
      "scheduling_policy": "SNAPSHOT",
      "postgres_database": "mydb",
      "create_database_objects_if_missing": true,
      "type_overrides": [
        { "column_name": "title", "pg_type": "PG_SPECIFIC_TYPE_VARCHAR", "size": 256 },
        { "column_name": "embedding", "pg_type": "PG_SPECIFIC_TYPE_VECTOR", "size": 1024 }
      ]
    }
  }'

Utan åsidosättningen skulle title vara TEXT och embedding skulle vara JSONB.

Hantera ogiltiga tecken

Vissa tecken som null byte (0x00) tillåts i Kolumnerna Unity Catalog STRING, ARRAY, MAP eller STRUCT, men stöds inte i Postgres TEXT- eller JSONB-kolumner. Detta kan orsaka synkroniseringsfel med fel som:

ERROR: invalid byte sequence for encoding "UTF8": 0x00
ERROR: unsupported Unicode escape sequence DETAIL: \u0000 cannot be converted to text
  • Det första felet uppstår när en nullbyte visas i en strängkolumn på toppnivå, som mappar direkt till Postgres TEXT.
  • Det andra felet uppstår när en null-byte visas i en sträng kapslad i en komplex typ (STRUCT, , eller ARRAY), som serialiseras som MAPJSONB. Under serialiseringen kastas alla strängar till Postgres TEXT, där \u0000 inte tillåts.

Lösningar:

  • Rensa strängfält: Ta bort tecken som inte stöds innan du synkroniserar. För null byte i STRING-kolumner:

    SELECT REPLACE(column_name, CAST(CHAR(0) AS STRING), '') AS cleaned_column FROM your_table
    
  • Konvertera till BINÄR: För STRING-kolumner där det är nödvändigt att bevara råa byte konverterar du till BINÄR typ.

Kapacitetsplanering

När du planerar implementeringen av dina synkroniserade tabeller bör du tänka på följande resurskrav:

  • Anslutningsanvändning: Varje synkad tabell använder upp till 16 anslutningar till din Lakebase-databas, vilka räknas mot projektets anslutningsgräns.
  • Storlekskvot: Total logisk data över alla synkade tabeller räknas mot grenens databaslagringskvot. Kontakta Databricks Support om du behöver en större kvot. Enskilda tabeller har ingen kvot, men Databricks rekommenderar att du inte överskrider 1 TB för tabeller som kräver uppdateringar.
  • Fulluppdateringsstorlek: När du utlöser en fullständig uppdatering tas inte den gamla versionen i Postgres bort förrän den nya synkroniseringen har slutförts. Båda versionerna räknas tillfälligt mot storlekskvoten för den logiska databasen under uppdateringen.
  • Tabeller per källa: En tabell med en enda källa kan ha upp till 20 synkroniserade tabeller.
  • Namngivningskrav: Databas-, schema- och tabellnamn får endast innehålla alfanumeriska tecken och understreck ([A-Za-z0-9_]+).
  • Vägledning för källidentifierare: Undvik att använda versaler eller specialtecken i kolumn- eller tabellnamn i unity catalog-källtabellen. Om du behåller dem måste du ange dessa identifierare när du refererar till dem i Postgres.
  • Schemautveckling: Endast tilläggsschemaändringar (som att lägga till kolumner) stöds för utlösta och kontinuerliga lägen.
  • Ändring av tabelldefinitionen: Att uppdatera en synkroniserad tabells definition på plats stöds inte via något gränssnitt (UI, SDK, CLI, REST API, Terraform eller DAB). För att ändra primärnyckeln eller tidsserienyckeln, eller för att göra en icke-additiv schemaändring, ta bort den synkroniserade tabellen och skapa en ny.
  • Duplicerade nycklar: Om två rader har samma primärnyckel i källtabellen misslyckas synkroniseringspipelinen om du inte konfigurerar deduplicering med hjälp av en tidsserienyckel.
  • API-idempotens: API:er för synkroniserade tabeller är idempotenter, så försök igen med tillfälliga fel för att säkerställa åtgärder i tid.
  • Uppdateringshastighet: För Lakebase stöder synkroniseringspipelinen kontinuerliga och utlösta skrivningar med cirka 150 rader per sekund per kapacitetsenhet (CU) och snapshot-skrivningar med upp till 2 000 rader per sekund per CU.

Åtgärder som tillåts för synkroniserade tabeller i Postgres

Azure Databricks rekommenderar att du endast utför följande åtgärder i Postgres för synkroniserade tabeller för att förhindra oavsiktliga överskrivningar eller datainkonsekvenser:

  • Skrivskyddade förfrågningar
  • Skapa index
  • Ta bort tabellen (för att frigöra utrymme när du har tagit bort den synkroniserade tabellen från Unity Catalog)

Även om det är möjligt att ändra synkroniserade tabeller i Postgres på andra sätt, stör det synkroniseringspipelinen.

Ägarskap och behörigheter

En synkroniserad tabell ägs av den interna databricks_writer_<dbid> rollen, inte av användaren som skapade den, eftersom synkroniseringspipelinen hanterar den (se Postgres-roller). Endast ägarkommandon, till exempel att konfigurera säkerhet på radnivå, kan inte köras direkt i en synkroniserad tabell.

Anmärkning

Det här är ett undantag från den allmänna Postgres-regeln, där objekt som du skapar själv ägs av din Azure Databricks identitet om inloggningen finns som en roll i Postgres. Pipelinen skapar synkroniserade tabeller åt dig.

Åtkomst för den användare som skapar en synkroniserad tabell

När du skapar en synkroniserad tabell beviljas din Azure Databricks-identitet automatiskt åtkomst för att använda den. Ingen databricks_superuser åtgärd krävs. Din identitet beviljas följande behörigheter i den synkroniserade tabellen:

Objekt Behörigheter Purpose
Synkroniserad tabell SELECT, DELETE, TRUNCATE Läsa eller rensa tabellen
Schema USAGE, CREATE Använd schemat och skapa objekt som index

Du beviljas inte INSERT eller UPDATE. Pipeline äger data i tabellen, så direkta skrivningar till tabellen skrivs över vid nästa uppdatering. DELETE och TRUNCATE rensar bara tabellen. Nästa uppdatering fyller i tabellen från källan igen.

Den här åtkomsten härleds från dina Behörigheter för Unity-katalogen i den synkroniserade tabellen och hanteras i Unity Catalog. Om du vill ändra den uppdaterar du användarens behörigheter för Unity-katalogen. Du kan inte REVOKE det direkt i Postgres med en Azure Databricks-identitet.

Anmärkning

Den här åtkomsten är kopplad till den identitet som skapade den synkroniserade tabellen. Om du ändrar pipelinens Kör som-identitet tilldelas den inte igen. Om du vill använda en annan ägande identitet skapar du den synkroniserade tabellen igen under den identiteten.

Hantera synkroniserad tabellåtkomst

När en synkroniserad tabell har skapats kan du databricks_superuser läsa en synkroniserad tabell från Postgres. databricks_superuser har pg_read_all_data, som tillåter den här rollen att läsa från alla tabeller. Den har också behörigheten pg_write_all_data , vilket gör att den här rollen kan skriva till alla tabeller. Det innebär att en databricks_superuser även kan skriva till en synkroniserad tabell i Postgres. Lakebase stöder det här skrivbeteendet om du behöver göra brådskande ändringar i måltabellen. Men Azure Databricks rekommenderar att du gör korrigeringar i källtabellen i stället.

  • databricks_superuser Kan också bevilja dessa behörigheter till andra användare:

    GRANT USAGE ON SCHEMA synced_table_schema TO user;
    
    GRANT SELECT ON synced_table_name TO user;
    
  • databricks_superuser Kan återkalla dessa behörigheter:

    REVOKE USAGE ON SCHEMA synced_table_schema FROM user;
    
    REVOKE {SELECT | INSERT | UPDATE | DELETE} ON synced_table_name FROM user;
    

Hantera synkroniserade tabellåtgärder

databricks_superuser Kan hantera vilka användare som har behörighet att utföra specifika åtgärder i en synkroniserad tabell. De åtgärder som stöds för synkroniserade tabeller är:

  • CREATE INDEX
  • ALTER INDEX
  • DROP INDEX
  • DROP TABLE

Alla andra DDL-åtgärder nekas för synkroniserade tabeller.

Om du vill bevilja dessa behörigheter till ytterligare användare databricks_superuser måste du först skapa ett tillägg på databricks_auth:

CREATE EXTENSION IF NOT EXISTS databricks_auth;

databricks_superuser Sedan kan lägga till en användare för att hantera en synkroniserad tabell:

SELECT databricks_synced_table_add_manager('"synced_table_schema"."synced_table"'::regclass, '[user]');

databricks_superuser Kan ta bort en användare från att hantera en synkroniserad tabell:

SELECT databricks_synced_table_remove_manager('[table]', '[user]');

databricks_superuser Kan visa alla chefer:

SELECT * FROM databricks_synced_table_managers;

Ta bort en synkroniserad tabell

Om du tar bort en synkroniserad tabell från Unity Catalog tas även motsvarande Postgres-tabell bort.

Användargränssnitt (UI)

Leta reda på din synkroniserade tabell i Katalog, klicka på menyikonen för Kebab. Välj Sedan Ta bort.

Python SDK

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

w.postgres.delete_synced_table("synced_tables/my-catalog.sales.orders").wait()

Java SDK

import com.databricks.sdk.WorkspaceClient;

WorkspaceClient w = new WorkspaceClient();

w.postgres().deleteSyncedTable("synced_tables/my-catalog.sales.orders").waitForCompletion();

lockig

curl -X DELETE "https://your-workspace.cloud.databricks.com/api/2.0/postgres/synced_tables/my-catalog.sales.orders" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Katalogintegrering

  • Katalogduplicering: Om du skapar en synkroniserad tabell i en standardkatalog som riktar sig mot en Postgres-databas som också är registrerad som en separat databaskatalog visas den synkroniserade tabellen i Unity Catalog under både standard- och databaskatalogerna.

Andra alternativ

För att synkronisera data till icke-Databricks-system, se Partner Connects verktyg för omvänd ETL som Census eller Hightouch.

Ytterligare resurser

Uppgift Beskrivning
Skapa ett projekt Konfigurera ett Lakebase-projekt
Ansluta till databasen Lär dig anslutningsalternativ för Lakebase
Registrera databasen i Unity-katalogen Gör dina Lakebase-data synliga i Unity Catalog för enhetlig styrning och frågor mellan källor
Integration av Unity-katalog Förstå styrning och behörigheter