Cet article se concentrera sur le stockage de Big Data le plus approprié pour les cas d’utilisation opérationnels à grande échelle, en temps réel – Data Fabric vs Data Lake. Il abordera également les entrepôts de données, ainsi que les bases de données relationnelles et non relationnelles.
Quels sont les cas d’utilisation opérationnels ?
Les entreprises gourmandes en données sont motivées par un large éventail de cas d’utilisation en temps réel nécessitant une architecture de données à grande échelle et à grande vitesse pouvant prendre en charge des millions de transactions simultanées. Les exemples comprennent:
- Vue client à 360 degrés à partir de nombreux systèmes hérités différents (vers un IVR en libre-service ou un portail mobile/web, des représentants du service client, des agents de chat/bots et des techniciens de terrain).
- Prédiction de désabonnement.
- Cotation de crédit.
- Prévention de la fraude.
- Sécurité des transactions par carte de paiement, et plus encore.
Conditions d’utilisation opérationnelles
Les cas d’utilisation opérationnels nécessitent une plate-forme Big Data capable d’effectuer des requêtes de données complexes en quelques millisecondes tout en traitant :
- Des données en direct, qui sont continuellement mises à jour à partir des systèmes opérationnels (avec des millions, voire des milliards, de mises à jour chaque jour).
- Des téraoctets de données fragmentées, couvrant de nombreuses bases de données ou tables différentes, généralement dans différents formats et technologies.
- Une instance spécifique d’une entité commerciale, telle qu’un client, un produit, un emplacement, etc.
- Concurrence élevée, représentant des milliers de demandes chaque seconde.
Options de stockage de Big Data
Aujourd’hui, les options de stockage les plus utilisées sur lesquelles les équipes de données s’appuient incluent :
-
Lac de données
Selon un analyste de Gartner, un lac de données est une collection d’instances de stockage de divers actifs de données. Ces actifs sont stockés et conservés sous la forme d’une réplique exacte, ou presque exacte, du format source structuré ou non structuré, en plus des magasins de données d’origine. Des exemples de fournisseurs de lacs de données incluent Amazon S3, Apache Hadoop et Azure Data Lake.
-
Entrepôts de données (DWH)
Un entrepôt de données fait référence à une architecture de stockage conçue pour conserver les données extraites des magasins de données opérationnelles, des systèmes de transaction et des sources externes. Il combine les données sous une forme agrégée appropriée pour l’analyse et le reporting des données à l’échelle de l’entreprise. Des exemples de fournisseurs DWH incluent Amazon Redshift, Google BigQuery et Snowflake.
-
Systèmes de gestion de bases de données (SGBD)
Un système de gestion de base de données stocke et organise les données avec des formats et des structures définis. Un SGBD est classé par sa structure de base et par son utilisation ou son déploiement.
-
Un SGBD relationnel, qui comprend généralement une API SQL (Structured Query Language), est organisé et accessible via les relations entre les entités de données. Des exemples de fournisseurs de SGBD relationnels incluent MS SQL, Oracle et PostgreSQL.
-
Un SGBD non relationnel (NoSQL) est souvent utilisé dans le Big Data et les applications Web en temps réel. Bien qu’optimisée pour une utilisation à grande échelle, une base de données non structurée ne peut pas imposer de relations entre les entités de données. Cassandra, MongoDB et Redis sont des exemples de fournisseurs de SGBD non relationnels.
-
Data Fabric
Une structure de données peut être définie comme une couche intégrée de données connectées, ingérées et normalisées à partir des sources de données d’une entreprise, quels que soient le format, la technologie ou le système source des données. Il conserve les données traitées dans son propre magasin de données, les livrant aux magasins de Big Data, aux applications consommatrices et aux moteurs de prise de décision AI/ML/en temps réel – à la demande. Des exemples de fournisseurs de Data Fabric incluent IBM Cloud Pak, K2View, Denodo, Talend et Informatica.
Options de stockage – Avantages et inconvénients
Ce qui suit résume les forces et les faiblesses de la fabrique de données par rapport au lac de données/DWH, ainsi que des bases de données relationnelles et non relationnelles.
-
Lac de données/DWH
Forces
- Prise en charge des requêtes de données complexes, sur des données structurées et non structurées.
Faiblesses
- Pas de prise en charge des requêtes d’entité unique, avec des temps de réponse lents qui en résultent.
- Aucune prise en charge des données en direct, de sorte que les données qui doivent être constamment mises à jour ne sont pas fiables ou livrées à des temps de réponse trop lents.
-
Base de données relationnelle
Forces
- Prise en charge de SQL, adoption généralisée et facilité d’utilisation.
Faiblesses
- Évolutivité non linéaire, nécessitant un matériel coûteux pour effectuer des requêtes complexes, sur des téraoctets de données, en temps quasi réel.
- Concurrence élevée, résultant en des temps de réponse trop lents.
-
Base de données NoSQL
Forces
- Architecture de magasin de données distribué, avec prise en charge de l’évolutivité linéaire.
Faiblesses
- Pas de support pour SQL, nécessitant des compétences spécialisées.
- Afin de prendre en charge les requêtes de données, les index doivent être prédéfinis – ou une logique d’application complexe doit être intégrée – ce qui entrave l’agilité de développement et le délai de mise sur le marché.
-
Fabric de données opérationnelles
Forces
- Prise en charge complète de SQL.
- Architecture de magasin de données distribué, avec prise en charge de l’évolutivité linéaire.
- Prise en charge de la simultanéité élevée, avec des performances élevées.
- Prise en charge de requêtes complexes pour des entités commerciales uniques.
Faiblesses
- Pas de prise en charge inhérente pour les requêtes sur plusieurs micro-bases de données, mais Elasticsearch résout ce problème de manière satisfaisante.
Conclusion
Dans la comparaison Data Fabric vs Data Lake, l’architecture de choix pour les cas d’utilisation opérationnels en temps réel est évidemment la Data Fabric. Mais les solutions de Data Fabric et les Data Lakes sont en fait complémentaires dans la mesure où la Data Fabric peut préparer des données de confiance pour les Data Lakes, tandis que les Data Lakes peuvent fournir une intelligence opérationnelle à la Data Fabric pour une utilisation immédiate.