Azure Data Lake : l’avenir de la BI ?

Comme fidèles lectrices et lecteurs de ce blog, il nous semble inutile de repréciser ici que les méga-données ou Big Data, porteuses de nouvelles opportunités, demandent certains ajustements (sous une forme ou une autre) aux entreprises de toutes tailles qui veulent en tirer avantage afin d’être en capacité de comprendre des phénomènes, de résoudre des problèmes posés, d’améliorer leur connaissance, de prendre des décisions, d’anticiper des actions ou bien encore de trouver de nouvelles idées clés pour faire évoluer/croître leurs affaires.

Dans un précédent billet souhaitant la Bienvenue à Azure Data Factory, nous évoquions à ce propos les évolutions des méthodes d’extraction relatives à l’utilisation de données en masse. Avec les Big Data, tout y passe : de l’ingestion à l’analyse en passant par le stockage des données à des fins d’analyses futures.

Ce billet sera donc l’occasion pour nous d’introduire en quoi le concept de « lac de données » ou Data Lake , un concept relativement nouveau dans l’industrie, marque une évolution au sein de l’architecture traditionnelle du système décisionnel. Rappelons que le bruit d’aujourd’hui constitue potentiellement la valeur de demain !

Ce sera également dans ce contexte l’opportunité de revenir sur l’annonce faite à la conférence Build 2015 le 29 mai dernier sur Azure Data Lake, un référentiel à très grande échelle sous forme de service dans le cloud et destiné aux charges de travail d’analyse des méga-données. Ce service novateur sera prochainement disponible en version préliminaire au niveau de la plateforme Microsoft Azure.

Avant d’aborder ce service, revenons un instant sur l’architecture d’un système décisionnel traditionnel.

Un bref retour sur l’architecture d’un système décisionnel traditionnel

Un processus de prise de décision peut être décomposé en 5 étapes comme suit :

Le système décisionnel intervient typiquement dans les 2^ème et 3^ème étapes : il permet en effet à ce titre de rassembler les données, de leur appliquer des traitements pour ensuite les analyser. Il permet également de transformer des données de production en information stratégique.

Un système de traitement transactionnel OLTP (Online Transactional Processing) enregistre en temps réel les transactions courantes relatives et/ou nécessaires au bon fonctionnement d’une entreprise comme par exemple les opérations bancaires, ou encore les achats et ventes réalisées. Il permet ainsi d’insérer de nouvelles données mais également de modifier et d’interroger rapidement celles qui sont déjà stockées. Provenant de sources diverses (bases de données, fichiers, journaux, etc.), ces données brutes ne peuvent à ce stade être analysées : il convient en effet de les rendre au préalable cohérentes, de les fiabiliser et de les centraliser.

Généralement, on utilise pour cela un outil de type ETL (Extract, Transform, and Load) qui, comme son nom l’indique, va permettre d’extraire ces données provenant de sources hétérogènes, de les trier, de les nettoyer, de les standardiser et enfin de les charger dans un entrepôt.

En regroupant les données, l’entrepôt permet de retrouver plus rapidement l’information et de l’analyser en adoptant une vue orientée sujet. Les données y sont regroupées en ne tenant pas compte de leur organisation fonctionnelle. Il offre également dans ce contexte une traçabilité des décisions prises (ajout, suppression, modification). Les données y sont datées et persistent dans le temps. Cependant, de par sa taille, le « Data Warehouse » est rarement utilisé par les décideurs car il contient plus que nécessaire. Les magasins de données viennent en général palier à ce problème. Ces derniers sont des sous-ensembles de l’entrepôt destinés à répondre à des besoins (plus) spécifiques d’une fonction de l’entreprise. On va ainsi par exemple disposer au sein d’une entreprise d’un « DataMart » propre à une entité commerciale, un autre propre au service R&D, etc. Ceux-ci vont permettre d’apporter une approche métier dans les analyses.

A ce stade, les données peuvent alimenter des cubes, la modélisation multidimensionnelle des données qui va faciliter l’analyse d’un fait selon différentes dimensions. Les données transformées en information (insight) peuvent enfin être analysées par le biais de Reporting, Data Mining, etc.

En conséquence, le schéma tente de résumer l’architecture traditionnelle d’un système décisionnel.

Un nouvel enjeu des Big Data : des données structurées aux données non structurées

Notion souvent évoquée dans les derniers billets de ce blog, les Big Data ont modifié le paysage des données qui est aujourd’hui plus varié que jamais avec des données structurées ou non, issues de nombreuses sources en local et dans le Cloud mais également qui sont susceptibles de se renouveler en continue. L’un des enjeux est donc aujourd’hui d’adapter le système décisionnel traditionnel à ce nouveau paysage en constante mouvance.

L’un des grands changements opérés par les Big Data réside donc ainsi dans la structure des données opérationnelles.

Dans les environnements courants, les données sont bien souvent structurées mais également stockées dans des bases de données présentant elles-mêmes une certaine structure (tables, champs, clés primaires, etc.). Les données y sont organisées en tables relationnelles dont la structure y permet par ailleurs la navigation. De même, dans la pratique, les entrepôts de données se sont souvent construits selon le schéma en étoile qui organise l’information en niveau hiérarchique (p. ex. pour le temps : année, mois, semaine, jour et heure). Au final, les bases et l’entrepôt de données imposent une certaine structure aux données qu’ils stockent. Cela convient parfaitement aux données structurées ou prévisibles car leur organisation reste inchangée dans le temps.

