Réflexions autour de Polybase (SQL Server 2016)

A moins de vivre dans une grotte, vous avez pu voir (et peut-être déjà vous amuser avec) que la CTP de SQL Server 2016 était disponible.

Une des fonctionnalités que j’attendais énormément est Polybase, moteur permettant d’interroger des bases de données relationnelles et du Hadoop dans la même requête de manière transparente.

J’ai ajouté un commentaire sur l’excellent article de Charles-Henri dédié à la prise en main de l’outil, c’est ce commentaire que je vais reprendre en détaillant un peu ici.

Un peu d’histoire :

Polybase était auparavant disponible uniquement sur les appliances APS/PDW de Microsoft. Ces appliances renfermaient à la fois un serveur SQL et un cluster Hadoop. Toute la légitimité de Polybase était d’attaquer ses données de manière totalement transparente où qu’elles soient stockées.

A l’époque, nous, consultants BI, étions plutôt déçus de ne pas pouvoir jouer avec. Je ne crois pas me tromper en disant qu’en France, le marché était/est marginal et que nous n’avons/avions pas beaucoup l’occasion de le rencontrer chez des clients. De ce fait l’annonce de la disponibilité de Polybase avec SQL Server 2016 a suscité un certain intérêt.

Aujourd’hui :

Les use cases

Maintenant que c’est disponible j’ai beaucoup plus de mal à associer les business cases en face du moteur. Si l’on reste sur un contexte décisionnel, le cas d’usage principal serait de laisser une table de forte volumétrie sur le cluster Hadoop tandis que les tables de dimensions seraient sur SQL Server.

Mais je trouve ça quand même très limite niveau urbanisation des SI : qui irait stocker ses tables de faits dans un fichier Excel pendant que ses tables de dimensions sont dans une base relationnelle ? Parce que finalement, ça consiste à faire ça.

De plus pourquoi s’empêcher d’utiliser tous les composants disponibles dans Hadoop, en n’intégrant pas vos tables de dimensions à votre cluster ? Déporter des tables dans SQL Server va vous obliger à utiliser Polybase et tout jugement de valeur ou de polyvalence mis de côté, vous ne pourrez pas utiliser les dernières évolutions des différents composants (Pig, Hive, etc…)

Nouveau moteur

Le point suivant que j’ai relevé dans mon commentaire est le fait de re-développer un moteur from scratch. Alors j’étais un peu partisan car c’est une feature nouvelle sur SQL Server 2016, mais le moteur existe depuis APS/PDW. Ceci dit, ça reste jeune même à l’échelle du Big Data.

Ce qui me gêne principalement, ou m’interpelle, est le fait que Microsoft en partenariat avec Hortonworks a investi pas mal d’argent et de ressource via l’initiative Stinger ou via le développement d’HDInsight pour des avancées majeures sur Hive en terme de performance et d’optimisation. Je pense entre autres à l’utilisation du moteur Tez pour l’exécution de requête, à la vectorisation, ou le Cost Based Optimizer.

De plus Hive évolue très vite, on peut déjà l’utiliser avec Spark, etc…

Ma crainte est que Polybase n’évolue pas avec le même rythme de release. D’ailleurs n’est-il pas encore basé sur de l’exécution de code Map/Reduce (vraie question dont je n’ai pas la réponse à l’instant, mais je n’ai rien trouvé qui ne dise l’inverse), alors que toutes les avancées Big Data promettant le temps réel, ont tendance à s’en passer et à utiliser de nouveaux moteurs, pour ne profiter au final que de la partie système de fichiers distribuées.

Conclusion

Autant avec APS, je pouvais comprendre la nécessité d’un tel moteur : il permettait d’être le point d’entrée unique à nos données. De plus, les clients visés étaient forcément plutôt des personnes venant de SQL Server, c’était sympa de garder les mêmes habitudes en terme d’outil et d’écriture de requêtes.

Aujourd’hui j’ai l’impression que son avantage majeur est de pouvoir écrire son code via un seul IDE (Management Studio), ce qui semble quand même un peu léger. Surtout qu’il s’agit d’un moteur in-fine (Ce serait aberrant de dire que le seul avantage d’un moteur de voiture vient du fait qu’il utilise du SP98)

Et c’est pour ça qu’en conclusion de mon commentaire, j’écris que je préférerais un support de Hive dans Management Studio. Ce ne serait pas compliqué à mettre en oeuvre. Et Hive a exactement été développé pour ça : permettre à des développeurs SQL de travailler sur les données d’un cluster Hadoop. Et ça permettrait d’être au niveau en terme de release, sachant que SSMS a son propre développement maintenant.