Le Lakehouse sémantique expliqué

Lacs de données et couches sémantiques existent depuis longtemps - chacun vivant dans ses propres jardins clos, étroitement couplé à des cas d'utilisation assez étroits. Alors que l'infrastructure de données et d'analyse migre vers le cloud, beaucoup se demandent comment ces composants technologiques fondamentaux s'intègrent dans la pile de données et d'analyse moderne. Dans cet article, nous allons nous plonger dans la façon dont un lac de données et une couche sémantique bouleversent la relation traditionnelle entre les lacs de données et l'infrastructure d'analyse. Nous apprendrons comment un Lakehouse sémantique peut considérablement simplifier architectures de données cloud, éliminez les déplacements de données inutiles et réduisez le délai de rentabilisation et les coûts liés au cloud.

L'architecture traditionnelle des données et de l'analyse

En 2006, Amazon a introduit Amazon Web Services (AWS) comme un nouveau moyen de décharger le centre de données sur site vers le cloud. Un service AWS de base était son magasin de données de fichiers et avec cela, le premier lac de données cloud, Amazon S3, est né. D'autres fournisseurs de cloud introduiraient leurs propres versions d'infrastructure de lac de données cloud par la suite.

Pendant la plus grande partie de sa vie, le lac de données cloud a été relégué au rôle de stupide, bon marché stockage de données - Un mise en scène zone pour les données brutes, jusqu'à ce que les données puissent être transformées en quelque chose d'utile. Pour l'analyse, le lac de données servait d'enclos pour les données jusqu'à ce qu'elles puissent être copiées et chargées dans une plate-forme d'analyse optimisée, généralement un entrepôt de données cloud relationnel alimentant soit des cubes OLAP, soit des extraits de données d'outils de business intelligence (BI) propriétaires comme Tableau Hyper ou Power BI Premium, ou tout ce qui précède. En raison de ce modèle de traitement, les données devaient être stockées au moins deux fois, une fois sous leur forme brute et une fois sous leur forme « optimisée pour l'analyse ». 

Sans surprise, la plupart des architectures d'analyse cloud traditionnelles ressemblent au schéma ci-dessous :

Comme vous pouvez le constater, « l'entrepôt d'analyses » est responsable de la majorité des fonctions qui fournissent des analyses aux consommateurs. Le problème avec cette architecture est le suivant :

1. Les données sont stockées deux fois, ce qui augmente les coûts et crée une complexité opérationnelle.
2. Les données de l'entrepôt d'analyse sont un instantané, ce qui signifie que les données sont instantanément obsolètes.
3. Les données de l'entrepôt d'analyse sont généralement un sous-ensemble des données du lac de données, ce qui limite les questions que les consommateurs peuvent poser.
4. L'entrepôt d'analyse évolue séparément et différemment de la plate-forme de données cloud, ce qui entraîne des coûts supplémentaires, des problèmes de sécurité et une complexité opérationnelle.

Compte tenu de ces inconvénients, vous pourriez vous demander "Pourquoi les architectes de données cloud choisiraient-ils ce modèle de conception ?" La réponse réside dans les exigences des consommateurs d'analytique. Alors que le lac de données pourrait théoriquement servir des requêtes analytiques directement aux consommateurs, en pratique, le lac de données est trop lent et incompatible avec les outils d'analyse populaires. 

Si seulement le lac de données pouvait offrir les avantages d'un entrepôt d'analyse et nous pouvions éviter de stocker les données deux fois !

La naissance du Data Lakehouse

Le terme « Lakehouse » a fait ses débuts en 2020 avec le livre blanc séminal de Databricks "Qu'est-ce qu'un Lakehouse?" de Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia et Ali Ghodsi. Les auteurs ont introduit l'idée que le lac de données pourrait servir de moteur pour fournir des analyses, et pas seulement un magasin de fichiers statiques.

Les fournisseurs de Data Lakehouse ont concrétisé leur vision en introduisant des moteurs de requête évolutifs à grande vitesse qui fonctionnent sur des fichiers de données brutes dans le lac de données et exposent une interface SQL standard ANSI. Avec cette innovation clé, les partisans de cette architecture affirment que les lacs de données peuvent se comporter comme un entrepôt d'analyse, sans qu'il soit nécessaire de dupliquer les données.

Cependant, il s'avère que l'entrepôt d'analyse remplit d'autres fonctions vitales qui ne sont pas satisfaites par la seule architecture de data lakehouse, notamment :

1. Fournir des requêtes "rapides de pensée" (requêtes en moins de 2 secondes) de manière cohérente sur un large éventail de requêtes.
2. Présenter une couche sémantique conviviale pour les entreprises qui permet aux consommateurs de poser des questions sans avoir besoin d'écrire du SQL.
3. Appliquer la gouvernance et la sécurité des données au moment de la requête.

Donc, pour qu'un lac de données remplace véritablement l'entrepôt d'analyse, nous avons besoin d'autre chose.

Le rôle de la couche sémantique

J'ai beaucoup écrit sur le rôle du couche sémantique dans la pile de données moderne. Pour résumer, une couche sémantique est une vue logique des données d'entreprise qui exploite la technologie de virtualisation des données pour traduire les données physiques en données conviviales au moment de la requête. 

En ajoutant une plate-forme de couche sémantique au-dessus d'un lac de données, nous pouvons éliminer complètement les fonctions d'entrepôt d'analyse car la plate-forme de couche sémantique :

1. Fournit des « requêtes rapides » sur le Lakehouse de données à l'aide de la virtualisation des données et du réglage automatisé des performances des requêtes.
2. Fournit une couche sémantique conviviale qui remplace les vues sémantiques propriétaires intégrées à chaque outil de BI et permet aux utilisateurs professionnels de poser des questions sans avoir à écrire de requêtes SQL.
3. Assure la gouvernance et la sécurité des données au moment de la requête.

Une plate-forme de couche sémantique fournit les pièces manquantes qui manquent au data lakehouse. En combinant une couche sémantique avec un data lakehouse, les organisations peuvent :

1. Éliminez les copies de données et simplifiez les pipelines de données.
2. Consolider la gouvernance et la sécurité des données.
3. Fournissez une « source unique de vérité » pour les mesures commerciales.
4. Réduisez la complexité opérationnelle en conservant les données dans le lac de données.
5. Fournissez un accès à plus de données et à des données plus opportunes aux consommateurs d'analyses.

The Semantic Lakehouse : tout le monde y gagne

Tout le monde y gagne avec cette architecture. Les consommateurs ont accès à des données plus précises sans latence. Les équipes informatiques et d'ingénierie des données ont moins de données à déplacer et à transformer. Les finances dépensent moins d'argent sur les coûts d'infrastructure cloud. 

Comme vous pouvez le voir, en combinant une couche sémantique avec un lac de données, les organisations peuvent simplifier leurs opérations de données et d'analyse, et fournir plus de données, plus rapidement, à plus de consommateurs, à moindre coût.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://www.dataversity.net/the-semantic-lakehouse-explained/