Big Data : ce qu'il faut prendre en compte dans les formats de données

Pourquoi JSON ?

Le format de données Java Script Object Notation, ou JSON, est apparu comme le format de facto pour la transmission de données entre les applications, qu’elles soient sur site, dans le cloud, destinées à l’IoT ou mobiles. La raison : le support des structures de données imbriquées et complexes ainsi qu’une grande lisibilité. Mais cela n'est pas efficace lorsqu'il s'agit de stocker ou d'analyser des données. Tout comme l’est CSV finalement.

« L'utilisation de JSON comme format de stockage pour l’analytique conduirait à une dégradation des performances », explique ainsi Reynold Xin, architecte en chef et co-fondateur de Databricks, spécialiste du framework open source Spark. Cela s’explique de plusieurs façons. JSON et d'autres formats, comme CSV, sont lents à analyser. Le taux de compression d'un format en ligne comme JSON est bien pire qu'un format en colonne. En outre, il n'y a pas de statistiques intégrées dans le format JSON ; impossible donc de guider une application d'analyse afin d'éviter que ne soient parsées toutes les données inutiles.

Un autre problème est que JSON attache des métadonnées aux données lors de chaque enregistrement. Le volume des données est ainsi de cinq à dix fois plus élevé par rapport à d'autres formats de données. « Si vous devez effectuer une analyse sur un fichier JSON de 2 To et que tout ce dont vous avez besoin est de lire trois à quatre colonnes de données, alors le processus lira quand même toutes les données – y compris les 95 % qui ne sont pas nécessaires », soutient Ramu Kalvakuntla, architecte en chef chez Clarity Insights, un cabinet de conseils.

Le problème principal réside dans les jointures de tables. Les bases de données dites NoSQL comme MongoDB, Cassandra et Amazon DynamoDB, qui sont optimisées pour la lecture de valeurs-clés, sont très performantes avec les fichiers JSON. De leur côté, beaucoup de bases de données analytiques traditionnelles ou d'entrepôts de données cloud nécessitent des jointures de tables. « Il n'y a pas de mauvais format en soi, seulement des scénarios qui ne conviennent pas. Il n'existe pas de base de données universelle qui puisse s'adapter à tous les scénarios. C’est la raison pour laquelle plusieurs bases de données coexistent dans les entreprises, ce qui augmente les coûts de gestion et de maintenance », commente à son tour Mohit Bhatnagar, vice-président Produits chez Qubole, fournisseur de plateformes de données dans le cloud.

JSON : les alternatives

Mais il existe des alternatives, généralement mieux adaptées aux applications analytiques, comme Apache Parquet et Apache Optimized Row Columnar (ORC). Ces formats plus orientés colonnes facilitent la lecture partielle d’un fichier volumineux. Ils atteignent un taux de  compression de près de 90 % avec des performances cinq à dix fois plus élevées que les formats de fichiers JSON, ajoute Ramu Kalvakuntla. Autre format : Apache Avro est quant à lui en ligne. Il est certes rapide dans les traitements et reste performant en matière de compression, mais il n'est pas aussi rapide quand on extrait des données d'une seule colonne.

Impossible de ne pas citer le format K-Store, un autre format open source conçu par la société française Indexima. Celui-ci a été développé pour le cloud, en partant du principe que les formats Parquet et ORC ne sont que peu adaptés à ce type d’environnement. Leurs performances sont dégradées avec des services de stockage en mode bloc, de plus en plus utilisés pour stocker les données dans le cloud.

Si ces formats permettent de stocker les données plus efficacement, ils peuvent également présenter des difficultés en matière de gestion des données, surtout lorsque des processus utilisant Parquet et Apache Spark tournent en production, rappelle Reynold Xin (Databricks). Les ingénieurs de données doivent ainsi développer des pipelines complexes qui renferment un code maison dont la vocation est de prévenir la corruption des données. Ce code s’exécute en parallèle des lectures et des écritures simultanées. Les performances se dégradent avec l'augmentation du volume de données, puisque les données sont réparties sur un plus grand nombre de fichiers. De plus, il est difficile de traiter les données de mauvaise qualité, avec par exemple Parquet, car il n'y a aucun moyen d'appliquer les schémas.

