Architecture LTAP

info

Bêta

Depuis le 15 juin, Lakebase est disponible en version bêta sur GCP. Voir Region availability pour les régions prises en charge.

Le LTAP (Lake Transactional/Analytical Processing) est une architecture de données qui prend en charge à la fois les charges de travail transactionnelles (OLTP) et analytiques (OLAP) à partir d'une couche de stockage de données unifiée dans le lake, sous un modèle de gouvernance unique, afin que vous n'ayez pas à maintenir des systèmes transactionnels et analytiques distincts synchronisés. Il supprime les pipelines de change data capture (CDC), de réplication et de transformation que les équipes maintiennent traditionnellement pour copier les données opérationnelles dans un système analytique distinct. Databricks construit le LTAP sur l'architecture de stockage Lakebase. Pour l'annonce, consultez Databricks lance le LTAP : la première architecture de traitement transactionnel/analytique de lake.

LTAP est une architecture, et non une fonctionnalité unique. Databricks le fournit via un ensemble de capacités Lakebase qui sont activement développées et étendues. Les capacités dont vous disposez dépendent de votre cloud. Cette page explique l'architecture. Pour les capacités que vous pouvez utiliser aujourd'hui sur votre cloud, consultez Capabilities that implement LTAP.

important

Avant de lire cette page, consultez l'architecture Lakebase pour comprendre l'architecture de Lakebase et ses composants : le compute Postgres sans état, les safekeepers, les pageservers et le stockage objet cloud. LTAP s'appuie directement sur la manière dont Lakebase sépare le compute du stockage, et le reste de cette page repose sur ce fondement.

Le coût du maintien de la synchronisation entre deux piles

Les applications divisent leur travail sur les données en deux types de charges de travail. Les charges de travail transactionnelles (OLTP) agissent sur quelques lignes à la fois et nécessitent un accès rapide au contenu complet de ces lignes, par exemple pour traiter un paiement ou renvoyer un résultat d’API. Les charges de travail analytiques (OLAP) recherchent des insights dans de grands datasets, en agrégeant et en joignant souvent de nombreuses lignes, par exemple pour prévoir les ventes ou détecter la fraude. Ces modèles vont dans des directions opposées : l’OLTP nécessite des lectures et des écritures constantes à faible latence sur des lignes individuelles, tandis que l’OLAP doit analyser et agréger de grands volumes de données. Pendant des décennies, la réponse consistait à utiliser deux systèmes distincts : une base de données transactionnelle pour l’application, et un data warehouse ou un lakehouse pour l’analytique.

Le pont entre ces deux piles est la partie coûteuse. Pour les maintenir synchronisés, il faut exécuter la capture de données modifiées (CDC), des pipelines de streaming et des réplicas de lecture dont le seul job est de copier les données d'un système à l'autre. Cette infrastructure est fragile, elle ajoute de la latence entre le moment où les données sont écrites et celui où elles peuvent être analysées, et elle entre en concurrence pour les ressources avec la base de données transactionnelle principale. Alors que les applications et les agents d’IA ont de plus en plus besoin d’analytique sur les données transactionnelles les plus récentes, cet écart ralentit les équipes. La copie de données entre deux systèmes crée également un risque de gouvernance : la traçabilité peut être rompue lors du déplacement des données, ce qui rend plus difficile la satisfaction d'obligations telles que les demandes de suppression liées au GDPR.

Comment LTAP unifie les données au niveau de la couche de stockage

Plutôt que de construire un pipeline amélioré entre deux stacks, LTAP supprime du tout le besoin d’un pipeline. Cela fait en repensant la base de données depuis le stockage vers le haut.

Lakebase sépare déjà le calcul Postgres sans état d'une couche de stockage durable composée de safekeepers, de pageservers et de stockage d'objets cloud. Une transaction commit une fois qu'un quorum de safekeepers enregistre durablement son write-ahead log, puis les pageservers matérialisent de manière asynchrone ces changements dans le stockage d'objets cloud, de sorte que les données ne restent plus verrouillées au sein d'un seul moteur de base de données.

remarque

Pour savoir comment Lakebase sépare le compute et le stockage, consultez Architecture Lakebase.

LTAP ajoute une étape à cette couche de stockage. À mesure que le stockage Lakebase matérialise les données dans le stockage d’objets, il transcode les données Postgres orientées ligne en un layout en colonnes Parquet au moment où les données arrivent dans le lake, où elles sont lisibles via des formats de table ouverts tels que Delta et Iceberg. Ce transcodage permet à une copie unique de données de servir à la fois les charges de travail OLTP et OLAP. Il est conçu de manière à ce que la copie en colonnes reste une représentation fidèle et efficace de l’original Postgres :

