NoSQL et Hadoop : changement de braquet en 2015

Les nouvelles facettes des bases NoSQL

Les bases NoSQL se sont ouvertes à d’autres options qui jusqu’alors étaient plutôt réservées à une poignée de fournisseurs de bases de données relationnelles. Toutefois, ce monde NoSQL est en perpétuelle évolution et cela devrait d’ailleurs se poursuivre en 2016.

En 2015, par exemple, MongoDB  a refondu le moteur de sa base, affirmant qu’il supporterait désormais un système de plug-ins pour y apporter de la flexibilité. Un élément généralement familier auprès des utilisateurs de la base MySQL. Ce nouveau moteur, nommé WiredTiger, doit résoudre des problèmes de lock-in qui freinaient quelque peu MongoDB. DataStax, qui publie une version commerciale de Cassandra, travaille quant à lui avec la communauté Open Source sur un nouveau moteur dont la sortie est prévue pour 2016.

Evidemment, ce qui caractérise NoSQL est justement son éloignement de SQL. Dans certains cas, il est toutefois supporté partiellement. Ce que souhaite une partie des utilisateurs de NoSQL, à la recherche de spécificités de SQL dans leurs processus de traitement des données. Les fournisseurs l’ont d’ailleurs bien compris. Cette année, Couchbase a par exemple présenté son langage de requête N1QL, qu’il positionne comme un environnement SQL pour le système de gestion de bases de données NoSQL de la marque.

Adaptations SQL au parfum d’Hadoop

Si d’un côté la « SQL-isation » des technologies NoSQL ne fait que commencer, celle pour le monde Hadoop a un peu plus progressé. Les technologies de type SQL-on-Hadoop, comme Hive, Impala et Presto, sont en gestation depuis maintenant des années et plusieurs d’entre elles ont éclos en 2015. Avec de tels outils, l’information stockée dans des lacs de données Hadoop devient facilement accessible, et donc exploitée – on raffine davantage les données ; celles-ci sont moins perdues dans des marécages de données.  Toutefois, SQL-on-Hadoop reste encore le terrain des early-adopers, travaillant à rechercher l’outil qui convient le mieux à leurs différents traitements. Tout dépend de la réussite de ces utilisateurs, car Hadoop pourrait devenir marginal s’il ne parvient pas à tirer profit des ressources en place, très versées dans le SQL.

Les fournisseurs, ainsi que les communautés Open Source, ont aussi contribué à augmenter le cœur d’Hadoop de nouvelles fonctions.  En octobre, par exemple, Cloudera a ajouté à cette complexe équation Hadoop, un data store en colonne, nommé Kudu. Il fonctionne avec Impala, moteur MPP SQL-on-Hadoop, au sein d’applications analytiques en temps réel. Selon votre point de vue, Kudu peut être perçu comme un complément ou une alternative à HDFS.

Spark joue sa partition

Assurément, le projet qui a le plus attiré l’attention est Apache Spark. Dès 2013, il était évident que le moteur, développé par l’Université de Barkeley, avait tout le potentiel pour remplacer MapReduce dans les traitements batch, tout en supportant également de nouveaux usages de traitement en temps réel. Même si finalement MapReduce attire toujours les utilisateurs, surtout ceux à la recherche de substituts aux opérations de chargement et de transformation des entrepôts de données, on peut dire que sa popularité s’est amoindri aux yeux des utilisateurs Hadoop qui n’ont d’yeux que pour les traitements ultra-rapides de Spark.

La startup Databricks s’est également distinguée en 2015, faisant son entrée dans le marché du Big Data avec une offre Cloud de Spark, disponible depuis juin. La société est dirigée par les créateurs originaux de Spark. Plutôt que de pousser des moteurs on-premise de Spark, Databricks a mise – au moins jusqu’à présent – sur le Cloud comme mode de distribution de Spark.

IBM a aussi rallié la cause Spark en 2015, s’engageant à former des développeurs au framework, et à embarquer la technologie dans ses produits. Le géant a également lancé une offre de services de Spark dans le Cloud.

Mais l’écosystème Spark comprend également des startups spécialisées dans l’intégration de données qui utilisent le framework et ses capacités de Machine Learning pour apprendre aux systèmes des patterns d’intégration. Certaines de ses sociétés avaient d’ailleurs considéré MapReduce en premier lieu avant de se ruer vers Spark.

Avec le temps, les fournisseurs et les utilisateurs auront la nécessité de devenir agile et seront prêts à intégrer de nouveaux moteurs de traitement, mais tout en gardant un œil sur les alternatives. Toutes ces technologies vantent un nouveau modèle de traitement des données capable d’apporter de nouvelles opportunités. Mais cela apporte aussi sa vague de difficultés, notamment auprès des professionnels de la donnée qui doivent prendre des décisions en matière.

Traduit et adapté par la rédaction