Octobre 2014 Quel moteur SQL choisir? Une comparaison de trois implémentations SQL sur Hadoop en termes de compatibilité, performance et évolutivité
Quel moteur SQL choisir? 2 Table des matières Rapport de synthèse... 2 Les avantages du SQL sur Hadoop... 3 Normes : le domaine prioritaire... 3 Evaluation des solutions SQL sur Hadoop... 3 SQL sur Hadoop les différentes implémentations... 4 Attention aux rapports subjectifs... 5 Ne pas négliger la performance... 5 Big SQL est synonyme de protection efficace des investissements...6 La qualité au-delà de la conformité... 6 Alors, lequel choisir?... 7 Pour en savoir plus... 7 Rapport de synthèse Lors d'un test de performance indépendant de trois implémentations populaires de SQL sur Hadoop, IBM a montré que Hadoop est capable d'exécuter des charges de travail OLAP et de requêtes complexes à un prix bien inférieur à celui des systèmes traditionnels... du moins, si vous choisissez la technologie appropriée. Face au nombre de fournisseurs vantant les mérites des performances et de la compatibilité de SQL sur Hadoop, IBM a décidé de tester les principales offres, en menant le tout premier test de performance Hadoop-DS. La comparaison a pour objet de tester IBM Big SQL, Cloudera Impala et Hortonworks Hive 0.13. Hadoop-DS est un test de performance d'aide à la décision Hadoop, élaboré par IBM et inspiré du test de performance reconnu Transaction Processing Council Decision Support (TPC-DS ). Pour rendre le processus équitable, IBM a constitué trois équipes concurrentes exécutant chaque distribution Hadoop sur des configurations matérielles identiques. IBM a fait appel aux services d'un professionnel TPC indépendant pour effectuer l'audit et établir une synthèse. En voici les résultats essentiels : Importance de la compatibilité IBM Big SQL est la seule solution ayant réussi l'exécution des 99 requêtes TPC-DS à l'échelle en effectuant des modifications mineures autorisées par les règles de TPC. Cloudera Impala est parvenu à exécuter 52 requêtes, et Hive en a exécuté 58 en conformité avec les règles de TPC. Les requêtes restantes ont nécessité des réécritures (parfois de grande ampleur) et l'exécution de certaines requêtes n'a même pas pu avoir lieu. Une mauvaise compatibilité SQL ne fait que nuire au résultat d'un test de performance, mais peut constituer un désastre en termes de coût dans un environnement de production. Importance du débit En comparant le Big SQL au sousensemble de requêtes pouvant être exécutées sur des plateformes concurrentes, IBM a exécuté les requêtes en moyenne 3,6 fois plus vite qu'impala et 5,4 fois plus vite que Hive lors d'un test d'une échelle de 10 To 1. Non seulement Big SQL est le seul moteur capable d'exécuter la charge de travail Hadoop DS, mais l'exécution de cette charge de travail est beaucoup plus rapide, en mode utilisateur unique ou multiples. Importance de l'échelle Hadoop reste associé au Big Data. IBM souhaitait initialement comparer les trois fournisseurs à une échelle de 30 To, mais il s'avère difficile d'obtenir de la stabilité à cette échelle. Même si Big SQL peut exécuter les requêtes de manière fiable à une échelle de 30 To, les plateformes concurrentes n'en sont pas capables et présentent diverses erreurs d'exécution. La même comparaison a été effectuée à une échelle de 10 To pour pouvoir reproduire les résultats, et donc les contrôler. Ces résultats sont parlants. Non seulement IBM Big SQL est la seule solution Hadoop testée capable de mener à bien l'exécution de l'ensemble des requêtes, mais elle s'avère également être la plus rapide, la plus évolutive et la plus fiable. 1 Résultat basé sur le «test de puissance» Hadoop DS. Les résultats de performance détaillés des tests de puissance et de débit sont présentés dans un rapport de test de performance connexe.
Quel moteur SQL choisir? 3 Les avantages de SQL sur Hadoop Dans les centres de données modernes, le SQL est devenu une méthode omniprésente d'accès et de manipulation des données. Le SQL fut d'abord un outil utilisé uniquement par les développeurs et les administrateurs de base de données. Aujourd'hui, la plupart des professionnels et analystes possèdent au moins des notions de SQL ou utilisent des outils dont il est la norme. Même si les types de données non structurées retiennent toute l'attention de cette étude pour les charges de travail Big Data, la plupart des projets réels concernent des données de journaux ou de transactions 2 (des formats généralement adaptés à la manipulation avec le SQL). Par conséquent, il n'est pas surprenant que SQL sur Hadoop soit étroitement lié à l'action. Même si l'on ne jurait que par Hive il y a quelques années, il existe désormais au moins une dizaine de solutions commerciales et open source de la concurrence liées au SQL sur Hadoop. Les fournisseurs cherchent à faire la différence sur le plan des performances, de la compatibilité et du niveau d'évolutivité, pour pouvoir supporter des charges de travail de production en situation réelle. Normes : le domaine prioritaire Les normes sont importantes dans tous les secteurs d'activité. Elles présentent plusieurs avantages : réduction des coûts, développement du marché, stimulation de l'innovation, réduction des risques. De manière générale, elles permettent aux organisations de prendre une longueur d'avance. Il en va de même pour le langage SQL. Dans presque toutes les organisations, le SQL est le pilier des données d'entreprise utilisées dans les systèmes transactionnels, les entrepôts de données, les bases de données en colonnes et les plateformes analytiques, pour ne citer que quelques exemples. De plus, un grand nombre d'outils commerciaux et développés en interne, utilisés pour accéder aux données, les manipuler et les visualiser, reposent sur le langage SQL. Le SQL est la clé de voûte des systèmes modernes de prise en charge des transactions et des décisions. L'unique souhait d'une organisation est d'adopter une technologie compatible avec les équipements qu'elle possède. L'utilisation de logiciels open source est un atout, mais la normalisation est finalement le facteur majeur, pour assurer le fonctionnement de ces logiciels. Evaluation des solutions SQL sur Hadoop Les clients savent bien que les tests de performance qui comptent le plus concernent leurs propres applications. Cependant, le test de performance TPC Benchmark DS (TPC-DS) fait partie des plus rigoureux en matière de tests standard. TPC-DS est un test de performance d'aide à la décision qui modélise plusieurs aspects des opérations métiers d'un grand commerçant au détail. Composé de 99 requêtes distinctes, il modélise des opérations commerciales en situation réelle, qui sont considérées comme courantes dans ce secteur d'activité et dans d'autres domaines. Même s'il n'existe aucun résultat officiel à la publication de ce document, TPC-DS est largement considéré comme un test de performance fiable et complet. De par sa rigueur et son réalisme, il est presque impossible pour les fournisseurs de «fausser» ce test de performance, tant qu'ils en respectent les spécifications et les règles. 2 70 % des 465 personnes interrogées citent les données transactionnelles comme objet principal des initiatives liées au Big Data - Note de recherche Gartner «Survey Analysis - Big Data Adoption in 2013 Shows Substance Behind the Hype», 12 sept. 2013. Analystes : Lisa Kart, Nick Heudecker, Frank Buytendijk
Quel moteur SQL choisir? 4 Fonctionnement immédiat à partir du modèle Modifications de requête conformes Les systèmes SQL sur Hadoop ne peuvent pas respecter certaines exigences technologiques du test de performance TPC-DS. IBM s'est donc inspiré de ce dernier pour créer le test de performance Hadoop-DS, en utilisant les mêmes requêtes et jeux de données. Cependant, certaines exigences non réalisables avec les systèmes Hadoop ont été écartées du test, telles que l'exécution d'opérations de gestion de données ou l'application de l'intégrité référentielle. Le test de performance est conçu pour modéliser les systèmes dans lesquels les données opérationnelles servent à la fois à une prise de décisions rapide et à la supervision d'une planification et d'une exploitation à long terme. Les requêtes concernées peuvent être classées globalement en quatre catégories. Fonctionnement immédiat à partir du modèle Modifications de requête conformes Réécriture de requête non conforme Requêtes de génération de rapport Requêtes ad hoc Requêtes OLAP itératives Requêtes d'exploration de données Mauvais fonctionnement ou pas de ré-écriture Fonctionnement immédiat à partir du modèle Modifications de requête conformes Réécriture de requête non conforme Mauvais fonctionnement ou pas de ré-écriture Figure 1 Compatibilité des requêtes par solution SQL sur Hadoop En raison des variations de taille des entreprises, le test de performance est également conçu pour modéliser à l'échelle des entrepôts de tailles différentes. Les tailles d'échelle standard sont les suivantes : 100 Go, 300 Go, 1 To, 3 To, 10 To, 30 To et 100 To. SQL sur Hadoop les différences d'implémentation L'une des premières difficultés du test de performance consiste tout simplement à réussir à exécuter les requêtes dans les trois environnements Hadoop. De ce point de vue, les implémentations SQL sur Hadoop ne sont pas toutes équivalentes à leur création. Comme le montre la Figure 1, IBM Big SQL est parvenu à exécuter 99 des requêtes standard TPC-DS après la création du jeu de données. 87 requêtes se sont exécutées immédiatement et 12 autres ont pu être modifiées facilement en quelques heures. Celles-ci ont fait l'objet de changements mineurs de syntaxe autorisés par les spécifications du test de performance TPC-DS 3. 3 La section 4.2 de la spécification TPC-DS 1.1.0 disponible sur le site tpc.org contient les règles relatives aux types de modification admissibles ou non.
Quel moteur SQL choisir? 5 Les autres distributions s'en sortent moins bien. Dans le cas de Cloudera Impala, 35 requêtes se sont exécutées sans modification, 17 ont nécessité des modifications mineures en conformité avec les règles TPC-DS, et 36 ont fait l'objet de modifications plus vastes non conformes au test. Obstacle plus important, certaines des 99 requêtes n'ont pas pu être exécutées du tout, soit parce qu'aucune ré-écriture de la requête n'a pu être effectuée, soit en raison d'un échec lors de l'exécution. La situation s'est avérée similaire dans le cas de Hive.13. 32 requêtes se sont exécutées immédiatement, 26 autres se sont exécutées suite à des modifications conformes et 13 ont pu être ré-écrites suite à des modifications non conformes au test. Cependant, lorsque l'équipe a augmenté l'échelle du test, les requêtes fonctionnant à une échelle plus réduite ont cessé de fonctionner. Pour une taille de jeu de données de 10 To, 30 % des requêtes ne se sont pas exécutées du tout. Cet exercice met en évidence un défi auquel les clients sont susceptibles de faire face s'ils tentent d'adapter des schémas et applications SQL à des implémentations SQL sur Hadoop. Attention aux rapports subjectifs Les fournisseurs se plaignent fréquemment des performances associées au test de performance TPC-DS en ne ciblant que certaines requêtes de la série des 99, et donc, en ne publiant que les requêtes qui s'avèrent fonctionnelles, présentent in fine une offre sous l'aspect le plus favorable. Dans certains cas, les fournisseurs modifient même les schémas de table pour éviter les problèmes de compatibilité ou stimuler les performances. Il est évident que ce n'est pas la meilleure manière de procéder à un test de performance. En réalité, les règles du test de performance interdisent expressément cette pratique. Le fait que la vitesse d'exécution des requêtes sélectionnées puisse être optimisée n'est pas une nouveauté, contrairement à l'échec complet de l'exécution de nombreuses requêtes SQL ANSI du test sur des plateformes concurrentes. Vous pouvez imaginer les défis associés à l'exécution de votre propre application de production sur une plateforme qui ne prend même pas en charge 50 % de vos requêtes standard. Cela reviendrait à une «ré-écriture» de l'application, ce qui génère des risques, des coûts supplémentaires et des retards. Ne pas négliger la performance Il n'a pas été possible d'établir une comparaison complète entre Impala, Hive et Big SQL, car Hive et Impala n'ont réussi à exécuter qu'un sous-ensemble des requêtes. Cependant, les résultats concernant l'ensemble commun des 46 requêtes exécutées avec succès par toutes les distributions ont pu faire l'objet d'une comparaison. La Figure 2 montre une comparaison directe du temps écoulé pour l'exécution de l'ensemble commun de requêtes sur les trois distributions. Même si Big SQL est parvenu à exécuter les 99 requêtes, cette comparaison ne prend en compte que celles également réussies par Hive et Impala. IBM Big SQL a terminé l'ensemble des requêtes communes en 48 minutes et 28 secondes, alors qu'impala a mis 2 heures, 55 minutes et 36 secondes. Hive.13 a enregistré les plus mauvaises performances d'exécution des requêtes, avec une durée de 4 heures, 25 minutes et 49 secondes.
Quel moteur SQL choisir? 6 18 000 16 000 14 000 12 000 10 000 8 000 6 000 4 000 2 000 0 Big SQL Impala Hive Figure 2 : Durée en secondes de l'exécution de l'ensemble commun de requêtes sur chaque plateforme SQL sur Hadoop Le même classement a été obtenu lors du test de débit, qui consistait à exécuter simultanément quatre flux de requêtes. Big SQL est synonyme de protection efficace des investissements Bonne nouvelle pour les clients d'ibm : Big SQL offre une protection efficace des investissements. Non seulement Big SQL est l'unique moteur SQL sur Hadoop capable d'exécuter toutes les requêtes lors des tests, mais c'est également le plus rapide et le seul à atteindre une taille de jeu de données de 30 To. Mieux encore, il n'est pas nécessaire pour les clients de faire de compromis sur les normes. Une compatibilité SQL rigoureuse signifie que les clients disposent des possibilités suivantes : Utilisation des investissements existants pour les logiciels, les outils et les compétences humaines Exécution d'applications existantes, le cas échéant, sur des entrepôts de données SQL sur Hadoop Exécution des requêtes plus rapide, plus efficace et à plus grande échelle, ce qui se traduit par une réduction des coûts de fonctionnement La qualité au-delà de la conformité Les normes de conformité et de performance sont essentielles, mais il est tout aussi important qu'une implémentation SQL donnée montre ce qu'elle a de plus que les autres. Dans Hadoop, cela implique plusieurs aspects : Prise en charge de formats open source Utilisation de pilotes de base de données côté client standard Prise en charge de fonctions intégrées attendues par les utilisateurs de SQL Présence de fonctions de sécurité sophistiquées Accès fédéré à plusieurs sources de données Formats de données ouverts, standard le SQL est un langage utile. Grâce à la normalisation et à plusieurs décennies de maturation, il est désormais reconnu et à même de résoudre de nombreux problèmes. Toutefois, ce n'est pas le seul langage disponible ni toujours la meilleure solution à tous les problèmes. Hadoop possède un éventail en expansion constante de langages et d'outils d'analyse de jeux de données volumineux. Cependant, pour pouvoir utiliser cette mine d'outils, les données doivent exister sous des formats Hadoop standard. Les adeptes d'hadoop seront heureux d'apprendre que les entrepôts de données Big SQL n'existent pas. Une table définie dans Hive est une table définie dans Big SQL, et inversement. Big SQL prend en charge 100 % des formats de fichier HDFS natifs. Ce n'est pas le cas de toutes les distributions, et les clients doivent se méfier des implémentations SQL sur Hadoop faisant intervenir leurs propres métadonnées propriétaires. Pilotes côté client courants Outre la possibilité de partager le SQL entre plusieurs plateformes, Big SQL prend en charge des pilotes client IBM standard, qui permettent d'utiliser les mêmes ensembles de pilotes JDBC, JCC, ODBC, CLI et.net conformes aux normes sur plusieurs bases de données et systèmes d'exploitation. Les clients qui utilisent ces pilotes peuvent accéder à IBM Big SQL, DB2, IBM Informix et aux environnements tiers de base de données de manière transparente. En combinant une implémentation SQL standard avec des pilotes spécialisés standard, il est possible d'augmenter le nombre d'applications FIL capables d'interagir de manière fluide avec IBM Big SQL. Des fonctions intégrées moteurs de productivité - Une implémentation SQL qui fonctionne est différente d'un environnement qui rend ses utilisateurs productifs. Doté d'une bibliothèque riche de plus de 250 fonctions intégrées, associées à des fonctions OLAP SQL, Big SQL est fait pour l'analyse. Il offre des fonctions avancées telles que la prise en charge de sous-requêtes, des types SQL supplémentaires et des variables (de session) globales.
Quel moteur SQL choisir? 7 Ces fonctions permettent tout simplement aux utilisateurs de faire plus de choses et de répondre à davantage de questions au sein de l'environnement SQL. S'ils utilisent d'autres solutions SQL ne possédant pas ces fonctions, les utilisateurs peuvent être contraints d'écrire du code personnalisé pour mettre en œuvre des fonctions déjà intégrées à Big SQL. Sécurité et audit Pour certaines implémentations SQL, la sécurité est secondaire. Big SQL a été conçu dans une optique de sécurité. L'authentification utilisateur est gérée par des mécanismes standard tels que LDAP et Kerberos. Big SQL s'intègre donc de manière fluide à votre environnement d'entreprise. Big SQL prend en charge des contrôles d'autorisation flexibles basés sur les utilisateurs, les groupes et les rôles. Il utilise la syntaxe standard SQL GRANT et REVOKE, familière aux administrateurs de base de données. En complément des contrôles d'accès de base au niveau table, Big SQL prend en charge des contrôles d'accès granulaires aux rôles et aux colonnes (RCAC). Le contrôle d'accès granulaire et des fonctions telles que le masquage de données permettent d'étendre la gamme de solutions auxquelles Big SQL peut prétendre. Big SQL fournit également des outils complets d'audit venant compléter son système flexible d'authentification et d'autorisation. En d'autres termes, Big SQL offre la richesse des fonctions de sécurité que les administrateurs RDBMS s'attendent à trouver dans l'univers Hadoop. Requêtes fédérées Dans les centres de données modernes, les données résident rarement à un seul endroit. Certaines données se trouvent dans des bases de données relationnelles et d'autres dans des entrepôts de données ou des bases de données en colonnes spécialisées. Big SQL prend en charge un éventail de fonctions de fédération, qui permettent aux utilisateurs d'écrire des requêtes servant à accéder non seulement aux données Hadoop, mais également à d'autres bases de données. Une même requête peut permettre d'associer des données issues de Big SQL, de Hive sur Hadoop, d'une table d'entrepôt Teradata, avec des données d'une base Oracle. Alors, lequel choisir? Les résultats de ce test de performance sont parlants. Les organisations placent d'énormes enjeux dans le langage SQL. La dernière chose dont les clients ont besoin est un dialecte SQL pour Hadoop, et un autre pour leur environnement de base de données traditionnel. Il est important de souligner que Big SQL est parvenu à exécuter la charge de travail Hadoop- DS, contrairement aux autres implémentations SQL sur Hadoop. Les résultats montrant que Big SQL est également plus rapide, plus évolutif, plus stable et plus riche en termes de fonctions sont tout à fait impressionnants. Big SQL est la seule implémentation capable d'exécuter l'intégralité des requêtes du test de performance Hadoop-DS Big SQL enregistre des performances plus de trois fois supérieures à celles de son concurrent le plus proche lors du test en mode utilisateur unique Big SQL est la seule offre capable d'atteindre 30 To et d'exécuter l'intégralité de la charge de travail à cette échelle Ce résultat ne doit pas surprendre. IBM a tout de même inventé le SQL et possède plus de 30 ans d'expérience en matière de création de moteurs et d'optimiseurs de requêtes SQL. Dans le domaine du SQL sur Hadoop, il est clair que c'est IBM InfoSphere BigInsights avec Big SQL qu'il faut choisir. Pour en savoir plus Pour en savoir plus sur Big SQL, téléchargez gratuitement le livre blanc d'ibm «SQL-on-Hadoop without compromise» à l'adresse suivante : https://www14.software.ibm.com/webapp/iwm/web/signup.do? source=sw-infomgt&s_pkg=ov23626 Pour essayer gratuitement IBM Big SQL, téléchargez IBM InfoSphere BigInsights QuickStart Edition, ou exécutez BigInsights sur le cloud à l'adresse suivante : http://www.ibm.com/software/data/infosphere/hadoop
Quel moteur SQL choisir? 8 Remarque : Les performances sont basées sur des mesures et des projections qui utilisent les tests de performance IBM standard dans un environnement contrôlé. Les résultats ou performances réelles peuvent varier d'un utilisateur à l'autre selon de nombreux facteurs. Il peut s'agir de la quantité de multiprogrammation dans le flux de travaux de l'utilisateur, de la configuration E/S, de la configuration de stockage et de la charge de travail traitée. Par conséquent, il n'existe aucune garantie selon laquelle chaque utilisateur obtiendra des résultats similaires à ceux présentés dans ce document. Copyright IBM Corporation 2014 Compagnie IBM France 17 avenue de l'europe 92275 Bois Colombes Cedex Imprimé en France Octobre 2014 Tous droits réservés IBM, le logo IBM, ibm.com, BigInsights, Cognos, DB2, Informix, InfoSphere, PureData et z/os sont des marques ou des marques déposées d'international Business Machines Corporation aux Etats-Unis et/ou dans certains autres pays. Si ces marques et d'autres marques d'ibm sont accompagnées d'un symbole de marque ( ou ) lors de leur première occurrence, ces symboles signalent des marques d'ibm aux Etats-Unis à la date de publication de ce document. Ces marques peuvent également exister et éventuellement avoir été enregistrées dans d'autres pays. La liste actualisée de toutes les marques d'ibm est disponible sur la page Web «Copyright and trademark information» à l'adresse ibm.com/legal/copytrade.shtml TPC Benchmark, TPC-DS et QphDS sont des marques du Transaction Processing Performance Council. Cloudera, le logo Cloudera et Cloudera Impala sont des marques de Cloudera. Hortonworks est une marque de Hortonworks Inc. Hadoop et Hive sont des marques de l'apache Software Foundation. Linux est une marque déposée de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays. Microsoft, Windows, Windows NT et le logo Windows sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays. Java et tous les logos et marques basés sur Java sont des marques ou des marques déposées d'oracle et/ou de ses partenaires. UNIX est une marque déposée de The Open Group aux Etats-Unis et dans certains autres pays. Les autres noms de produits, de sociétés et de services peuvent appartenir à des tiers. Dans cette publication, les références à des produits et services IBM n'impliquent pas qu'ibm prévoie de les commercialiser dans tous les pays où IBM est implanté.