Traiter des données lakehouse avec des tables synchronisées

Les tables synchronisées vous permettent de proposer des données lakehouse via Lakebase Postgres. Les tables du catalogue Unity se synchronisent avec Postgres afin que les applications puissent interroger les données 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 requêtes de type recherche rapide et une cohérence transactionnelle.

Qu’est-ce que les tables synchronisées ?

Les tables synchronisées vous permettent de traiter des données de niveau analytique à partir de Unity Catalog via Lakebase Postgres, ce qui permet aux applications qui ont besoin de requêtes à faible latence et de transactions ACID complètes. Ils permettent de combler le fossé entre le stockage analytique et les systèmes opérationnels en gardant vos données prêtes à servir dans des applications en temps réel.

Sources prises en charge

Les tables synchronisées prennent en charge les types de sources de catalogue Unity suivants :

• Tables Delta managées et externes
• Tables Iceberg managées et externes
• Vues et vues matérialisées

Fonctionnement

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

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

Par exemple, vous pouvez synchroniser des tables d'or, des fonctions conçues ou des sorties ML depuis analytics.gold.user_profiles vers une nouvelle table analytics.gold.user_profiles_synced synchronisée. Dans Postgres, le nom du schéma du catalogue Unity devient le nom du schéma Postgres. Cela s’affiche donc comme gold.user_profiles_syncedsuit :

SELECT * FROM gold.user_profiles_synced WHERE user_id = 12345;

Les applications se connectent avec des pilotes Postgres standard et interrogent les données synchronisées en même temps que leur propre état opérationnel.

Les pipelines de synchronisation utilisent des pipelines Lakeflow managés pour mettre à jour en continu la table de catalogue Unity et la table Postgres avec des 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, afin que les applications puissent lire des données enrichies tout en gérant les insertions, mises à jour et suppressions dans la même base de données.

Synchronisation initiale accélérée

Les écritures directes LTAP sont une fonctionnalité bêta de l’architecture LTAP qui réduit le temps nécessaire pour les chargements initiaux et les rafraîchissements complets. Il charge les données directement dans la couche de stockage sous-jacente à votre branche Lakebase au lieu d’acheminer l’écriture en masse via le point de terminaison de calcul actif. Par conséquent, les traitements volumineux se terminent plus rapidement et n’ajoutent pas de charge de requêtes au point de terminaison pendant qu’ils s’exécutent.

La capacité LTAP Direct Writes accélère la charge initiale pour chaque mode de synchronisation. Chaque table synchronisée commence par charger une copie complète de la source, et ce premier chargement utilise LTAP Direct Writes, que vous choisissiez le mode Snapshot, Triggered ou Continuous. Il accélère également les rafraîchissements complets, y compris les chargements complets récurrents que le mode Snapshot exécute à chaque synchronisation suivante.

LTAP Direct Writes est en phase bêta et nécessite un projet Lakebase exécutant Postgres 17. Pour l’utiliser, un administrateur de l’espace de travail active l’aperçu LTAP Direct Writes depuis la page Aperçu dans les paramètres de l’espace de travail.

Sur Azure, LTAP Direct Writes est disponible dans toutes les régions sauf Est des États-Unis, Est US 2, Europe de l’Ouest et Ouest US 2.

Modes de synchronisation

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

L’exigence de la source dépend du mode de synchronisation :

• Snapshot copie toutes les données de chaque synchronisation, donc la source n’a besoin de supporter SELECT *que .
• Triggered et Continuous appliquent de façon incrémentielle les modifications au niveau des lignes ; la source doit donc fournir un flux de données de modification. Activez le flux de données de changement au moment d’écriture sur la source, ou utilisez le flux automatique de données de changement. Si une source déclenchée ou continue n’a pas de flux de données de changement, l’interface affiche un avertissement avec la commande exacte ALTER TABLE à exécuter.

Le flux automatique de données de changement (Public Preview) calcule les changements au niveau des lignes au moment de la lecture au lieu d’exiger un flux de données de changement au moment de l’écriture sur la source. Cela permet de synchroniser davantage de types de sources, y compris les tables Apache Iceberg et les vues matérialisées, en mode déclenché ou continu . Pour les types de sources pris en charge par le flux automatique de données de changement, consultez la documentation du flux automatique de données de changement .

