Aller au contenu principal
Dernière mise à jour le

Servir les données lakehouse avec des tables synchronisées (Lakebase provisionnée)

info

Lakebase Provisioned est l'offre originale de Lakebase qui utilise un compute provisionné que vous mettez à l'échelle manuellement. Pour les régions prises en charge, consultez la disponibilité des régions. Pour la dernière version de Lakebase, avec compute à dimensionnement automatique, mise à l'échelle jusqu'à zéro, création de branches et restauration instantanée, consultez Lakebase Autoscaling.

Depuis le 12 mars 2026, les nouvelles instances Lakebase sont créées en tant que projets de dimensionnement automatique. Les instances provisionnées existantes sont mises à niveau automatiquement vers la mise à l'échelle automatique, à compter de juin 2026. Pour plus de détails, consultez Mise à niveau vers le dimensionnement automatique Lakebase.

Les tables synchronisées vous permettent de servir les données du lakehouse via des instances Postgres provisionnées Lakebase. 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 servir des données de qualité analytique depuis Unity Catalog via Lakebase Provisioned 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.

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. Après la création, les tables synchronisées peuvent être query directement à l'aide des outils Postgres.

Les principales caractéristiques des tables synchronisées sont les suivantes :

  • N'exécutez que des requêtes de lecture sur la table dans Postgres pour maintenir l'intégrité des données avec la source.
  • Synchronisé automatiquement à l'aide de LakeFlow Pipelines gérés
  • Interrogeable via des interfaces PostgreSQL standards
  • Géré via Unity Catalog pour la gouvernance et la gestion du cycle de vie.
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, voir Opérations prises en charge.

Avant de commencer​

  • Vous avez une table Unity Catalog dans n'importe quel catalogue.
  • Vous disposez des autorisations CAN USE sur l'instance de base de données.

Créer une table synchronisée​

Pour synchroniser une table Unity Catalog dans Postgres, procédez comme suit :

  1. Cliquez sur Catalogue dans la barre latérale de l'Workspace.

  2. Recherchez et sélectionnez la table Unity Catalog sur laquelle vous souhaitez créer une table synchronisée.

  3. Cliquez sur Créer > table synchronisée .

  4. Sélectionnez votre catalogue, votre schéma et saisissez un nom de table pour la nouvelle table synchronisée.

    • Les tables synchronisées peuvent également être créées dans les catalogues standard, avec une configuration supplémentaire. Sélectionnez votre catalogue Standard, un schéma, et saisissez un nom de table pour la table synchronisée nouvellement créée.

  5. Sélectionnez une instance de base de données et saisissez le nom de la base de données Postgres dans laquelle créer la table synchronisée. Le champ de base de données Postgres est défini par default sur le catalogue cible actuellement sélectionné. Si une base de données Postgres n'existe pas sous ce nom, Databricks en crée une nouvelle.

  6. Sélectionnez une **clé principale**. Une clé principale est requise car elle permet un accès efficace aux lignes pour les lectures, les mises à jour et les suppressions.

important

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

  1. Si deux lignes ont 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, les tables synchronisées contiennent uniquement les lignes avec la dernière valeur de clé de série temporelle pour chaque clé primaire.

  2. Sélectionnez le mode de synchronisation parmi Instantané , le Trigger et Continu . Pour plus d'informations sur chaque mode de synchronisation, consultez Explication des modes de synchronisation.

  3. Choisissez si vous souhaitez créer cette table synchronisée à partir d'un pipeline nouveau ou existant.

    • Si vous créez un nouveau pipeline et utilisez un catalogue géré, choisissez l'emplacement de stockage pour la table de staging. Si vous utilisez un catalogue standard, la table de préproduction est automatiquement stockée dans le catalogue.
    • Si vous utilisez un pipeline existant, vérifiez que le nouveau mode de synchronisation correspond au mode du pipeline.

  4. (Facultatif) Sélectionnez une **politique d'utilisation Serverless**. Pour créer une politique d'utilisation serverless, voir Attribution de l'utilisation avec les politiques d'utilisation serverless. Ceci vous permet d'attribuer l'utilisation de la facturation à des politiques d'utilisation Serverless spécifiques.

    • Pour les tables synchronisées, l'entité facturable est le pipeline sous-jacent. Pour modifier la politique d'utilisation, modifiez l'objet pipeline sous-jacent. Voir Configurer un pipeline serverless.

  5. Une fois le statut de table synchronisée en ligne , Connexion à votre instance de base de données et interrogez la table nouvellement créée. Interrogez votre table à l'aide de l'éditeur SQL, d' outils externes ou de Notebook.

