Delta Lake : quand l'entreprise repose sur Microsoft

Une entreprise fonctionne sur Microsoft depuis quinze ans. Messagerie, documents et réunions dans Microsoft 365, rapports dans Power BI, et depuis peu un espace Fabric où l’équipe données dépose des extractions de l’ERP. Quand une telle entreprise envisage un système d’exploitation pour toute l’activité, la première question de l’informatique est raisonnable : le registre finit-il quelque part où nos outils peuvent encore lire ?

Pour une entreprise dans cette situation, la réponse passe par Delta Lake. OneLake, le stockage sous Fabric, conserve ses tables en Delta Parquet selon la documentation de Microsoft, de sorte qu’un registre en Delta est un registre que Fabric peut lire sans copie. L’intégration de Hurukan avec Microsoft 365 Copilot est prévue, pas active, et la couche Données est en construction ; ce texte porte sur ce que Delta Lake apporte au registre dans ce cadre, et sur ce qui reste à l’entreprise de décider. La raison d’être du registre est dans l’état courant et le registre.

Ce que fait le journal

Delta Lake ajoute une chose à un répertoire de fichiers Parquet : un journal de transactions. _delta_log/ contient un fichier JSON par commit, nommé par version, chacun listant quels fichiers ont été ajoutés ou retirés et quels sont le schéma et le protocole. Des points de contrôle Parquet périodiques résument le journal pour qu’un lecteur ne le rejoue pas depuis le début. Le document de protocole le définit ; la version 4.4.0 est courante (vérifié le 21 octobre 2026).

De ce seul mécanisme découle tout ce dont le registre a besoin. Une écriture est atomique parce que le fichier de commit existe ou n’existe pas. Les lecteurs voient une version entière parce qu’ils lisent un commit numéroté, pas un listing de répertoire. Deux écrivains ne se corrompent pas parce que la concurrence optimiste détecte le conflit au moment du commit. Et « la table telle qu’elle était quand l’agent a proposé ceci » est un numéro de version, ce qui rend la question de l’audit soluble.

Les fonctions qui comptent pour un registre

Les fonctions de table de Delta s’activent par table et sont portées dans le protocole, de sorte qu’un lecteur sait s’il peut lire ce qu’il regarde. La page de versionnage les liste avec les versions de lecteur et d’écrivain qu’elles exigent (vérifié le 21 octobre 2026). Quatre d’entre elles façonnent un registre d’entreprise.

Les vecteurs de suppression marquent des lignes comme retirées sans réécrire le fichier, de sorte qu’une demande de suppression pour une personne ne réécrit pas une année de factures. Le retrait devient définitif quand les anciens fichiers sont nettoyés, ce qui est un réglage de rétention, pas un effet automatique.

Le flux de données de changement (Change Data Feed) expose ce qui a changé entre deux versions, ce qui est la manière dont les tables en aval et les agents apprennent un changement sans tout relire.

Le clustering liquide remplace les partitions fixes par des clés de regroupement qui peuvent changer plus tard, de sorte que la disposition peut suivre la façon dont le registre est réellement interrogé.

UniForm écrit des métadonnées Iceberg à côté du journal Delta, de sorte que les moteurs qui lisent Iceberg voient la même table. Il exige le mappage des colonnes, est en lecture seule du côté Iceberg, et a des limites documentées autour des vecteurs de suppression et des données de changement, décrites sous Delta UniForm. Le texte de la série sur XTable et UniForm détaille ce que cela apporte.

Ce que Fabric gère, et ce qu’il ne gère pas

Une plateforme managée retire à l’entreprise un vrai travail : le stockage, le calcul, les moteurs, la connexion Power BI, et de plus en plus les tâches de maintenance. C’est un endroit raisonnable pour un registre si l’entreprise a déjà décidé de reposer sur Microsoft. Quatre choses restent à l’entreprise, qu’elle le remarque ou non.

Le catalogue. OneLake décide du nom d’une table, de qui peut la lire et de l’endroit où sa version courante est déclarée. Les fichiers sont ouverts ; le répertoire des fichiers appartient à la plateforme. Un plan de sortie qui dit « nous avons du Parquet dans un lac » n’a pas tenu compte de ce répertoire.

Rétention et suppression. La rétention du journal et les seuils de nettoyage sont des réglages de table. Ils déterminent jusqu’où remonte le voyage dans le temps (time travel) et quand une personne supprimée a réellement disparu. Personne à la plateforme ne les fixe pour vous, et un agent dans Hurukan peut les proposer mais ne les approuve pas.

L’activation des fonctions. Activer une fonction plus récente élève la version du protocole et peut exclure un lecteur plus ancien ailleurs dans l’entreprise. Le gain est réel ; le lecteur qui cesse de fonctionner aussi. Une personne décide, table par table, avec la liste des lecteurs sous les yeux.

Le chemin d’écriture. Delta peut être écrit par de nombreux moteurs, mais le moteur qui écrit une table donnée est une décision de conception, parce que c’est là que siège la propriété des données. Dans Hurukan, les modules écrivent par le chemin propre du registre et la plateforme lit ; l’inverse est une autre architecture.

Lesquelles de ces choses l’entreprise possède est exactement la question posée sous sécurité et souveraineté : une infrastructure que l’entreprise choisit, des données et des modèles qui restent les siens, une sortie possible en pratique.

Où les agents aident, et où ils s’arrêtent

La maintenance d’un registre Delta est mécanique et continue : compactage, nettoyage, statistiques, regroupement. Les agents rédigent bien ces tâches, et ils expliquent une requête lente mieux qu’un tableau de bord. Dans Hurukan, chaque tâche de ce type est une proposition dans la boîte d’approbation, avec son raisonnement, approuvée par une personne et enregistrée comme tout autre changement.

Ce que les agents ne font pas, c’est décider de la rétention, approuver une montée de version du protocole ou choisir le chemin d’écriture. Ces trois décisions fixent ce que le registre pourra prouver plus tard, et une entreprise doit pouvoir dire qui les a prises.

Un test à faire aujourd’hui

Ouvrez une table que votre espace Fabric contient déjà et trouvez trois réglages : sa rétention de journal, son seuil de nettoyage, et la version de protocole qu’elle exige d’un lecteur. Si les trois sont là où la plateforme les a laissés, personne n’a encore décidé jusqu’où remonte votre registre ni lesquels de vos outils pourront le lire l’an prochain. C’est la première décision dont un registre d’entreprise a besoin, et elle ne coûte rien à prendre.