Comment construire une plateforme de données Lakehouse évolutive et rentable

Au cours de la dernière décennie, nous sommes passés d'entrepôts de données rigides à des lacs de données flexibles et, plus récemment, à des architectures lakehouse qui promettent de combiner le meilleur des deux mondes.

Pourtant, passer d'une génération de plateformes de données à la suivante s'avère plus difficile que prévu. Ceux qui sont déjà engagés dans ce parcours découvrent des défis et répètent des erreurs en transposant d'anciens modèles de conception dans de nouveaux systèmes.

Ayant aidé de nombreuses organisations à concevoir et à faire évoluer des plateformes de données modernes, j'ai constaté que le succès ne dépend pas des outils, mais de la discipline. Cet article est un guide pratique sur la manière de réussir la transition, ce qu'il faut éviter et comment traduire les choix techniques en valeur commerciale mesurable.

Pourquoi l'histoire pure du Big Data n'est plus utile

Si nous regardons en arrière, le mouvement du big data a commencé avec un rêve de stockage illimité et d'expérimentation sans fin. Vers le milieu des années 2010, les entreprises ont commencé à collecter tous les journaux, clics et transactions possibles, convaincues que le volume seul apporterait des informations. En pratique, cette croyance n'a fait que créer plus de complexité. Les lacs de données sont apparus comme le successeur à la mode des entrepôts, mais la plupart d'entre eux sont rapidement devenus des marécages de données, des endroits où l'information entre facilement mais revient rarement sous une forme utilisable.

En 2022, le secteur avait mûri et les questions avaient commencé à changer. Les équipes ne demandent plus combien de données elles peuvent stocker, mais comment elles peuvent faire confiance et utiliser ce qu'elles possèdent déjà. Le véritable défi aujourd'hui n'est pas la capacité mais la gouvernance, pas l'ingestion mais l'interprétation.

La leçon clé ici est simple. Collecter plus de données ne fait pas d'une entreprise une entreprise axée sur les données. Ce qui compte vraiment, c'est comprendre les données, maintenir une gouvernance appropriée et les utiliser efficacement.

Je recommande de définir la propriété de chaque ensemble de données, d'établir des politiques claires de rétention et de qualité, et de concentrer les efforts d'ingénierie sur les données qui soutiennent directement les décisions commerciales. Sans cette base, même le lakehouse le plus avancé finit par se transformer en marécage moderne.

Le Lakehouse comme point tournant

L'essor du lakehouse reflète exactement ce changement. Au lieu de choisir entre performance et flexibilité, le modèle lakehouse combine les deux. À la base, il utilise un stockage cloud peu coûteux dans des formats tels que Delta ou Iceberg, enrichis de métadonnées et de garanties transactionnelles. Le résultat est un système qui coûte aussi peu qu'un lac et se comporte comme un entrepôt lors des requêtes.

Cela est important pour les dirigeants d'entreprise car cela élimine le compromis constant entre un stockage bon marché pour les données historiques et des systèmes coûteux pour l'analytique en direct. Je suggère toujours de positionner votre lakehouse non pas comme un remplacement de tout le reste, mais comme une base partagée qui permet à la fois l'analytique traditionnelle et l'apprentissage automatique dans un seul environnement.

Dans un lakehouse, le même environnement peut prendre en charge un tableau de bord pour le directeur financier, un modèle d'apprentissage automatique qui prédit le comportement des clients et une requête ad hoc d'un analyste produit. Les données ne sont plus dupliquées entre les systèmes, ce qui simplifie la gouvernance et permet une optimisation naturelle des coûts.

Défis structurels et de gouvernance dans l'adoption du Data Lakehouse

Lorsque les entreprises passent d'entrepôts de données classiques ou de lacs de données à une architecture lakehouse plus flexible, la transition est rarement fluide. De nombreuses équipes copient les structures existantes de l'ancien entrepôt dans le nouvel environnement sans repenser leur objectif. Le résultat est l'émergence de silos de données, en d'autres termes, la fragmentation. Une version des données vit dans l'entrepôt, une autre dans le lac, et une troisième quelque part entre les deux. Évitez cela en redessinant les schémas pour le lakehouse à partir de zéro. Modélisez les données en fonction des modèles d'accès et des besoins des consommateurs plutôt que de la logique héritée de l'entrepôt.

