Architecture de LTAP

Le traitement transactionnel/analytique (LTAP) est une architecture de données qui sert à la fois des charges transactionnelles (OLTP) et analytiques (OLAP) depuis une couche de stockage unifiée dans le lac, sous un seul modèle de gouvernance, afin que vous n’ayez pas à synchroniser les systèmes transactionnels et analytiques séparés. Elle supprime les pipelines de capture de données de changement (CDC), de réplication et de transformation que les équipes maintiennent traditionnellement pour copier les données opérationnelles dans un système analytique séparé. Azure Databricks construit LTAP sur l’architecture de stockage Lakebase. Voir l’annonce Databricks lance LTAP : la première architecture de traitement transactionnel/analytique Lake.

LTAP est une architecture, pas une seule fonctionnalité. Azure Databricks le propose via un ensemble de fonctionnalité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 fonctionnalités que vous pouvez utiliser aujourd’hui sur votre cloud, consultez Fonctionnalités qui implémentent LTAP.

Le coût de maintenir deux stacks synchronisés

Les applications divisent leur travail de données en deux types de charges de travail. Les charges de travail transactionnelles (OLTP) agissent sur quelques lignes à la fois et nécessitent rapidement l’intégralité du contenu de ces lignes, comme le traitement d’un paiement ou le retour d’un résultat API. Les charges de travail analytiques (OLAP) recherchent des insights sur de grands ensembles de données, en agrégeant et rejoignant souvent de nombreuses lignes, comme la prévision des ventes ou la détection de fraudes. Ces motifs tirent dans des directions opposées : OLTP nécessite des lectures et écritures constantes à faible latence sur des lignes individuelles, tandis qu’OLAP doit analyser et agréger sur de grands volumes de données. Pendant des décennies, la réponse a été deux systèmes distincts : une base de données transactionnelle pour l’application, et un entrepôt de données ou un refuge lacustre pour l’analytique.

C'est la mise en relation de ces deux piles qui représente le plus gros coût. Les maintenir synchronisés signifie exécuter la capture de données de changement (CDC), des pipelines de streaming et des répliques de lecture dont la seule tâche est de copier les données d’un système à l’autre. Cette infrastructure est fragile, elle ajoute de la latence entre l’écriture des données et celle où elles peuvent être analysées, et elle est en concurrence pour les ressources avec la base de données transactionnelle principale. À mesure que les applications et les agents IA ont de plus en plus besoin d’analyses 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 lignée peut se rompre avec le déplacement des données, ce qui rend plus difficile le respect des obligations comme les demandes de retrait du GDPR.

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

Plutôt que de construire un pipeline amélioré entre deux piles, LTAP rend tout pipeline superflu. Il le fait en repensant la base de données en partant du stockage.

Lakebase sépare déjà les ressources de calcul Postgres sans état d'une couche de stockage durable composée de safekeepers, de pageservers et d'un stockage d'objets dans le cloud. Une transaction est validée dès qu'un quorum de safekeepers enregistre de manière durable son journal d'écriture anticipée ; les pageservers se chargent ensuite de répercuter ces modifications de manière asynchrone dans le stockage d'objets dans le cloud, de sorte que les données ne sont plus enfermées dans un seul moteur de base de données.

Le 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 en lignes vers le format colonnaire de Parquet lors de leur arrivée dans le lac, où elles sont lisibles dans des formats de table ouverts tels que Delta et Iceberg. Ce transcodage permet à une seule copie de données de servir à la fois les charges de travail OLTP et OLAP. Il est conçu pour que la copie en colonne 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 en sa forme en colonnes tout en conservant la représentation Postgres originale, de sorte que tout moteur compatible Postgres peut réinterpréter les données sans perdre d’informations. Les types qui ne correspondent pas proprement à Parquet, tels que NaN, NUMERIC overflow, ou les types d’extension comme vector, array, geography et JSON, sont préservés dans un champ de overflow qui contient la représentation canonique de Postgres.
• Les versions en rangée sont conservées. Le transcodage conserve les versions intermédiaires des lignes, de sorte que la copie en colonne porte les mêmes informations de version que les données de lignes.
• Les données en colonnes se compressent bien. Le format colonnaire est très compressé, ce qui réduit l’empreinte de stockage et la quantité de données déplacées vers et depuis le stockage d’objets.

