2 Oui, il est possible d’exploiter un data lakehouse sur un stockage objet sur site, et de plus en plus de banques, d’administrations, de fournisseurs d’énergie, d’industriels et d’organismes de recherche le font. Le modèle lakehouse associe le stockage économique et évolutif d’un data lake aux fonctions de fiabilité et de performance d’un entrepôt de données, grâce à des formats de tables ouverts posés sur un stockage objet. Comme la couche de stockage parle l’API S3, l’architecture qui fonctionne dans le cloud public peut fonctionner dans votre propre centre de données, sur votre matériel et sous votre contrôle. Cet article explique comment se construit un data lakehouse sur site, ce qu’il exige du stockage objet, la place des moteurs de requêtes et des catalogues, et dans quels cas le sur site est plus pertinent que le cloud. Il s’adresse aux architectes de plateformes de données. Pour le contexte, consultez data lake ou entrepôt de données (en anglais) et le stockage objet pour les data lakes (en anglais). Qu’est-ce qu’un lakehouse ? Un data lakehouse stocke les données dans des formats de fichiers ouverts, généralement Parquet, sur un stockage objet, et ajoute une couche de format de table qui apporte des fonctions de type base de données : Transactions ACID (en anglais) : les processus d’écriture et de lecture concurrents voient des données cohérentes. Évolution du schéma : les tables peuvent changer sans réécrire toutes les données. Partitionnement et élagage : les requêtes ne lisent que les fichiers pertinents. Voyage dans le temps : les utilisateurs peuvent interroger des versions antérieures d’une table. Gestion des snapshots : pour des lectures cohérentes et le retour arrière. Les moteurs distribués de requêtes et de traitement lisent et écrivent ces tables directement sur le stockage objet. Un catalogue suit les tables et leurs métadonnées courantes. Les couches d’un lakehouse sur site Stockage Le stockage objet compatible S3 conserve les fichiers de données, les métadonnées de tables et les manifestes. Il doit monter jusqu’au pétaoctet, soutenir un débit élevé et gérer un grand nombre d’objets. C’est la fondation : toutes les autres couches en dépendent. Format de table Les formats de tables ouverts définissent la représentation des tables sur le stockage. Les principaux formats sont largement pris en charge par les moteurs et fonctionnent bien sur un stockage compatible S3. Catalogue Un catalogue associe les noms de tables à l’emplacement de leurs métadonnées courantes et coordonne les commits. Les options comprennent des services de metastore hérités d’anciennes plateformes de données, des services de catalogue REST et des catalogues adossés à une base de données. Le catalogue doit être hautement disponible, puisque chaque requête en dépend. Moteurs de requêtes et de traitement Les moteurs SQL distribués servent l’analytique interactive et la business intelligence. Les frameworks de traitement distribué prennent en charge le traitement à grande échelle et l’ingénierie des données. D’autres moteurs servent le streaming, le machine learning et des charges spécialisées. Comme les données sont dans des formats ouverts, plusieurs moteurs peuvent partager les mêmes tables. Gouvernance et sécurité Le contrôle d’accès, l’audit, le lignage des données et le chiffrement couvrent toutes les couches. Dans les environnements réglementés, ils comptent autant que les performances. Ce que le lakehouse exige du stockage objet Compatibilité avec l’API S3 Les moteurs et les formats de tables utilisent intensivement les opérations S3 : GET avec plages d’octets, PUT et téléversements en plusieurs parties, LIST, HEAD et DELETE. Le stockage doit les implémenter correctement et de façon cohérente. La cohérence forte en lecture après écriture est essentielle pour les commits de tables et les opérations de métadonnées. Débit agrégé élevé Les requêtes analytiques balaient de gros volumes de données en parallèle. Le stockage doit fournir un débit de lecture agrégé élevé sur de nombreuses connexions simultanées, et progresser à mesure que des nœuds sont ajoutés. Performances sur les petits objets et les métadonnées Les métadonnées de tables, les manifestes et les petits fichiers de données génèrent de nombreuses petites requêtes. Le stockage doit gérer des taux de requêtes élevés avec une faible latence, et pas seulement de grosses lectures séquentielles. Évolutivité Les lakehouses grossissent vite à mesure que de nouvelles sources s’ajoutent et que l’historique est conservé. Le stockage doit monter à de nombreux pétaoctets et des milliards d’objets sans mises à niveau perturbatrices. Protection et résilience des données Le codage à effacement protège les données au sein d’un site, et la réplication ou les architectures multisites protègent contre la perte d’un site. Le versionnage et le verrouillage d’objets peuvent protéger les données critiques contre la suppression accidentelle ou malveillante. Sécurité Chiffrement au repos et en transit, politiques d’accès fines, intégration aux systèmes d’identité et journalisation d’audit. L’article sur les politiques d’accès S3 (en anglais) traite de leur conception. Pourquoi exploiter un lakehouse sur site Souveraineté des données et réglementation De nombreuses organisations doivent conserver leurs données dans leur pays ou leurs propres installations. En Europe, les établissements financiers sont soumis à DORA et aux attentes des superviseurs nationaux ; les organismes publics et les opérateurs d’infrastructures critiques à NIS2 et aux règles de sécurité nationale. Les administrations et les agences de défense aux États-Unis, au Royaume-Uni, en France, en Allemagne, au Japon et ailleurs exigent souvent que les données restent dans des installations agréées. Un lakehouse sur site garde les données sous contrôle direct. Prévisibilité des coûts Les charges analytiques lisent beaucoup de données. Dans le cloud public, les frais de stockage, de requêtes et de transfert augmentent avec l’usage. Sur site, les coûts sont en grande partie fixes et prévisibles, ce qui convient aux charges régulières et lourdes. Proximité des sources de données et du calcul Les données produites sur site, par des systèmes de trading, des capteurs, des lignes de production ou des instruments scientifiques, peuvent être analysées là où elles arrivent, sans être déplacées vers le cloud. Les clusters GPU et CPU sur site peuvent lire directement dans le stockage objet local. Éviter la dépendance Les formats de tables ouverts sur un stockage compatible S3 gardent les données portables entre moteurs et entre sur site et cloud. Quand le cloud peut mieux convenir Les lakehouses dans le cloud peuvent se justifier pour les organisations aux charges très variables, aux petites équipes, aux sources de données natives du cloud ou sans infrastructure sur site. Beaucoup d’organisations finissent en mode hybride : charges sensibles ou lourdes sur site, autres charges dans le cloud, avec des formats ouverts partagés. Migrer depuis Hadoop De nombreuses plateformes de données sur site ont démarré sur Hadoop avec HDFS. Passer à un lakehouse sur stockage objet sépare le calcul du stockage, réduit la complexité d’exploitation et permet d’adopter des moteurs modernes. Voir la migration de HDFS vers le stockage objet. IA et machine learning sur le lakehouse Les lakehouses alimentent de plus en plus l’IA et le machine learning en plus de la business intelligence. L’ingénierie des caractéristiques, l’entraînement des modèles et les pipelines de recherche augmentée lisent de gros volumes de données dans les mêmes tables que celles interrogées par les analystes. Garder ces charges sur une seule copie gouvernée des données, plutôt que d’exporter des extraits vers des systèmes séparés, réduit la duplication et garde un lignage clair. Cela relève toutefois l’exigence de débit du stockage, car les entraînements lisent les données par grandes rafales parallèles. Concevoir dès le départ la couche de stockage objet pour les accès analytiques et d’IA évite de devoir créer plus tard une seconde plateforme de données déconnectée. Une architecture de référence type sur site Une architecture sur site courante se présente ainsi : un cluster de stockage objet compatible S3 réparti sur plusieurs baies, ou sur deux sites pour la résilience ; un service de catalogue hautement disponible adossé à une base de données répliquée ; un moteur SQL distribué pour les requêtes interactives et les outils décisionnels ; un cluster de traitement, souvent à base de conteneurs, pour l’ingénierie des données ; une ingestion en flux qui écrit dans des tables au format ouvert ; et une couche de gouvernance qui applique les politiques d’accès et enregistre le lignage. Les clusters de calcul évoluent indépendamment du stockage : ajouter des analystes n’oblige pas à ajouter de la capacité, et ajouter des années d’historique n’oblige pas à ajouter du calcul. Dimensionner un lakehouse sur site Capacité : données actuelles, rythme de croissance, durée de conservation et historique des tables issu des snapshots, plus le surcoût de protection. Débit : charge maximale simultanée de requêtes et de traitement, mesurée en Go par seconde agrégés. Taux de requêtes : activité de métadonnées et de petits fichiers, en particulier pour les tables souvent mises à jour. Réseau : bande passante entre clusters de calcul et stockage ; les moteurs analytiques peuvent saturer les liens. Croissance : prévoir l’extension par petits incréments. Exploiter le lakehouse Les lakehouses nécessitent une maintenance régulière au niveau du format de table : compactage des petits fichiers, expiration des anciens snapshots et suppression des fichiers orphelins. Ces tâches maintiennent de bonnes performances de requêtes et maîtrisent la consommation de stockage. Supervisez le débit, la latence et la capacité du stockage en même temps que les performances des moteurs, car un stockage lent se traduit par des requêtes lentes. Liste de contrôle : data lakehouse sur site Choisir un format de table ouvert largement pris en charge par les moteurs. Sélectionner un stockage objet compatible S3 à cohérence forte et à débit élevé. Déployer un catalogue hautement disponible. Dimensionner le stockage pour la capacité, le débit, les taux de requêtes et la croissance. Fournir un réseau à haut débit entre calcul et stockage. Mettre en place contrôle d’accès, chiffrement et journalisation d’audit. Planifier la maintenance des tables : compactage et expiration des snapshots. Concevoir une protection multisite pour les données critiques. Planifier la migration depuis les plateformes historiques comme HDFS. En résumé Un data lakehouse sur site est non seulement possible, mais de plus en plus courant. Les formats de tables ouverts, un catalogue fiable et des moteurs de requêtes modernes fonctionnent sur un stockage objet compatible S3 dans votre propre centre de données : vous obtenez une architecture de type cloud avec le contrôle du sur site, des coûts prévisibles et des données qui restent là où la réglementation l’exige. La couche de stockage doit offrir la compatibilité S3, une cohérence forte, un débit élevé et l’évolutivité ; avec ces bases, le reste de la pile peut évoluer librement. Questions fréquentes Un data lakehouse peut-il fonctionner sur site ? Oui. Les formats de tables ouverts et les moteurs de requêtes fonctionnent sur un stockage objet compatible S3 dans votre propre centre de données, comme dans le cloud public. Quel format de table fonctionne le mieux sur site ? Choisissez un format largement pris en charge par les moteurs qu’utilisent vos équipes. Côté stockage, les principaux formats ont des exigences presque identiques. De quoi le stockage objet a-t-il besoin pour un lakehouse ? Compatibilité avec l’API S3, cohérence forte en lecture après écriture, débit agrégé élevé, bonnes performances sur les petits objets et évolutivité. Pourquoi choisir le sur site plutôt que le cloud pour un lakehouse ? Pour la souveraineté des données, les exigences réglementaires, la prévisibilité des coûts des charges lourdes, la proximité des sources de données et la portabilité. Ai-je encore besoin de Hadoop pour un data lake sur site ? Non. Beaucoup d’organisations passent de HDFS au stockage objet avec des moteurs modernes, en séparant calcul et stockage. Pour aller plus loin Formats de tables ouverts sur S3 sur site Performances des moteurs SQL sur stockage objet Migration de HDFS vers le stockage objet Data lakes souverains Stockage objet pour les data lakes (en anglais)
