Un seul chemin d'écriture, plusieurs entrées : comment Rippling utilise Apache Iceberg™ géré par Unity Catalog

Ceci est un article invité de Tae Lee, Staff Engineer, Data Platform chez Rippling

Chez Rippling, le moteur qui écrit une table n'est pas toujours celui qui la lit. Un job Databricks peut produire une table, mais le consommateur en aval peut être la couche de requête basée sur Trino de Rippling Data Cloud, Snowflake ou un autre lecteur de lakehouse. Le choix du catalogue est donc bien plus qu'un simple détail de métadonnées : il détermine qui peut écrire dans la table, qui la gère et comment les autres moteurs la lisent.

Cela signifie que l'objectif n'est pas de contraindre chaque workload à utiliser un seul moteur ou un seul catalogue. L'objectif est de permettre à chaque producteur d'utiliser la plateforme sur laquelle il fonctionne le mieux, tout en publiant des tables gouvernées que les systèmes en aval peuvent consommer sans duplication.

Les tables Iceberg gérées par Unity Catalog sont le modèle que nous utilisons pour la partie de cette architecture produite par Databricks.

La propriété du catalogue suit le moteur d'écriture

Notre stratégie de catalogue commence par une règle simple : le catalogue doit suivre le moteur d'écriture.

Pour le calcul natif AWS, nous utilisons AWS Glue Data Catalog. C'est le choix naturel pour les workloads écrits par des moteurs AWS tels que Glue, Athena, EMR ou les infrastructures associées.

Pour les workloads produits par Databricks, nous utilisons Unity Catalog. C'est particulièrement important pour Apache Iceberg™. Databricks peut lire des tables Iceberg externes via la fédération, mais ces tables ne sont pas identiques aux tables Iceberg gérées par Unity Catalog. Si Databricks doit écrire dans la table, ou si le workload dépend fortement des performances et de la gouvernance de Databricks, la table doit être gérée par UC.

Pour les données produites par Snowflake qui doivent être partagées entre plusieurs plateformes, nous utilisons Snowflake Horizon Catalog avec des tables Iceberg gérées par Snowflake. Il s'agit d'une décision de catalogue distincte, dictée par Snowflake en tant que producteur.

C'est là une distinction importante : Iceberg nous offre un format de table ouvert, mais le catalogue reste propriétaire des validations de métadonnées (commits), des autorisations et du cycle de vie des tables. La portabilité des formats et la propriété du catalogue sont liées, mais ce ne sont pas la même chose.

Pourquoi choisir Iceberg géré pour les workloads Databricks

Avant d'adopter ce modèle, un résultat produit par Databricks devant être consommé ailleurs nécessitait généralement une étape supplémentaire : exporter une deuxième copie après l'écriture de Databricks, ou écrire directement dans le système de consommation et le relire via un connecteur ou un chemin de fédération lorsque Databricks en avait de nouveau besoin. Les deux approches fonctionnent, mais elles ajoutent une matérialisation en double, du calcul supplémentaire et des limites spécifiques aux connecteurs. 

Iceberg géré par Unity Catalog nous offre une délimitation plus nette.

Databricks écrit la table de manière native. Unity Catalog gère les métadonnées de la table, le modèle d'accès et le cycle de vie. Les données de la table et les métadonnées Iceberg sont stockées dans un espace de stockage S3 appartenant à Rippling. 

Les moteurs externes se connectent via l'API Iceberg REST Catalog ou la fédération de catalogues. La distribution d'identifiants (credential vending) permet à ces moteurs d'accéder de manière ciblée au stockage sous-jacent. Les moteurs lisent ensuite les fichiers Parquet directement depuis S3 en utilisant leur propre puissance de calcul. 

C'est la propriété clé pour nous. Un job Databricks peut produire la table une seule fois, et un moteur en aval tel que Trino, Snowflake, Spark, Athena ou EMR peut consommer cette même table via des modèles d'accès Iceberg standards. Le consommateur n'a pas besoin de faire passer chaque requête par le dialecte SQL ou la couche d'exécution d'un autre moteur, ce qui réduit la dépendance vis-à-vis de la traduction entre moteurs, du comportement de pushdown, de la régulation (throttling) et du calcul côté producteur pour les lectures en aval. 

Il ne s'agit pas d'un export Databricks. C'est une table Iceberg ouverte avec un producteur natif Databricks.

Des résultats de ML au Data Cloud

Chez Rippling, les workloads de ML et d'AI choisissent toujours la cible qui correspond à leur cas d'usage : tables Delta, bases de données vectorielles, OpenSearch ou d'autres destinations spécialisées. Iceberg géré est un modèle de publication sélectionné, et non la cible par défaut pour chaque résultat de ML.

