kovaleff - Fotolia
Quels critères pour bien choisir son moteur SQL-On-Hadoop
Rick van der Lans explique pourquoi il est important de bien évaluer les différences qui existent entre les technologies permettent d’interroger les données Hadoop avec SQL
Dans le monde d’Hadoop et de NoSQL, tous les projecteurs se tournent sur les moteurs SQL-On-Hadoop. Leurs différences sont notables, compliquant un peu plus le choix des entreprises. Cet article donne un éclairage sur les éléments clés à prendre en considération pour sélectionner la bonne technologie.
Avec les technologies SQL-On-Hadoop, il est aujourd’hui possible d’interroger des données stockées dans Hadoop, en ayant recours à SQL. Les utilisateurs peuvent y connecter presque tous les outils de reporting ou d’analyse afin d’étudier en profondeur les données. Auparavant, sans ces technologies, cette opération était réservée à une élite. Vous deviez avoir des compétences étendues en matière d’APIs, telles que celles liées à HDFS, MapReduce ou encore HBase, pour manipuler les données.
Désormais, grâce à SQL-On-Hadoop, tout le monde peut utiliser ses outils habituels de reporting. En entreprise, cela permet logiquement d’étendre les usages du Big Data et ainsi accroître le ROI.
Le premier moteur de ce type fut Apache Hive, mais d’autres ont également débarqué, comme CitusDB, Cloudera Impala, Concurrent Lingual, Hadapt, InfiniDB, JethroData, MammothDB, Apache Drill, MemSQL, Pivotal Hawq, Progress DataDirect, ScleraDB, Simba et Splice Machine.
A cela doit aussi s’ajouter les outils de visualisation de données car ceux-ci offrent également des capacités de requêtage SQL sur des données Hadoop. Ils ont d’ailleurs été conçus pour donner accès à des sources de données hétérogènes, dont Hadoop. Ils permettent aussi d’y intégrer d’autres sources. Parmi ces plateformes, on retrouve Cirro Data Hub, Cisco/Composite Information Server, Denodo Platform, Informatica Data Services, Red Hat JBoss Data Virtualisation et Stone Bond Enterprise Enabler Virtuoso.
Evidemment, il existe aussi certains systèmes de gestion de bases de données SQL qui supportent une persistance « polyglotte ». Ils peuvent par exemple stocker des données dans leurs propres bases natives SQL ou dans Hadoop ; en faisant cela, ils donnent un accès SQL aux données Hadoop. On retrouve par exemple HP Vertica (on MapR), Microsoft PolyBase, Actian ParAccel et Teradata Aster Database (via SQL-H).
Un même SQL sur Hadoop ?
Ainsi, les entreprises font face à un marché où les offres s’entrechoquent. Mais comment sélectionner l’offre la plus adaptée ? Les technologies sont-elles si identiques qu’il importe peu de choisir ?
La réponse : non. Toutes ne sont pas sur le même pied d’égalité. En surface, elles se ressemblent beaucoup, mais sous le moteur, elles sont très différentes. Par exemple, CitusDB sait où sont stockées toutes les données et cela lui permet d’y accéder de façon efficace. JethroData stocke les indexes pour avoir un accès direct aux données et Splice Machine propose une interface de type SQL transactionnel.
Choisir la bonne technologie SQL-On-Hadoop nécessite donc une analyse minutieuse des technologies. Vous pouvez commencer par passer en revue les différents critères listés ci-dessous :
- La syntaxe SQL. Plus la syntaxe supportée SQL est riche, plus le nombre d’applications sera élevé et pourra en bénéficier. De plus, si le support de SQL est étendu, les capacités de requêtage sur Hadoop seront surmultipliées. Cette opération ne sera plus réservée aux applications et aux outils de reporting.
- Jointures. Réaliser rapidement et efficacement des jointures sur des grandes tables n’est pas toujours faciles, surtout si le moteur SQL-On-Hadoop ne sait pas où sont stockées les données. Si cela n’est pas fait de manière optimisée, des répercutions sont à prévoir sur les I/O et cela risque de provoquer de nombreux transferts de données entre nœuds. Résultats, une dégradation des performances.
- Des données inhabituelles. A l’origine, SQL a été développé pour traiter des données très structurées : chaque enregistrement d’une table dispose d’un nombre de colonnes identique, chaque colonne une valeur atomique. Une structure traditionnelle que l’on ne retrouve pas partout. Les fichiers Hadoop peuvent renfermer des données imbriquées, des données variables (avec des structures hiérarchiques), dépourvues de schéma, par exemple. Un moteur SQL-On-Hadoop doit aussi être capable de traduire tous ces formats de données en des données relationnelles « flat ». Les requêtes doivent aussi pouvoir être optimisées pour ces formats.
- Format de stockage. Hadoop support certains formats « standard » de stockage des données, comme Parquet, Avro ou ORCFile. Plus les technologies SQL-On-Hadoop reconnaîtront et liront ces formats, moins il sera nécessaire de réaliser des transferts et de la réplication de données. Il est ainsi important de vérifier si un format propriétaire est utilisé.
- Fonctions personnalisées (UDF). Pour exécuter des fonctions analytiques complexes avec SQL, comme l’analyse discriminante gaussienne, il est clé qu’elles soient supportées par SQL ou puissent être développées. De telles fonctions sont appelées « User-defined functions » (UDF).
- Workloads multi-users. Il doit être possible d’entrer des paramètres qui déterminent comment le moteur partage ses ressources entre les différentes requêtes. Par exemple, des requêtes issues de différentes applications peuvent avoir des priorités de traitement plus ou moins élevées, celles à l’exécution longue devraient avoir une priorité moins élevée sur celles, plus simples, exécutées en simultané ; les requêtes imprévues mais très consommatrices de ressources doivent pouvoir être annulées ou temporairement suspendues. Les outils SQL-On-Hadoop nécessitent ainsi des gestionnaires intelligents et avancés de workloads.
- Fédération de données. Toutes les données ne sont pas stockées dans Hadoop. La plupart des données des entreprises sont encore stockées dans d’autres solutions, comme des bases SQL. Un moteur SQL-On-Hadoop doit dès lors supporter les jointures distribuées sur toutes les données stockées, quelle qu’en soit la source. Autrement dit, il doit supporter la fédération des données.
Traduit et adapté par la rédaction
