Bâtir un datalake sur AWS: quelles solutions ?

Bâtir un datalake sur AWS: quelles solutions ?

1800 1360 Patrick Marshall

Concrètement, qu’est ce qu’un datalake ?

Un datalake est un endroit où stocker de manière unifiée de larges volumes de données – souvent à l’échelle d’une entreprise entière -, qu’elles soient structurées, semi-structurées ou non structurées. On distingue souvent le datalake du data-warehouse, au sens où le premier fait office de dépôt « natif » de la donnée brute, sans limites de taille de fichiers ou de formats, alors que le second est une galaxie ordonnée de bases de données déjà structurées.

Pourquoi un datalake ?

On dispose souvent d’une myriade de sources de données applicatives, que l’on souhaite consolider au sein d’une structure plus globale. Cette structure doit permettre de garantir une agilité business, c’est à dire de donner aux équipes la possibilité de croiser des données issues de différentes sources métier pour en tirer de la valeur pour l’entreprise. Le datalake doit en outre être capable d’ingérer de la donnée avec une composante temps-réel (i.e logs applicatifs, IoT), de stocker cette donnée en vue d’être traitée par la suite pour des besoins analytiques, du reporting, ou tout autre recherche de valeur (machine learning…)

L’idée principale derrière la mise en place d’un datalake, outre la consolidation des données au sein d’un même entrepôt d’entreprise, est la réduction des coûts d’ownership et de stockage sur le long-terme.

Source: AWS

Quelle architecture pour mon datalake ?

Les différentes composantes et couches à prendre en compte lors de l’architecture d’un datalake sont les suivantes:

  • Ingestion: représente les connexions aux différentes sources externes et les processus de déversement vers notre datalake. Les données peuvent être déversées de manière « batch » ou en temps-réel.
  • Stockage: un stockage de type S3 ou HDFS, infiniment scalable, est de manière générale très peu couteux et bien adapté à ce besoin tant en termes de données structurées que de données non-structurées. C’est un point de chute pour l’ensemble des données au repos.
  • Exploration: les données stockées doivent pouvoir être requêtées facilement et de manière transparente, de préférence avec des langages déclaratifs usuels de type SQL.
  • ETL (extract, transform, load): l’étape appelée ici ETL est celle qui consiste à convertir de la donnée brute depuis l’étape de stockage vers un état structuré, et ce à des fins de traitement ultérieur.
  • Processing: on souhaite évidemment pouvoir manipuler, requêter et croiser les données, et ce quel que soit la fréquence d’input (batch, live), à des fins d’analyse et d’extraction de valeur ajoutée.
  • Opérations: on regroupera sous cette appellation tous les services ayant trait à la sécurité, aux performances globales, au monitoring, à l’audit, ou encore au management du catalogue de données. Un datalake correctement architecturé doit garantir une bonne disponibilité de la donnée – y compris sous la charge – ainsi qu’une bonne sécurité et intégrité via un monitoring et une restriction des accès à un grain très fin. Les opérations regroupent pour cela:
    • la gouvernance: la découverte de données est une étape importante de l’organisation de notre datalake et sa structuration générale. Cette étape est cruciale car elle va servir à constituer notre catalogue de données; on y trouvera des informations aussi cruciales que la source initiale, le format, la sémantique…
    • la sécurité: elle doit être implémentée dans chaque couche du datalake, du stockage (résilience et réplication), à la lecture des données et leur consommation (authentification et contrôle des accès aux datasets par les différentes équipes). Enfin, chaque accès doit pouvoir être loggé à des fins d’audit; un audit du catalogue de données permet d’évaluer la compliance aux différentes régulations ainsi que les risques liés à la manipulation de données sensibles.
    • la qualité: elle est une composante essentielle de l’architecture de notre datalake. En effet, la donnée sera la source de la valeur métier. Une donnée de mauvaise qualité entrainera à coup sûr une valeur métier moindre.
    • le lineage: la couche de Data Lineage doit permettre de « retracer » les évolutions apportées à la donnée par rapport à son ingestion initiale depuis une « golden source ». En effet, lors d’audit, on cherchera à traquer les changements apportés à la donnée par les différentes applications, et les auteurs de ces changements.