Le flux automatique de données de modification des tables synchronisées est en aperçu. Pendant qu’il est en aperçu, complétez deux étapes supplémentaires :

1. Activez l’aperçu. Un administrateur d’espace de travail active l’aperçu automatique du flux de données de modification depuis la page Aperçu dans les paramètres de l’espace de travail.

2. Réglez la chaîne du pipeline en version préliminaire. Lorsque vous créez la table synchronisée, définissez le canal du pipeline à PREVIEW. Cette option est actuellement disponible uniquement via l’API :

   {
     "spec": {
       "new_pipeline_spec": {
         "pipeline_channel": "PREVIEW"
       }
     }
   }
   

Exemples de cas d’usage

Vous pouvez utiliser des tables synchronisées pour les cas d’usage de service de données comme :

• Moteurs de personnalisation qui fournissent de nouveaux profils utilisateur aux Applications Databricks
• Applications qui traitent les prédictions de modèle ou les valeurs de fonctionnalités calculées dans le lakehouse
• Tableaux de bord destinés aux clients qui fournissent des indicateurs de performance clés en temps réel
• Services de détection des fraudes qui fournissent des scores de risque pour agir immédiatement
• Outils de support qui traitent les enregistrements client enrichis des données lakehoude

Créer une table synchronisée

Prerequisites

Tu as besoin de:

• Un espace de travail Databricks avec Lakebase activé.
• Un projet Lakebase (voir Créer un projet).
• Table de catalogue Unity à synchroniser.
• Autorisations pour créer des tables synchronisées. Vous devez USE_SCHEMA et CREATE_TABLE pour tous les schémas que vous utilisez.

Pour les modes déclenché ou continu , la source doit fournir un flux de données de changement. Soit activez le flux de données de changement au moment d’écriture sur une table source Delta éligible, soit utilisez le flux automatique de données de changement pour des sources telles que les tables Apache Iceberg et les vues matérialisées. Le flux automatique de données de modification est en Aperçu public et nécessite la configuration supplémentaire décrite dans les modes Sync.

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

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 La planification des types de données et de la compatibilité et de la capacité.

IU

1. Accédez au catalogue dans la barre latérale de l’espace de travail et sélectionnez la table catalogue Unity que vous souhaitez synchroniser.

   

2. Cliquez sur Créer une>table synchronisée à partir de la vue 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 incluent uniquement les schémas catalogue Unity où l’utilisateur actuel dispose de privilèges USE_SCHEMA et CREATE_TABLE . Si vous ne voyez pas de schéma attendu, confirmez vos autorisations auprès de votre administrateur de catalogue.

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

   2. Type de base de données : Choisissez Lakebase Serverless (mise à l’échelle automatique).

   3. Mode de synchronisation : choisissez instantané, déclenché ou continu en fonction de vos besoins (voir les modes de synchronisation ci-dessus).

   4. Configurez vos sélections de projet, de branche 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 Null 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é Timeseries pour configurer la déduplication. Lorsqu’une clé timeseries est spécifiée, la table synchronisée contient uniquement la ligne avec la dernière valeur de clé timeseries pour chaque clé primaire. Pour le cas d’échec sans clé de série temporelle, voir Clés dupliquées.

   Si vous avez choisi le mode déclenché ou continu et n’avez pas encore activé le flux de données modifiées, vous verrez un avertissement avec la commande exacte à exécuter. Pour connaître les questions de compatibilité des types de données, consultez Types de données et compatibilité.

   Cliquez sur Créer pour créer la table synchronisée.

4. Surveillez la table synchronisée dans le catalogue. L’onglet Vue d’ensemble affiche l’état de synchronisation, la configuration, l’état du pipeline et le dernier horodatage de synchronisation. Utilisez La synchronisation maintenant pour l’actualisation manuelle.

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

L’argument SYNCED_TABLE_ID positionnel 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 avec laquelle postgres_database vous avez défini (ici, mydb). La commande attend que l’opération se termine par défaut. Pour toutes les options disponibles, consultez databricks postgres create-synced-table.

