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

Les tables synchronisées vous permettent de diffuser les données lakehouse 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é ETL inverse. 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 queries rapides de type recherche et une cohérence transactionnelle.

Que sont les tables synchronisées ?

Les tables synchronisées vous permettent de diffuser des données de qualité analytique depuis Unity Catalog via Lakebase Postgres, les rendant disponibles pour les applications qui nécessitent des queries à faible latence et des transactions ACID complètes. Ils comblent le fossé entre le stockage analytique et les systèmes opérationnels en conservant vos données prêtes à être utilisées dans les applications en temps réel.

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 :

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

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 Drivers Postgres standard et interrogent les données synchronisées parallèlement à leur propre état opérationnel.

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.

Les pipelines de synchronisation utilisent des LakeFlow pipelines gérés pour mettre à jour en continu la table synchronisée Unity Catalog et la table Postgres avec les modifications de la table source. Chaque synchronisation peut utiliser jusqu'à 16 connexions à votre base de données Lakebase.

Lakebase Postgres prend en charge jusqu'à 1 000 connexions simultanées avec des garanties transactionnelles, de sorte que les applications peuvent lire des données enrichies tout en gérant les insertions, les mises à jour et les suppressions dans la même base de données.

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	La source modifie >10 % des lignes par cycle, ou la source ne prend pas en charge le CDF (vues, tables Iceberg)	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	La source modifie >10 % des lignes par cycle, ou la source ne prend pas en charge le CDF (vues, tables Iceberg)	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

Les modes déclenché et continu nécessitent que le flux de données de modification (CDF) soit activé sur votre table source. Si le CDF n’est pas activé, vous verrez un avertissement dans l’interface utilisateur avec la commande exacte ALTER TABLE à exécuter. Pour plus de détails sur le flux de données de modification, consultez Utiliser le flux de données de modification de Delta Lake sur Databricks.

remarque

Les sources qui ne prennent pas en charge la CDF (telles que les vues, les vues matérialisées et les tables Iceberg) peuvent être synchronisées uniquement en mode Instantané . Pour le mode Instantané, la source doit prendre en charge SELECT *.

Exemples de cas d'usage

Vous pouvez utiliser des tables synchronisées pour des cas d'usage de service 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

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 avez besoin de USE_SCHEMA et de CREATE_TABLE sur n'importe quel schéma que vous utilisez.

Pour les modes Triggered ou Continuous , le Change Data Feed doit être activé sur votre table source :

SQL

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

Pour la planification de la capacité et la compatibilité des types de données, consultez Types de données et compatibilité et Planification de la capacité.

UI

1. Accédez au **Catalogue** dans la barre latérale du workspace et sélectionnez la table Unity Catalog que vous souhaitez synchroniser.

   

2. Cliquez sur Créer > Table synchronisée dans la vue des détails de la table.

   

3. Dans la boîte de dialogue Créer une table synchronisée :

   Les listes de catalogues et de schémas n'incluent que les schémas Unity Catalog où l'utilisateur actuel dispose des privilèges USE_SCHEMA et CREATE_TABLE . Si vous ne voyez pas le schéma attendu, confirmez vos autorisations avec l’administrateur de votre catalogue.

   1. Nom de la table : Saisissez un nom pour votre table synchronisée (elle est créée dans le même catalogue et schéma que votre table source). Cela crée à la fois une table synchronisée Unity Catalog et une table Postgres que vous pouvez query.

   2. Type de base de données : Choisissez Lakebase Serverless (Autoscaling) .

   3. Sync mode : Choisissez Snapshot , Triggered ou Continuous en fonction de vos besoins (voir les modes de synchronisation ci-dessus).

   4. Configurez vos sélections de projet, de Branch et de base de données.

   5. Vérifiez que la clé primaire est correcte (généralement détectée automatiquement).

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 .

6. (Facultatif) Si deux lignes peuvent partager la même clé primaire dans la table source, sélectionnez une **clé de série temporelle** pour configurer la déduplication. Lorsqu’une clé de série temporelle est spécifiée, la table synchronisée contient uniquement la ligne avec la dernière valeur de la clé de série temporelle pour chaque clé primaire. Pour le mode de défaillance sans clé de série temporelle, consultez Clés en double.

