Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Importante
Lakebase Provisioned è disponibile nelle aree seguenti: westus, westus2, eastus, eastus2, centralus, southcentralusnortheuropewesteuropeaustraliaeast, . brazilsouthcanadacentralcentralindiasoutheastasiauksouth
Lakebase Provisioned è l'offerta originale di Lakebase che utilizza calcolo provisionato che puoi scalare manualmente. Per la versione più recente di Lakebase, con calcolo con scalabilità automatica, scala-a-zero, branching e ripristino istantaneo, vedere Lakebase Autoscaling.
Le nuove istanze di Lakebase verranno create come progetti di scalabilità automatica. L'implementazione inizia il 12 marzo 2026. Per informazioni dettagliate, vedere Scalabilità automatica per impostazione predefinita.
Le tabelle sincronizzate consentono di gestire i dati lakehouse tramite le istanze di Postgres con provisioning di Lakebase. Le tabelle del catalogo Unity vengono sincronizzate in Postgres in modo che le applicazioni possano eseguire query sui dati lakehouse direttamente con bassa latenza. Questo processo è comunemente noto come ETL inverso. Il lakehouse è ottimizzato per l'analisi e l'arricchimento, mentre Lakebase è progettato per carichi di lavoro operativi che richiedono query in stile ricerca veloce e coerenza transazionale.
Che cosa sono le tabelle sincronizzate?
Le tabelle sincronizzate consentono di gestire dati di livello di analisi da Unity Catalog tramite Lakebase Provisioned Postgres, rendendoli disponibili per le applicazioni che necessitano di query a bassa latenza e transazioni ACID complete. Consentono di colmare il divario tra l'archiviazione analitica e i sistemi operativi mantenendo i dati pronti per la gestione in applicazioni in tempo reale.
Le pipeline di sincronizzazione utilizzano le Lakeflow Spark Declarative Pipelines gestite per aggiornare continuamente sia la tabella sincronizzata di Unity Catalog che la tabella Postgres con le modifiche dalla tabella di origine. Dopo la creazione, è possibile eseguire query sulle tabelle sincronizzate direttamente usando gli strumenti Postgres.
Le caratteristiche principali delle tabelle sincronizzate sono le seguenti:
- La tabella viene considerata di sola lettura in Postgres per mantenere l'integrità dei dati con l'origine
- Sincronizzazione automatica con le pipeline dichiarative di Spark di Lakeflow gestite
- Interrogabile tramite interfacce standard PostgreSQL
- Gestito tramite il catalogo Unity per la governance e la gestione del ciclo di vita
Avviso
Anche se è possibile modificare una tabella sincronizzata direttamente in Postgres, Azure Databricks consiglia rigorosamente di eseguire solo query di lettura per proteggere l'integrità dei dati con l'origine. Per le operazioni supportate sulle tabelle sincronizzate, vedere Operazioni supportate.
Prima di iniziare
- È disponibile una tabella del catalogo Unity in qualsiasi catalogo.
- Hai
CAN USEautorizzazioni sull'istanza del database.
Creare una tabella sincronizzata
INTERFACCIA UTENTE
Per sincronizzare una tabella del catalogo Unity in Postgres, eseguire le operazioni seguenti:
Fare clic su Catalogo nella barra laterale dell'area di lavoro.
Trovare e selezionare la tabella del catalogo Unity in cui si vuole creare una tabella sincronizzata.
Fare clic su Crea>tabella sincronizzata.
Selezionare il catalogo, lo schema e immettere un nome di tabella per la nuova tabella sincronizzata.
- Le tabelle sincronizzate possono essere create anche nei cataloghi Standard, con alcune configurazioni aggiuntive. Selezionare il catalogo Standard, uno schema e immettere un nome di tabella per la tabella sincronizzata appena creata.
Selezionare un'istanza del database e immettere il nome del database Postgres in cui creare la tabella sincronizzata. Per impostazione predefinita, il campo del database Postgres corrisponde al catalogo di destinazione attualmente selezionato. Se un database Postgres non esiste con questo nome, Azure Databricks ne crea uno nuovo.
Selezionare una chiave primaria. Una chiave primaria è necessaria perché consente un accesso efficiente alle righe per letture, aggiornamenti ed eliminazioni.
Importante
Le colonne nella chiave primaria non sono annullabili nella tabella sincronizzata. Di conseguenza, le righe con valori Null nelle colonne chiave primaria vengono escluse dalla sincronizzazione.
Se due righe hanno la stessa chiave primaria nella tabella di origine, selezionare una chiave Timeseries per configurare la deduplicazione. Quando viene specificata una chiave timeseries , le tabelle sincronizzate contengono solo le righe con il valore della chiave timeseries più recente per ogni chiave primaria.
Selezionare la modalità di sincronizzazione da Snapshot, Attivata e Continua. Per altre informazioni su ogni modalità di sincronizzazione, vedere Spiegazione delle modalità di sincronizzazione.
Scegliere se si vuole creare questa tabella sincronizzata da una pipeline nuova o esistente.
- Se si crea una nuova pipeline e si utilizza un catalogo gestito, scegliere la posizione di archiviazione per la tabella di staging. Se si usa un catalogo standard, la tabella di staging viene archiviata automaticamente nel catalogo.
- Se si usa una pipeline esistente, verificare che la nuova modalità di sincronizzazione corrisponda alla modalità pipeline.
(Facoltativo) Selezionare un Serverless Budget Policy. Per creare una politica di budget serverless, vedere Utilizzo degli attributi con politiche di budget serverless. In questo modo è possibile attribuire l'utilizzo della fatturazione a criteri di utilizzo specifici.
- Per le tabelle sincronizzate, l'entità fatturabile è la pipeline dichiarativa sottostante di Lakeflow Spark. Per modificare i criteri di budget, modificare l'oggetto pipeline sottostante. Consulta Configurare una pipeline serverless.
Dopo che lo stato della tabella sincronizzata è Online, accedere all'istanza del database ed eseguire una query sulla tabella appena creata. Esegui query sulla tabella utilizzando l'editor SQL, strumenti esterni o notebook.
PYTHON SDK
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.database import SyncedDatabaseTable, SyncedTableSpec, NewPipelineSpec, SyncedTableSchedulingPolicy
# Initialize the Workspace client
w = WorkspaceClient()
# Create a synced table in a database catalog
synced_table = w.database.create_synced_database_table(
SyncedDatabaseTable(
name="database_catalog.schema.synced_table", # Full three-part name
spec=SyncedTableSpec(
source_table_full_name="source_catalog.source_schema.source_table",
primary_key_columns=["id"], # Primary key columns
scheduling_policy=SyncedTableSchedulingPolicy.TRIGGERED, # SNAPSHOT, TRIGGERED, or CONTINUOUS
# Optional: timeseries_key="timestamp" # For deduplication
new_pipeline_spec=NewPipelineSpec(
storage_catalog="storage_catalog",
storage_schema="storage_schema"
)
),
)
)
print(f"Created synced table: {synced_table.name}")
# Create a synced table in a standard UC catalog
synced_table = w.database.create_synced_database_table(
SyncedDatabaseTable(
name="standard_catalog.schema.synced_table", # Full three-part name
database_instance_name="my-database-instance", # Required for standard catalogs
logical_database_name="postgres_database", # Required for standard catalogs
spec=SyncedTableSpec(
source_table_full_name="source_catalog.source_schema.source_table",
primary_key_columns=["id"],
scheduling_policy=SyncedTableSchedulingPolicy.CONTINUOUS,
create_database_objects_if_missing=True, # Create database/schema if needed
new_pipeline_spec=NewPipelineSpec(
storage_catalog="storage_catalog",
storage_schema="storage_schema"
)
),
)
)
print(f"Created synced table: {synced_table.name}")
# Check the status of a synced table
synced_table_name = "database_catalog.schema.synced_table"
status = w.database.get_synced_database_table(name=synced_table_name)
print(f"Synced table status: {status.data_synchronization_status.detailed_state}")
print(f"Status message: {status.data_synchronization_status.message}")
CLI
# Create a synced table in a database catalog
databricks database create-synced-database-table \
--json '{
"spec": {
"name": "database_catalog.schema.synced_table",
"source_table_full_name": "source_catalog.source_schema.source_table",
"primary_key_columns": ["id"],
"scheduling_policy": "TRIGGERED"
},
"new_pipeline_spec": {
"storage_catalog": "storage_catalog",
"storage_schema": "storage_schema"
}
}'
# Create a synced table in a standard UC catalog
# new_pipeline_spec, storage_catalog, and storage_schema are optional
databricks database create-synced-database-table \
--database-instance-name "my-database-instance" \
--logical-database-name "databricks_postgres" \
--json '{
"name": "standard_catalog.schema.synced_table",
"spec": {
"source_table_full_name": "source_catalog.source_schema.source_table",
"primary_key_columns": ["id"],
"scheduling_policy": "CONTINUOUS",
"create_database_objects_if_missing": true
}
}'
# Check the status of a synced table
databricks database get-synced-database-table "database_catalog.schema.synced_table"
curva
Creare una tabella sincronizzata in un catalogo di database.
export CATALOG_NAME=<Database catalog>
export SRC_TBL="source_catalog.source_schema.source_table"
export DEST_TBL="$CATALOG_NAME.some_schema.synced_table"
export PKS='["id"]'
export ST_CATALOG="storage_catalog"
export ST_SCHEMA="storage_schema"
curl -X POST https://$WORKSPACE/api/2.0/database/synced_tables \
-H "Content-Type: text/json" \
-H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
--data-binary @- << EOF
{
"name": "$DEST_TBL",
"spec": {
"source_table_full_name": "$SRC_TBL",
"primary_key_columns": $PKS,
"scheduling_policy": "TRIGGERED",
},
"new_pipeline_spec": {
"storage_catalog": "$ST_CATALOG",
"storage_schema": "$ST_SCHEMA",
}
}
EOF
Creare una tabella sincronizzata in un catalogo standard di Unity Catalog.
export CATALOG_NAME=<Standard catalog>
export DATABASE_INSTANCE=<database instance>
export POSTGRES_DATABASE=$CATALOG_NAME
export SRC_TBL="source_catalog.source_schema.source_table"
export DEST_TBL="$CATALOG_NAME.some_schema.sync_table"
export PKS='["id"]'
export ST_CATALOG="storage_catalog"
export ST_SCHEMA="storage_schema"
curl -X POST https://$WORKSPACE/api/2.0/database/synced_tables \
-H "Content-Type: text/json" \
-H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
--data-binary @- << EOF
{
"name": "$DEST_TBL",
"database_instance_name": "$DATABASE_INSTANCE",
"logical_database_name": "$POSTGRES_DATABASE",
"spec": {
"source_table_full_name": "$SRC_TBL",
"primary_key_columns": $PKS,
"scheduling_policy": "TRIGGERED",
},
"new_pipeline_spec": {
"storage_catalog": "$ST_CATALOG",
"storage_schema": "$ST_SCHEMA",
}
}
EOF
Controllare lo stato di una tabella sincronizzata.
export SYNCEDTABLE='pg_db.silver.sbtest1_online'
curl --request GET \
"https://e2-dogfood.staging.cloud.databricks.com/api/2.0/database/synced_tables/$SYNCEDTABLE" \
--header "Authorization: Bearer dapi..."
Modalità di sincronizzazione illustrate
È possibile creare una tabella sincronizzata con una delle modalità di sincronizzazione seguenti, che determinano la modalità di sincronizzazione dei dati dall'origine alla tabella sincronizzata in Postgres:
| Modalità di sincronizzazione | Description | Quando utilizzare | Performance |
|---|---|---|---|
| Snapshot | La pipeline viene eseguita una volta per creare uno snapshot della tabella di origine e copiarla nella tabella sincronizzata. Le esecuzioni successive della pipeline copiano l'intero dato di origine nella destinazione e le sostituiscono in modo atomico. La pipeline può essere attivata manualmente, tramite un'API o in base a una pianificazione. | L'origine modifica >10% delle righe per ciclo oppure non supporta il Change Data Feed (viste, tabelle Iceberg). | 10 volte più efficiente rispetto alle modalità incrementali per le tabelle a varianza elevata. |
| Attivato | La pipeline viene eseguita una volta per creare uno snapshot della tabella di origine e copiarla nella tabella sincronizzata. A differenza della modalità di sincronizzazione snapshot, quando la tabella sincronizzata viene aggiornata, vengono recuperate e applicate alla tabella sincronizzata solo le modifiche apportate dall'ultima esecuzione della pipeline. L'aggiornamento incrementale può essere attivato manualmente, tramite un'API o in base a una pianificazione. | Le righe di origine cambiano in modo incrementale in base a una frequenza nota. Gli inserimenti, gli aggiornamenti e le eliminazioni vengono propagati a ogni aggiornamento. | Buon compromesso di costo/ritardo per le sincronizzazioni su richiesta o pianificate. L'esecuzione più frequente di ogni cinque minuti può costare più rispetto alla modalità continua. |
| Continuo | La pipeline viene eseguita una volta per creare uno snapshot della tabella di origine e copiarla nella tabella sincronizzata, quindi la pipeline viene eseguita continuamente. Le modifiche successive alla tabella di origine vengono applicate in modo incrementale alla tabella sincronizzata in tempo reale. Non è necessario alcun aggiornamento manuale. | Le modifiche devono essere visualizzate in Lakebase quasi in tempo reale. | Ritardo più basso, costo più alto. |
Annotazioni
Per supportare la modalità di sincronizzazione attivata o la modalità di sincronizzazione continua, la tabella di origine deve avere il feed di dati delle modifiche abilitato. Alcune origini (come le Visualizzazioni) non supportano il flusso di dati delle modifiche, quindi possono essere sincronizzate solo in modalità snapshot.
Pianificare o attivare le sincronizzazioni successive
Alla creazione, lo snapshot iniziale viene eseguito automaticamente. Per le modalità snapshot e attivate , le sincronizzazioni successive devono essere attivate in modo esplicito. La modalità continua si gestisce automaticamente.
Attività di sincronizzazione della tabella del database nella pipeline
L'attività della pipeline di sincronizzazione delle tabelle del database nei Processi Lakeflow esegue la pipeline di una tabella sincronizzata come passaggio nel flusso di lavoro. Configurare l'attività con un trigger di aggiornamento tabella o una pianificazione.
Trigger per gli aggiornamenti delle tabelle di origine
Genera il compito quando viene aggiornata la tabella del Catalogo Unity di origine. Con la modalità attivata , vengono applicate in modo incrementale solo le nuove modifiche, offrendo aggiornamenti quasi in tempo reale senza il costo sempre attivo della modalità continua.
- Nella barra laterale fare clic su Flussi di lavoro.
- Fare clic su Crea processo o aprire un processo esistente.
- Nella scheda Attività fare clic su + Aggiungi un altro tipo di attività.
- In Inserimento e trasformazione selezionare Pipeline di sincronizzazione tabelle di database.
- Nel campo Pipeline selezionare la pipeline associata alla tabella sincronizzata.
- In Pianificazioni e trigger fare clic su Aggiungi trigger.
- Selezionare Aggiornamento tabella come tipo di trigger.
- In Tabelle selezionare la tabella del catalogo Unity di origine da monitorare.
- Fare clic su Salva.
Generare attività in base a una pianificazione
Esegue la sincronizzazione a cadenza fissa. Ideale per la modalità snapshot , in cui un aggiornamento completo notturno o settimanale è in genere il modello più efficiente.
- Seguire i passaggi da 1 a 5 precedenti per aggiungere un'attività della pipeline di sincronizzazione tabelle di database a un processo.
- In Pianificazioni e trigger fare clic su Aggiungi trigger.
- Scegli Pianificato come tipo di trigger.
- Impostare la pianificazione cron e il fuso orario, quindi fare clic su Salva.
Uso dell'SDK
Attivare un'esecuzione di sincronizzazione a livello di codice, ad esempio alla fine di un notebook o di una pipeline upstream:
from databricks.sdk import WorkspaceClient
w = WorkspaceClient()
# Get the pipeline ID from the synced table
table = w.database.get_synced_database_table(name="catalog.schema.synced_table")
pipeline_id = table.data_synchronization_status.pipeline_id
# Trigger a sync run
w.pipelines.start_update(pipeline_id=pipeline_id)
Operazioni supportate
Azure Databricks consiglia di eseguire solo le operazioni seguenti in Postgres per le tabelle sincronizzate per evitare sovrascrizioni accidentali o incoerenze dei dati:
- Query di sola lettura
- Creazione di indici
- Eliminazione della tabella (per liberare spazio dopo la rimozione della tabella sincronizzata dal catalogo unity)
anche se è possibile modificare le tabelle sincronizzate in Postgres in altri modi, interferisce con la pipeline di sincronizzazione.
Eliminare una tabella sincronizzata
Per eliminare una tabella sincronizzata, è necessario eliminarla da Unity Catalog e quindi eliminare la tabella nell'istanza del database. L'eliminazione della tabella sincronizzata da Unity Catalog annulla la registrazione della tabella e arresta eventuali aggiornamenti dei dati. Tuttavia, la tabella rimane nel database Postgres sottostante. Per liberare spazio nell'istanza del database, connettersi all'istanza e usare il DROP TABLE comando .
INTERFACCIA UTENTE
- Fare clic su Catalogo nella barra laterale dell'area di lavoro.
- Trovare e selezionare la tabella sincronizzata da eliminare.
- Fare clic
>Elimina.
- Connetti all'istanza con
psql, l'editor SQL o da un notebook. - Eliminare la tabella usando PostgreSQL.
DROP TABLE synced_table_database.synced_table_schema.synced_table
PYTHON SDK
from databricks.sdk import WorkspaceClient
# Initialize the Workspace client
w = WorkspaceClient()
# Delete a synced table from UC
synced_table_name = "catalog.schema.synced_table"
w.database.delete_synced_database_table(name=synced_table_name)
print(f"Deleted synced table from UC: {synced_table_name}")
# To free up space in your database instance, you need to connect to the
# instance and drop the table using PostgreSQL:
#
# DROP TABLE synced_table_database.synced_table_schema.synced_table;
CLI
# Delete a synced table from UC
databricks database delete-synced-database-table "catalog.schema.synced_table"
# To free up space in your database instance, you need to connect to the
# instance and drop the table using PostgreSQL:
#
# DROP TABLE synced_table_database.synced_table_schema.synced_table;
curva
# Delete a synced table from UC
curl -X DELETE --header "Authorization: Bearer ${DATABRICKS_TOKEN}" \
https://$WORKSPACE/api/2.0/database/synced_tables/$SYNCED_TABLE_NAME
# To free up space in your database instance, you need to connect to the
# instance and drop the table using PostgreSQL:
#
# DROP TABLE synced_table_database.synced_table_schema.synced_table;
Proprietà e autorizzazioni
Se si crea un nuovo database, uno schema o una tabella Postgres, la proprietà postgres viene impostata come segue:
- La proprietà viene assegnata all'utente che crea il database, lo schema o la tabella, se l'account di accesso di Azure Databricks esiste come ruolo in Postgres. Per aggiungere un ruolo di identità di Azure Databricks in Postgres, vedere Gestire i ruoli postgreSQL.
- In caso contrario, la proprietà viene assegnata al proprietario dell'oggetto padre in Postgres (in genere ).
databricks_superuser
Gestire l'accesso alle tabelle sincronizzate
Dopo aver creato una tabella sincronizzata, è databricks_superuser possibile READ sincronizzare una tabella da Postgres. Il databricks_superuser ha pg_read_all_data, che consente a questo ruolo di leggere da tutte le tabelle. Ha anche il pg_write_all_data privilegio, che consente a questo ruolo di scrivere su tutte le tabelle. Ciò significa che un databricks_superuser oggetto può anche scrivere in una tabella sincronizzata in Postgres. Lakebase supporta questo comportamento di scrittura nel caso in cui sia necessario apportare modifiche urgenti nella tabella di destinazione. Tuttavia, Databricks consiglia di apportare correzioni nella tabella di origine.
Il
databricks_superuserpuò anche concedere questi privilegi ad altri utenti:GRANT USAGE ON SCHEMA synced_table_schema TO user;GRANT SELECT ON synced_table_name TO user;databricks_superuserpuò revocare questi privilegi:REVOKE USAGE ON SCHEMA synced_table_schema FROM user;REVOKE {SELECT | INSERT | UPDATE | DELETE} ON synced_table_name FROM user;
Gestire le operazioni delle tabelle sincronizzate
databricks_superuser Può gestire gli utenti autorizzati a eseguire operazioni specifiche su una tabella sincronizzata. Le operazioni supportate per le tabelle sincronizzate sono:
CREATE INDEXALTER INDEXDROP INDEXDROP TABLE
Tutte le altre operazioni DDL vengono negate per le tabelle sincronizzate.
Per concedere questi privilegi ad altri utenti, è databricks_superuser necessario innanzitutto creare un'estensione in databricks_auth:
CREATE EXTENSION IF NOT EXISTS databricks_auth;
databricks_superuser Può quindi aggiungere un utente per gestire una tabella sincronizzata:
SELECT databricks_synced_table_add_manager('"synced_table_schema"."synced_table"'::regclass, '[user]');
Può databricks_superuser rimuovere un utente dalla gestione di una tabella sincronizzata:
SELECT databricks_synced_table_remove_manager('[table]', '[user]');
Il sistema databricks_superuser può visualizzare tutti i responsabili:
SELECT * FROM databricks_synced_table_managers;
Mappatura del tipo di dati
Questa tabella di mappatura dei tipi definisce come ogni tipo di dati nella tabella del catalogo Unity di origine viene mappato alla tabella di sincronizzazione di destinazione in Postgres.
| Tipo di colonna di origine | Tipo di colonna Postgres |
|---|---|
| BIGINT | BIGINT |
| BINARIO | BYTEA |
| BOOLEANO | BOOLEAN |
| DATA | DATTERO |
| DECIMAL(p,s) | NUMERICO |
| DOPPIO | PRECISIONE DOPPIA |
| FLOAT | REALE |
| INT | INTEGER |
| INTERVAL intervalQualifier | INTERVALLO |
| SMALLINT | SMALLINT |
| STRINGA | TESTO |
| TIMESTAMP | TIMESTAMP CON FUSO ORARIO |
| TIMESTAMP_NTZ | TIMESTAMP SENZA FUSO ORARIO |
| TINYINT | SMALLINT |
| GEOGRAPHY(srid) | NON SUPPORTATO |
| GEOMETRY(srid) | NON SUPPORTATO |
| ARRAY tipoElemento <> | JSONB |
| MAP < keyType,valueType > | JSONB |
| STRUTTURA < [nomeCampo : tipoCampo [NON NULLO][COMMENTO str][, ...]] > | JSONB |
| VARIANTE | JSONB |
| OGGETTO | NON SUPPORTATO |
Annotazioni
- Il mapping per i tipi ARRAY, MAP e STRUCT è stato modificato a maggio 2025. Le tabelle sincronizzate create in precedenza continuano a eseguire il mapping di tali tipi su JSON.
- Il mapping per TIMESTAMP è stato modificato nell'agosto 2025. Le tabelle create prima continuano a essere mappate a TIMESTAMP SENZA FUSO ORARIO.
Gestire caratteri non validi
Alcuni caratteri, ad esempio il byte Null (0x00), sono consentiti nelle STRINGcolonne , ARRAY, MAPo STRUCT nelle tabelle Delta, ma non sono supportati in Postgres TEXT o JSONB colonne. Di conseguenza, la sincronizzazione di tali dati da Delta a Postgres può causare errori di inserimento.
org.postgresql.util.PSQLException: ERROR: invalid byte sequence for encoding "UTF8": 0x00
org.postgresql.util.PSQLException: ERROR: unsupported Unicode escape sequence DETAIL: \u0000 cannot be converted to text.
- Il primo errore si verifica quando compare un byte nullo in una colonna stringa di primo livello, che esegue il mapping diretto a Postgres
TEXT. - Il secondo errore si verifica quando un byte Null viene visualizzato in una stringa annidata all'interno di un tipo complesso (
STRUCT,ARRAYoMAP), che Azure Databricks serializza comeJSONB. Durante la serializzazione, tutte le stringhe vengono convertite in PostgresTEXT, dove\u0000non è consentito.
Soluzione:
È possibile risolvere questo problema in uno dei modi seguenti:
Purificare i campi stringa
Rimuovere o sostituire caratteri non supportati da tutti i campi stringa, inclusi quelli all'interno di tipi complessi, prima di eseguire la sincronizzazione con Postgres.
Per rimuovere byte null da una colonna di primo livello
STRING, usare la funzioneREPLACE.SELECT REPLACE(column_name, CAST(CHAR(0) AS STRING), '') AS cleaned_column FROM your_table;Converti in binario (solo per
STRINGle colonne)Se è necessario conservare il contenuto dei byte non elaborati, convertire le colonne interessate
STRINGinBINARY.
Limitazioni e considerazioni
Tabelle di origine supportate
A seconda della modalità di sincronizzazione di una tabella sincronizzata, sono supportati diversi tipi di tabelle di origine:
Per la modalità snapshot, la tabella di origine deve supportare
SELECT *. Ad esempio: tabelle Delta, tabelle Iceberg, viste, viste materializzate e altri tipi simili.Per le modalità di sincronizzazione attivate o continue, la tabella di origine deve avere abilitato ancheil feed di dati delle modifiche .
Limitazioni dei nomi e degli identificatori
-
Caratteri consentiti: I nomi di database, schema e tabella Postgres per le tabelle sincronizzate possono contenere solo caratteri alfanumerici e caratteri di sottolineatura (
[A-Za-z0-9_]+). I trattini (-) e altri caratteri speciali non sono supportati. - Identificatori di colonna e tabella: Evitare di usare lettere maiuscole o caratteri speciali nei nomi di colonna o tabella nella tabella del catalogo Unity di origine. Se mantenuto, è necessario citare questi identificatori quando si fa riferimento a tali identificatori in Postgres.
Prestazioni e sincronizzazione
- Velocità di sincronizzazione: La sincronizzazione dei dati in tabelle sincronizzate può risultare più lenta rispetto alla scrittura dei dati direttamente nell'istanza del database con un client PostgreSQL nativo a causa di un'ulteriore elaborazione. La modalità di sincronizzazione continua aggiorna i dati dalla tabella gestita di Unity Catalog alla tabella sincronizzata con un intervallo minimo di 15 secondi.
- Utilizzo della connessione: Ogni sincronizzazione di tabelle può usare fino a 16 connessioni all'istanza del database, che vengono conteggiati per il limite di connessione dell'istanza.
- Idempotenza API: Le API delle tabelle sincronizzate sono idempotenti e potrebbe essere necessario ripetere l'operazione quando si verificano errori per garantire operazioni tempestive.
-
Modifiche dello schema: Per le tabelle sincronizzate in
Triggeredmodalità oContinuous, nella tabella sincronizzata vengono riflesse solo le modifiche dello schema aggiuntive (ad esempio, l'aggiunta di una nuova colonna) dalle tabelle del catalogo Unity. - Chiavi duplicate: Se due righe hanno la stessa chiave primaria nella tabella di origine, la pipeline di sincronizzazione ha esito negativo a meno che non si configuri la deduplicazione usando una chiave timeseries. Tuttavia, l'uso di una chiave serie temporale comporta una penalizzazione delle prestazioni.
- Frequenza di aggiornamento: Per Lakebase Provisioned, la pipeline di sincronizzazione supporta scritture continue e scritture attivate a circa 1200 righe al secondo per unità di capacità (CU) e scritture snapshot fino a 15.000 righe al secondo per CU.
Capacità e limiti
-
Limiti delle tabelle:
- Limite di 20 tabelle sincronizzate per tabella di origine.
- Ogni sincronizzazione delle tabelle può usare fino a 16 connessioni di database.
-
Limiti di dimensioni e aggiornamento completo:
- Se si aggiorna completamente una tabella sincronizzata, la versione precedente in Postgres non viene eliminata fino a quando non viene sincronizzata la nuova tabella. Entrambe le versioni vengono conteggiate temporaneamente al limite di dimensioni del database logico durante l'aggiornamento.
- Le singole tabelle sincronizzate non hanno un limite, ma il limite totale delle dimensioni dei dati logici per tutte le tabelle nell'istanza è di 2 TB. Tuttavia, se sono necessari aggiornamenti anziché la ricreazione completa della tabella, Databricks consiglia di non superare 1 TB.
- Se le dimensioni non compresse del formato di riga della tabella del catalogo Unity superano il limite di dimensioni dell'istanza del database (2 TB), la sincronizzazione non riesce. È necessario eliminare la tabella sincronizzata in Postgres prima di scrivere ulteriormente nell'istanza.
Integrazione del catalogo
- Duplicazione del catalogo: La creazione di una tabella sincronizzata in un catalogo standard destinata a un database Postgres registrato anche come catalogo di database separato fa sì che la tabella sincronizzata venga visualizzata in Unity Catalog sia con i cataloghi standard che con i cataloghi di database.