Servir les données du lakehouse avec des tables synchronisées

Les tables synchronisées vous permettent de diffuser des données de qualité analytique depuis Unity Catalog via Lakebase Postgres. Les tables Unity Catalog se synchronisent dans Postgres afin que les applications puissent query les données du lakehouse directement avec une faible latence. Ce processus est communément appelé extraction, transformation et chargement (ETL) inversés. Le lakehouse est optimisé pour l’analytique et l'enrichissement, tandis que Lakebase est conçu pour les charges de travail opérationnelles qui nécessitent des requêtes de type recherche rapide et des Transactions ACID complètes. Les tables synchronisées comblent le fossé entre le stockage analytique et les systèmes opérationnels en gardant vos données prêtes à être utilisées dans des applications en temps réel.

Schéma architectural montrant le flux de données du lakehouse vers Lakebase et les applications

Exemples de cas d'usage

Vous pouvez utiliser des tableaux synchronisés pour des cas d'usage de fourniture de données, tels que :

Moteurs de personnalisation qui fournissent des profils utilisateur actualisés aux Databricks Apps
Applications qui servent des prédictions de modèle ou des valeurs de caractéristiques calculées dans le lakehouse
Tableaux de bord destinés aux clients qui présentent des KPI en temps réel
Services de détection de la fraude qui fournissent des scores de risque pour une action immédiate
Outils de support qui fournissent des enregistrements client enrichis à partir de données lakehouse

Sources prises en charge

Les tables synchronisées prennent en charge les types de source Unity Catalog suivants :

Tables Delta gérées et externes
Tables Iceberg gérées et externes
Vues et vues matérialisées

Comment cela fonctionne

Les tables synchronisées Databricks créent une copie gérée de vos données Unity Catalog dans Lakebase. Lorsque vous créez une table synchronisée, vous obtenez :

Une table synchronisée dans Unity Catalog qui référence le pipeline de synchronisation
Une table Postgres dans Lakebase (en lecture seule, interrogeable par vos applications)

Diagramme illustrant la relation à trois tables dans les tables synchronisées

Par exemple, vous pouvez synchroniser des tables Gold, des fonctionnalités conçues ou des sorties ML de analytics.gold.user_profiles dans une nouvelle table synchronisée analytics.gold.user_profiles_synced. Dans Postgres, le nom du schéma Unity Catalog devient le nom du schéma Postgres, cela apparaît donc comme gold.user_profiles_synced:

SQL
SELECT * FROM gold.user_profiles_synced WHERE user_id = 12345;

Les applications se connectent avec des Driver Postgres standard et query les données synchronisées avec leur propre état opérationnel, gérant les insertions, les mises à jour et les suppressions sur leurs propres tables dans la même base de données.

Les pipelines de synchronisation utilisent des pipelines Lakeflow gérés pour mettre à jour en continu à la fois la table synchronisée Unity Catalog et la table Postgres avec les changements de la table source. Chaque synchronisation peut utiliser jusqu'à 16 connexions à votre base de données Lakebase. Les limites de connexion dépendent de la taille du compute. Voir les spécifications de compute.

attention

Bien qu'il soit possible de modifier une table synchronisée directement dans Postgres, Databricks recommande vivement d'exécuter uniquement des queries en lecture afin de protéger l'intégrité des données avec la source. Pour les Opérations prises en charge sur les tables synchronisées, consultez Opérations autorisées sur les tables synchronisées dans Postgres.

Modes de synchronisation

Choisissez le mode de synchronisation approprié en fonction des besoins de votre application :

Mode	Description	Quand utiliser	Performance
Instantané	Copie unique de toutes les données	Modifications de la source > 10 % des lignes par cycle	10 x plus efficace si vous modifiez > 10 % des données sources
Déclenché	Mises à jour planifiées qui s'exécutent à la demande ou à intervalles réguliers	Les lignes source changent à une cadence connue. Les insertions, mises à jour et suppressions sont propagées à chaque refresh.	Bon équilibre coût/latence. Coûteux si exécuté <5 min intervalles
Continu	Streaming en temps réel avec une latence de quelques secondes	Les changements doivent apparaître dans Lakebase en quasi temps réel	Le plus faible délai, le coût le plus élevé. Intervalles de 15 secondes minimum

