Bien comprendre les services Data Lake et Data Warehouse d'AWS

Data warehouse vs Data Lake

Les entreprises utilisent les lacs et les entrepôts de données pour générer de la valeur, mais pour des raisons différentes. « Les Data Lakes sont les plus adaptés quand les organisations n’ont pas une définition stricte des usages analytiques », déclare Justin Richie, directeur data science pour Nerdery, un consultant IT.

A l’inverse, les Data Warehouses fonctionnent mieux quand la compagnie utilisatrice a défini des logiques économiques et stratégiques précises, parce qu’il est difficile de les modifier après leur adoption. Cependant, ces deux architectures ne sont pas exclusives et les entreprises peuvent les utiliser en tandem pour de meilleurs résultats.

En principe, un lac de données facilite le stockage de n’importe quel type de données. Cela s’avère très utile pour s’adapter aux workloads imprévus. Sur AWS, la plupart des Data Lakes repose sur le service S3. « Le stockage objet s’accommode très bien des données non structurées », déclare Sean Feeney, directeur des pratiques d’ingénierie cloud chez Nerdery.

De son côté, un entrepôt de données facilite la gestion des données structurées pour des usages analytiques ou des cas d’usage communs. En ce sens, Amazon Redshift est le choix par défaut pour stocker des données relationnelles dans le cloud chez AWS.

Le géant du cloud fournit deux services pour requêter les informations non structurées dans S3 : Athena et Redshift Spectrum. Selon Sean Feeney, cela apporte une architecture dynamique pour lancer des requêtes sur des objets.

Une infrastructure Big Data implique également la sélection de services pour déplacer les données suivant les différentes charges de travail. Beaucoup de produits AWS pompent les données en entrée et en sortie de S3 ainsi que de RedShift : Datasync, Database Migration Service, Kinesis, Storage Gateway, Snowball, Data Pipeline, Glue et enfin Snowmobile.

Commencer avec une idée précise en tête

Finalement, les services liés à ces architectures poussés par AWS visent à augmenter la vitesse de développement des solutions analytiques. Les entreprises devraient avoir en tête les objectifs visés au moment d’établir leur stratégie analytique et Big Data. Cela les aiderait à choisir le service de stockage AWS le plus approprié selon leurs besoins.

« Il faut penser aux différents aspects des systèmes de gestion de données en vue de déployer des applications analytiques sur AWS, déclare Manoj Karanth, responsable data science et ingénierie chez MindTree. En premier lieu, il convient de collecter et d’ingérer les données brutes après nettoyage. Dans un second temps, il faut créer des data views, des tables logiques, basées sur la consommation de données.

Pour ce qui est de l’ingestion continue, « Glue est bon framework ETL », selon Manoj Karanth. Dans le cas où cette étape concerne des événements et n’est pas fréquente, « cela peut être plus efficace d’utiliser une combinaison d’AWS Lambda et des Steps Functions pour gérer le traitement et les flux de travail », ajoute-t-il.

Les entreprises peuvent stocker les données brutes sur S3 et choisir leur mode de consommation. Selon le responsable, Amazon Aurora et RDS (Relational Database Service) sont de bons choix pour la gestion des requêtes basiques, tandis que Redshift est meilleure pour effectuer des rapports BI impliquant beaucoup d’agrégations de données. Concernant l’exécution des requêtes, il s’aperçoit également qu’Athena fournit des performances similaires, voire supérieures dans de nombreux scénarios.

« In fine, la meilleure façon de choisir la bonne offre AWS, c’est de mesure le coût par indicateur », déclare Manoj Karanth. Une meilleure maîtrise des coûts implique de sélectionner des services cloud différents pour le stockage et pour l’analytique, considère-t-il.

Lake Formation vs Redshift

AWS Lake formation et Redshift ne sont pas concurrents au sens traditionnel du terme, puisque Redshift peut être intégré avec le premier nommé. « Mais vous ne pouvez pas interchanger ces deux services », déclare Erik Gfesser, architecte principal chez SPR.

Lake Formation, dont la disponibilité générale a été annoncée en août 2019, est une couche d’abstraction par-dessus S3, Glue, Redshift Spectrum et Athena qui offriraient un catalogue de données séparées et des schémas d’ingestion vers S3 depuis des sources variées. Selon Sean Feeney, « c’est un bon outil pour construire un nouveau Data Lake sur AWS ou pour séparer la gestion de l’accès des données, des espaces de stockage eux-mêmes ».

Redshift est l’option native pour construire un Data Warehouse relationnel. C’est un service de base de données pensé pour un entrepôt supportant des workloads analytiques impliquant des requêtes sur des pétaoctets de données en vue d’effectuer des rapports et de la data visualization. Lake Formation peut en principe charger les données dans Redshift à cet effet.

