L’avenir du Data Lakehouse – Ouvert

Les clients de Cloudera exploitent certains des plus grands lacs de données au monde. Ces lacs alimentent l’analyse de données à grande échelle, l’intelligence d’affaires (BI) et les cas d’utilisation d’apprentissage automatique, y compris les entrepôts de données d’entreprise. Ces dernières années, le terme « data lakehouse » a été inventé pour décrire ce modèle architectural d’analyse tabulaire sur les données du lac de données. Pressés de s’approprier ce terme, de nombreux éditeurs ont perdu de vue que l’ouverture d’une architecture de données est ce qui garantit sa pérennité et sa pérennité.

Sur les entrepôts de données et les lacs de données

Les lacs de données et les entrepôts de données unifient de grands volumes et variétés de données dans un emplacement central. Mais avec des visions du monde architecturales très différentes. Les entrepôts sont intégrés verticalement pour SQL Analytics, tandis que Lakes privilégie la flexibilité des méthodes analytiques au-delà de SQL.

Afin de tirer parti des avantages des deux mondes (flexibilité de l’analyse dans les lacs de données et SQL simple et rapide dans les entrepôts de données), les entreprises ont souvent déployé des lacs de données pour compléter leurs entrepôts de données, le lac de données alimentant un système d’entrepôt de données comme dernière étape. d’un pipeline d’extraction, de transformation, de chargement (ETL) ou d’ELT. Ce faisant, ils ont accepté le verrouillage résultant de leurs données dans des entrepôts.

Mais il y avait un meilleur moyen : entrer dans le Hive Metastore, l’un des succès dormants de la plate-forme de données de la dernière décennie. Au fur et à mesure que les cas d’utilisation mûrissaient, nous avons constaté le besoin à la fois d’analyses BI efficaces et interactives et d’une sémantique transactionnelle pour modifier les données.

Itérations de la maison du lac

La première génération de Hive Metastore a tenté de répondre aux considérations de performances pour exécuter SQL efficacement sur un lac de données. Il a fourni le concept d’une base de données, de schémas et de tables pour décrire la structure d’un lac de données d’une manière qui permet aux outils de BI de parcourir efficacement les données. Il a ajouté des métadonnées décrivant la disposition logique et physique des données, permettant des optimiseurs basés sur les coûts, l’élagage dynamique des partitions et un certain nombre d’améliorations de performances clés ciblées sur l’analyse SQL.

La deuxième génération de Hive Metastore a ajouté la prise en charge des mises à jour transactionnelles avec Hive ACID. La maison du lac, bien qu’elle n’ait pas encore de nom, était très florissante. Les transactions ont permis les cas d’utilisation d’ingestion et d’insertions/mises à jour/suppressions (ou MERGE) continus, ce qui a ouvert l’interrogation, les capacités et les migrations de style entrepôt de données d’autres systèmes d’entreposage vers des lacs de données. Cela a été extrêmement précieux pour beaucoup de nos clients.

Des projets comme Delta Lake ont adopté une approche différente pour résoudre ce problème. Delta Lake a ajouté la prise en charge des transactions aux données d’un lac. Cela a permis la conservation des données et a donné la possibilité d’exécuter des analyses de type entrepôt de données sur le lac de données.

Quelque part le long de cette chronologie, le nom « data lakehouse » a été inventé pour ce modèle d’architecture. Nous pensons que les maisons du lac sont un excellent moyen de définir succinctement ce modèle et ont gagné en notoriété très rapidement parmi les clients et l’industrie.

Que nous ont dit les clients ?

Au cours des dernières années, alors que de nouveaux types de données sont nés et que de nouveaux moteurs de traitement de données sont apparus pour simplifier l’analyse, les entreprises en sont venues à s’attendre à ce que le meilleur des deux mondes exige vraiment flexibilité du moteur analytique. Si des données volumineuses et précieuses pour l’entreprise sont gérées, l’entreprise doit être ouverte pour choisir différents moteurs d’analyse, voire différents fournisseurs.

Le modèle de la maison du lac, tel qu’il est mis en œuvre, avait une contradiction critique à cœur : alors que les lacs étaient ouverts, les maisons du lac ne l’étaient pas.