Mode	Description	Quand utiliser	Performance
Instantané	Copie unique de toutes les données	Modifications de la source > 10 % des lignes par cycle	10 x plus efficace si vous modifiez > 10 % des données sources
Déclenché	Mises à jour planifiées qui s'exécutent à la demande ou à intervalles réguliers	Les lignes source changent à une cadence connue. Les insertions, mises à jour et suppressions sont propagées à chaque refresh.	Bon équilibre coût/latence. Coûteux si exécuté <5 min intervalles
Continu	Streaming en temps réel avec une latence de quelques secondes	Les changements doivent apparaître dans Lakebase en quasi temps réel	Le plus faible délai, le coût le plus élevé. Intervalles de 15 secondes minimum

Dans la boîte de dialogue Créer une table synchronisée , Snapshot et Trigger sont tous deux des modes de synchronisation On-demand , disponibles sous Paramètres avancés , tandis que Continuous est un mode distinct.

La configuration requise pour la source dépend du mode de synchronisation :

Snapshot copie toutes les données à chaque synchronisation ; la source doit donc uniquement prendre en charge SELECT *.
Trigger et Continu appliquent les changements au niveau des lignes de manière incrémentielle ; la source doit donc fournir un flux de données de modification. Activez le flux de données de modification au moment de l'écriture sur la source, ou utilisez le flux de données de modification automatique. Si une source déclenchée ou continue ne dispose pas de flux de données de modification, l'interface utilisateur affiche un avertissement avec la commande ALTER TABLE exacte à exécuter.

Automatic change data feed computes row-level changes at read time instead of requiring write-time change data feed on the source. This lets more source types, including Apache Iceberg tables, sync in Triggered or Continuous mode. For the source types that automatic change data feed supports, see the automatic change data feed documentation.

Créer une table synchronisée

Prérequis

Vous avez besoin :

Un workspace Databricks avec Lakebase activé.
Un projet Lakebase (voir Créer un projet).
Une table Unity Catalog à synchroniser.
Autorisations pour créer des tables synchronisées. Vous devez disposer des rôles USE_SCHEMA et CREATE_TABLE sur tout schéma que vous utilisez. Pour accorder ces privilèges, consultez Gestion des privilèges dans Unity Catalog.

Pour les modes Trigger ou Continuous , la source doit fournir un flux de données de modification. Activez le flux de données de modification hérité sur une table source Delta Lake éligible, ou utilisez le flux de données de modification automatique pour les sources telles que les tables Apache Iceberg.

Pour activer le flux de données de modification au moment de l'écriture sur une table source Delta, exécutez :

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

Avant de créer une table synchronisée, vérifiez les éléments suivants :

Source : les types de sources pris en charge sont répertoriés dans Sources prises en charge.
Noms et limites : les règles de nommage, l’utilisation des connexions et les limites par source sont répertoriées dans Planification de la capacité.
Types de colonnes : les mappages de types, les types non acceptés et les caractères provoquant des échecs de synchronisation sont abordés dans Types de données et compatibilité.
Identité du créateur : l'identité qui crée la table synchronisée se voit accorder l'accès à celle-ci, et vous ne pouvez pas réattribuer cet accès ultérieurement. Voir Accès pour l'utilisateur qui crée une table synchronisée.

UI
CLI
Python SDK
Java SDK
curl

Dans Lakehouse, accédez à Catalog dans la barre latérale du workspace et sélectionnez la table Unity Catalog que vous souhaitez synchroniser.
Cliquez sur Créer > Table synchronisée dans la vue des détails de la table.
Dans la boîte de dialogue Create synced table , configurez les sections suivantes, puis cliquez sur Create :

Destination
- Nom : sélectionnez le catalogue et le schéma de la table synchronisée, puis saisissez un nom de table. Cela crée à la fois une table synchronisée Unity Catalog et une table Postgres que vous pouvez query. La liste des catalogues et des schémas inclut uniquement les schémas Unity Catalog pour lesquels vous disposez des privilèges USE_SCHEMA et CREATE_TABLE . Si vous ne voyez pas le schéma attendu, vérifiez vos autorisations auprès de l’administrateur de votre catalogue.
- Lakebase Postgres Database : définissez le champ Database type sur Autoscaling , puis sélectionnez vos éléments Project , Branch et Postgres database .
Paramètres de synchronisation
- Mode de synchronisation : sélectionnez À la demande ou Continu . Pour On-demand , développez Paramètres avancés et choisissez Snapshot ou Triggered . Consultez la section modes de synchronisation pour obtenir des conseils.
Paramètres du pipeline
- Pipeline : sélectionnez Créer un nouveau pour créer un pipeline pour cette table synchronisée, ou Utiliser l'existant pour en réutiliser un.
- Politique d’utilisation serverless : (Facultatif) Sélectionnez une politique d’utilisation serverless pour le pipeline de synchronisation.
Schéma
- Clé primaire : vérifiez la clé primaire (généralement détectée automatiquement). Laissez l'option Unique sélectionnée si chaque valeur de clé primaire est unique dans la source. Si les valeurs de la clé primaire peuvent se répéter, décochez Unique et définissez une Clé de série temporelle . Vous ne pouvez pas changer la clé primaire ou la clé de série temporelle après avoir créé la table synchronisée.

