Avec Facebook qui a récemment rendu public Presto open source, le marché déjà encombré des solutions pour le SQL sous Hadoop est juste devenu un peu plus complexe. Un certain nombre d'outils sont en compétition pour capter l'attention des développeurs : Stinger Initiative d'Hortonworks autour de Hive, Apache Drill, Apache Tajo, Impala de Cloudera, Phoenix de Salesforce (pour HBase) et maintenant Presto de Facebook.
Les organisations utilisant déjà Hadoop pour leur production réclament un support interactif pour les requêtes SQL et une intégration harmonieuse avec les outils de BI existants.
Vijay Madhavan (eBay) affirme sur son blog dans le post SQL in Hadoop landscape:
" Most of the current map-reduce based systems for analysis including current versions of Hive, Pig, Cascading work well in the non-interactive and batch SLA domain. Many products are attempting to support real-time and interactive SLAs by offering interactive "SQL in Hadoop" solutions. "
La plupart des systèmes basés sur la map-reduce pour les analyses, y compris les versions actuelles de Hive, Pig, Cascading fonctionnent bien pour le SLA (Service Level Agreement) dans le domaine du non-interactif et du batch. De nombreux produits essaient de répondre aux SLAs de manière interactive et en temps réel en offrant des solutions "SQL-in-Hadoop" interactives.
L'utilisation des solutions SQL pour Hadoop doivent permettre de supporter les requêtes ad-hoc interactives, de garantir les reporting/la visualisation en utilisant des systèmes de BI comme MicroStrategy/Tableau et les données multi-sources (par exemple: les données comportementales dans HDFS (Hadoop Distributed File System) doivent pouvoir être reliées aux données démographiques d'un SGBDR ou d'une autre source).
Beaucoup de ces solutions ont certains points communs :
- Au niveau des métadonnées, il semble que HCatalog / Hive Metastore s'impose comme la norme de facto pour la gestion de schémas pour différentes sources de données.
- Ensuite, il y a certains formats de données, tels que Parquet et ORC, qui — pour des charges de travail particulières — sont devenus de plus en plus populaires et plus largement utilisés.
- La plupart des solutions semblent respecter un large éventail de recommandations SQL de l'ANSI (American National Standards Institute) (sous différentes versions: 1992,1999, 2003).
Tous ces point communs devraient permettre aux utilisateurs de mixer entre les différentes solutions sans trop de difficultés pour les migrations.
Mais il y a aussi quelques différences notables, comme celles indiquées ci-dessous :
Certaines des solutions sont détenues par Apache et sa communauté (Stinger, Drill, Trajo) alors que d'autres sont détenues par des entités isolées (Impala, Phoenix, Presto).
De plus, certaines d'entre elles sont limitées pour les sources de données. Elles peuvent interroger le système Hadoop, alors que d'autres, du point de vue architectural, sont plus flexibles, en permettant d'interroger les bases de données relationnelles et les banques de données NoSQL in-situ (Presto, Drill).
Une autre différence se situe au niveau des opérations sur les données : certaines sont des systèmes de requête purs (distribués) tandis que d'autres permettent des opérations de mise à jour.
Durant les 10-18 derniers mois, de plus en plus de personnes et d'entités commerciales ont décidé de faire un essai et ont réalisé un accès SQL ad-hoc aux données stockées sur Hadoop avec une faible latence. Néanmoins, en raison d'une recoupe des besoins et des préférences en termes d'utilisation, il y aura probablement plus d'une solution SQL pour Hadoop dans le long terme.