Quelques principes de base à respecter lors de la mise en place d’un datalake

  • De manière générale, pour piloter au mieux les coûts de mise en place ainsi que les projections de coût long terme, il convient de se poser la question de la structuration de la donnée, de sa fréquence de mise à jour, mais aussi et surtout ce que l’on souhaite en faire.
  • Modulariser son datalake de manière à séparer les composantes listées ci-dessus. Stockage, ingestion, administration, qualité, visualisation… doivent pouvoir être gérées indépendamment.
  • Un datalake sera différent d’une entreprise à l’autre de par la variété des métiers, des approches et des besoins. Les spécificités de l’entreprise et du métier doivent être prises en compte dès la conception.
  • Un datalake correctement architecturé doit pouvoir intégrer facilement et rapidement de nouvelles sources de données

Petit rappel des différences entre les conceptions usuelles de data-lake et data-warehouse

Data Lake Data Warehouse
Typologie de donnée Intégralité de la donnée brute Donnée pré-structurée pour un besoin métier précis
Processing Données brutes et non traitées. Ingestion rapide de nouvelles données Donnée nettoyée et pré-traitée. Difficultés potentielles à inclure de nouvelles données
Type de donnée Structurée, semi-structurée et non-structurée Structurée (tabulaire)
Stockage Stockage bas-coût Stockage plus cher mais permettant d’excellents temps de chargement et de réponse
Schéma Schéma inféré à la lecture Schéma défini à l’écriture
Outillage Majorité d’outils open-source Majorité d’outils commerciaux

Quels outils pour un datalake sur le cloud AWS ?

Comparaison de l’approche Redshift vs. S3+Glue+Athena

La solution de Data-Warehousing AWS: Redshift

Quand on parle de Data Warehouse sur AWS, la solution qui s’impose est bien évidemment Redshift. Redshift est une solution de data-warehousing distribuée. Sous le capot, c’est un cluster de noeuds gérant à la fois le stockage et le traitement des requêtes. Son architecture est basée sur un traitement massivement parallélisé du chargement, de la sauvegarde ou de la restoration; elle est donc par essence résiliente. Les requêtes fonctionnent en mémoire, ce qui leur confère une rapidité quasi inégalée. Aussi, contrairement à beaucoup de SGBD, le stockage est effectué de manière colonnaire, ce qui permet d’optimiser les traitements sur des grandes quantités de données « répétées » (de type séries temporelles notamment). A ajouter à cela une compression des données efficace et une optimisation native des requêtes, vous obtenez une réduction drastique des opérations de lecture/écriture nécessaires.

Une de ses autres forces réside dans sa grande scalabilité horizontale (ajout/suppression de noeuds) comme verticale (changement de type d’instance des noeuds). Lors d’une opération de mise à l’échelle, pendant le temps de basculement, la data est migrée parallèlement entre les anciens et les nouveaux noeuds. Le cluster original reste disponible pour les opérations de lecture, ce qui permet une transition ininterrompue et sans accroc.

Sa capacité de stockage est immense: les options de base permettent de stocker jusqu’à 1 Po de données. Ce volume peut être amplement dépassé en ajoutant des noeuds à notre cluster.

Le cluster peut être requêté via le Redshift Query Engine. Ce moteur est basé sur ParAccel, un puissant outil de requêtage distribué lui-même basé sur PostgreSQL. Les requêtes se font en SQL, et Redshift fonctionne avec les drivers Postgres JDBC/ODBC existants, ce qui permet de l’interfacer avec la plupart des outils de BI du marché.

Il va sans dire que Redshift est extrêmement bien intégré avec l’ensemble de services de base AWS (S3, EC2, RDS…). Si le reste de votre infrastructure est déjà chez AWS, vous bénéficiez de la proximité des données et d’un coût réseau réduit. Les données peuvent être chargées depuis S3 via une commande COPY (en simulé comme en réel): l’opération est extrêmement rapide du fait de sa parallélisation.

En termes de sécurité, Redshift jouit de l’ensemble des fonctionnalités AWS liées au cloisonnement réseau telles que les VPC. Il permet aussi un contrôle des accès très granulaire: on peut en effet autoriser un utilisateur à requêter un nombre restreint de tables ou encore lui permettre de n’accéder qu’à certaines colonnes d’une table. Il propose enfin le cryptage des données au repos comme en transit.