Modes de synchronisation expliqués​

Une table synchronisée peut être créée avec l'un des modes de synchronisation suivants, qui déterminent comment les données sont synchronisées de la source vers la table synchronisée dans Postgres :

Mode de synchronisation

Description

Quand utiliser

Performance

Instantané

Le pipeline s'exécute une fois pour prendre un instantané de la table source et le copier dans la table synchronisée. Les exécutions de pipelines suivantes copient l'intégralité des données source vers la destination et les remplacent de manière atomique sur place. Le pipeline peut être déclenché manuellement, via une API ou selon un calendrier.

La source modifie plus de 10 % des lignes par cycle, ou la source ne prend pas en charge le Change Data Feed (vues, tables Iceberg).

10x plus efficace que les modes incrémentaux pour les tables à forte rotation.

Déclenché

Le pipeline s'exécute une fois pour prendre un instantané de la table source et le copier dans la table synchronisée. Contrairement au mode de synchronisation instantanée (Snapshot), lorsque la table synchronisée est actualisée, seuls les changements depuis la dernière exécution du pipeline sont récupérés et appliqués à la table synchronisée. Le refresh incrémentiel peut être déclenché manuellement, via une API ou selon un calendrier.

Les lignes sources changent de manière incrémentielle selon une cadence connue. Les insertions, les mises à jour et les suppressions sont toutes propagées à chaque refresh.

Bon compromis coût/latence pour les synchronisations à la demande ou planifiées. Une exécution plus fréquente que toutes les 5 minutes peut coûter plus cher que le mode continu.

Continu

Le pipeline s'exécute une fois pour prendre un instantané de la table source et le copier dans la table synchronisée, puis le pipeline s'exécute en continu. Les modifications ultérieures apportées à la table source sont appliquées de manière incrémentielle à la table synchronisée en temps réel. Aucun refresh manuel n’est nécessaire.

Les modifications doivent apparaître dans Lakebase en quasi temps réel.

Décalage le plus faible, coût le plus élevé.

Mode de synchronisation

Description

Quand utiliser

Performance

Instantané

Le pipeline s'exécute une fois pour prendre un instantané de la table source et le copier dans la table synchronisée. Les exécutions de pipelines suivantes copient l'intégralité des données source vers la destination et les remplacent de manière atomique sur place. Le pipeline peut être déclenché manuellement, via une API ou selon un calendrier.

La source modifie plus de 10 % des lignes par cycle, ou la source ne prend pas en charge le Change Data Feed (vues, tables Iceberg).

10x plus efficace que les modes incrémentaux pour les tables à forte rotation.

Déclenché

Le pipeline s'exécute une fois pour prendre un instantané de la table source et le copier dans la table synchronisée. Contrairement au mode de synchronisation instantanée (Snapshot), lorsque la table synchronisée est actualisée, seuls les changements depuis la dernière exécution du pipeline sont récupérés et appliqués à la table synchronisée. Le refresh incrémentiel peut être déclenché manuellement, via une API ou selon un calendrier.

Les lignes sources changent de manière incrémentielle selon une cadence connue. Les insertions, les mises à jour et les suppressions sont toutes propagées à chaque refresh.

Bon compromis coût/latence pour les synchronisations à la demande ou planifiées. Une exécution plus fréquente que toutes les 5 minutes peut coûter plus cher que le mode continu.

Continu

Le pipeline s'exécute une fois pour prendre un instantané de la table source et le copier dans la table synchronisée, puis le pipeline s'exécute en continu. Les modifications ultérieures apportées à la table source sont appliquées de manière incrémentielle à la table synchronisée en temps réel. Aucun refresh manuel n’est nécessaire.

Les modifications doivent apparaître dans Lakebase en quasi temps réel.

Décalage le plus faible, coût le plus élevé.

remarque

Pour prendre en charge le mode de synchronisation Triggered ou Continuous , la table source doit avoir le flux de données de modification activé. Certaines sources (comme les vues) ne prennent pas en charge le flux de données de modification, elles ne peuvent donc être synchronisées qu'en mode instantané.

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 source Unity Catalog à 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 .