Pour autant, cela ne convient pas aux données semi ou non structurées ou dont la structure varie au cours du temps (données issues des réseaux sociaux, images, textes, etc.). Il devient en effet difficile, couteux et contraignant de revoir l’organisation de ses tables et de son entrepôt sans perte de données.

Pour autant, le poids des données de toutes sortes, qu’il s’agisse de données issues des objets connectés et de leur(s) capteur(s), Internet des objets (IoT) et connexion omniprésente obligent, des journaux des applications SaaS, etc. ne fera que croitre dans les prochaines années. (Pour celles et ceux qui le souhaitent, vous trouverez ici une vidéo qui illustre s’il en était besoin la propension à croitre de ces données les plus diverses à croître d’ici à 2020.) Il faudra alors disposer de services capables de traiter ces Pétaoctets de données de types très variés, d‘où l’intérêt de pouvoir commencer à stocker cette information brute dès aujourd’hui.

Les systèmes de stockage arborescents comme Hadoop avec HDFS ont ouvert en la matière de nouvelles voies pour palier à ce problème. Nouvelles voies qu’emprunte le concept de « lac de données » ou Data Lake. Un lac de données est un référentiel étendu d’entreprise de tous les types de données collectées en un seul endroit avant tout définition formelle des exigences ou de schémas.

Cela permet à tous les types de données d’être maintenus sans discrimination quelle que soit sa taille, structure, ou vitesse à laquelle il est ingéré. En d’autres termes, le lac de données permet de stocker massivement des données structurées, semi-structurées ou non structurées dont on ne connait pas encore les axes d’analyses futures. Ainsi, contrairement aux tables et entrepôts de données, le lac de données ne présente aucune structure. Les données n’y sont pas stockées selon une organisation particulière. Surtout, leur structure sera créée lorsqu’elles seront analysées.

Les entreprises peuvent ensuite utiliser Hadoop ou d’autres systèmes d’analytiques avancées pour trouver des modèles (patterns). Les lacs de données peuvent également servir de référentiel à faible coût pour la préparation des données de coût inférieur avant le déplacement des données nettoyées dans un entrepôt de données.

Alors que le potentiel du lac données peut être important ou profond ;-), il doit encore pouvoir être pleinement réalisé dans les faits. Les limites propres à la capacité de stockage, à l’acquisition de matériel, à l’évolutivité (scalability), aux performances et bien sûr aux coûts constituent tout autant de raisons valides pour lesquelles une entreprise donnée n’est pas forcément en mesure de passer du concept à la mise en œuvre effective d’un lac de données.

Azure Data Lake : une version préliminaire publique bientôt disponible !

Parmi les trois annonces majeures faites à Build 2015 sur la plateforme de données Microsoft, le référentiel Azure Data Lake est le prochain service cloud de la plateforme de données Microsoft permettant aux entreprises quelles qu’elle soient de (pouvoir) disposer d’un tel lac de données et ce, à faibles coûts.

Comme indiqué en introduction de ce billet, Azure Data Lake est un référentiel à très grande échelle destiné aux charges de travail d’analyse des méga-données à destination de nos clients qui souhaitent maximiser la valeur de leurs données structurées, semi-structurées ou non structurées. Scott Guthrie, vice-président exécutif du groupe Cloud et Entreprise chez Microsoft, le décrit comme

« a nearly infinite data repository that supports petabyte-size files and all types of data ».

Ce service s’inscrit naturellement dans la continuité des investissements engagés par Microsoft en vue d’une adoption large par nos clients des méga-données. Ces derniers se sont traduits pour la plateforme de données Microsoft par la mise à disposition d’une suite de solutions/services à destination des Big Data et des analyses (prédictives) avancées avec Azure HDInsight, Azure Data Factory et Azure Machine Learning, etc. autant de services auxquelles nous avons consacré des billets sur ce blog et/ou sur le blog MSDN Machine Learning France (aka.ms/MLFrance).

Azure Data Lake vient donc compléter cette plateforme pour renforcer les synergies possibles pour le plus grand bénéfice de nos clients et partenaires. Ainsi, comme l’ajoute Scott Guthrie,

« Machine learning and big data services from Microsoft, and partners like Cloudera and Hortonworks, are integrated into Data Lake to give developers high-performance ways to store, process and reason over exabytes of structured and unstructured data to quickly deliver insights to power more intelligent apps. »

Pour cela et dans la pratique, Azure Data Lake s’avère être un système de fichiers Hadoop compatible avec HDFS et fonctionnant avec l'ensemble de l’écosystème Hadoop. Sans surprise, Azure Data Lake est donc intégré avec Azure HDInsight et sera intégré aux offres Microsoft telles que Revolution-R Enterprise, une acquisition de Microsoft en avril dernier, aux distributions standard telles que Hortonworks, Cloudera et MapR, et à des projets Hadoop spécifiques tels que Spark, Storm, Flume, Sqoop, Kafka, etc.

Votre curiosité est aiguisée ! :-) N’hésitez à vous rendre dès à présent sur la page dédiée d'Azure Data Lake où vous trouverez une description des principaux apports techniques et fonctionnels.

Nous vous invitons enfin à vous y inscrire ici afin d’être notifié(e) de la prochaine disponibilité de la version préliminaire publique.