important

Les colonnes de la clé primaire ne peuvent pas être nulles dans la table synchronisée. Les lignes avec des valeurs nulles dans les colonnes de clé primaire sont exclues de la synchronisation .

Clé de série temporelle : (Facultatif) Lorsque les valeurs de clé primaire peuvent se répéter dans la source, sélectionnez une colonne pour configurer la déduplication. La table synchronisée contient alors uniquement la ligne avec la dernière valeur de clé de série temporelle pour chaque clé primaire. Pour connaître le mode d'échec sans clé de série temporelle, consultez Clés en double.

Si vous avez choisi Trigger ou Continuous et que vous n'avez pas encore activé le flux de données de modification, un avertissement s'affiche avec la commande exacte à exécuter. 4. Surveillez la table synchronisée dans le **Catalogue**. Le tab Overview affiche le statut de synchronisation, la configuration, le statut du pipeline et le Timestamp de la dernière synchronisation. Utilisez Synchroniser maintenant pour le refresh manuel.

Bash
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
    }
  }'

L’argument positionnel SYNCED_TABLE_ID utilise le format catalog.schema.table. Dans Postgres, la table {table} est créée dans le schéma {schema}, à l'intérieur de la base de données que vous avez définie avec postgres_database (ici, mydb). La commande attend que l’opération se termine by default. Pour toutes les options disponibles, consultez databricks postgres create-synced-table.

Python
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}")

Le synced_table_id utilise le format catalog.schema.table et devient le nom de la table synchronisée Unity Catalog. Dans Postgres, la table {table} est créée dans le schéma {schema}, dans la base de données que vous avez définie avec postgres_database (ici, mydb).

Java
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());

Bash
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
    }
  }'

Ceci renvoie une Opération de longue durée. Sonder le champ name renvoyé jusqu'à done: true. Consultez Opérations de longue durée. Pour la configuration de l'authentification, consultez Authentification.

Planifier ou Trigger des synchronisations ultérieures

La charge initiale s’exécute automatiquement lorsque vous créez une table synchronisée. Après cela, la façon dont les synchronisations s’exécutent dépend du mode de synchronisation :

Le mode Continu diffuse les modifications au fur et à mesure qu'elles se produisent. Vous n'avez pas besoin de Trigger des synchronisations.
Les modes Snapshot et Triggered ne se synchronisent que lorsqu'ils sont déclenchés. Pour lancer une synchronisation manuellement, ouvrez la table synchronisée dans Catalogue et cliquez sur Synchroniser maintenant sous le tab Vue d’ensemble. Pour exécuter automatiquement les synchronisations, ajoutez le pipeline de la table synchronisée à un Job dans Lakeflow Jobs en tant que tâche de pipeline de synchronisation des tables de base de données , puis configurez le Job avec l’un des Trigger suivants :
- Trigger sur les mises à jour des tables sources: idéal pour le mode Triggered .
- Trigger sur un planning: idéal pour le mode Instantané .

Trigger lors des mises à jour de la table source

Déclenche le job lorsque la table Unity Catalog source est mise à jour. Avec le mode Trigger , seuls les nouveaux changements sont appliqués de manière incrémentale, offrant une fraîcheur quasi en temps réel sans le coût permanent du mode continu.

Dans votre Workspace, cliquez sur Tâches et pipelines dans la barre latérale.
Cliquez sur **Créer un Job** ou ouvrez un Job existant.
Dans le Tasks tab , cliquez sur + Ajouter un autre type de tâche .
Sous Ingestion et Transformation , sélectionnez pipeline de synchronisation de tables de base de données .
Dans le champ Pipeline , sélectionnez le pipeline associé à votre table synchronisée.
Sous Plannings & Trigger , cliquez sur Ajouter un Trigger .
Sélectionnez **Mise à jour de la table** comme type de Trigger.
Sous Tables , sélectionnez la table Unity Catalog source à surveiller.
Cliquez sur Enregistrer .