Enfin, en termes de coûts, la solution Redshift est bien plus intéressante que ses équivalents on-premise. Amazon nous propose de payer à la consommation, ou bien de réserver des instances de noeuds sur le long terme, ce qui permet de faire baisser la facture. Le cout va bien évidemment dépendre des noeuds sous-jacents, et donc des besoins de stockage et de processing: il est à l’heure actuelle de l’ordre de 1 à 5$ par heure et par noeud. Un cluster de 3 instances « modestes » (2 CPU et 16 Go de mémoire chacune) pour un stockage d’ 1To vous reviendra à environ 500$/mois.

Toutefois, Redshift a aussi quelques limitations. La solution ne pourra par exemple pas être utilisée en tant que base de données « live ». En effet, bien qu’ultra-rapide pour des requêtes sur des gros volumes de données, elle ne le sera pas assez pour des transactions de type temps-réel. Il faudra donc passer par une base intermédiaire (type RDS) qui s’occupera de récupérer/déverser les données vers et depuis Redshift.

La parallélisation a aussi ses travers: l’unicité de la donnée n’est pas garantie et doit être gérée « manuellement » par un système amont de dé-duplication. Cette parallélisation du chargement de données depuis des sources externes, que nous évoquions plus haut, n’est aussi pour le moment (février 2020) possible que depuis S3, DynamoDB ou un cluster EMR.

L’organisation de la donnée et son indexation doivent faire l’objet de toutes les attentions lors de la structuration des tables. Il faut pour cela avoir de bonnes notions en bases de données pour choisir des clés de tri et de distribution minutieusement et ainsi optimiser le requêtage.

L’alternative S3

Comme nous l’évoquions plus haut, dans les architectures big data « modernes », il est de bonne pratique de découpler le stockage du requêtage, et de venir charger la donnée en mémoire uniquement lorsqu’elle a besoin d’être requêtée. Dans les data warehouses un peu plus anciens et reposant par exemple sur les technologies de la suite Apache (ex: Hadoop), ce couplage a toujours été présent, mais il est peu flexible pour des gros volumes de données ou un besoin de scaling peu anticipé.

C’est sur ce constat qu’est né le concept de data « lakehouse »: un endroit qui servirait à la fois au stockage de données structurées et cataloguées, mais aussi aux données brutes.

Pourquoi donc ne pas tirer des propriétés du stockage S3 pour contruire un datalake ? C’est en effet une option qui est de plus en plus poussée par Amazon, et le développement d’outils managés tels que Glue ou Athena vont en ce sens.

En effet, il n’y a pas d’endroit plus « natif » pour construire un datalake qu’S3: on tire profit de sa durabilité, de son élasticité, de son coût très faible (notamment en comparaison d’un cluster Redshift allumé en permanence). C’est sans compter les options de réplication multi-régions, celles de cryptage au repos et en transit, celles de gestion du cycle de vie de la donnée… La gestion des autorisations et des accès est native et plus que complète.

En terme d’importation, des services comme Amazon DMS (Data Migration Service) permettent de déverser des données issues d’un grand nombre de sources dans S3. On dispose d’options pour simuler les chargements – et surtout les erreurs qui en découlent – ce qui permet d’anticiper d’éventuels problèmes. Si vous disposez de bases de données tournant sous de multiples moteurs, l’outil intégré AWS Schema Conversion Tool convertira le schéma et le code de la base de données source pour qu’ils correspondent à ceux de la base de données cible. Son coût est d’environ 3$ par To migré: vous payez un agent de migration et de la bande passante. Ce coût de transit ne prend évidemment pas en compte celui lié au stockage cible.

Source: AWS

Quel format pour un stockage S3 ?

Les fichiers de données peuvent être compressés dans des formats bien connus des adeptes de la suite Apache et du stockage distribué, comme le Parquet. Ces formats binaires et compressés permettent des gains d’espace de stockage très conséquents, notamment dans le cas de données répetitives en colonne comme des séries temporelles. A ajouter à cela qu’un partitionnement optimal à l’écriture (ex: capteur=XY/annee=2020/mois=02/jour=01) permet d’emblée d’exclure des pans entiers du jeu de données, et donc de réduire d’autant le temps de traitement. Ce genre de fichier est efficace pour l’analyse de données (lecture de fichiers et filtrage des entrées) mais convient toutefois assez peu à l’ajout de données « en continu » ou au modifications fréquentes de données existantes. Ces propriétés font du Parquet un format approprié pour des analyses à grande échelle.

Découverte des méta-données