• La sémantique est préservée. Le stockage Lakebase transcode chaque valeur sous sa forme colonnaire tout en conservant la représentation Postgres originale, afin que tout moteur compatible Postgres puisse réinterpréter les données sans perte d'information. Les types qui ne correspondent pas exactement à Parquet, tels que NaN, le dépassement NUMERIC ou les types d'extension comme vector, array, geography et JSON, sont conservés dans un champ de dépassement qui contient la représentation Postgres canonique.
• Les versions de ligne sont conservées. Le transcodage conserve les versions de lignes intermédiaires, de sorte que la copie en colonnes porte les mêmes informations de version que les données de ligne.
• Les données en colonnes se compressent bien. Le layout en colonnes est fortement compressé, ce qui réduit l'empreinte de stockage et la quantité de données transférées vers et depuis le stockage d'objets.

Le transcodage s'exécute entièrement dans la couche de stockage, isolé de l'instance Postgres principale, afin de ne pas affecter votre charge de travail de service transactionnel. Il s'appuie sur une fonctionnalité déjà existante dans Lakebase : le vidage des données validées vers le stockage d'objets cloud. LTAP ajoute simplement le format colonnaire à ce même vidage. Il n'y a aucun pipeline à construire et aucun processus externe n'interroge votre base de données.

Tout n’est pas transcodé. Les index Postgres conservent leur représentation d’origine dans la couche de stockage durable, plutôt que d’être convertis en colonnes ; ainsi, les lectures ponctuelles transactionnelles et les recherches restent rapides, tandis que la copie colonnaire sert à l’analytique.

Comme les données résident dans un stockage externalisé et versionné, la création d'une Branch ou la restauration à un état antérieur précis est une opération de métadonnées plutôt qu'une copie physique. Vous pouvez créer une Branch d'une grande base de données de production en quelques secondes, exécuter une Experimentation ou une migration risquée sur cette Branch, puis la supprimer, sans dupliquer les données sous-jacentes.

remarque

Une Branch Lakebase est un clone « copy-on-write » du stockage de votre base de données : elle partage les données existantes du parent et ne stocke que les modifications, de sorte qu'aucune donnée n'est dupliquée au préalable. La restauration à un instant T utilise le même stockage versionné pour ramener une base de données à un moment antérieur dans sa fenêtre de restauration. Pour en savoir plus, consultez Branches de base de données et Restauration à un instant T.

Cette approche au niveau du stockage est ce qui distingue LTAP de la capture des changements de données (CDC). La CDC réplique les données de votre stockage OLTP vers un niveau d'analytique distinct à l'aide d'un processus externe qui interroge en continu la base de données principale et d'un pipeline qui transforme les changements de lignes en données colonnaires. Ce pipeline consomme des ressources sur votre base de données transactionnelle principale, vous oblige à gérer vous-même les changements de schéma et les cas limites, et sacrifie la fraîcheur des données au profit du coût du pipeline, tout en ajoutant des points de défaillance. LTAP adopte plutôt une approche au niveau du stockage : le stockage Lakebase transcode les données dans le lake dans le cadre d'une opération de stockage normale, sans processus externe entrant en concurrence avec votre charge de travail et sans pipeline à créer ou à maintenir.

Les trois piliers du LTAP

L'unification des données au niveau de la couche de stockage confère à LTAP trois propriétés déterminantes.

• Gouvernance universelle. Unity Catalog régit l'accès analytique à une copie logique de vos données pour les deux charges de travail.
• Moteurs spécialement conçus. Postgres gère les transactions et le Lakehouse gère l’analytique, sans que l’un ne compromette l’autre.
• Une copie logique unique dans le stockage ouvert. Les deux moteurs lisent une copie de vos données dans des formats ouverts, sans réplicas ni pipelines à synchroniser.

Gouvernance universelle

Unity Catalog régit l'accès analytique à vos données pour les deux charges de travail. Après avoir enregistré une base de données Lakebase, Unity Catalog applique les autorisations, le lignage et l'audit au compute externe qui la lit.

remarque

La gouvernance Unity Catalog s'applique aujourd'hui à l'accès analytique : le compute externe, tel que Lakehouse//RT et Change Data Feed, qui lit vos données Lakebase enregistrées. Il ne régit pas encore directement les tables Postgres individuelles. L'accès via le chemin transactionnel , c'est-à-dire les applications et les clients se connectant à Postgres, est toujours contrôlé par les privilèges Postgres standard (GRANT et REVOKE), et non par Unity Catalog. En pratique, Unity Catalog régit l'accès analytique et lakehouse, tandis que les rôles et privilèges Postgres régissent l'accès transactionnel.