Un autre problème récurrent est la normalisation. Qu'est-ce que je veux dire par là ? Les entrepôts sont construits sur des structures strictes et profondément normalisées avec des dizaines de tables interconnectées. Lorsque celles-ci sont copiées directement dans un lac, chaque requête nécessite une forêt de jointures. Les performances s'effondrent, les ingénieurs blâment l'infrastructure et le projet perd sa crédibilité. Au lieu de cela, dénormalisez là où cela améliore les performances et placez les entités liées plus près les unes des autres pour minimiser le shuffle. Traitez la conception des performances comme une partie de la modélisation des données, et non comme une optimisation ultérieure.

La gouvernance et le contrôle sont essentiels. Dans un lac de données, il y a souvent peu de supervision car les équipes travaillent directement avec des fichiers. Dans un entrepôt, des règles strictes s'appliquent telles que la sécurité au niveau des lignes, l'accès basé sur les rôles et des pistes d'audit détaillées. Un lakehouse doit trouver un équilibre en garantissant l'ouverture sans perdre la responsabilité. Vous devez mettre en œuvre l'accès basé sur les rôles et le suivi de la lignée dès le début. La gouvernance fonctionne mieux lorsqu'elle grandit avec la plateforme et devient la fondation de la confiance.

Les performances dépendent également d'une conception intelligente. Les entrepôts traditionnels s'appuient sur l'indexation automatique, mais dans les lakehouses, l'efficacité provient du partitionnement ou du clustering liquide, de la mise en cache et du choix des bons formats de fichiers pour l'analytique. Je recommande de traiter la stratégie de partitionnement et la disposition des fichiers comme des citoyens de première classe dans votre architecture.

L'optimisation des coûts est une autre promesse clé du lakehouse, mais elle ne vient pas automatiquement. Bien que le stockage cloud soit peu coûteux et que l'analytique puisse évoluer à la hausse ou à la baisse selon les besoins, ces avantages sont souvent compensés par une mauvaise conception des données et une croissance incontrôlée. Vous devez gérer activement les cycles de vie des ensembles de données et supprimer les copies inutilisées. Si ce processus est ignoré, les coûts du cloud augmenteront silencieusement au fil du temps.

L'optimisation des coûts comme règle numéro un

J'aimerais me concentrer plus en détail sur l'optimisation des coûts, car c'est l'un des principaux avantages de l'architecture lakehouse.

L'une des principales façons dont l'architecture lakehouse réduit les coûts est de minimiser le shuffle, c'est-à-dire le déplacement de données entre les systèmes ou les nœuds de traitement. Pour y parvenir, concevez toujours vos données de sorte que les entités liées soient stockées ensemble.

En conservant toutes les données au même endroit et en stockant les entités liées à proximité les unes des autres, le lakehouse élimine le besoin de jointures excessives et de transferts de données. Lorsque nous effectuons des analyses, par exemple lors de la construction d'un modèle d'apprentissage automatique pour l'analyse des clients, nous pouvons utiliser à la fois des données historiques et des données transactionnelles réelles sans les copier ou les déplacer entre les systèmes.

Un autre principe clé qui permet l'optimisation des coûts est le découplage du stockage et du calcul. Le stockage des données et le traitement des données évoluent indépendamment en fonction de la demande réelle. Nous ne payons que pour les ressources que nous utilisons au lieu de maintenir de grands systèmes à capacité fixe. Le stockage reste peu coûteux et évolutif, et la puissance de calcul peut être augmentée ou réduite selon les besoins. Cette flexibilité conduit à une réduction des coûts d'infrastructure et à des opérations de données plus efficaces. Commencez toujours petit et laissez l'autoscaling faire son travail. Surveillez l'utilisation et comprenez vos modèles de charge de travail avant de vous engager dans une capacité réservée.

Les clusters à mise à l'échelle automatique aident davantage à contrôler les coûts. Une charge de travail d'apprentissage automatique nécessite des ressources informatiques dans le cloud, des machines virtuelles avec de la mémoire et de la puissance de traitement similaires à un ordinateur ordinaire. Dans le passé, les entreprises achetaient ou louaient des serveurs physiques à l'avance et exécutaient des processus sur cette capacité fixe. Dans le cloud, nous payons pour le calcul en fonction de l'utilisation réelle, par unité de temps et par quantité de ressources. Je recommande fortement de commencer avec des tailles de cluster minimales, d'observer le comportement de mise à l'échelle et de fixer des limites supérieures pour éviter des coûts incontrôlés.