Pour la suite de la mise en place, le service AWS Glue, un outil entièrement managé, répond à 3 besoins:

  • le crawling: lors du dépôt de fichiers tabulaires dans un bucket S3, le crawler va inférer le schéma de vos données et leur type et va stocker ces méta-données dans un catalogue.
  • le cataloging: Glue va vous permettre de constituer un catalogue des méta-données de vos données (schéma, localisation, partitionnement…) qui vont permettre d’expliquer à d’autres services comment le bucket S3 est segmenté.
  • ETL (extract, transform, load): Glue va nous permettre de créer des chaines de transformation, d’enrichissement, ou encore de nettoyage de la donnée.

L’outil est serverless et ne nécessite que très peu de configuration. En termes de coût, les crawlers sont facturées au DPU (Data Processing Unit), de l’ordre de 0,5$ pour une heure de traitement. Le catalogue (meta-store) est quant à lui gratuit pour le premier million d’objets stockés, ce qui est amplement suffisant pour des structures de type PME.

Quid du requêtage ?

Donnée stockée et partitionnée, catalogue constitué, nous allons enfin faire appel à un 3ème outil, AWS Athena, qui va nous permettre, à l’aide du catalogue, de requêter nos données via uns syntaxe SQL classique, en toute transparence, comme si nous requêtions une base de SQL classique.

Athena fonctionne aussi de manière serverless, nous n’aurons donc pas besoin de provisionner ou de gérer des serveurs; tout est fait à l’échelle et de manière transparente quelle que soit la requête.

Sa puissance réside dans le fait que l’outil va venir lire la donnée là où elle réside, c’est à dire directement sur S3. Au milieu, notre meta-store agit comme ensemble de tables externes. Athena repose sur l’outil Presto développé par Facebook et rendu open-source par la suite. La donnée est lue sur S3 et chargée en mémoire dynamiquement, le tout en suivant un plan d’exécution optimal.

Quelques astuces supplémentaires pour optimiser les requêtes avec Athena: https://aws.amazon.com/fr/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/

Côté Redshift, l’outil Redshift Spectrum permet de compléter le moteur d’exécution de Redshift et de requêter des données structurées ou semi-structurées depuis S3, et ce à travers le même mécanisme de tables externes utilisé par Athena. Les tables, internes comme externes, seront « vues » de la même manière par Redshift. Cette stratégie de sources multiples via Redshift Spectrum peut être intéressante dans le cas d’un cluster rempli: au lieu de provisionner un nouveau nœud, on pourra ainsi « décharger » une partie des données – les moins utilisées – dans une table externe stockée sur S3 et donc bien moins chère.

En conclusion, S3+Glue+Athena vs. Redshift+Spectrum: quel solution choisir pour mon data-lake ?

Redshift est recommandé si vous disposez et ne souhaitez traiter que des données de type structurées. La solution est très aisément scalable, toute sa puissance réside dans la parallélisation des requêtes. Le setup d’Athena+Glue est quant à lui instantané du fait de son caractère serverless: il n’y a pas de dépendance car pas d’infrastructure. l’outil va simplement créer ses tables externes à partir de données S3.

Les deux solutions sont requêtables via la très grande majorité des outils de BI du marché (Tableau, Qlikview etc…) du fait de la disponibilité de drivers ODBC/JDBC.

Le coût des deux solutions en terme de requêtage est sensiblement équivalent, à savoir de l’ordre de 5$ par To de données analysées; si la requête échoue, elle n’est pas facturée et reste gratuite, on est donc à l’abri de grosses surprises dans un cadre de recherche notamment. Redshift est toutefois bien plus chère que son alternative du fait de la taille des nœuds sous-jacents qu’il faut provisionner. La solution sera donc intéressante pour de très gros volumes de données structurées et nécessitant des requêtes très « memory-intensive » de type JOIN.

Athena va donc plutôt être la solution de choix dans le cas du souhait de constituer un datalake puis un data-warehouse les plus « serverless » possibles, et dans le cas ou l’entreprise ne dispose pas de prémices de l’un ou l’autre de ces entrepôts.

A la façon de ce que l’entreprise proposait pour la mise en place d’une organisation des comptes avec Landing Zone ou Control Tower, elle propose désormais une aide à la structuration de datalake avec le service AWS Lake Formation (annoncé à la re:Invent 2018)

Laisser une réponse