Les clients d’AWS peuvent utiliser Redshift Spectrum de la même manière qu’Athena pour effectuer les requêtes SQL dans un Data Lake S3. Cela permettrait également de rejoindre les données avec celles présentes dans les tables Redshift, et ainsi profiter d’une approche hybride du stockage. « C'est une bonne option pour les entreprises qui souhaitent bénéficier des capacités de Redshift, mais qui souhaitent également sortir du marché de la gestion de clusters et adopter la technologie serverless », déclare Sean Feeney.

L’intégration de données avec Lake Formation

Lake Formation est construit à partir des capacités de Glue, soit quatre composants : un catalogue de données (Data Catalog), un robot d’indexation (Crawlers), la gestion des tâches (Jobs) et des flux de travail (Workflows). Combinés, ils cataloguent et traitent les données en provenance des systèmes sources.

Data Catalog repose sur Apache Hive Metastore, un catalogue qui stocke les métadonnées et qui peut être utilisé avec de multiples services AWS et des produits tiers. Avec Crawlers, les utilisateurs peuvent automatiser la manière dont ces métadonnées sont rassemblées au fur et à mesure que les données sont ingérées. Workflows sert, lui, à connecter les services compatibles avec Lake Formation. Les « Glue Jobs » peuvent traiter et charger les données à l’aide de scripts shell Python tout comme ceux d’Apache Spark ETL. Selon Erik Gfesser, les scripts shell Python gèrent les tâches génériques d’un workflow, tandis qu’un job Spark utilise l’environnement serverless lié à Apache Spark.

Redshift conserve une approche traditionnelle

Pour développer des applications Big Data à partir d’un DWaaS, Redshift épouse une approche traditionnelle. Toutefois, cette technologie demande plus d’administration et de maintenance au fur et à mesure que le nombre de données et de recherches s’accumulent. Erik Gfesser assure que le service gère moins de formats de données qu’Athena.

Par ailleurs, Redshift est véritablement pensé pour des volumes importants et c’est dans ce contexte qu’il devient pertinent. « La vitesse des requêtes peut décevoir les utilisateurs, comparée à celle offerte par Athena », ajoute-t-il.

« Même si les fonctionnalités de Redshift Spectrum empiètent sur celles d’Athena, le coût est relativement plus élevé en comparaison de ce dernier. Spectrum nécessite un cluster Redshift, alors que le modèle économique d’Athena repose sur le volume de requêtes », déclare le consultant.

Par ailleurs, avec Redshift, les utilisateurs doivent charger les sources de données dans cette base spécifique. Athena fonctionne avec les données présentes dans S3. Spectrum dispose également de cet atout, mais il n’est pas totalement intégré et ne semble pas utile à moins que les données du client soient déjà dans des tables Redshift.

Comment tirer le meilleur des services AWS ?

Idéalement, les entreprises combinent les Data Lakes et les Data Warehouses. Les premiers servent à la découverte de logiques, les seconds permettent de les appliquer.

Les grands groupes ont souvent un lac de données et plusieurs entrepôts, parce que ses divisions utilisent les informations de manière différente. Beaucoup d’éditeurs proposent les deux types de solution. « Les outils SQL sont souvent les mêmes entre les lacs de données et les entrepôts de données », déclare Justin Richie, de Nerdery.

Pour Ashish Thusoo, co-fondateur et CEO de Qubole, les organisations devraient commencer avec un système de rapports BI conçus pour des jeux de données standardisés, pré agrégés. Au fur et à mesure que les utilisateurs explorent ces ressources, ils peuvent à nouveau fouiller le Data Lake pour affiner leurs analyses.

« De nombreuses entreprises disposent d'un lac pour leurs données brutes non structurées et des entrepôts pour celles qui sont raffinées », explique Hannu Valtonen, vice-président produit chez Aiven. Cette approche permettrait de faciliter et d’accélérer les analyses, plutôt que de transformer des informations tirées d’un lac en partant de zéro.

Ainsi, les sociétés préservent un historique de données brutes pour une utilisation future au sein du Data Lake. Un traitement effectué à même cette infrastructure sera plus lent et plus coûteux qu’en utilisant un Data Warehouse, car les data scientists doivent choisir, préparer les données et écrire les algorithmes associés.

« Comme les coûts de stockage ont rapidement baissé, il est devenu possible pour de plus en plus d'entreprises de conserver des masses de données sous leur forme brute dans un Data Lake », explique Hannu Valtonen. Enfin, elles pourraient les conserver indéfiniment, en attendant le jour où elles pourront être exploitées.