Choisir la bonne approche architecturale

Parlons de l'architecture lakehouse. À bien des égards, sa conception dépend de la façon dont nous structurons le modèle de données. L'approche la plus courante et la plus efficace est l'architecture en couches, ou médaillon, où chaque couche a un objectif spécifique et prend en charge différents types d'utilisateurs et de charges de travail.

— La première couche, souvent appelée brute ou bronze, est une copie directe des données source. Elle répond principalement aux besoins techniques et n'est conservée que pendant une courte période pour permettre un retraitement rapide si nécessaire. Elle doit être traitée comme un stockage temporaire.

— La deuxième couche, ou couche de normalisation, contient des données nettoyées et structurées, parfois jointes à d'autres tables comme les utilisateurs et les commandes. C'est là que les modèles d'apprentissage automatique sont souvent entraînés. Il est recommandé d'automatiser la validation des données et l'application du schéma à ce stade. Le maintien de la cohérence est plus précieux que le traitement de grands volumes de données.

— La couche finale, connue sous le nom de couche or, est l'endroit où vivent les données agrégées. Les tableaux de bord et les outils BI tels que Tableau ou Power BI se connectent généralement à cette couche pour accéder aux métriques et visualisations prêtes. Pourtant, tout ne peut pas être pré-calculé.

Chaque couche a un objectif, et ensemble, elles permettent à l'apprentissage automatique et à l'intelligence d'affaires de prospérer.

Vous devez aligner votre stratégie de couches sur les modèles de consommation. Les data scientists travaillent généralement avec la couche argent, et les cadres attendent des réponses de la couche or. La flexibilité est la véritable force du lakehouse, la capacité de servir plusieurs publics sans construire et maintenir plusieurs systèmes séparés.

Enseignements du terrain

Si je devais concevoir à partir de zéro, je ferais quelques choses différemment de la façon dont l'industrie a abordé les données dans le passé.

Voici les leçons que j'ai tirées d'implémentations réelles et ce que je recommande maintenant.

1. Commencer petit, livrer vite

Tout migrer en une seule fois n'est pas toujours optimal. Les entreprises essaient souvent de déplacer des téraoctets de données dans un nouveau système, pour découvrir que personne ne les utilise. Une meilleure voie est de commencer par un seul cas d'usage qui apporte une valeur commerciale claire, comme un moteur de recommandation, une tarification dynamique ou un modèle de rétention client. Le succès dans ce domaine fournit à la fois de la crédibilité et un modèle pour l'évolution.

1. Traduire les exigences commerciales tôt

Je traduirais les exigences commerciales en exigences techniques le plus tôt possible. Si un rapport doit filtrer par région, cette exigence implique un partitionnement par région au niveau du stockage. Si les analystes s'attendent à des mises à jour en temps quasi réel, cela guide les décisions concernant l'indexation ou la mise en cache. Sans cette traduction, la technologie s'éloigne des objectifs commerciaux et la confiance s'érode.

1. Faire correspondre la technologie à la capacité organisationnelle

Je ferais toujours correspondre la technologie aux capacités de l'organisation. Une entreprise avec une forte culture d'ingénierie peut préférer des composants open source et un contrôle maximal. Une entreprise avec des ressources techniques limitées peut être mieux servie par des services gérés qui exposent des interfaces SQL aux analystes. Il n'y a pas de solution universelle, ce qui compte, c'est d'aligner l'ambition avec la capacité.

Enfin, je remettrais en question l'hypothèse selon laquelle un lakehouse est simplement un meilleur lac. En réalité, c'est un paradigme différent. Il hérite de certaines caractéristiques des lacs et des entrepôts, mais n'est pas un remplacement pour tous les cas d'usage. Les charges de travail transactionnelles à haute fréquence, par exemple, peuvent encore nécessiter des systèmes spécialisés. Reconnaître ces limites évite la déception et garantit que le lakehouse est utilisé là où il excelle vraiment.