Cet article est une traduction de mon article sur Medium -
Getting Started with Data Lake , qui s'est avéré être très populaire, probablement en raison de sa simplicité. Par conséquent, j'ai décidé de l'écrire en russe et de le compléter un peu afin qu'une personne simple qui n'est pas un spécialiste des données puisse comprendre ce qu'est un entrepôt de données (DW) et ce qu'est un Data Lake et comment ils s'entendent. .
Pourquoi ai-je voulu écrire sur un lac de données? Je travaille avec des données et des analyses depuis plus de 10 ans, et maintenant je travaille définitivement avec les big data chez Amazon Alexa AI à Cambridge, qui est à Boston, bien que moi-même j'habite à Victoria sur l'île de Vancouver et visite souvent Boston, Seattle et Vancouver, et parfois même à Moscou, je parle lors de conférences. De plus, j'écris de temps en temps, mais j'écris principalement en anglais, et j'ai déjà écrit
plusieurs livres , j'ai aussi besoin de partager les tendances analytiques d'Amérique du Nord, et parfois j'écris dans des
télégrammes .
J'ai toujours travaillé avec des entrepôts de données et depuis 2015, j'ai commencé à travailler en étroite collaboration avec Amazon Web Services et, en général, je suis passé à l'analyse cloud (AWS, Azure, GCP). J'ai observé l'évolution des solutions d'analyse depuis 2007, et j'ai même travaillé chez le fournisseur d'entrepôt de données Teradat et l'ai implémenté dans Sberbank, puis le Big Data avec Hadoop est apparu. Tout le monde a commencé à dire que l'ère des stockages était passée et maintenant tout était sur Hadoop, puis ils ont recommencé à parler de Data Lake, maintenant que l'entrepôt de données était sûrement terminé. Mais heureusement (peut-être pour quelqu'un et malheureusement, qui a gagné beaucoup d'argent en créant Hadoop), l'entrepôt de données n'a pas disparu.
Dans cet article, nous considérerons ce qu'est un lac de données. Cet article est destiné aux personnes qui ont peu ou pas d'expérience avec l'entreposage de données.
Sur la photo, le lac de Bled est l'un de mes lacs préférés, même si je n'y suis allé qu'une seule fois, mais je m'en souviens pour la vie. Mais nous parlerons d'un autre type de lac - le lac de données. Beaucoup d'entre vous ont peut-être déjà entendu parler de ce terme plus d'une fois, mais une autre définition ne fera de mal à personne.
Tout d'abord, voici les définitions les plus populaires d'un Data Lake:
«Stockage de fichiers de tous les types de données brutes qui sont disponibles pour analyse par n'importe qui dans l'organisation» - Martin Fowler.
«Si vous pensez qu'une vitrine de données est une bouteille d'eau - purifiée, emballée et conditionnée pour une utilisation pratique, alors le lac de données est un énorme réservoir d'eau sous sa forme naturelle. Utilisateurs, je peux puiser de l'eau pour moi-même, plonger dans les profondeurs, explorer "- James Dixon.
Maintenant, nous savons avec certitude que le lac de données concerne l'analyse, il nous permet de stocker de grandes quantités de données dans leur forme d'origine et nous avons l'accès nécessaire et pratique aux données.
J'aime souvent simplifier les choses, si je peux dire un terme complexe avec des mots simples, alors pour moi j'ai compris comment ça marche et à quoi ça sert. D'une certaine manière, je sélectionnais mon iPhone dans la galerie de photos, et il m'est apparu, c'est un vrai lac de données, j'ai même fait une diapositive pour les conférences:
Tout est très simple. Nous prenons une photo sur le téléphone, la photo est enregistrée sur le téléphone et peut être enregistrée dans iCloud (stockage de fichiers dans le cloud). Le téléphone recueille également des métadonnées de la photo: ce qui est affiché, géo-tag, heure. En conséquence, nous pouvons utiliser l'interface iPhone pratique pour trouver notre photo et en même temps, nous voyons même des indicateurs, par exemple, lorsque je cherche des photos avec le mot feu, je trouve 3 photos avec l'image d'un feu. Pour moi, c'est comme un outil de Business Intelligence qui fonctionne très rapidement et clairement.
Et bien sûr, nous ne devons pas oublier la sécurité (autorisation et authentification), sinon nos données peuvent facilement entrer en libre accès. Il y a beaucoup de nouvelles sur les grandes entreprises et les start-ups, dans lesquelles les données sont tombées dans le domaine public en raison de la négligence des développeurs et du non-respect de règles simples.
Même une image aussi simple nous aide à imaginer ce qu'est un lac de données, ses différences avec un entrepôt de données traditionnel et ses principaux éléments:
- Le chargement de données (ingestion) est un élément clé d'un lac de données. Les données peuvent entrer dans l'entrepôt de données de deux manières: par lots (téléchargement à intervalles réguliers) et par diffusion en continu (flux de données).
- Le stockage de fichiers est le composant principal de Data Lake. Nous avons besoin que le stockage soit facilement évolutif, extrêmement fiable et à faible coût. Par exemple, dans AWS, il s'agit de S3.
- Catalogue et recherche - afin d'éviter le marécage de données (c'est lorsque nous vidons toutes les données dans une pile, puis il est impossible de travailler avec elles), nous devons créer une couche de métadonnées pour classer les données afin que les utilisateurs puissent facilement trouver les données dont ils ont besoin pour l'analyse. De plus, vous pouvez utiliser des solutions de recherche supplémentaires, telles que ElasticSearch. La recherche aide l'utilisateur à rechercher les données souhaitées via une interface pratique.
- Traitement (Processus) - cette étape est responsable du traitement et de la transformation des données. Nous pouvons transformer les données, changer leurs structures, claires et bien plus encore.
- Sécurité - il est important de passer du temps à concevoir une solution de sécurité. Par exemple, le chiffrement des données pendant le stockage, le traitement et le chargement. Il est important d'utiliser des méthodes d'authentification et d'autorisation. En conclusion, un outil d'audit est nécessaire.
D'un point de vue pratique, nous pouvons caractériser un lac de données avec trois attributs:
- Collectez et stockez tout ce que vous voulez - le lac de données contient toutes les données, à la fois des données brutes brutes pour n'importe quelle période et des données traitées / effacées.
- Analyse approfondie - un lac de données permet aux utilisateurs d'explorer et d'analyser des données.
- Accès flexible - un lac de données fournit un accès flexible à diverses données et à différents scénarios.
Maintenant, nous pouvons parler de la différence entre un entrepôt de données et un lac de données. Les gens demandent généralement:
- Mais qu'en est-il de l'entrepôt de données?
- Remplaçons-nous l'entrepôt de données par un lac de données ou l'étendons-nous?
- Est-il possible de se passer d'un lac de données?
Bref, il n'y a pas de réponse claire. Tout dépend de la situation spécifique, des compétences de l'équipe et du budget. Par exemple, la migration d'un entrepôt de données vers Oracle dans AWS et la création d'un lac de données par une filiale d'Amazon - Woot -
Notre histoire de lac de données: Comment Woot.com a construit un lac de données sans serveur sur AWS .
D'un autre côté, le fournisseur Snowflake déclare que vous n'avez plus besoin de penser à un lac de données, car sa plate-forme de données (jusqu'en 2020, c'était un entrepôt de données) vous permet de combiner à la fois un lac de données et un entrepôt de données. Je n'ai pas beaucoup travaillé avec Snowflake, et c'est un produit vraiment unique qui peut le faire. Le prix de la question est une autre question.
En conclusion, mon opinion personnelle est que nous avons toujours besoin d'un entrepôt de données comme principale source de données pour nos rapports, et nous stockons tout ce qui ne rentre pas dans le lac de données. Le rôle de l'analytique est de fournir un accès pratique à l'entreprise pour la prise de décision. Quoi qu'il en soit, les utilisateurs professionnels travaillent plus efficacement avec un entrepôt de données qu'avec un lac de données, par exemple, sur Amazon - il y a Redshift (entrepôt de données analytiques) et Redshift Spectrum / Athena (interface SQL pour le lac de données dans S3 basé sur Hive / Presto). Il en va de même pour les autres entrepôts de données analytiques modernes.
Regardons une architecture typique d'entrepôt de données:
Il s'agit d'une solution classique. Nous avons des systèmes sources, en utilisant ETL / ELT, nous copions les données dans l'entrepôt de données analytiques et connectons la solution à la Business Intelligence (mon tableau préféré et le vôtre?).
Cette solution présente les inconvénients suivants:
- Les opérations ETL / ELT prennent du temps et des ressources.
- En règle générale, la mémoire pour stocker des données dans un entrepôt de données analytiques n'est pas bon marché (par exemple, Redshift, BigQuery, Teradata), car nous devons acheter un cluster entier.
- Les utilisateurs professionnels ont accès à des données nettoyées et souvent agrégées et ils n'ont pas la possibilité d'obtenir des données brutes.
Bien sûr, tout dépend de votre cas. Si vous n'avez aucun problème avec votre entrepôt de données, vous n'avez absolument pas besoin d'un lac de données. Mais lorsque des problèmes surviennent avec un manque d'espace, de capacité ou que le prix du problème a un rôle clé, vous pouvez alors envisager l'option d'un lac de données. C'est pourquoi, le lac de données est très populaire. Voici un exemple d'une architecture de lac de données:
En utilisant l'approche du lac de données, nous chargeons des données brutes dans notre lac de données (batch ou streaming), puis nous traitons les données si nécessaire. Le lac de données permet aux utilisateurs professionnels de créer leurs propres transformations de données (ETL / ELT) ou d'analyser des données dans des solutions de Business Intelligence (si vous avez le bon pilote).
Le but de toute solution analytique est de servir les utilisateurs professionnels. Par conséquent, nous devons toujours travailler sur les exigences de l'entreprise. (En Amazonie, c'est l'un des principes - travailler en arrière).
En travaillant à la fois avec l'entrepôt de données et le lac de données, nous pouvons comparer les deux solutions:
La principale conclusion qui peut être tirée est que l'entrepôt de données ne rivalise pas avec le lac de données, mais le complète davantage. Mais c'est à vous de décider ce qui convient à votre cas. Il est toujours intéressant de l'essayer vous-même et de tirer les bonnes conclusions.
Je voudrais également parler d'un des cas où j'ai commencé à utiliser l'approche Data Lake. Tout est assez banal, j'ai essayé d'utiliser l'outil ELT (nous avions Matillion ETL) et Amazon Redshift, ma solution a fonctionné, mais elle ne correspondait pas aux exigences.
Je devais prendre des journaux Web, les transformer et les agréger pour fournir des données pour 2 cas:
- L'équipe marketing a voulu analyser l'activité des bots pour le référencement
- Le service informatique voulait surveiller les mesures du site
Journaux très simples, très simples. Voici un exemple:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012" 1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"
Un fichier pesait 1 à 4 mégaoctets.
Mais il y avait une difficulté. Nous avions 7 domaines à travers le monde et en un jour 7 000 000 fichiers ont été créés. Ce n'est pas un très gros volume, seulement 50 gigaoctets. Mais la taille de notre cluster Redshift était également petite (4 nœuds). Le téléchargement d'un seul fichier de manière traditionnelle a pris environ une minute. Autrement dit, la tâche n'a pas été résolue dans le front. Et ce fut le cas lorsque j'ai décidé d'utiliser l'approche Data Lake. La solution ressemblait à ceci:
C'est assez simple (je veux noter que l'avantage de travailler dans le cloud est la simplicité). J'ai utilisé:
- AWS Elastic Map Reduce (Hadoop) comme puissance de calcul
- AWS S3 en tant que stockage de fichiers avec la possibilité de crypter les données et de restreindre l'accès
- Spark en tant que puissance de calcul InMemory et PySpark pour la transformation de la logique et des données
- Parquet à la suite de Spark
- AWS Glue Crawler en tant que collecteur de métadonnées sur les nouvelles données et partitions
- Redshift Spectrum en tant qu'interface SQL au lac de données pour les utilisateurs existants de Redshift
Le plus petit cluster EMR + Spark a traité tout un tas de fichiers en 30 minutes. Il existe d'autres cas pour AWS, en particulier beaucoup liés à Alexa, où il y a beaucoup de données.
Plus récemment, j'ai découvert l'un des inconvénients du lac de données est le RGPD. Le problème est que lorsque le client lui demande de supprimer et que les données se trouvent dans l'un des fichiers, nous ne pouvons pas utiliser le langage de manipulation de données et l'opération DELETE comme dans la base de données.
J'espère que l'article clarifie la différence entre un entrepôt de données et un lac de données. Si c'était intéressant, je peux quand même traduire mes articles ou l'article de professionnels que j'ai lu. Et aussi parler des solutions avec lesquelles je travaille, et de leur architecture.