En 2016, on ne parle que de Big Data et de modèles analytiques extraordinaires. Mais les journalistes, comme les consultants, ont oublié qu’il y a loin de la « coupe aux lèvres » et que les problèmes techniques sous-jacents restent particulièrement difficiles à résoudre.

Parmi ceux-ci, il y a le formatage des données, sur lesquelles va porter le modèle analytique, en aval.

Car il faut bien comprendre le paysage auquel on a affaire.

On se retrouve devant un certain nombre de fournisseurs de données, qui publient des résultats de mesure ou de calcul, généralement avec des formats physiques différents, qu’ils stockent dans des fichiers qui peuvent être autant des bases de données relationnelles que des fichiers « à plat » ou toute autre structure logique. Pas facile donc, sauf à passer par des étapes de transcodage longues, de les attaquer par des moteurs analytiques standards.

Il convient donc de fédérer ces sources, sur lesquelles il n’est pas possible d’intervenir en amont, mais que l’on modifiera (via leurs créateurs) pour que les données qu’elles génèrent viennent s’insérer harmonieusement dans un réceptacle commun.

Et c’est là où intervient une nouvelle fois Apache.

Arrow, la fusion « in-memory »

L’idée qu’a eue Apache a été de mettre « autour de la table », un certain nombre de contributeurs de l’écosystème Hadoop, parmi lesquels Spark, une plate-forme d’analyse de gros volumes de données avec des fonctions de « learning machine » et de prédictivité, Drill un moteur SQL pour attaquer des données Hadoop, Kudu un moteur analytique dédié aussi à Hadoop, Impala qui effectue des traitements en temps réel sur des données structurées ou non (alternative à Map and Reduce), etc.

Apache ayant aussi pris soin d’associer à son projet Arrow d’autres prestataires, qui ne participent pas nécessairement et directement à Hadoop, comme Cassandra (base NoSQL colonnes/clés valeurs), Pandas une API destinée à Python ou Storm, une architecture de traitement distribuée en clusters.

Par ce biais, Apache fédère aussi les intégrateurs et développeurs qui sont derrière ces technologies, comme Hortonworks, Cloudera et MapR.

Tous ces « gens » étant réunis, il est alors plus facile de leur expliquer qu’ils ont tout intérêt à définir un format logique de données commun, qui constituera une sorte de fondation de données, auquel ils contribueront tous, format qui sera élaboré de manière à gommer les différences existant entre eux et accélérer les traitements effectués en aval.

Apache leur demande donc de générer une structure de données logique, conforme à ce format commun.

L’option qui a été choisie avec Arrow est une base de données « in-memory » organisée en mode colonnes, comme peut l’être le fameux « Big Table » de Google, ou Cassandra, en fait un mixte de deux structures logiques.

Au bout du compte, chaque fournisseur va générer les données au format attendu, via des interfaces spécifiques internes, données que l’on pourra ensuite « attaquer » en mode « in-memory », sans passer par les phases pénalisantes de sérialisation/désérialisation, qu’Apache estime représenter entre 70 à 80 % du temps total de traitement (prétraitement des données, pour les rendre compatibles avec un moteur de requête externe).

L’autre très gros avantage d’Arrow sera d’être compatible avec toute forme de données, relationnelles, dynamiques JSON, générées par exemple par des objets dans l’IoT, NoSQL clé-valeurs, colonnes, etc.

Un écosystème à part

On voit bien comment les choses vont évoluer.

A l’intérieur de l’écosystème Hadoop, va donc se constituer une sorte de sous écosystème de l’écosystème, avec quelques contributeurs Hadoop et l’apport d’autres compagnies, capable de prendre en charge le « Big Data » sous toutes ses formes, traitement et stockage, avec une population homogène, qui parlera le même langage, avec des temps de traitement supersoniques dus au mode « in-memory » et au stockage logique « colonnes » retenus.

Pour Apache le projet Arrow est tellement important qu’il n’est pas passé par la mécanique habituelle de création de projet et il l’a déclaré d’emblée « top-level », une appellation spécifique, qui lui évite de passer l’examen de l’Incubator, chère à son VP Ted Dunning.

Nous prenons tous les paris : Arrow sera aussi important dans l’histoire d’Apache que l’aura été Hadoop lui-même. Et ce format deviendra le PDF de l’analytique.