smart solutions for smarter enterprises

Architecture 3.0 : zoom sur le concept de lac de données

Pour répondre à l’équation digitale complexe que doit résoudre l’entreprise, Sentelis a développé et promeut une nouvelle vision du système d’information porté par un modèle d’architecture SI dit 3.0. Un modèle pensé pour répondre aux disruptions digitales et au stress sans précédent qu’elles créent sur deux ressources clés de l’entreprise : son SI et ses données.

Basée sur une architecture dite ‘data-centrée’, l’architecture 3.0 place la donnée au cœur du SI et propose un nouveau paradigme d’intégration entre les composants du SI. Une intégration par les données, dont l’une des vertus est de préserver les investissements dans les legacy systems en leur évitant une surcharge de services digitaux incompatibles avec leurs natures et leurs rôles historiques. Ce modèle centré autour de la donnée est adossé à une infrastructure partagée et fédérée de stockage et de traitement des données qui en constitue l’épine dorsale. Un des constituants majeurs de ce Shared Data Backbone est l’un des concepts qui fait aujourd’hui le plus de buzz dès lors que l’on parle de Big Data, celui de Data Lake, littéralement lac de données. Petite plongée dans ce dernier qui cristallise beaucoup d’envies et de promesses.

Le concept de lac de données, est un concept relativement récent (2011), dont la parenté du terme est communément attribuée à James Dixon, CTO de Pentaho, un acteur spécialisé de l’intégration de données et de l’analytique. L’idée du lac de données est née du constat que les entreprises sous exploitent leur capital informationnel et ne seront bientôt plus en mesure de faire face à sa croissance exponentielle en volume et en vitesse et que les approches traditionnelles pour capturer et traiter cette masse d’information ont atteint leur limite.

Dans sa forme la plus simple, un lac de données est un lieu de stockage universel, un Polyglot Enterprise Data Store, dans lequel on peut mettre n’importe quel type de donnée, provenant de n’importe quelle source et/ou flux et ce, quelle qu’en soit le volume, la variété, la véracité, la valeur et la vélocité.

Si cela n’est pas sans rappeler le concept d’entrepôt de données (Data Warehouse), vieux de plusieurs décennies, le concept de lac de données est un vrai changement de paradigme.

Dans un entrepôt de données, la structure est prédéfinie à l’avance (Schema on write), généralement à des fins d’analyse historique. Avant ou au cours de leur intégration, les données subissent de nombreux traitements (mise en forme, mise en qualité, réconciliation, agrégation…).

Dans un lac de données, l’idée au contraire est de limiter au maximum les traitements et la préparation des données à l’ingestion. Celle-ci doit être à la fois rapide et peu coûteuse, deux paramètres essentiels pour absorber le déluge de données.

Ces dernières sont ainsi ingérées au plus près de leur forme originale (Raw Data) pour un traitement et une indexation à postériori et itérative. La structure de stockage n’a ainsi pas à être conçue en avance pour un usage déterminé et souvent unique (Schema ahead of time), mais définie ultérieurement selon l’usage que l’on en fera (Schema on use/on read).

Dans le lac de données, les données ne sont donc pas stockées de façons ultra-structurées, donnée par donnée, dans des tables comme dans un modèle entité-relation. Elles sont juste déposées à plat (Flat storage) et rangées de façon basique sans intégrité forte entre les différentes sources, généralement sous forme arborescente (Large data sets) ou étiquetée (Meta-Data tagging) dans une logique clé/valeur (key/value) pour les données interactives (Data Stream). L’idée est de s’assurer que l’on pourra facilement les repérer ultérieurement et surtout éviter qu’avec le temps, le flux de déversement continu de données ne transforme le lac de données en marécage (Data swamp).

Et c’est là un avantage décisif à l’ère du Big Data, où l’on ne connait pas par avance la valeur et l’intérêt de toutes les données que l’on capture et l’usage que l’on pourrait en faire dans le futur. Les traitements minimalistes que l’on opère à leur ingestion les rendent naturellement multi-usages et leur décloisonnement les rend disponibles au plus grand nombre, moyennant les habilitations adéquates et le respect des règles de gestion de l’information.

Ainsi déversées dans le lac, les données sont disponibles pour toute sorte de traitement, des plus simples au plus complexes et peuvent être façonnées et exposées de façon totalement adaptée à l’usage que l’on en fait (mise en qualité, détection de corrélation non triviales, recherche d’information, analyse historique, prédictive, cognitive) et ce, tant en terme de contenu que de structure.

L’usage du lac de données ne se restreint pas à des usages purement analytiques à froid comme on peut l’entendre trop souvent. Il joue un rôle clé dans nombres d’usages opérationnels : vision 360, profilage et segmentation client à la volée, contextualisation de la conversation client, stock temps réel, assistance virtuelle, recommandation d’action, adaptation de l’expérience utilisateur, détection de fraude, etc.

Côté solution, le Framework Open Source Hadoop, de la fondation Apache, s’est rapidement imposé comme la technologie de référence. Il propose un écosystème complet pour motoriser les fonctions fondamentales du lac de données autour de 2 composants majeurs :

  • HDFS, un système de gestion de fichier distribué, hautement extensible et auto-redondant pour le stockage de fichiers massifs de données. Hadoop est tout particulièrement adapté aux usages analytiques, aux usages de type write-once/read many et aux usages pouvant être opérés de façon différée (batch mode).
  • HBASE, une base de données NoSQL clé/valeur en colonne adossée à/au-dessus de HDFS, i.e. qui stocke ses données dans HDFS. HBASE est tout particulièrement adapté pour le stockage de milliards de données avec des accès fréquents à un sous-ensemble de celles-ci et dès lors que la latence doit être minimale (random access).

Le succès d’Hadoop provient de différents facteurs. Sa capacité de persistance polyglote (HDFS et/ou HBASE selon le cas d’usage). Sa capacité à distribuer la charge sur des serveurs et disques banalisés (commodity hadware). Les nombreuses distributions Big Data du marché qui le package et le complète pour en simplifier l’installation, la configuration, la supervision, la sécurisation et l’exploitation (Cloudera, Horton, MapR, IBM, etc.).Et enfin, la prolifération d’add-on/plug-in et de solutions nativement intégrées pour en exploiter la pleine puissance et le plein potentiel des données.

Hadoop incarne ainsi toute les qualités que l’on attend du lac de données : agilité, économie, tolérance aux pannes, flexibilité, évolutivité et (relative) simplicité.

Tous nos clients l’ont d’ailleurs adopté et nous avons chez Sentelis, développé une vraie expertise dans son industrialisation.

Cela ne veut pas pour autant dire que les systèmes de gestion de données actuelles (SGBDR) sont morts. Ils restent la plateforme de choix dès lors que l’on veut de la vélocité transactionnelle en écriture et lecture sur des volumes modérés de données, ou lorsque l’on a besoin d’un modèle optimisé d’analyse sur un sous-ensemble de données (pattern type DatamartStar/Snow-flakes).

Laisser une réponse

*