L'évolution de l'architecture des bases de données

L’augmentation de la production des données et l’évolution des besoins ont fortement modifié les paradigmes de stockage de la donnée et des traitements au sein des entreprises.

Partie 1 Historique

A la fin des années 80, les entreprises commencent à prendre conscience de la valeur qu’ils peuvent tirer de l’analyse de leurs données, le Data Warehouse est alors utilisé dans le but d’historiser les données produites par les applications, ils ne fournissent pas d’accès en temps réel à ces données mais servent à produire des analyses.

Les Data Warehouse sont orientés sujet, ce qui veut dire que les données y sont organisées par thèmes, et bien qu’elles proviennent de sources hétérogènes, elles sont rapatriées dans un modèle de données commun. Ils étaient initialement principalement utilisés dans le domaine de la finance, par les banques notamment, qui étaient par ailleurs les premières entreprises à intégrer l’utilisation des bases de données dans leur métier.

Les données produites par les banques étant structurées, les Data Warehouses étaient parfaitement adaptés à leurs besoins, cependant avec l’essor de l’IT au sein des entreprises, de nouveaux besoins sont apparus et avec eux de nouveaux paradigmes de stockage.

‍

Une dizaine d’années plus tard, poussé par l’augmentation de la production de données non structurées et l’apparition des besoins d’intégration en temps réel des résultats analytiques augmentent, on assiste peu à peu à un remplacement des Data Warehouse par les Data Lake.

Cette solution permet, tout comme les Data Warehouses, une historisation des données, cependant ceux-ci ont la capacité de stocker plusieurs modèles de données. L’IT prend alors une part de plus en plus importante et se met au service des entreprises.

Les Data Warehouses ainsi que les Data Lakes sont des solutions on premise (sur site) et dont le coût d’installation est conséquent, avec la diversification des offres cloud des grands acteurs tels que GCP, AWS et Azure, il est désormais possible de migrer son infrastructure data sur le cloud. Ces solutions apportent une flexibilité et un paiement à l’usage (pay as you go), il est également possible d’utiliser périodiquement des ressources pour des traitements lourds.

‍

Partie 2 Ecosystème Big Data en 2021

En 2021, l’écosystème Big Data se compose d’une pléthore d’outils. Une infrastructure Data actuelle se compose, en général, à minima d’Hadoop, de diverses bases de données (SQL et noSQL) et d’outils de monitoring. S’ajoutent ensuite selon les besoins, des ETL, des outils de BI et/ou des outils de Machine Learning.

Plusieurs solutions de stockage existent, elles sont à choisir en fonction du besoin et sont souvent complémentaires. Hadoop est utilisé pour le stockage de fichiers, que ce soit on premise avec des plateformes clé en main telles que HDP, ou sur le cloud avec les solutions proposées par les cloud providers.

Pour le stockage des données non structurées plusieurs solutions existent. En fonction du contexte, nous choisirons les bases orientées documents telle que mongoDB et Couchbase, les bases orientées colonnes telles que Cassandra de Druid, les bases orientées clé/valeur telle que Redis ou les bases orientées graphes telle que Neo4J. Toutes ces solutions implémentent des systèmes de stockage plus performants que le traditionnel SQL.

Au niveau des traitements, Spark reste le framework distribué le plus utilisé et a de beaux jours devant lui. Pour le streaming Kafka, Apache Beam ou Spark Streaming restent quant à eux les principaux outils. Pour le monitoring, on privilégiera Prometheus couplé à Grafana ou la suite Elastic (anciennement ELK).

Les besoins en Machine Learning ont évolué, on voit désormais apparaître de nouvelles plateformes, dites MLOps, qui couvrent le cycle de vie des applications Machine Learning. Ces plateformes proposent d’augmenter la collaboration et la communication entre les Data Scientists notamment l'entraînement de modèles, le versionning et le déploiement continu. On peut citer MLFlow, Comet et Kubeflow, mais la discipline étant nouvelle, les solutions proposées évoluent rapidement.

‍

Partie 3 D’une architecture monolithique à une architecture micro-services

Aujourd’hui tous ces outils fonctionnent sous la forme d’une architecture monolithique dans laquelle les composants sont difficilement dissociables.

Dans une architecture micro-services, une application se compose de services développés, testés et déployés unitairement, ils fonctionnent indépendamment les uns des autres dans des processus séparés et communiquent entre eux à travers les API qu’ils exposent. Ils sont interopérables, ce qui signifie qu’ils peuvent communiquer avec les autres composants sans restriction d’accès ou de mise en œuvre.

Bien qu’assez récentes (le terme microservice est apparu en 2011), ces architectures tendent à gagner en popularité, elles sont aujourd’hui privilégiées dans plusieurs domaines de l’informatique, notamment dans les applications web, mais encore trop peu dans les projets Big Data.

Viser une telle architecture permettrait de cloisonner les applications avec seulement les composants dont elles ont besoin, par exemple avoir la possibilité d’avoir des bases de données propres à chaque service.

Il est aussi à noter que l’évolution de chacun des composants de l’application peut se faire sans incidence sur les autres applications, cela se traduit par une plus grande maîtrise de la disponibilité des applications. De plus, cette approche permet de disposer d’une infrastructure flexible et capable d’évoluer de façon linéaire.