Trigger planifié

Exécute la synchronisation à une cadence fixe. Bien adapté au mode **Snapshot**, où une refresh complète quotidienne ou hebdomadaire est généralement le modèle le plus efficace.

Dans votre Workspace, cliquez sur Tâches et pipelines dans la barre latérale.
Cliquez sur **Créer un Job** ou ouvrez un Job existant.
Dans le Tasks tab , cliquez sur + Ajouter un autre type de tâche .
Sous Ingestion et Transformation , sélectionnez pipeline de synchronisation de tables de base de données .
Dans le champ Pipeline , sélectionnez le pipeline associé à votre table synchronisée.
Sous Plannings & Trigger , cliquez sur Ajouter un Trigger .
Sélectionnez Scheduled comme type de trigger.
Définissez votre calendrier cron et votre fuseau horaire, puis cliquez sur Enregistrer .

Vérifier l'état de synchronisation

Pour vérifier l'état actuel et la dernière heure de synchronisation d'une table synchronisée :

remarque

Pendant une synchronisation, le pipeline effectue l’ensemble de son traitement de données tout en signalant l’événement INITIALIZING. Une grande synchronisation peut signaler INITIALIZING pour l’exécution complète. C’est normal et cela ne signifie pas que le pipeline est bloqué.

UI
Python SDK
Java SDK
curl

Dans Catalog , accédez à votre table synchronisée et sélectionnez l'onglet tab . Il affiche l'état de synchronisation actuel, l'état du pipeline et le dernier Timestamp de synchronisation.

Python
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
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());

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

Types de données et compatibilité

Les types de données du Unity Catalog sont mappés sur des types Postgres lors de la création de tables synchronisées. Les types complexes (ARRAY, MAP, STRUCT) et VARIANT sont stockés en tant que JSONB dans Postgres.

Type de colonne source	Type de colonne Postgres
BIGINT	BIGINT
BINAIRE	BYTEA
Booléen	Booléen
Date	Date
DECIMAL(p,s)	NUMÉRIQUE
Double	DOUBLE PRECISION
Présentation libre	RÉEL
INT	INTEGER
INTERVALLE	INTERVALLE
SMALLINT	SMALLINT
CHAÎNE	Texte
Horodatage	TIMESTAMP AVEC FUSEAU HORAIRE
TIMESTAMP_NTZ	TIMESTAMP sans fuseau horaire
TINYINT	SMALLINT
ARRAY<elementType>	JSONB
MAP<keyType,valueType>	JSONB
STRUCT<fieldName:fieldType[, ...]>	JSONB
VARIANT	JSONB

Type de colonne source	Type de colonne Postgres
BIGINT	BIGINT
BINAIRE	BYTEA
Booléen	Booléen
Date	Date
DECIMAL(p,s)	NUMÉRIQUE
Double	DOUBLE PRECISION
Présentation libre	RÉEL
INT	INTEGER
INTERVALLE	INTERVALLE
SMALLINT	SMALLINT
CHAÎNE	Texte
Horodatage	TIMESTAMP AVEC FUSEAU HORAIRE
TIMESTAMP_NTZ	TIMESTAMP sans fuseau horaire
TINYINT	SMALLINT
ARRAY<elementType>	JSONB
MAP<keyType,valueType>	JSONB
STRUCT<fieldName:fieldType[, ...]>	JSONB
VARIANT	JSONB

remarque

Les types GEOGRAPHY, GEOMETRY et OBJECT ne sont pas pris en charge.

Mappages de types personnalisés

Gérer les caractères non valides

Certains caractères, tels que les octets nuls (0x00), sont autorisés dans les colonnes STRING, ARRAY, MAP ou STRUCT de Unity Catalog, mais ne sont pas pris en charge dans les colonnes TEXT ou JSONB de Postgres. Cela peut entraîner des échecs de synchronisation avec des erreurs telles que :

ERROR: invalid byte sequence for encoding "UTF8": 0x00
ERROR: unsupported Unicode escape sequence DETAIL: \u0000 cannot be converted to text

