Utiliser les tables transactionnelles partagées pour optimiser l’entreposage de données

Celles-ci étaient jusqu’ici réservées aux entrepôts traditionnels, à la fois onéreux, limités aux outils propriétaires du fournisseur et dont le niveau critique d’évolutivité obligeait à créer des ilots de données. A l’inverse, l’écosystème Big Data permet à de très nombreux outils open source d’accéder à des tables au sein d’un grand lac de données partagé. Ceux-ci sont également utilisés pour la nouvelle génération d’entrepôts de données Big Data et permettent d’optimiser le système pour qu’il fonctionne aussi bien sur un support de stockage cloud plus lent, grâce aux options de mise en cache.

L’approche Big Data privilégie nettement les tables comme modèle de stockage de données. En effet, celles-ci sont suffisamment flexibles pour être utilisées avec des systèmes continus et par lots. Elles peuvent alors modéliser une table traditionnelle, un groupe de clés et de valeurs comme dans Apache HBase, des objets dans S3, des fichiers dans un répertoire ou un flux Apache Kafka. Elles prennent également en charge suffisamment de métadonnées, de type schémas, informations sur le format de stockage et statistiques, optimisant les fonctionnalités et les performances.
L’écosystème Hadoop permettait initialement l’insertion transactionnelle de nouvelles informations dans une table. Les opérations de remplacement de données, d’annexion, de mise à jour ou de suppression, n’étant pas transactionnelles, nécessitaient alors une action humaine pour éviter les erreurs. Chaque mise à jour ou suppression d’une ligne de données imposait de réécrire toute la partition ou au moins un fichier en entier.
Désormais, les utilisateurs ont besoin de pouvoir insérer des lignes de données, les mettre à jour, les supprimer ou les fusionner, plutôt que de simplement ajouter ou remplacer des partitions. La méthode des dimensions à évolution lente (Slow changing dimensions), couramment utilisée pour gérer les modifications au fil du temps, nécessite alors des mises à jour. Pour se conformer aux réglementations de confidentialité, il faut par exemple pouvoir supprimer les informations d’un seul client. Il faut alors pouvoir insérer des données en continu depuis une source de flux, comme Apache Kafka, pour charger des données dans l’entrepôt, quasiment en temps réel. L’ajout de ces petits ou micro-lots à partir de systèmes frontaux suppose également une fusion. Toutes ces opérations nécessitent des transactions de sorte que les écritures n’entrent pas en conflit et que les utilisateurs aient accès à des données cohérentes quels que soient les changements intervenant au cours de leurs requêtes.
L’approche transactionnelle fournit des fonctionnalités avancées dont la cohérence permet d’aller plus vite et ce, avec plus de sécurité. La mise en cache est également bien plus facile avec les transactions. Les données des tables et même les métadonnées peuvent ainsi être mises en cache et n’être relues que lorsque le système transactionnel indique que la table a été changée. Les résultats des requêtes peuvent aussi être mis en cache et recalculés uniquement quand une modification est indiquée. Le système transactionnel sait quand les vues matérialisées sont à jour et permet à l’utilisateur de décider quand les privilégier plutôt que de consulter la table de base. Une fois qu’il est avéré que la vue matérialisée est obsolète, l’algorithme de rebuild peut utiliser les transactions pour déterminer comment procéder en un minimum d’étapes. Et grâce aux transactions, le système de réplication peut identifier facilement ce qui a été modifié dans une table pour ensuite l’envoyer vers une autre.
La protection et la gouvernance des données de ces tables transactionnelles doivent également être assurées. Le contrôle d’accès au niveau de toute la base de données, d’une table ou, pire, des fichiers où sont stockées les données de base de la table, ne suffit pas. Il convient alors d’appliquer des autorisations au niveau de la colonne et de la ligne. Les responsables de la conformité doivent pouvoir identifier les données à caractère personnel et restreindre l’accès à ces tables, colonnes ou lignes. Ceci doit s’appliquer quel que soit l’outil d’accès.

Ces transactions linéaires doivent être prises en charge par l’ensemble des outils. Un aspect essentiel de l’écosystème Big Data consiste à offrir le choix du meilleur outil à partir de technologies open source innovantes. Ceci exige donc de la flexibilité puisque de nouveaux arrivent sans cesse. Il doit alors être possible d’enregistrer des flux de données dans une table avec Spark et de la lire avec Presto. Il faut aussi pouvoir mettre à jour une table dans Hive et l’interroger avec Impala sans impacter la cohérence transactionnelle. Cette compatibilité doit aussi s’étendre au stockage, avec des tables dans S3, GFS, ADLS et HDFS.
Alors comment satisfaire ces exigences dans l’écosystème Big Data ? La compatibilité des tables transactionnelles avec les différents outils suppose de réunir les trois conditions suivantes : partage du stockage, des métadonnées et transactions, et de la sécurité et gouvernance. Tout doit être ouvert et utilisable par l’ensemble des acteurs.
Pourtant, même quand ces conditions sont réunies, le partage des données entre outils peut s’avérer difficile. En effet, la compatibilité avec les données se faisait auparavant sur la base des formats de fichiers auquel les transactions et la nécessité d’une sécurité avancée ne correspondent plus. De plus, on ne peut pas raisonnablement attendre de chaque outil qu’il comprenne le stockage de données des autres. Des outils différents peuvent alors traiter les données différemment, y compris avec le même format de fichier. Certains ne proposeront pas toutes les fonctionnalités de sécurité requises pour avoir accès à un jeu de données spécifique. Il faut alors créer des liens pour faciliter l’accès aux différentes solutions.

Des compromis doivent être trouvés au moment de décider comment connecter les outils aux bases transactionnelles et de sécurité existantes. Les entreprises doivent être conscientes que la compatibilité induit d’autres considérations que les seules écritures et lectures des tables transactionnelles. Un outil peut par exemple choisir d’appliquer une fonctionnalité d’une certaine façon et un autre d’une manière différente, deux approches non compatibles. Prenons l’exemple de la segmentation des données en alvéoles (buckets). Spark utilise une fonction différente de celle de la dernière version de Hive. Si chaque outil lit les données écrites par l’autre en pensant que celles alvéolées suivent sa propre approche, les résultats obtenus seront incorrects. Mais le métastore peut facilement enregistrer la façon dont les données ont été segmentées et informer les utilisateurs quand le schéma utilisé est différent du leur. Ainsi, le métastore conservera une trace du mécanisme utilisé. Quand des données segmentées par l’algorithme Spark sont lues par Hive, le traducteur garde les données intactes et informe juste Hive que celles de Spark ne sont pas segmentées afin d’éviter qu’il traite le schéma Spark comme le sien et produise des résultats erronés.

Il est ainsi primordial de comprendre la vision, les fondements et la façon de rendre compatibles les outils et les technologies de l’entrepôt de données de nouvelle génération.