Le transcodage s’exécute entièrement dans la couche de stockage, isolé de l’instance principale de Postgres, donc cela n’affecte pas votre charge de travail transactionnelle de service. Cela s’appuie sur une fonctionnalité que Lakebase assure déjà : l’écriture des données validées vers le stockage d’objets dans le cloud. LTAP ajoute simplement le format en colonne à ce même vidage. Il n’y a pas de pipeline à construire, ni de processus externe pour interroger votre base de données.

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

Parce que les données résident dans un stockage externe et versionné, créer une branche ou restaurer à un moment donné est une opération de métadonnées plutôt qu’une copie physique. Vous pouvez brancher une grande base de données de production en quelques secondes, lancer une expérience ou une migration risquée sur la branche, et la jeter sans dupliquer les données sous-jacentes.

Cette approche au niveau de stockage est ce qui distingue LTAP de la capture de données de changement (CDC). CDC réplique les données de votre stockage OLTP dans une couche analytique distincte à 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 en colonnes. 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 échange la fraîcheur des données contre le coût du pipeline, tout en ajoutant des points de défaillance. LTAP adopte plutôt une approche à l’échelle du stockage : le stockage de Lakebase transcode les données vers le lac de données dans le cadre du fonctionnement normal du stockage, sans qu’aucun processus externe n’entre en concurrence avec votre charge de travail et sans pipeline à créer ni à maintenir de votre côté.

Les trois piliers du LTAP

Unifier les données à la couche de stockage confère à LTAP trois propriétés définissantes.

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

Gouvernance universelle

Unity Catalog régit l’accès analytique à vos données sur les deux charges de travail. Après avoir enregistré une base de données Lakebase, le catalogue Unity applique les permissions, la lignée et l’audit au calcul externe qui le lit.

Moteurs spécialement conçus

Postgres répond à votre charge de travail transactionnelle et le Lakehouse propose l’analytique, chacun avec les points forts pour lesquels il a été conçu. Une idée reçue courante est que l’unification des 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 le Postgres standard. L’indexation, le branchement, la récupération à un moment donné, les extensions, ainsi que les lectures et écritures de points à faible latence continuent de fonctionner exactement comme aujourd’hui.

Les lectures analytiques ne rivalisent pas avec votre charge de travail transactionnelle car elles sont isolées de l’instance principale de Postgres. Lorsqu’un moteur analytique comme Lakehouse//RT interroge des données Lakebase en direct, il restitue un résultat neuf et transactionnellement cohérent sans copier les données :

• Le moteur lit la majeure partie des données depuis la copie colonnaire stockée dans le stockage d’objets, et non depuis Postgres.
• Pour obtenir une vue transactionnellement cohérente, il ne demande à Postgres que le numéro de séquence de logarithme actuel (LSN), une seule valeur qui marque une position dans le journal d’écriture anticipée. C’est une recherche de métadonnées peu coûteuse.
• En ce qui concerne le petit ensemble de modifications très récentes qui ne se sont pas encore répercutées sur le lac, le système les récupère depuis le serveur de pages et les intègre par-dessus.

Postgres ne fournit aucun trafic de lecture analytique au-delà du retour de ce LSN unique, et le transcodage s’exécute dans la couche de stockage, pas sur l’instance Postgres qui sert votre application. Votre charge opérationnelle continue de fonctionner comme prévu.

Une seule copie logique en stockage ouvert

Parce que les données vivent dans le lac sous forme de parquet colonnaire, lisibles via des formats de tables ouvertes tels que Delta et Iceberg, Lakebase (OLTP) et le Lakehouse (OLAP) partagent la même base de stockage. Vous maintenez une copie logique des données sur les deux charges de travail, au lieu de 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 les performances. Lakebase utilise des pages Postgres pour des lectures ponctuelles OLTP rapides, et les moteurs analytiques lisent le format colonnaire Parquet. Vous travaillez toujours avec un seul jeu de données logique , plutôt que de maintenir des copies transactionnelles et analytiques séparées et de les synchroniser.

Chaque table a un seul auteur, soit Lakebase, soit le Lakehouse. Les deux moteurs lisent cette copie logique unique, donc les mêmes données sont disponibles pour vos applications et pour l’analytique sans une seconde copie.

Faut-il changer la façon dont vous utilisez Lakebase ?

