Lecturas en cortocircuito en Hadoop y rendimiento de la base de datos

Si has estado trabajando con Hadoop es probable que te hayas topado con el concepto de Short Circuit Reads (SCRs) y cómo pueden ayudar al rendimiento. Hoy en día están habilitados por defecto (aunque no en Apache "vainilla" o derivados cercanos como Amazon EMR).

Actian VectorH aporta SQL de alto rendimiento, cumplimiento de ACID y seguridad empresarial a Hadoop, y quería comprobar la importancia, o no, de los SCR en el rendimiento observado.

El primer reto que tuve fue averiguar exactamente lo que está vigente y lo que está obsoleto. Esto es bastante común cuando se trabaja con Hadoop - a veces la normalmente muy útil "búsqueda en google" arroja un montón de información contradictoria y no toda ella etiquetada con una fecha útil para evaluar la pertinencia del material. En el caso de los SCR, la confusión inicial se debe principalmente a que existen dos formas de implementarlos: la más antigua, que permite el acceso directo a los bloques de HDFS, lo que mejora el rendimiento pero abre un agujero de seguridad, y el método más reciente, que utiliza un socket de memoria y, por tanto, mantiene el control del DataNode.

Tenga en cuenta que para esta entrada estoy excluyendo MapR de la discusión. Hasta donde yo sé, MapR implementa su equivalente de SCR automáticamente y no requiere configuración (por favor, hágamelo saber si ese no es el caso).

Con la nueva forma, lo único que se necesita para que funcionen los SCRs es una librería nativa válida, la propiedad dfs .client.read.shortcircuit puesta a true, y la propiedad dfs.domain.socket.path puesta a algo a lo que tanto el cliente como el DataNode puedan acceder. *Tenga en cuenta que hay otros ajustes que afectan al rendimiento de los SCR, pero esta entrada no los examina.

En mi clúster Hortonworks de prueba esto es lo que obtengo por defecto:

# hadoop checknative -a
16/03/09 12:21:41 INFO bzip2.Bzip2Factory: Successfully loaded & initialized ...
16/03/09 12:21:41 INFO zlib.ZlibFactory: Cargado e inicializado correctamente ...
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 revisión:99
bzip2: true /lib64/libbz2.so.1
openssl: false No se puede cargar libcrypto.so (libcrypto.so: no se puede abrir ...

# hdfs getconf -confkey dfs.client.read.shortcircuit
true
# hdfs getconf -confkey dfs.domain.socket.path
/var/lib/hadoop-hdfs/dn_socket

Para las pruebas utilicé uno de nuestros clusters de demostración estándar. Tiene 5 nodos (1 NameNode y 4 DataNodes) ejecutando, en este caso, HDP 2.2 sobre RHEL 6.5. Los DataNodes son HP DL380 G7 con 2 x 6 núcleos a 2,8 Ghz. Los DataNodes son HP DL380 G7s con 2 x 6 cores @2.8Ghz, 288GB RAM, 1x 10GbE network card, y 16x300GB SFF SAS drives (una especificación razonable en 2012 pero muy lejos del "estado del arte" actual).

Los datos para la prueba son un esquema en estrella con unas 25 tablas de dimensiones cuyo tamaño oscila entre 100 y 50 millones de filas, y una única tabla de hechos con 8.000 millones de filas.

Las consultas de la demostración unen dos o más de las tablas de dimensiones a la tabla de hechos y filtran en un intervalo de fechas junto con otros predicados.

La mayoría de las consultas utilizadas en la demostración se ejecutan en fracciones de segundo, por lo que no hay muchas posibilidades de medir el efecto de los SCR. Por ejemplo, la siguiente consulta se ejecuta en 0,3 segundos contra 8.000 millones de filas (cada fecha tiene como objetivo unos 80 millones de filas):
[sql]
seleccione
d1.EtiquetaFecha, d2.EtiquetaMedida, sum(f.ValorMedida)
de
Hecho f
,Fecha_Dim d1
,Medida_Dim d2
donde
f.DateId = d1.DateId
y d2.MeasureId = f.MeasureId
y d1.DateLabel en ('05-Feb-2015′)
agrupar por
d1.EtiquetaFecha
d2.MeasureLabel
[/sql]
Para tener la oportunidad de observar las ventajas de los SCR, creé una consulta que agregaba los 8.000 millones de filas contra todas las filas de ambas tablas de dimensiones (es decir, eliminando el predicado "and d1.DateLabel in (...)". Esto crea un conjunto de resultados de decenas de miles de filas, pero que no sesga el tiempo de resultado lo suficiente como para invalidar la prueba.

Para asegurarse de que todos los datos se leían desde el DataNode, Actian VectorH se reinició antes de ejecutar la consulta. La caché del sistema de archivos Linux se dejó tal cual para no interrumpir nada de lo que el DataNode pudiera estar haciendo internamente con los manejadores de archivos, etc.

Armado con esta nueva consulta realicé mis primeras pruebas comparando la diferencia con y sin SCR's y no obtuve ninguna diferencia en absoluto - ¡Huh! Explorando un poco descubrí que VectorH estaba usando la red muy eficientemente de modo que la ausencia de SCRs no afectaba a los tiempos de lectura. Entonces simulé alguna carga de red usando scp y enviando datos entre los diferentes nodos mientras ejecutaba las consultas. Bajo estas condiciones los SCRs tuvieron un impacto positivo de alrededor del 10%.

En conclusión, con una buena configuración de red y un software que haga buen uso de ella, es posible que los SCR no supongan una avantage de rendimiento. Sin embargo, si la red está bastante ocupada, es probable que los SCR ayuden. La diferencia medida aquí fue de alrededor del 10%.

Acerca de Actian Corporation

Actian hace que los datos sean fáciles. Nuestra plataforma de datos simplifica el modo en que las personas conectan, gestionan y analizan los datos en entornos en la nube, híbridos y locales. Con décadas de experiencia en gestión de datos y análisis, Actian ofrece soluciones de alto rendimiento que permiten a las empresas tomar decisiones basadas en datos. Actian cuenta con el reconocimiento de los principales analistas y ha recibido premios del sector por su rendimiento e innovación. Nuestros equipos comparten casos de uso probados en conferencias (por ejemplo, Strata Data) y contribuyen a proyectos de código abierto. En el blog de Actian, cubrimos temas que van desde la ingestión de datos en tiempo real hasta el análisis impulsado por IA.