Moteurs spécialement conçus

Postgres prend en charge votre charge de travail transactionnelle et le Lakehouse prend en charge l’analytique, chacun avec les points forts pour lesquels il a été conçu. Une idée fausse courante est qu’unifier les deux signifie que vos données opérationnelles deviennent des données froides stockées dans Iceberg. Ce n’est pas le cas. Lakebase reste du Postgres standard. L’indexation, le branching, la restauration à un instant T, les extensions, ainsi que les lectures et écritures ponctuelles à faible latence continuent tous de fonctionner exactement comme aujourd’hui.

Les lectures analytiques ne sont pas en concurrence avec votre charge de travail transactionnelle, car elles sont isolées de l'instance Postgres principale. Lorsqu'un moteur analytique tel que Lakehouse//RT interroge des données Lakebase en temps réel, il renvoie un résultat récent et transactionnellement cohérent sans copier les données :

• Le moteur lit la majeure partie des données à partir de la copie en colonnes dans le stockage d'objets, et non à partir de Postgres.
• Pour obtenir une vue cohérente sur le plan transactionnel, il demande uniquement à Postgres le numéro de séquence du log (LSN) actuel, une valeur unique qui marque une position dans le write-ahead log. Il s'agit d'une recherche de métadonnées peu coûteuse.
• Pour le petit ensemble de modifications très récentes qui ne se sont pas encore matérialisées dans le lake, il les lit depuis le pageserver et les fusionne par-dessus.

Postgres ne traite aucun trafic de lecture analytique au-delà du renvoi de ce LSN unique, et le transcodage s'exécute dans la couche de stockage, et non sur l'instance Postgres qui dessert votre application. Votre charge de travail opérationnelle continue de s'exécuter comme prévu.

Une copie logique unique dans un stockage ouvert

Comme les données résident dans le lac sous forme de Parquet en colonnes, lisibles via des formats de table ouverts tels que Delta et Iceberg, Lakebase (OLTP) et le Lakehouse (OLAP) partagent la même base de stockage. Vous conservez une copie logique unique des données pour les deux charges de travail, au lieu de réconcilier une base de données transactionnelle avec une copie analytique distincte.

Chaque moteur peut mettre en cache ou représenter ces données dans un format physique différent pour optimiser les performances. Lakebase utilise des pages Postgres pour des lectures ponctuelles OLTP rapides, et les moteurs analytiques lisent le format Parquet en colonnes. Vous travaillez toujours avec un seul dataset logique , plutôt que de maintenir des copies transactionnelles et analytiques distinctes et de les synchroniser.

Chaque table possède un seul rédacteur, soit Lakebase, soit le lakehouse. Les deux moteurs lisent cette copie logique unique ; les mêmes données sont donc disponibles pour vos applications et pour l’analytique sans nécessiter de seconde copie.

Avez-vous besoin de modifier votre utilisation de Lakebase

Non. L'adoption des fonctionnalités LTAP ne nécessite pas de migration de données ni de modification de la manière dont vos applications se connectent à Lakebase. Lakebase reste du Postgres standard : vos extensions, index, query et codes d'application existants continuent de fonctionner sans modification. Chacune des fonctionnalités LTAP est indépendante, vous pouvez donc adopter n'importe laquelle d'entre elles dès qu'une charge de travail le nécessite.

Fonctionnalités qui implémentent LTAP

Vous mettez l'architecture LTAP en pratique grâce à un ensemble de fonctionnalités Lakebase. Chacun s'appuie sur la fondation de stockage partagé décrite ci-dessus, et ensemble, ils couvrent les chemins que les données empruntent via LTAP :

• Gouverner et enregistrer : intégrez les données Lakebase dans Unity Catalog.
• Servir les données du lakehouse dans Lakebase : tables synchronisées, accélérées par les écritures directes LTAP.
• Query live Lakebase data : Lakehouse//RT pour l’analytique, flux de données de changement Lakebase pour les flux de changement.

Le diagramme suivant montre comment ces fonctionnalités écrivent et lisent à partir d'une copie unique de vos données, régies par Unity Catalog.

Lakehouse//RT et le flux de données de changement (Change Data Feed) de Lakebase lisent tous deux les mêmes données sous-jacentes mais les représentent différemment. Lakehouse//RT lit l'état actuel des données Postgres en direct pour l'analytique. Change Data Feed fournit un Stream de changements au niveau des lignes pour les pipelines en aval et l'audit. Il ne s'agit pas non plus du CDC externe que LTAP supprime : les deux fonctionnent sur la copie unique des données.