Kit de développement logiciel (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 qui devient le nom de table synchronisée du catalogue Unity. Dans Postgres, la table {table} est créée dans le schéma {schema}, à l’intérieur de la base de données avec laquelle postgres_database vous avez défini (ici, mydb).

Kit de développement logiciel (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

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 longue. Interrogez le champ name renvoyé jusqu’à done: true. Consultez les opérations de longue durée. Pour la configuration de l’authentification, consultez Authentification.

Planifier ou déclencher des synchronisations ultérieures

L’instantané initial s’exécute automatiquement lors de la création. Pour les modes instantané et déclenché , les synchronisations suivantes doivent être déclenchées explicitement. Le mode continu est auto-gérant.

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

La tâche de pipeline de synchronisation de table de base de données dans les travaux Lakeflow exécute le pipeline d’une table synchronisée en tant qu’étape de workflow. Configurez la tâche avec un déclencheur de mise à jour de table ou un planning.

Déclencheur pour les mises à jour de la table source

Déclenche le travail lorsque la table de catalogue Unity source est mise à jour. Avec le mode déclenché , seules les nouvelles modifications sont appliquées de manière incrémentielle, ce qui donne une actualisation quasi en temps réel sans le coût permanent du mode continu.

1. Dans la barre latérale, cliquez sur Flux de travail.
2. Cliquez sur Créer un travail ou ouvrez un travail existant.
3. Sous l’onglet Tâches , cliquez sur + Ajouter un autre type de tâche.
4. Sous Ingestion et Transformation, sélectionnez pipeline de synchronisation de table de base de données.
5. Dans le champ Pipeline , sélectionnez le pipeline associé à votre table synchronisée.
6. Sous Planifications et déclencheurs, cliquez sur Ajouter un déclencheur.
7. Sélectionnez Mise à jour de table comme type de déclencheur.
8. Sous Tables, sélectionnez la table de catalogue Unity source à surveiller.
9. Cliquez sur Enregistrer.

Déclencher selon une planification

Exécute la synchronisation à une cadence fixe. Adaptée au mode Instantané, où une actualisation complète nocturne ou hebdomadaire constitue 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 travail.
2. Sous Planifications et déclencheurs, cliquez sur Ajouter un déclencheur.
3. Sélectionnez Scheduled comme type de déclencheur.
4. Définissez votre planification cron et votre fuseau horaire, puis cliquez sur Enregistrer.

Vérifier l’état de synchronisation

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

IU

Dans Catalogue, accédez à votre table synchronisée et sélectionnez l’onglet Vue d’ensemble . Il affiche l’état de synchronisation actuel, l’état du pipeline et le dernier horodatage de synchronisation.

Kit de développement logiciel (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}")

Kit de développement logiciel (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

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 catalogue Unity 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.

Mappages de types personnalisés

Lorsque vous créez une table synchronisée, vous pouvez remplacer la correspondance par défaut Delta-à-Postgres pour des colonnes spécifiques avec type_overrides.

CREATE EXTENSION IF NOT EXISTS lakebase_vector CASCADE;

Les mappages personnalisés de types sont configurables via l’API, la CLI et les SDK Databricks lorsque vous créez une table synchronisée.

Pour une table source main.docs.chunks(id BIGINT, title STRING, embedding ARRAY<FLOAT>), les correspondances suivantes associent title à varchar(256) et embedding à vector(1024) dans 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 }
      ]
    }
  }'

Sans la dérogation, title serait TEXT et embedding serait JSONB.

Gérer les caractères non valides

Certains caractères tels que les octets Null (0x00) sont autorisés dans les colonnes STRING, ARRAY, MAP ou STRUCT du catalogue Unity, mais pas prises en charge dans les colonnes TEXT ou JSONB 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 Null apparaît dans une colonne de chaîne de niveau supérieur, qui est mappée directement à Postgres TEXT.
• La deuxième erreur se produit lorsqu’un octet Null apparaît dans une chaîne imbriquée à l’intérieur d’un type complexe (STRUCT, ARRAYou MAP), qui est sérialisé en tant que JSONB. Pendant la sérialisation, toutes les chaînes sont converties en Postgres TEXT, où \u0000 est interdit.

Solutions :

• Nettoyer les champs de chaîne : supprimez les caractères non pris en charge avant la synchronisation. Pour les octets null dans les colonnes STRING :

  SELECT REPLACE(column_name, CAST(CHAR(0) AS STRING), '') AS cleaned_column FROM your_table
  

• Convertir en BINARY : pour les colonnes STRING où la conservation 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 des besoins en ressources suivants :