Là où Iceberg géré prend tout son sens, c'est lors du transfert. Pour certains résultats sélectionnés, un job Databricks peut publier une table Iceberg gérée par Unity Catalog une seule fois. Rippling Data Cloud peut ensuite consommer cette même table via sa couche de requête, y compris les modèles d'accès basés sur Trino, et l'utiliser dans des transformations en aval, des tableaux de bord et des fonctionnalités produit basées sur l'AI.

L'architecture ressemble à ceci :

Cela nous donne une table gouvernée et un chemin d'écriture uniques. Les consommateurs en aval n'ont pas besoin d'une copie physique en double, et les Lakeflow Jobs n'ont pas besoin d'écrire séparément dans chaque système de consommation.

Les opérations comptent tout autant que l'ouverture

Les formats de table ouverts ne représentent qu'une partie de l'histoire. Les tables Iceberg ont toujours besoin de maintenance : compaction des fichiers, expiration des instantanés (snapshots), nettoyage des fichiers orphelins et collecte de statistiques.

Pour les tables Iceberg cataloguées dans Glue, cette maintenance relève du parcours de la plateforme native AWS. Glue dispose de fonctionnalités d'optimisation des tables, mais il s'agit toujours d'un modèle opérationnel distinct : nous devons décider où activer ces fonctionnalités, comment les surveiller et comment valider le comportement pour les workloads qui utilisent Glue.

Pour Iceberg géré par Unity Catalog, Databricks gère une plus grande partie de ce cycle de vie grâce à Predictive Optimization, notamment la maintenance automatique des tables, l'optimisation et la compaction des fichiers, la collecte de statistiques et l'optimisation de la disposition des données pour les tables gérées. C'est très utile car la plateforme qui écrit la table gère également une grande partie de l'entretien nécessaire pour maintenir ses performances.

C'est l'une des raisons pour lesquelles nous ne considérons pas Iceberg géré par UC uniquement comme une fonctionnalité d'interopérabilité. C'est également un modèle opérationnel. Pour les tables produites par Databricks, le parcours de maintenance compte tout autant que le parcours de lecture.

Être précis sur la dépendance (lock-in)

Cette architecture réduit la dépendance aux données (lock-in), mais elle n'élimine pas toutes les dépendances.

La dépendance aux données est faible. La table est au format Iceberg sur Parquet dans un stockage S3 appartenant à Rippling.

Les moteurs en aval peuvent lire les données directement via des modèles Iceberg ouverts.

La dépendance vis-à-vis du catalogue et de la gouvernance est réelle. Unity Catalog reste le plan de contrôle pour les métadonnées, les autorisations, le lignage (lineage) et le comportement des tables gérées. Si nous devions quitter Databricks, les données seraient portables, mais nous devrions remplacer le catalogue et le système de maintenance.

C'est un compromis acceptable pour cette catégorie de tables. UC s'impose lorsque Databricks est le producteur et que la table doit être gouvernée, maintenue et lisible par d'autres moteurs.

Le résultat concret

La valeur d'Iceberg géré par Unity Catalog n'est pas de nous fournir un catalogue unique pour chaque table. Ce n'est pas le cas, et ce n'est pas notre objectif.

Sa valeur réside dans le fait qu'il nous offre un chemin d'écriture unique pour les tables produites par Databricks qui nécessitent une consommation ouverte en aval. Databricks bénéficie du chemin d'écriture et d'optimisation natif. Les systèmes en aval obtiennent un accès direct aux données ouvertes dans S3. 

Les moteurs qui accèdent à la table via le catalogue REST passent par la même couche de métadonnées et d'accès plutôt que de contourner la gouvernance

via des chemins de stockage bruts. C'est le résultat concret :

"Unity Catalog et Iceberg géré nous offrent le meilleur des deux mondes : des performances natives pour nos pipelines d'AI et de ML, et une interopérabilité ouverte pour chaque consommateur en aval. Un seul chemin d'écriture, zéro duplication et une couche de gouvernance respectée par tous les moteurs, y compris les produits basés sur l'AI que nous développons pour le Data Cloud de Rippling."

Pour Rippling, l'interopérabilité ne consiste pas à rendre chaque moteur interchangeable. Il s'agit de permettre à chaque moteur de faire ce pour quoi il est doué, tout en gardant la table publiée portable, gouvernée et utilisable par les systèmes qui en ont besoin.

Pour en savoir plus sur Unity Catalog et le support d'Iceberg, visitez la page produit de Unity Catalog. 

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original