Une autre approche consiste à séparer le format des données des outils utilisés par les utilisateurs, les développeurs et les analystes qui écrivent des requêtes, explique Justin Makeig, directeur de la gestion des produits chez MarkLogic, éditeur d’une base de données NoSQL. Certaines applications du système de gestion de base de données (SGBD) peuvent analyser les données et les modèles de requêtes et ajuster les index et les plans de requêtes.

Bill Tolson, vice-président du marketing du service d'archivage Archive360, a déclaré que beaucoup d’entreprises doivent stocker des données commerciales dans des formats adaptés à la conformité mais qui ne sont pas optimisés pour l’analytique. Elles utilisent alors un ETL pour transformer ces données brutes en un format plus hiérarchisé, de type JSON, et les injecter dans leurs applications analytiques.

Automatiser la transformation des données

Certains outils pourraient aussi permettre d’adapter dynamiquement les outils à différents scénarios d'analyse. Databricks a créé Databricks Delta, qui combine un moteur de traitement et un format ouvert construit sur Apache Spark et Parquet. Cela permet de générer des index optimisés pour les pipelines de données et de supporter les cas d’usage Big Data, analytiques et liés au Machine Learning.

Une autre approche consiste à tirer parti des optimiseurs d'indexation et de requêtes intégrés aux bases de données. Les éditeurs de SGBD investissent massivement dans l'automatisation de ce processus, souligne Justin Makeig (Marklogic). Cette automatisation pourrait adapter l’indexation à la volée sans que les administrateurs de bases de données n'aient à déclarer les requêtes à l'avance.

Équilibre entre simplicité et efficacité

Certains experts recommandent de choisir par défaut des formats de fichiers en colonnes, comme Parquet et ORC, pour des raisons d'efficacité, car ils fonctionnent bien dans de nombreux cas d’usage, souligne quant à lui David Besemer, vice-président de l'ingénierie chez OmniSci, spécialiste de l’analytique accélérée par GPU. Si on doit stocker les données dans un format différent, il est préférable de traiter le système analytique comme un bac à sable dans lequel les données sont chargées pour y être traitées.

D'autres suggèrent de commencer par les besoins techniques. « Lors du choix d'un format pour l’analytique, l'efficacité du stockage, la vitesse de traitement et l'interopérabilité sont des critères à prendre en compte, ainsi que les outils et les langages utilisés pour traiter les données », soutient Gökhan Öner, architecte principal chez Hazelcast, une société de base In-Memory. Selon lui, des jeux de données peuvent être stockés et traités plus efficacement en ayant recours à des formats différents pour chaque cas d'usage. Plutôt que de choisir le format le plus compact ou le plus rapide pour chaque cas, le choix d'un ou deux formats de données interopérables sera plus profitable dans le temps.

Commencez en ayant le résultat à l’esprit

Une bonne pratique consiste à commencer par le type d’indicateur métier que l’on souhaite voir émerger de ces données, en tenant compte des profils, des applications, du matériel et des processus en place. Le choix de la base de données vient après le choix du format de fichiers : « Certaines entreprises ont déjà fait leur choix de base de données. Mais les nouveaux projets introduisent généralement de nouvelles solutions et c'est généralement le rôle de l'architecte de données de considérer ces facteurs de manière holistique et de trouver un équilibre en tenant compte du budget, de la taille des équipes, de la croissance des données et des futures ambitions commerciales »,  explique Mohit Bhatnagar.

« Les inefficacités provoquées par des données désordonnées,  sans gouvernance sont probablement plus coûteuses et plus risquées que les problèmes de performances dûs à des structures de données inadaptées », rappelle Justin Makeig. De nombreux data scientists passent la plupart de leur temps à nettoyer les données, à les comprendre et à résoudre les problèmes de qualité en amont, plutôt qu'à effectuer des analyses. Cela peut être particulièrement problématique lorsque l'on travaille avec des données recueillies par d'autres. Opter pour une plateforme centralisée, cohérente sur le plan sémantique, permet de se concentrer sur l'analyse, et non pas sur les processus de transformation (ETL).