Enseignements du hackathon Lakebase

En juillet, nous avons participé au hackathon Databricks Lakebase à Zurich. Les équipes ont développé des applications fonctionnelles, allant d'interfaces de chat sur des données de santé et d'outils de gestion des risques à des applications de campagnes marketing et des solutions de soutien au trading et aux prévisions dans le secteur de l'énergie.

Lakebase est la base de données PostgreSQL entièrement gérée de Databricks pour les charges de travail transactionnelles. Elle est conçue pour les applications qui ont besoin de lectures et d'écritures à faible latence en parallèle des données du lakehouse.

Databricks a invité ELCA à accompagner les participants pour toutes leurs questions liées à la plateforme tout au long de l'événement. Nous les avons aidés sur les aspects pratiques : mise en place des connexions Lakebase, synchronisation des données et discussion sur la manière d'implémenter certaines fonctionnalités applicatives pour chaque cas d'usage.

Pour aider les équipes à démarrer rapidement, nous avons également préparé avant l'événement un dépôt Lakebase Quickstart. Plusieurs équipes l'ont utilisé comme point de départ, ce qui a réduit l'effort de mise en place et leur a permis de démarrer leurs projets plus vite. À partir de là, notre soutien est naturellement passé de la configuration aux projets individuels, à leurs flux de données et à leurs questions spécifiques.

Si l'on repense au hackathon, trois enseignements s’en dégagent.

Les hackathons rendent les frictions d'infrastructure douloureusement visibles. Perdez deux ou trois heures en provisionnement, identifiants et configuration d'environnement, et une grande partie de la journée est déjà passée.

Lakebase a changé ce point de départ. La fonctionnalité de branching de Lakebase fournit en quelques secondes des copies isolées et modifiables grâce à un stockage copy-on-write. La capacité de calcul inactive peut descendre à zéro et reprendre automatiquement en quelques centaines de millisecondes lorsqu'ille est de nouveau sollicitée.

Pour un hackathon, cette rapidité compte. Les développeurs peuvent travailler sur des branches isolées, tester des modifications sans toucher à la base principale, abandonner ce qui n'a pas fonctionné et continuer d'avancer.

Associée à notre Quickstart et à l'outillage PostgreSQL familier, cette approche a relégué la mise en place de la base de données à l'arrière-plan. Dès le deuxième café, les équipes se concentraient sur leurs cas d'usage plutôt que sur la configuration de l'infrastructure.

L'un des projets les plus intéressants était une interface de chat sur des mesures de santé personnelles.

L'application combinait des données issues d'Unity Catalog et de Lakebase afin que les utilisateurs puissent poser des questions sur leurs propres données. L'équipe l'a ensuite étendue avec Agent Bricks, en utilisant une couche de vérification basée sur le RAG pour valider les réponses générées.

Cela illustre l'un des schémas les plus forts de Lakebase. Les applications ont souvent besoin de données gouvernées qui existent déjà dans le lakehouse : informations clients, métriques, résultats de modèles ou données de référence. Traditionnellement, servir ces données avec la latence d'une application implique d'ajouter une base de données opérationnelle et de construire un pipeline supplémentaire pour la tenir à jour.

Les tables synchronisées de Lakebase raccourcissent ce chemin : les données d'Unity Catalog deviennent accessibles via PostgreSQL avec une faible latence, sans aucun pipeline de synchronisation à implémenter spécifiquement, ni à maintenir. Une fois cette connexion en place, les équipes ont pu consacrer leur temps à des fonctionnalités applicatives plus riches plutôt qu'à l'infrastructure commune ou à des fonctions élémentaires de saisie de données.

Les projets que nous avons vus lors du hackathon ont rendu ce changement tangible, par exemple :

• Une application de gestion de règles de risque a transformé des données en un workflow opérationnel.
• Un outil de réaffectation des employés a soutenu les opérations d'entrepôt.
• Une autre application combinait métriques gouvernées et lineage avec un workflow de feedback reposant sur Lakebase.

Les applications doivent aussi permettre la saisie de données, conserver leur état et déclencher des actions. Lakebase offre aux équipes une base de données transactionnelle directement aux côtés du lakehouse. Il devient ainsi plus simple de construire des capacités opérationnelles à proximité des données gouvernées déjà en place, plutôt que d'exporter les données analytiques vers une pile applicative distincte.

Pour nous, ce fut l'un des changements les plus intéressants de la journée. Le lakehouse n'était plus seulement un endroit où les données sont analysées. Il est devenu le fondement des applications construites autour de ces données. 

Simplifier l'infrastructure ne fait pas disparaître les décisions d'ingénierie. Lakebase supprime une part importante du travail opérationnel, et le développement assisté par l'IA peut accélérer encore davantage l'implémentation. Mais cela ne dispense pas de concevoir un modèle de données solide.

Les clés primaires, les index et les schémas d'accès comptent toujours. Tout comme le choix de ce qui relève de la base opérationnelle, de ce qui doit rester analytique, et de la manière dont les données doivent circuler entre les deux.

C'était visible tout au long du hackathon. Les équipes pouvaient construire rapidement et, lorsque des questions d'architecture ou de bonnes pratiques se posaient, elles se tournaient vers nous. C'est précisément pour cela que nous étions là, et c'est là qu'ELCA apporte de la valeur : en associant expertise de la plateforme et expérience d'ingénierie au développement assisté par l'IA, afin que les accélérateurs de la plateforme mènent à la bonne solution, et pas simplement à une implémentation plus rapide.