Si vous avez choisi le mode Trigger ou Continu et que vous n'avez pas encore activé le flux de données de modification, vous verrez un avertissement avec la commande exacte à exécuter. Pour toute question sur la compatibilité des types de données, consultez Types de données et compatibilité.

Cliquez sur **Create** pour créer la table synchronisée. 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.

CLI

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 SDK

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 SDK

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

curl

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

L'instantané initial s'exécute automatiquement lors de la création. Pour les modes Snapshot et Déclenché , les synchronisations ultérieures doivent être déclenchées explicitement. Le mode continu est autogéré.

Tâche de pipeline de synchronisation de tables de base de données

La tâche pipeline de synchronisation des tables de base de données dans Lakeflow Jobs exécute le pipeline d'une table synchronisée en tant qu'étape de workflow. Configurez le Job avec un Trigger de mise à jour de table ou un planning.

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.

1. Dans la barre latérale, cliquez sur Workflows .
2. Cliquez sur **Créer un Job** ou ouvrez un Job existant.
3. Dans le Tasks tab , cliquez sur + Ajouter un autre type de tâche .
4. Sous Ingestion et Transformation , sélectionnez pipeline de synchronisation de tables de base de données .
5. Dans le champ Pipeline , sélectionnez le pipeline associé à votre table synchronisée.
6. Sous Plannings & Trigger , cliquez sur Ajouter un Trigger .
7. Sélectionnez **Mise à jour de la table** comme type de Trigger.
8. Sous Tables , sélectionnez la table Unity Catalog source à surveiller.
9. 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.

1. Suivez les étapes 1 à 5 ci-dessus pour ajouter une tâche de pipeline de synchronisation de table de base de données à un job.
2. Sous Plannings & Trigger , cliquez sur Ajouter un Trigger .
3. Sélectionnez Scheduled comme type de trigger.
4. 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 :

UI

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 SDK

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 SDK

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

curl

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 Unity Catalog sont mappés aux types Postgres lors de la création de tables synchronisées. Les types complexes (ARRAY, MAP, STRUCT) 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

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

remarque

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

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 prises en compte dans la limite de connexion de l'instance.
• Quota de taille : la quantité totale de données logiques sur toutes les tables synchronisées est soumise à un quota de 16 To. Veuillez contacter 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.
• **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 l'autoscaling Lakebase, le pipeline de synchronisation prend en charge les écritures continues et Triggered à environ 150 lignes par seconde par Unité de capacité (UC) et les écritures Snapshot jusqu'à 2 000 lignes par seconde par UC.

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
• 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.

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.

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

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

Python SDK

Python

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

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

Java SDK

Java

import com.databricks.sdk.WorkspaceClient;

WorkspaceClient w = new WorkspaceClient();

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

curl

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

En savoir plus

Tâche	Description
Créer un projet	Configurer un projet Lakebase
Connectez-vous à votre base de données	Découvrez les options de connexion pour Lakebase
Enregistrer la base de données dans Unity Catalog	Rendez vos données Lakebase visibles dans Unity Catalog pour une gouvernance unifiée et des queries inter-sources.
Intégration d'Unity Catalog	Comprendre la gouvernance et les autorisations

Tâche	Description
Créer un projet	Configurer un projet Lakebase
Connectez-vous à votre base de données	Découvrez les options de connexion pour Lakebase
Enregistrer la base de données dans Unity Catalog	Rendez vos données Lakebase visibles dans Unity Catalog pour une gouvernance unifiée et des queries inter-sources.
Intégration d'Unity Catalog	Comprendre la gouvernance et les autorisations

Intégration du catalogue

• Duplication de catalogue : La création d'une table synchronisée dans un catalogue standard ciblant une base de données Postgres qui est également enregistrée comme un catalogue de base de données séparé entraîne l'apparition de la table synchronisée dans Unity Catalog sous les catalogues standard et de base de données.

Autres options

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.