La première erreur se produit lorsqu'un octet nul apparaît dans une colonne de chaîne de premier niveau, qui correspond directement à Postgres TEXT.
La deuxième erreur se produit lorsqu'un octet nul apparaît dans une chaîne imbriquée dans un type complexe (STRUCT, ARRAY, ou MAP), qui est sérialisé en tant que JSONB. Lors de la sérialisation, toutes les chaînes sont converties en Postgres TEXT, où \u0000 n'est pas autorisé.

Solutions:

Désinfecter les champs de chaîne : Supprimez les caractères non pris en charge avant la synchronisation. Pour les octets nuls dans les colonnes STRING :
SQL
```
SELECT REPLACE(column_name, CAST(CHAR(0) AS STRING), '') AS cleaned_column FROM your_table
```
Convertir en BINARY : Pour les colonnes STRING où la préservation des octets bruts est nécessaire, convertissez en type BINARY.

Planification de la capacité

Lors de la planification de l'implémentation de vos tables synchronisées, tenez compte de ces exigences en matière de ressources :

Utilisation des connexions : Chaque table synchronisée utilise jusqu'à 16 connexions à votre base de données Lakebase, qui sont comptabilisées dans la limite de connexions du projet.
Quota de taille : la quantité totale de données logiques sur l’ensemble des tables synchronisées est comptabilisée dans le quota de stockage de base de données de la Branch. Contactez l’assistance Databricks si vous avez besoin d’un quota plus important. Les tables individuelles n’ont pas de quota, mais Databricks recommande de ne pas dépasser 1 To pour les tables nécessitant des refresh.
Taille du full-refresh : Lorsque vous Trigger un full-refresh, l'ancienne version dans Postgres n'est pas supprimée tant que la nouvelle synchronisation n'est pas terminée. Les deux versions sont temporairement prises en compte dans le quota de taille de la base de données logique pendant le refresh.
Tables par source : une seule table source peut avoir jusqu'à 20 tables synchronisées.
Exigences de dénomination : Les noms de base de données, de schéma et de table ne peuvent contenir que des caractères alphanumériques et des traits de soulignement[A-Za-z0-9_]+ ().
Conseils pour les identifiants de source : Évitez d'utiliser des majuscules ou des caractères spéciaux dans les noms de colonnes ou de tables de la table source Unity Catalog. Si vous les conservez, vous devez citer ces identifiants lorsque vous y faites référence dans Postgres.
**Évolution des schémas** : Seules les modifications de schéma additives (comme l'ajout de colonnes) sont prises en charge pour les modes déclenchés et continus.
Modification de la définition de table : la mise à jour sur place de la définition d'une table synchronisée n'est prise en charge par aucune interface (UI, SDK, CLI, API REST, Terraform ou DAB). Pour modifier la clé primaire ou la clé de série temporelle, ou pour effectuer une modification de schéma non additive, supprimez la table synchronisée et créez-en une nouvelle.
**Clés en double** : Si deux lignes ont la même clé primaire dans la table source, le pipeline de synchronisation échoue, à moins que vous ne configuriez la déduplication à l'aide d'une clé de série temporelle.
**Idempotence des API** : Les API de table synchronisées sont idempotentes, donc réessayez en cas d'erreurs transitoires pour garantir des opérations opportunes.
Taux de mise à jour : pour Lakebase, le pipeline de synchronisation prend en charge les écritures continues et déclenchées à environ 150 lignes par seconde par unité de capacité (CU) et les écritures de snapshot jusqu’à 2 000 lignes par seconde par CU.

Opérations autorisées sur les tables synchronisées dans Postgres

Databricks recommande d'effectuer uniquement les Opérations suivantes dans Postgres pour les tables synchronisées afin d'éviter les remplacements accidentels ou les incohérences de données :

Requêtes en lecture seule
Création d'index (voir Ajouter des index à une table synchronisée)
Suppression de la table (pour libérer de l'espace après la suppression de la table synchronisée de Unity Catalog)

Bien qu'il soit possible de modifier des tables synchronisées dans Postgres d'autres manières, cela interfère avec le pipeline de synchronisation.

Ajouter des index à une table synchronisée

Une table synchronisée est créée avec un index de clé primaire. Pour ajouter d'autres index, créez-les dans Postgres une fois que la table existe. Par exemple, pour prendre en charge les queries de confinement sur une colonne JSONB, telle qu'une colonne synchronisée à partir d'une colonne source VARIANT, créez un index GIN :

SQL
CREATE INDEX orders_payload_gin ON sales.orders USING GIN (payload);

Les index que vous créez sur une table synchronisée persistent au travers des synchronisations. Chaque chargement complet, y compris chaque synchronisation de Snapshot et chaque refresh complet, reconstruit vos index. Par conséquent, chaque index supplémentaire ajoute du temps à ces synchronisations. Dans les modes Trigger et Continu , chaque index ralentit également les mises à jour incrémentielles.

Pour créer des index, vous devez être le propriétaire ou le créateur de la table synchronisée, le databricks_superuser, ou un utilisateur ajouté comme gestionnaire de la table synchronisée. Voir Gérer les opérations de table synchronisée.

Gardez les éléments suivants à l'esprit lors de la création d'index :

Les tables synchronisées sont des tables partitionnées. Postgres ne prend pas en charge CREATE INDEX CONCURRENTLY sur une table partitionnée, utilisez donc CREATE INDEX à la place. CREATE INDEX bloque les écritures dans la table, y compris les écritures du pipeline de synchronisation, jusqu'à ce que la build se termine. Si la build prend plus de 20 minutes pendant qu'une synchronisation est en attente, la synchronisation échoue et n'est pas réessayée automatiquement. Les queries peuvent toujours lire la table, sauf si un chargement complet est en attente d'échange dans les données actualisées. Sur les grandes tables, créez des index lorsqu'aucune synchronisation n'est en cours.
Exécutez la création d’index longs à partir d’un client Postgres. La création d’un index sur une grande table peut prendre beaucoup de temps. Exécutez la création à partir d’un client tel que psql au lieu de l’éditeur SQL.

Propriété et autorisations

Une table synchronisée appartient au rôle interne databricks_writer_<dbid>, et non à l'utilisateur qui l'a créée, car le pipeline de synchronisation la gère (voir rôles Postgres). Les commandes réservées aux propriétaires, telles que la configuration de la sécurité au niveau des lignes, ne peuvent pas être exécutées directement sur une table synchronisée.

remarque

Il s'agit d'une exception à la règle générale de Postgres, selon laquelle les objets que vous créez vous-même sont la propriété de votre identité Databricks si son login existe en tant que rôle dans Postgres. Le pipeline crée des tables synchronisées en votre nom.

Accès pour l'utilisateur qui crée une table synchronisée

Lorsque vous créez une table synchronisée, votre identité Databricks se voit automatiquement accorder l'accès pour l'utiliser. Aucune action databricks_superuser n'est requise. Votre identité se voit accorder les privilèges suivants sur la table synchronisée :

Objet	Privilèges	Objectif
Table synchronisée	`SELECT`, `DELETE`, `TRUNCATE`	Lire ou effacer le tableau
Schéma	`USAGE`, `CREATE`	Utilisez le schéma et créez des objets tels que des index.

Il ne vous est pas accordé INSERT ou UPDATE. Le pipeline est propriétaire des données de la table, ainsi les écritures directes sont écrasées lors de la prochaine refresh. DELETE et TRUNCATE ne font qu'effacer la table. La prochaine refresh repopulera la table à partir de la source.

Cet accès est dérivé de vos autorisations Unity Catalog sur la table synchronisée et est géré dans Unity Catalog. Pour le modifier, mettez à jour les autorisations Unity Catalog de l’utilisateur. Vous ne pouvez pas REVOKE à partir d’une identité Databricks directement dans Postgres.

remarque

Cet accès est lié à l'identité qui a créé la table synchronisée. La modification de l'identité Exécuter en tant que du pipeline ne la réaffecte pas. Pour utiliser une identité propriétaire différente, recréez la table synchronisée sous cette identité.

Gérer l'accès aux tables synchronisées

Une fois qu'une table synchronisée est créée, le databricks_superuser peut lire une table synchronisée à partir de Postgres. Le databricks_superuser dispose de pg_read_all_data, ce qui permet à ce rôle de lire toutes les tables. Il dispose également du privilège pg_write_all_data, ce qui permet à ce rôle d'écrire dans toutes les tables. Cela signifie qu'un databricks_superuser peut également écrire dans une table synchronisée dans Postgres. Lakebase prend en charge ce comportement d'écriture au cas où vous auriez besoin d'apporter des modifications urgentes à votre table cible. Cependant, Databricks recommande d'effectuer les corrections dans votre table source à la place.

Le databricks_superuser peut également accorder ces privilèges à d'autres utilisateurs :

SQL
GRANT USAGE ON SCHEMA synced_table_schema TO user;

SQL
GRANT SELECT ON synced_table_name TO user;

Le databricks_superuser peut révoquer ces privilèges :

SQL
REVOKE USAGE ON SCHEMA synced_table_schema FROM user;

SQL
REVOKE {SELECT | INSERT | UPDATE | DELETE} ON synced_table_name FROM user;

Gérer les opérations de table synchronisées

Le databricks_superuser peut gérer quels utilisateurs sont autorisés à effectuer des opérations spécifiques sur une table synchronisée. Les opérations prises en charge pour les tables synchronisées sont :

CREATE INDEX
ALTER INDEX
DROP INDEX
DROP TABLE

Toutes les autres Opérations DDL sont refusées pour les tables synchronisées.

Pour accorder ces privilèges à des utilisateurs supplémentaires, le databricks_superuser doit d'abord créer une extension sur databricks_auth:

SQL
CREATE EXTENSION IF NOT EXISTS databricks_auth;

Ensuite, databricks_superuser peut ajouter un utilisateur pour gérer une table synchronisée :

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

Le databricks_superuser peut retirer un utilisateur de la gestion d'une table synchronisée :

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

Le databricks_superuser peut afficher tous les gestionnaires :

SQL
SELECT * FROM databricks_synced_table_managers;

Supprimer une table synchronisée

La suppression d'une table synchronisée de Unity Catalog supprime également la table Postgres correspondante.

UI
Python SDK
Java SDK
curl

Dans Catalogue , recherchez votre table synchronisée, cliquez sur le menu et sélectionnez Supprimer .

Python
from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

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

Java
import com.databricks.sdk.WorkspaceClient;

WorkspaceClient w = new WorkspaceClient();

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

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

Intégration du catalogue

Une table synchronisée peut apparaître dans plus d’un catalogue dans Unity Catalog. Cette duplication de catalogue est attendue lorsque vous créez une table synchronisée dans un catalogue standard et que sa base de données Postgres de destination est également enregistrée en tant que catalogue de bases de données. Dans ce cas, la table synchronisée apparaît dans les deux catalogues.

Synchroniser vers des systèmes en dehors de Databricks

Pour la synchronisation des données vers des systèmes non-Databricks, consultez les solutions d'ETL inversé de Partner Connect telles que Census ou Hightouch.

Ressources supplémentaires

Apprenez à vous connecter à votre base de données
Enregistrez une base de données Lakebase dans Unity Catalog
Découvrez Unity Catalog

Exemples de cas d'usage​

Sources prises en charge​

Comment cela fonctionne​

Modes de synchronisation​

Créer une table synchronisée​

Prérequis​

Planifier ou Trigger des synchronisations ultérieures​

Trigger lors des mises à jour de la table source​

Trigger planifié​

Vérifier l'état de synchronisation​

Types de données et compatibilité​

Mappages de types personnalisés​

Gérer les caractères non valides​

Planification de la capacité​

Opérations autorisées sur les tables synchronisées dans Postgres​

Ajouter des index à une table synchronisée​

Propriété et autorisations​

Accès pour l'utilisateur qui crée une table synchronisée​

Gérer l'accès aux tables synchronisées​

Gérer les opérations de table synchronisées​

Supprimer une table synchronisée​

Intégration du catalogue​

Synchroniser vers des systèmes en dehors de Databricks​

Ressources supplémentaires​

Exemples de cas d'usage

Sources prises en charge

Comment cela fonctionne

Modes de synchronisation

Créer une table synchronisée

Prérequis

Planifier ou Trigger des synchronisations ultérieures

Trigger lors des mises à jour de la table source

Trigger planifié

Vérifier l'état de synchronisation

Types de données et compatibilité

Mappages de types personnalisés

Gérer les caractères non valides

Planification de la capacité

Opérations autorisées sur les tables synchronisées dans Postgres

Ajouter des index à une table synchronisée

Propriété et autorisations

Accès pour l'utilisateur qui crée une table synchronisée

Gérer l'accès aux tables synchronisées

Gérer les opérations de table synchronisées

Supprimer une table synchronisée

Intégration du catalogue

Synchroniser vers des systèmes en dehors de Databricks

Ressources supplémentaires