Utilisation du SDK​

Trigger une exécution de synchronisation par programme, par exemple à la fin d'un Notebook ou d'un pipeline en amont :

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

Opérations prises en charge​

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 les tables synchronisées dans Postgres de différentes manières, cela interfère avec le pipeline de synchronisation.

Supprimer une table synchronisée​

Pour supprimer une table synchronisée, vous devez la supprimer de Unity Catalog, puis déposer la table dans l'instance de base de données. La suppression de la table synchronisée de Unity Catalog désenregistre la table et arrête les refresh de données. Cependant, la table reste dans la base de données Postgres sous-jacente. Pour libérer de l'espace dans votre instance de base de données, connectez-vous à l'instance et utilisez la commande DROP TABLE.

  1. Cliquez sur Catalogue dans la barre latérale de l'Workspace.

  2. Trouvez et sélectionnez la table synchronisée que vous souhaitez supprimer.

  3. Cliquez sur Icône du menu kebab. > Supprimer .

  4. Connectez-vous à l'instance avec psql, l'éditeur SQL ou à partir d'un notebook.

  5. Supprimez la table à l'aide de PostgreSQL.

    SQL
    DROP TABLE synced_table_database.synced_table_schema.synced_table

Propriété et autorisations​

Si vous créez une nouvelle base de données, un nouveau schéma ou une nouvelle table Postgres, la propriété Postgres est définie comme suit :

  • La propriété est attribuée à l’utilisateur créant la base de données, le schéma ou la table, si son login Databricks existe en tant que rôle dans Postgres. Pour ajouter un rôle d’identité Databricks dans Postgres, consultez Rôles Postgres.
  • Dans le cas contraire, la propriété est attribuée au propriétaire de l'objet parent dans Postgres (généralement le databricks_superuser).

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

Une fois qu'une table synchronisée est créée, le databricks_superuser peut READ une table synchronisée depuis Postgres. Le databricks_superuser a pg_read_all_data, ce qui permet à ce rôle de lire toutes les tables. Il a é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 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;

Mappage des types de données​

Ce tableau de mappage de type définit la façon dont chaque type de données de la table source Unity Catalog est mappé à la table de synchronisation de destination 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

INTERVAL intervalQualifier

INTERVALLE

SMALLINT

SMALLINT

CHAÎNE

Texte

Horodatage

TIMESTAMP AVEC FUSEAU HORAIRE

TIMESTAMP_NTZ

TIMESTAMP sans fuseau horaire

TINYINT

SMALLINT

GEOGRAPHY(srid)

NON PRIS EN CHARGE

GÉOMÉTRIE(srid)

NON PRIS EN CHARGE

ARRAY < elementType >

JSONB

MAP < keyType,valueType >

JSONB

STRUCT < [fieldName : fieldType [NOT NULL][COMMENT str][, …]] >

JSONB

VARIANT

JSONB

Objet

NON PRIS EN CHARGE

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

INTERVAL intervalQualifier

INTERVALLE

SMALLINT

SMALLINT

CHAÎNE

Texte

Horodatage

TIMESTAMP AVEC FUSEAU HORAIRE

TIMESTAMP_NTZ

TIMESTAMP sans fuseau horaire

TINYINT

SMALLINT

GEOGRAPHY(srid)

NON PRIS EN CHARGE

GÉOMÉTRIE(srid)

NON PRIS EN CHARGE

ARRAY < elementType >

JSONB

MAP < keyType,valueType >

JSONB

STRUCT < [fieldName : fieldType [NOT NULL][COMMENT str][, …]] >

JSONB

VARIANT

JSONB

Objet

NON PRIS EN CHARGE

remarque
  • Le mappage des types ARRAY, MAP et STRUCT a été modifié en mai 2025. Les tables de synchronisation créées avant cela continuent de mapper ces types au JSON.
  • Le mappage pour TIMESTAMP a été modifié en août 2025. Les tables de synchronisation créées avant cela continuent à le mapper à TIMESTAMP WITHOUT TIME ZONE.

Gérer les caractères non valides​

Certains caractères, tels que l'octet nul (0x00), sont autorisés dans les colonnes STRING, ARRAY, MAP ou STRUCT des tables Delta, mais ne sont pas pris en charge dans les colonnes Postgres TEXT ou JSONB. Par conséquent, la synchronisation de ces données de Delta vers Postgres peut entraîner des échecs d'insertion avec des erreurs :

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.
  • 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), que Databricks sérialise comme JSONB. Lors de la sérialisation, toutes les chaînes sont converties en Postgres TEXT, où \u0000 n'est pas autorisé.

