Revisión de Google Hadoop (dataproc)

Hace algún tiempo, activé una prueba gratuita en Google para su nube, no resolví mi problema, resultó que Google da $ 300 por 12 meses en la prueba, pero en contra de mis expectativas, se imponen otros límites además del límite presupuestario. Por ejemplo, no permití el uso de máquinas virtuales con más de 8 vcpu en una región. Después de medio año, decidí usar el presupuesto de prueba para familiarizarme con dataproc, un clúster preinstalado de Google. La tarea es tratar de evaluar qué tan fácil sería para mí lanzar un proyecto sobre el acceso de Google, si tiene sentido o si es mejor concentrarse inmediatamente en mi hardware y pensar en la administración. Tengo la vaga sensación de que el hardware moderno y los bigdates deberían adaptarse fácilmente a pequeñas bases de datos de decenas o cientos de GB, cargando brutalmente, si no todo el conjunto de datos, la gran mayoría en la memoria del clúster. Es posible que ya no se requieran algunos subdatos separados para los data marts.

En resumen, dataproc quedó impresionado por la facilidad de lanzamiento y configuración, en comparación con Oracle y Cloudera. En la primera etapa, jugué con un clúster de nodo en 8 vCpu, el máximo de los cuales permite una prueba completamente gratuita. Si observa la simplicidad, su tecnología ya permite que un hindú inicie un clúster en 15 minutos, cargue datos de muestra y prepare informes utilizando una herramienta de BI normal, sin ventanas secundarias intermedias. Ya no se requiere ningún conocimiento profundo de Hadoup.

En principio, vi que la cosa es maravillosa para un comienzo rápido y, por un dinero razonable, puede ejecutar un prototipo y evaluar qué tipo de hardware necesita para una tarea. Sin embargo, un grupo más grande, en docenas de nodos, obviamente comerá mucho más que un alquiler + un par de administradores que están mirando el grupo. Lejos del hecho de que la nube se verá económicamente viable. El primer paso intenté evaluar una opción completamente micro con un clúster de nodo 8 vCpu y 0.5 TB de datos sin procesar. En principio, las pruebas de chispa + hadoop en grupos más grandes ya están completas en Internet, pero planeo probar la opción un poco más tarde.

En solo una hora, busqué en Google las secuencias de comandos para crear una copia de seguridad del clúster, configurar su firewall y un servidor de segunda mano, lo que permitió que jdbc se conectara a spark sql desde Windows. Pasé otras dos o tres horas optimizando la configuración predeterminada de chispa y cargando un par de tablas pequeñas de aproximadamente 10 GB de tamaño (el tamaño de los archivos de datos en Oracle). Empujé todas las tablas a la memoria (alter table cache;) y fue posible trabajar con ellas desde mi máquina Windows desde Dbeaver y Tableau (a través del conector spark sql).

De forma predeterminada, spark utilizaba solo 1 ejecutor en 4 vCpu, edité spark-defaults.conf, instalé 3 ejecutores, 2 vCpu cada uno y durante mucho tiempo no pude entender por qué realmente solo tengo 1 ejecutor en mi trabajo. Resultó que no edité la memoria, los otros dos hilos simplemente no podían asignar memoria. Configuré 6.5 GB en el ejecutador, después de lo cual los tres comenzaron a aumentar como se esperaba.
Luego, decidí jugar con un volumen un poco más serio y una tarea más cercana a DWH de las pruebas de TPC-DS. Para empezar, generé oficialmente tablas con un factor de escala 500 de la herramienta oficial. Obtuve algo así como 480 GB de datos sin procesar (texto delimitado). La prueba TPC-DS es un DWH típico, con hechos y dimensiones. No entendía cómo generar datos directamente en el almacenamiento de Google, tenía que generar máquinas virtuales en el disco y luego copiarlas en el almacenamiento de Google. Google, según tengo entendido, cree que el capó funciona perfectamente con el almacenamiento de Google y la velocidad allí promete un poco mejor que si los datos estuvieran dentro del clúster en HDFS. En este caso, parte de la carga va de HDFS a Google Storage.

Después de conectarme a través de Dbeaver, convertí los archivos de texto en tabletas basadas en parquet con empaquetado rápido utilizando comandos SQL. 480 GB de datos de texto empaquetados en archivos de parquet de 187 GB. El proceso tomó aproximadamente dos horas, la tabla más grande en el texto ocupaba 188 GB, 3 ejecutores de chispas los convirtieron en parquet en 74 minutos, el tamaño del SUV fue de 66.8 GB. En mi escritorio con aproximadamente el mismo 8 vCpu (i7-3770k) creo que "insertar en la tabla select * ..." en una tabla Oracle con un bloque de 8k tomaría un día, y cuánto imagina el archivo de datos sería incluso aterrador.



Luego, verifiqué el rendimiento de las herramientas de BI en dicha configuración, elaboré un informe simple en Tableua



En cuanto a las consultas, Consulta1 de la prueba TPC-DS


completado en 1:08, Consulta2 con la participación de las tablas más grandes (catalog_sales, web_sales)


completado en 4:33 minutos, Consulta3 en 3.6, Consulta4 en 32 minutos.

Si alguien está interesado en la configuración, debajo de cortar mis notas sobre cómo crear un clúster. En principio, solo hay un par de comandos de gcloud y la configuración HIVE_SERVER2_THRIFT_PORT.


Continuará ...