Un "Data Lake" est un repository de stockage, souvent réalisé avec Apache Hadoop, qui contient un volume important de données brutes dans leurs formats natifs.
C'est une bonne solution pour effectuer des recherches, analyses, agrégations et archiver des données.
Les data lakes deviennent de plus en plus nécessaires avec les besoins d'exploiter plusieurs sources de données différentes: réseaux sociaux, web sites, web logs, sensors data, données d'entreprises, données externes (open data) etc.
D'autres besoins justifient également le recours aux data lakes:
- stockage d'un volume important de données, dans tous types de formats et sur du long terme. A un faible coût (Hadoop?)
- permettre la collecte de données sans être certain d'en avoir besoin demain. Mais comme le coût de stockage n'est pas rédhibitoire pourquoi les détruire.
- permettre de stocker au même endroit des données structurées, semi-structurées ou non-structurées -texte, audio, video, XML, sensors data)
- un moyen de stocker des données sans schéma prédéfini. (concept de "schema on read")
- compléter le datawarehouse (EDW) existant et pouvoir utiliser le data lake comme une source de données pour le EDW.
- Limiter les coûts du EDW, stockage, data model etc.
- Permettre l'exploration de données sans avoir à attendre que les données soient disponibles dans l'EDW. (temps de modélisation etc.) et permettre aux analystes de s'assurer de l'intérêt des données avant de les mettre dans un EDW.
- Permettre l'exécution d'analyses sur des volumes de données très importants pour détecter par exemple des fraudes.
- Le data lake est aussi l'endroit idéal où stocker des streaming data en provenance de Twitter ou d'IoT.
- Certains traitements sont plus efficaces avec Hadoop qu'avec un ETL comme SSIS.
A noter que certains appellent les data lakes autrement: bit bucket, staging area, landing zone or entreprise data hub (Cloudera).
Vous pouvez noter l'utilisation du terme ELT au lieu de ETL. ELT signifie Export, Load, Transform.
Cela accélère considérablement les transformations des données puisque le data lake est habituellement dans un cluster Hadoop qui peut transformer les données beaucoup plus vite qu'un outil d'ETL traditionnel.
Beaucoup de solutions de data warehouse qui utilisent la technologie MPP (https://en.wikipedia.org/wiki/Massively_parallel_(computing), sont déjà passées à l'ELT et chargent les données dans des tables de staging dans des appliances MPP puis les transforment pour profiter de la puissance du traitement parallèle SQL.
Ainsi en changeant l'architecture pour les besoins des analystes, nous obtenons les avantages suivants:
- l'intégralité des données est collectées sans se préoccuper du coût et des besoins
- les données brutes sont toujours conservées et disponibles pour du data mining
- le data lake est compatible avec les méthodologies de EDW classiques
- le data lake est facilement scalable
- les accès aux données sont moins rigides, plus flexibles
- les analyses prédictives, etc sont plus faciles à réaliser car toutes les données sont conservées et accessibles et on peut les croiser facilement.
Une question qui revient fréquemment à propos des data lakes est de savoir si on peut y stocker des données relationnelles.
La réponse est que dans la plupart des cas il n'est pas nécessaire de copier les données relationnelles (stockées dans une RDBMS) dans le data lake puis dans le EDW.
Toutefois dans certains uses cases précis cela peut s'avérer judicieux:
a) On veut transférer à Hadoop le "data refinement" afin de réduire la charge du data warehouse (EDW)
b) On veut utiliser des techno disponibles dans Hadoop et pas dans le EDW (JSON, images, video)
c) On veut collecter et stocker des données massives et non structurées, et on veut de la redondance.
d) Les traitements prennent trop de temps sur l'EDW car le volume des données devient trop important. Dans ce cas on les déporte sur le data lake
e) Vous voulez utiliser des données plus tard sans trop savoir si elles ont de la valeur. Puis y accéder en SQL via Polybase par exemple.
C'est une bonne solution pour effectuer des recherches, analyses, agrégations et archiver des données.
Les data lakes deviennent de plus en plus nécessaires avec les besoins d'exploiter plusieurs sources de données différentes: réseaux sociaux, web sites, web logs, sensors data, données d'entreprises, données externes (open data) etc.
D'autres besoins justifient également le recours aux data lakes:
- stockage d'un volume important de données, dans tous types de formats et sur du long terme. A un faible coût (Hadoop?)
- permettre la collecte de données sans être certain d'en avoir besoin demain. Mais comme le coût de stockage n'est pas rédhibitoire pourquoi les détruire.
- permettre de stocker au même endroit des données structurées, semi-structurées ou non-structurées -texte, audio, video, XML, sensors data)
- un moyen de stocker des données sans schéma prédéfini. (concept de "schema on read")
- compléter le datawarehouse (EDW) existant et pouvoir utiliser le data lake comme une source de données pour le EDW.
- Limiter les coûts du EDW, stockage, data model etc.
- Permettre l'exploration de données sans avoir à attendre que les données soient disponibles dans l'EDW. (temps de modélisation etc.) et permettre aux analystes de s'assurer de l'intérêt des données avant de les mettre dans un EDW.
- Permettre l'exécution d'analyses sur des volumes de données très importants pour détecter par exemple des fraudes.
- Le data lake est aussi l'endroit idéal où stocker des streaming data en provenance de Twitter ou d'IoT.
- Certains traitements sont plus efficaces avec Hadoop qu'avec un ETL comme SSIS.
A noter que certains appellent les data lakes autrement: bit bucket, staging area, landing zone or entreprise data hub (Cloudera).
Vous pouvez noter l'utilisation du terme ELT au lieu de ETL. ELT signifie Export, Load, Transform.
Cela accélère considérablement les transformations des données puisque le data lake est habituellement dans un cluster Hadoop qui peut transformer les données beaucoup plus vite qu'un outil d'ETL traditionnel.
Beaucoup de solutions de data warehouse qui utilisent la technologie MPP (https://en.wikipedia.org/wiki/Massively_parallel_(computing), sont déjà passées à l'ELT et chargent les données dans des tables de staging dans des appliances MPP puis les transforment pour profiter de la puissance du traitement parallèle SQL.
Ainsi en changeant l'architecture pour les besoins des analystes, nous obtenons les avantages suivants:
- l'intégralité des données est collectées sans se préoccuper du coût et des besoins
- les données brutes sont toujours conservées et disponibles pour du data mining
- le data lake est compatible avec les méthodologies de EDW classiques
- le data lake est facilement scalable
- les accès aux données sont moins rigides, plus flexibles
- les analyses prédictives, etc sont plus faciles à réaliser car toutes les données sont conservées et accessibles et on peut les croiser facilement.
Une question qui revient fréquemment à propos des data lakes est de savoir si on peut y stocker des données relationnelles.
La réponse est que dans la plupart des cas il n'est pas nécessaire de copier les données relationnelles (stockées dans une RDBMS) dans le data lake puis dans le EDW.
Toutefois dans certains uses cases précis cela peut s'avérer judicieux:
a) On veut transférer à Hadoop le "data refinement" afin de réduire la charge du data warehouse (EDW)
b) On veut utiliser des techno disponibles dans Hadoop et pas dans le EDW (JSON, images, video)
c) On veut collecter et stocker des données massives et non structurées, et on veut de la redondance.
d) Les traitements prennent trop de temps sur l'EDW car le volume des données devient trop important. Dans ce cas on les déporte sur le data lake
e) Vous voulez utiliser des données plus tard sans trop savoir si elles ont de la valeur. Puis y accéder en SQL via Polybase par exemple.
Comments
Post a Comment