Non. Adopter des capacités LTAP ne nécessite pas de migration de données ni de modification de la connexion de vos applications à Lakebase. Lakebase reste la norme Postgres : vos extensions, index, requêtes et code d’application existants continuent de fonctionner sans changement. Chacune des capacités LTAP est indépendante, donc vous pouvez en adopter n’importe laquelle quand une charge de travail en a besoin.

Capacités qui implémentent LTAP

Vous mettez en pratique l’architecture LTAP via un ensemble de fonctionnalités Lakebase. Chacune s’appuie sur la base de stockage partagé décrite ci-dessus, et ensemble elles couvrent les chemins empruntés par les données via LTAP :

• Gouverner et enregistrer : intégrez les données Lakebase sous Unity Catalog.
• Servir les données de lakehouse dans Lakebase : tables synchronisées, accélérées par LTAP Direct Writes.
• Interroger les données Lakebase en temps réel : Lakehouse//RT pour l’analyse, Lakebase Change Data Feed pour les flux de modifications.

Le diagramme suivant montre comment ces capacités écrivent et lisent à partir d’une seule copie de vos données, régie par Unity Catalog.

Lakehouse//RT et Lakebase Change Data Feed 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 temps réel pour l’analyse. Change Data Feed propose un flux de modifications au niveau des lignes pour les pipelines en aval et l’audit. Il n’en va pas non plus de même pour le CDC externe que LTAP supprime : les deux fonctionnent sur une seule copie des données.

Le tableau suivant liste chaque capacité LTAP et son fonctionnement, ainsi que son statut de sortie sur votre cloud. La disponibilité varie selon le cloud, donc une fonctionnalité qui n’est pas proposée sur votre cloud est marquée comme non disponible.

Comment aborder la mise en œuvre

Maintenant que vous connaissez les fonctionnalités disponibles, la question est de savoir desquelles votre charge de travail a besoin. Vous implémentez LTAP en combinant les fonctionnalités qui correspondent à la façon dont les données circulent dans votre architecture.

La décision clé est la direction : pour chaque jeu de données, quel système possède l’écriture ? Chaque table a un rédacteur unique, et cela détermine quelles fonctionnalités vous utilisez.

• Lakebase a l’exclusivité en écriture. Votre application écrit sur Postgres, et vous voulez que ces données opérationnelles soient disponibles pour l’analyse sans les copier. Par exemple, une application de vente envoie des commandes et des paiements à Lakebase au fur et à mesure qu’ils se réalisent. Utilisez Lakehouse//RT pour faire tourner un tableau de bord de revenus en direct sur ces commandes, ou Lakebase Change Data Feed pour canaliser chaque changement de commande dans un pipeline en aval ou un journal d’audit.
• La lakehouse a l'exclusivité de l’écriture. Vos données sont produites ou maintenues dans le lakehouse, et vous souhaitez des lectures OLTP à faible latence depuis votre application. Par exemple, un travail lakehouse nocturne calcule des recommandations de produits ou un tableau de tarification. 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 la charge initiale d’une grande table.

Associez chaque jeu de données à l’une de ces orientations, enregistrez la base de données dans Unity Catalog à des fins de gouvernance, puis suivez la documentation relative à chaque fonctionnalité pour mettre en œuvre chaque approche. Une même application utilise souvent les deux sens : elle alimente Postgres en données de référence depuis le lakehouse, tout en exposant ses propres écritures transactionnelles aux outils d’analyse. 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.
• Enregistrez une base de données dans le catalogue Unity : Gérez les données de Lakebase et interrogez-les depuis la maison du lac. Consultez Inscrire une base de données Lakebase dans le catalogue Unity.
• Servir les données avec des tables synchronisées : synchroniser les données des tables du catalogue Unity dans Lakebase pour des lectures à faible latence, et accélérer les grosses charges avec des écritures directes LTAP. Consultez Traiter des données lakehouse avec des tables synchronisées.

• Flux de données de changement Lakebase : modifications au niveau des lignes de flux de la lakehouse pour les pipelines et l’audit. Consultez Lakebase Change Data Feed.

En savoir plus

• Annonce : Databricks lance LTAP : la première architecture de traitement transactionnel/analytique Lake
• Blog d’ingénierie : Du monolithe à Lakebase en passant par LTAP : repenser la base de données depuis le stockage vers le haut
• Démo : LTAP : La première architecture de traitement transactionnel/analytique de Lake