Le metastore Hive a suivi une évolution Hive-first, avant d’ajouter des moteurs comme Impala, Spark, entre autres. Le lac Delta a eu une évolution lourde en étincelles; les options des clients diminuent rapidement s’ils ont besoin de liberté pour choisir un moteur différent de celui qui est primordial pour le format de tableau.

Les clients ont exigé plus dès le départ. Plus de formats, plus de moteurs, plus d’interopérabilité. Aujourd’hui, le métastore Hive est utilisé à partir de plusieurs moteurs et avec plusieurs options de stockage. Hive et Spark bien sûr, mais aussi Presto, Impala, et bien d’autres. Le métastore Hive a évolué de manière organique pour prendre en charge ces cas d’utilisation, de sorte que l’intégration était souvent complexe et sujette aux erreurs.

Un Lakehouse de données ouvertes conçu avec ce besoin d’interopérabilité résout ce problème architectural à la base. Cela rendra mal à l’aise ceux qui sont « tout compris » sur une seule plate-forme, mais l’innovation axée sur la communauté consiste à résoudre les problèmes du monde réel de manière pragmatique avec les meilleurs outils et à surmonter le blocage des fournisseurs, qu’ils approuvent ou non.

Une cabane à ciel ouvert et la naissance d’Apache Iceberg

Apache Iceberg a été conçu dès le départ dans le but d’être facilement interopérable sur plusieurs moteurs d’analyse et à l’échelle du cloud. Netflix, où cette innovation est née, est peut-être le meilleur exemple d’un Lac de données S3 à l’échelle de 100 Po qui devait être intégré dans un entrepôt de données. La format de tableau natif du cloud a été open source dans Apache Iceberg par ses créateurs.

La véritable superpuissance d’Apache Iceberg est sa communauté. Organiquement, au cours des trois dernières années, Apache Iceberg a ajouté une liste impressionnante d’intégrations de première classe avec une communauté florissante :

• Traitement de données et moteurs SQL Hive, Impala, Spark, PrestoDB, Trino, Flink
• Plusieurs formats de fichiers : Parquet, AVRO, ORC
• Grands utilisateurs de la communauté : Apple, LinkedIn, Adobe, Netflix, Expedia et autres
• Services gérés avec AWS Athena, Cloudera, EMR, Snowflake, Tencent, Alibaba, Dremio, Starburst

Ce qui fait prospérer cette communauté variée, c’est le besoin collectif de milliers d’entreprises de s’assurer que les lacs de données peuvent évoluer pour subsumer les entrepôts de données, tout en préservant la flexibilité analytique et l’ouverture entre les moteurs. Cela permet d’avoir une maison du lac ouverte : une qui offre une flexibilité analytique illimitée pour l’avenir.

Comment accueillons-nous Iceberg ?

Chez Cloudera, nous sommes fiers de nos racines open source et déterminés à enrichir la communauté. Depuis 2021, nous avons contribué à la communauté croissante d’Iceberg avec des centaines de contributions sur Impala, Hive, Spark et Iceberg. Nous avons étendu le Hive Metastore et ajouté des intégrations à nos nombreux moteurs open source pour tirer parti des tables Iceberg. Début 2022, nous avons activé un Aperçu technique d’Apache Iceberg dans Cloudera Data Platform permettant aux clients de Cloudera de réaliser la valeur de l’évolution des schémas d’Iceberg et des capacités de voyage dans le temps dans nos services d’entreposage de données, d’ingénierie de données et d’apprentissage automatique.

Nos clients nous ont toujours dit que les besoins analytiques évoluent rapidement, qu’il s’agisse de BI moderne, d’IA/ML, de science des données, ou plus. Le choix d’un Lakehouse de données ouvertes alimenté par Apache Iceberg donne aux entreprises la liberté de choix pour l’analyse.

Si vous voulez en savoir plus, rejoignez-nous le 21 juin sur notre webinaire avec Ryan Blue, co-créateur d’Apache Iceberg et Anjali Norwood, Big Data Compute Lead chez Netflix.