Le tableau suivant répertorie chaque capacité LTAP et sa fonction, ainsi que son statut de publication sur votre cloud. La disponibilité varie selon le cloud ; ainsi, une fonctionnalité qui n’est pas proposée sur votre cloud est marquée comme non disponible.

Compétence	Statut	Description
Enregistrez Lakebase dans Unity Catalog	GA	Gouvernez l'accès analytique aux données Lakebase et exécutez des queries inter-sources depuis le lakehouse.
Servez les données avec des tables synchronisées	GA	Servez les données de table Unity Catalog dans Lakebase pour des lectures OLTP à faible latence.
Requêtes Lakehouse//RT sur Lakebase	Non disponible sur GCP	Exécutez des queries OLAP transactionnellement cohérentes sur des données Postgres en direct, sans impacter les performances OLTP de Lakebase.
Flux de données de modification (Change Data Feed) Lakebase	Non disponible sur GCP	Stockez les changements au niveau des lignes des tables Postgres de Lakebase sous forme de tables Delta dans Unity Catalog pour les pipelines en aval et l’audit.

Compétence	Statut	Description
Enregistrez Lakebase dans Unity Catalog	GA	Gouvernez l'accès analytique aux données Lakebase et exécutez des queries inter-sources depuis le lakehouse.
Servez les données avec des tables synchronisées	GA	Servez les données de table Unity Catalog dans Lakebase pour des lectures OLTP à faible latence.
Requêtes Lakehouse//RT sur Lakebase	Non disponible sur GCP	Exécutez des queries OLAP transactionnellement cohérentes sur des données Postgres en direct, sans impacter les performances OLTP de Lakebase.
Flux de données de modification (Change Data Feed) Lakebase	Non disponible sur GCP	Stockez les changements au niveau des lignes des tables Postgres de Lakebase sous forme de tables Delta dans Unity Catalog pour les pipelines en aval et l’audit.

Comment aborder la mise en œuvre

Maintenant que vous connaissez les capacités, la question est de savoir lesquelles sont nécessaires à votre charge de travail. Vous implémentez LTAP en combinant les capacités qui correspondent à la façon dont les données circulent dans votre architecture.

La décision clé est la direction : pour chaque dataset, quel système détient l'écriture ? Chaque table possède un seul rédacteur, ce qui détermine les fonctionnalités que vous utilisez.

• Lakebase gère l’écriture. Votre application écrit dans Postgres et vous souhaitez que ces données opérationnelles soient disponibles pour l’analytique sans avoir à les copier. Par exemple, une application de ventes écrit les commandes et les paiements dans Lakebase au fur et à mesure qu’ils se produisent. Utilisez Lakehouse//RT pour exécuter un tableau de bord des revenus en direct sur ces commandes, ou le flux de données de changement (CDF) de Lakebase pour stream chaque changement de commande dans un pipeline en aval ou un log d’audit.
• Le lakehouse gère l'écriture. Vos données sont produites ou conservées dans le lakehouse, et vous souhaitez effectuer des lectures OLTP à faible latence depuis votre application. Par exemple, un job lakehouse nocturne calcule des recommandations de produits ou une table de tarifs. Utilisez des tables synchronisées pour servir ces données dans Lakebase afin que votre application puisse les lire avec une faible latence, et activez les écritures directes LTAP pour accélérer le chargement initial d'une grande table.

Mapper chaque dataset dans l’une de ces directions, enregistrer la base de données dans Unity Catalog pour la gouvernance, puis suivre la documentation de la capacité pour implémenter chaque chemin. Une seule application utilise souvent les deux directions : servir les données de référence du lakehouse à Postgres, tout en exposant ses propres écritures transactionnelles à l’analytique. La disponibilité varie selon le cloud, donc consultez le tableau des capacités ci-dessus pour confirmer ce qui est proposé sur votre cloud.

Étapes suivantes

• Architecture Lakebase : Comprenez comment Lakebase sépare le calcul sans état du stockage durable. Voir architecture de Lakebase.
• Enregistrer une base de données dans Unity Catalog : gérez les données Lakebase et interrogez-les depuis le lakehouse. Voir Enregistrer une base de données Lakebase dans Unity Catalog.
• Servir les données avec des tables synchronisées : synchronisez les données de table Unity Catalog dans Lakebase pour des lectures à faible latence et accélérez les chargements volumineux avec les écritures directes LTAP. Consultez Servir les données du lakehouse avec des tables synchronisées.

En savoir plus

• Annonce : Databricks lance LTAP : la première architecture de traitement transactionnel/analytique de lac
• Blog de data engineering : Du monolithe à Lakebase vers LTAP : repenser la base de données à partir du stockage
• Démo : LTAP : la première architecture de traitement transactionnel/analytique de lac