Comment résoudre :

Vous pouvez résoudre ce problème de l'une des manières suivantes :

  • Nettoyer les champs de chaîne

    Supprimez ou remplacez les caractères non pris en charge de tous les champs de chaîne, y compris ceux des types complexes, avant la synchronisation avec Postgres.

    Pour supprimer les octets nuls d'une colonne STRING de niveau supérieur, utilisez la fonction REPLACE :

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

  • Convertir en binaire (pour STRING colonnes uniquement)

    Si la conservation du contenu brut en octets est nécessaire, convertissez les STRING colonnes concernées en BINARY.

Limitations et considérations​

Tables sources prises en charge​

Selon le mode de synchronisation d'une table synchronisée, différents types de tables sources sont pris en charge :

  • Pour le mode Snapshot, la table source doit prendre en charge SELECT *. Les exemples incluent les tables Delta, les tables Iceberg, les vues, les vues matérialisées et d'autres types similaires.

  • Pour les modes de synchronisation Trigger ou Continu, la table source doit également avoir le flux de données de modification activé.

Limitations de nommage et d'identificateur​

  • Caractères autorisés : Les noms de base de données, de schéma et de table Postgres pour les tables synchronisées peuvent uniquement contenir des caractères alphanumériques et des traits de soulignement[A-Za-z0-9_]+ (). Les tirets (-) et les autres caractères spéciaux ne sont pas pris en charge.
  • Identifiants de colonne et de table : Évitez d’utiliser des lettres majuscules ou des caractères spéciaux dans les noms de colonne ou de table de la table source Unity Catalog. Si vous les conservez, vous devez citer ces identifiants lorsque vous les référencez dans Postgres.

Performances et synchronisation​

  • Vitesse de synchronisation : La synchronisation des données dans les tables synchronisées peut être plus lente que l'écriture directe des données dans l'instance de base de données avec un client PostgreSQL natif en raison d'un traitement supplémentaire. Le mode de synchronisation continue refresh les données de la table gérée Unity Catalog vers la table synchronisée à un intervalle minimum de 15 secondes.
  • Utilisation de la connexion : Chaque synchronisation de table peut utiliser jusqu'à 16 connexions à l'instance de base de données, qui sont prises en compte pour la limite de connexions de l'instance.
  • Idempotence de l'API : Les APIs de table synchronisées sont idempotentes et peuvent devoir être réessayées en cas d'erreurs pour garantir des opérations en temps voulu.
  • Modifications de schéma : Pour les tables synchronisées en mode Triggered ou Continuous, seules les modifications de schéma additives (par exemple, l’ajout d’une nouvelle colonne) des tables Unity Catalog sont répercutées sur la table synchronisée.
  • 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. Cependant, l'utilisation d'une clé de série temporelle entraîne une pénalité de performance.
  • Taux de mise à jour : Pour Lakebase Provisioned, le pipeline de synchronisation prend en charge les écritures continues et déclenchées à environ 1 200 lignes par seconde et par unité de capacité (CU) et les écritures instantanées jusqu'à 15 000 lignes par seconde et par CU.

Capacité et limites​

  • Limites des tables :

    • Limite de 20 tables synchronisées par table source.
    • Chaque synchronisation de table peut utiliser jusqu'à 16 connexions de base de données.

  • Limites de taille et full refresh :

    • Si vous effectuez un full-refresh d'une table synchronisée, l'ancienne version dans Postgres n'est pas supprimée tant que la nouvelle table n'est pas synchronisée. Les deux versions comptent temporairement pour la limite de taille de la base de données logique pendant le refresh.
    • Les tables synchronisées individuelles n’ont pas de limite, mais la limite de taille totale des données logiques sur toutes les tables de l’instance est de 2 To. Cependant, si vous avez besoin de refreshs au lieu d'une recréation complète de la table, Databricks recommande de ne pas dépasser 1 To.
    • Si la taille non compressée au format ligne de la table Unity Catalog dépasse la limite de taille d'instance de base de données (2 To), la synchronisation échoue. Vous devez supprimer la table synchronisée dans Postgres avant d'écrire davantage dans l'instance.

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.
Sur cette page