Hadoop Short Circuit Reads et performance des bases de données

Si vous avez travaillé avec Hadoop, vous avez probablement rencontré le concept des lectures en circuit court (SCR) et la façon dont elles peuvent améliorer les performances. De nos jours, ils sont généralement activés par défaut (bien que ce ne soit pas le cas dans Apache "vanille" ou ses dérivés proches comme Amazon EMR).

Actian VectorH intègre à Hadoop un système SQL haute performance, la conformité ACID et la sécurité d'entreprise, et j'ai voulu tester l'importance, ou non, des SCR dans les performances observées.

La première difficulté que j'ai rencontrée a été de savoir exactement ce qui est en place et ce qui est obsolète. C'est assez courant lorsqu'on travaille avec Hadoop - parfois la recherche Google, habituellement très utile, donne beaucoup d'informations contradictoires qui ne sont pas toutes assorties d'une date pratique permettant d'évaluer la pertinence du matériel. Dans le cas des SCR, la confusion initiale est principalement due au fait qu'il existe deux façons de les mettre en œuvre : l'ancienne méthode qui accorde un accès direct aux blocs HDFS - ce qui permet de réaliser des gains de performance mais ouvre une faille de sécurité, et la méthode plus récente qui utilise un socket de mémoire et garde ainsi le DataNode sous contrôle.

Notez que pour cet article, j'exclus MapR de la discussion. Pour autant que je sache, MapR implémente son équivalent de SCRs automatiquement et ne nécessite pas de configuration (veuillez me faire savoir si ce n'est pas le cas).

Avec la nouvelle méthode, les seules choses nécessaires pour faire fonctionner les SCR sont une bibliothèque native valide, la propriété dfs.client.read.shortcircuit définie sur true, et la propriété dfs.domain.socket.path définie sur quelque chose à laquelle le client et le DataNode peuvent accéder. *Notez qu'il existe d'autres paramètres qui affectent les performances des SCR, mais cette entrée ne les examine pas.

Sur mon cluster Hortonworks de test, voici ce que j'obtiens par défaut :

# hadoop checknative -a
16/03/09 12:21:41 INFO bzip2.Bzip2Factory : Successfully loaded & initialized ...
16/03/09 12:21:41 INFO zlib.ZlibFactory : Successfully loaded & initialized ...
hadoop : true /usr/hdp/2.3.2.0-2950/hadoop/lib/native/libhadoop.so.1.0.0
zlib : true /lib64/libz.so.1
snappy : true /usr/hdp/2.3.2.0-2950/hadoop/lib/native/libsnappy.so.1
lz4 : true revision:99
bzip2 : true /lib64/libbz2.so.1
openssl : false Cannot load libcrypto.so (libcrypto.so : cannot open shared ...

# hdfs getconf -confkey dfs.client.read.shortcircuit
vrai
# hdfs getconf -confkey dfs.domain.socket.path
var

Pour les tests proprement dits, j'ai utilisé l'un de nos clusters de démonstration standard. Il comporte 5 nœuds (1 NameNode et 4 DataNodes) exécutant, dans ce cas, HDP 2.2 sur RHEL 6.5. Les DataNodes sont des HP DL380 G7 avec 2 x 6 cœurs @2.8Ghz, 288GB RAM, 1x 10GbE network card, et 16x300GB SFF SAS drives (donc une spécification raisonnable en 2012 mais très loin de l'état de l'art d'aujourd'hui).

Les données utilisées pour le test sont un schéma en étoile comprenant environ 25 tables de dimensions dont la taille varie entre 100 et 50 millions de lignes, et une table de faits unique de 8 milliards de lignes.

Les requêtes de la démonstration joignent deux ou plusieurs tables de dimensions à la table des faits et filtrent sur une plage de dates ainsi que sur d'autres prédicats.

C'est là que j'ai rencontré mon deuxième défi - la plupart des requêtes utilisées dans la démo s'exécutent en quelques fractions de seconde et il n'y a donc pas beaucoup d'occasions de mesurer l'effet des SCR. Par exemple, la requête ci-dessous s'exécute en 0,3 seconde sur 8 milliards de lignes (chaque date cible environ 80 millions de lignes) :
[sql]
select
d1.DateLabel, d2.MeasureLabel, sum(f.MeasureValue)
à partir de
Fait f
,Date_Dim d1
d1 ,Measure_Dim d2
où
f.DateId = d1.DateId
et d2.MeasureId = f.MeasureId
et d1.DateLabel in ('05-Feb-2015′)
group by
d1.DateLabel
,d2.MeasureLabel
[/sql]
Pour avoir une chance d'observer les avantages des SCR, j'ai créé une requête qui a agrégé les 8 milliards de lignes contre toutes les lignes des deux tables de dimension (c'est-à-dire en supprimant le prédicat "and d1.DateLabel in (...)". Cela crée un ensemble de résultats de dizaines de milliers de lignes, mais cela ne fausse pas suffisamment le temps de résultat pour invalider le test.

Pour s'assurer que toutes les données sont lues à partir du DataNode, Actian VectorH a été redémarré avant l'exécution de la requête . Le cache du système de fichiers Linux a été laissé tel quel afin de ne pas perturber ce que le DataNode pourrait faire en interne avec les handles de fichiers, etc.

Armé de cette nouvelle requête , j'ai effectué mes premiers tests en comparant la différence avec et sans SCR et je n'ai obtenu aucune différence - Huh ! En explorant un peu la question, j'ai découvert que VectorH utilisait le réseau de manière très efficace, de sorte que l'absence de SCR n'affectait pas les temps de lecture. J'ai donc simulé une certaine charge réseau en utilisant scp et en envoyant des données entre les différents nœuds tout en exécutant les requêtes. Dans ces conditions, les SCR ont eu un impact positif global d'environ 10 %.

En conclusion, avec une bonne configuration de réseau et un logiciel qui en fait bon usage, les SCR n'offrent pas nécessairement un avantage termes de performances. Cependant, si le réseau est raisonnablement chargé, les SCR seront probablement utiles. La différence mesurée ici était d'environ 10 %.

À propos d'Actian Corporation

Actian facilite l'accès aux données. Notre plateforme de données simplifie la façon dont les gens connectent, gèrent et analysent les données dans les environnements cloud, hybrides et sur site . Avec des décennies d'expérience dans la gestion des données et l'analyse, Actian fournit des solutions de de haute performance qui permettent aux entreprises de prendre des décisions basées sur les données. Actian est reconnu par les principaux analystes et a reçu des prix de l'industrie pour sa performance et son innovation. Nos équipes partagent des cas d'utilisation éprouvés lors de conférences (par exemple, Strata Data) et contribuent à des projets à code source ouvert. Sur le blog d'Actian, nous couvrons des sujets allant de l'ingestion de données en temps réel à l'analyse pilotée par l'IA. Faites connaissance avec l'équipe dirigeante https://www.actian.com/company/leadership-team/