• Utilisation des connexions : chaque table synchronisée utilise jusqu’à 16 connexions à votre base de données Lakebase, qui comptent dans la limite de connexion du projet.
• Quota de taille : le nombre total de données logiques sur toutes les tables synchronisées a un quota de 16 To. Contactez le support 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 actualisations.
• Taille d’actualisation complète : lors du déclenchement d’une actualisation complète, 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 logique de la base de données pendant l’opération d’actualisation.
• Tables par source : une table source unique peut avoir jusqu’à 20 tables synchronisées.
• Exigences de nommage : Les noms de base de données, de schéma et de table peuvent contenir uniquement des caractères alphanumériques et des traits de soulignement ([A-Za-z0-9_]+).
• Conseils relatifs à l’identificateur de source : évitez d’utiliser des lettres majuscules ou des caractères spéciaux dans les noms de colonnes ou de tables de la table catalogue Unity source. Si vous les conservez, vous devez citer ces identificateurs lors de leur référencement dans Postgres.
• Évolution du schéma : seules les modifications de schéma additifs (comme l’ajout de colonnes) sont prises en charge pour les modes déclenchés et continus.
• Modification de la définition de la table : La mise à jour de la définition d’une table synchronisée en place n’est prise en charge via aucune interface (UI, SDK, CLI, REST API, Terraform ou DAB). Pour modifier la clé primaire ou la clé de la série temporelle, ou pour effectuer un changement de schéma non additif, 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, sauf si vous configurez la déduplication à l’aide d’une clé timeseries.
• Idempotence des API : les API des tables synchronisées sont idempotentes ; réessayez en cas d’erreurs transitoires afin de garantir l’exécution des opérations dans les délais.
• 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 instantanées jusqu’à 2 000 lignes par seconde par CU.

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

Azure 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 avoir supprimé la table synchronisée du catalogue Unity)

Bien qu’il soit possible de modifier des tables synchronisées dans Postgres d’une autre manière, elle 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 le gère (voir rôles Postgres). Les commandes propriétaire uniquement, 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.

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

Lorsque vous créez une table synchronisée, votre identité de Azure Databricks est automatiquement autorisée à l’utiliser. Aucune databricks_superuser action n’est requise. Votre identité dispose des privilèges suivants sur la table synchronisée :

Vous ne disposez pas de INSERT ou de UPDATE. Le pipeline possède les données de la table, de sorte que les écritures directes sont remplacées lors de la prochaine actualisation. DELETE et TRUNCATE effacent uniquement le tableau. L’actualisation suivante remplit la table à partir de la source.

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

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

Après la création d’une table synchronisée, le databricks_superuser peut lire une table synchronisée depuis Postgres. databricks_superuserA pg_read_all_data , qui permet à ce rôle de lire à partir de toutes les tables. Il possède également le 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 si vous devez apporter des modifications urgentes dans votre table cible. Toutefois, Azure Databricks recommande d’apporter des correctifs dans votre table source à la place.

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

  GRANT USAGE ON SCHEMA synced_table_schema TO user;
  

  GRANT SELECT ON synced_table_name TO user;
  

• databricks_superuser peut révoquer ces privilèges :

  REVOKE USAGE ON SCHEMA synced_table_schema FROM user;
  

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

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

Les databricks_superuser peuvent 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 les suivantes :

• 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, databricks_superuser doit d’abord créer une extension sur databricks_auth:

CREATE EXTENSION IF NOT EXISTS databricks_auth;

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

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

Le databricks_superuser peut supprimer un utilisateur de la gestion d’une table synchronisée.

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

databricks_superuser peut afficher tous les gestionnaires :

SELECT * FROM databricks_synced_table_managers;

Supprimer une table synchronisée

La suppression d’une table synchronisée à partir du catalogue Unity supprime également la table Postgres correspondante.

IU

Dans Catalogue, recherchez votre table synchronisée, cliquez sur Menu, puis sélectionnez Supprimer.

Kit de développement logiciel (SDK) Python

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

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

Kit de développement logiciel (SDK) Java

import com.databricks.sdk.WorkspaceClient;

WorkspaceClient w = new WorkspaceClient();

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

curl

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

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 inscrite en tant que catalogue de bases de données distinct entraîne l’affichage de la table synchronisée dans le catalogue Unity sous les catalogues standard et de base de données.

Autres options

Pour synchroniser des données dans des systèmes autres que Databricks, consultez les solutions ETL inversées Partner Connect telles que Census ou Hightouch.