meetup errores en proyectos big data

Errores que todos cometemos en proyectos Big DataJulio 2016

Meetup

Presentación

Presentación

JORGE LÓPEZ-MALLA

Tras trabajar con algunasmetodologías tradicionalesempecé a centrarme en el

mundo del Big Data, del cualme enamoré. Ahora soy

arquitecto Big Data en Stratio yhe puesto proyectos en

producción en distintas partesdel mundo.

Jorge López-Malla Matute

ÍNDICE

[email protected]

Stratio

123

Empecemos por el principio: conceptos

Errores en Proyectos en Batch (Con Spark)

Errores en Proyectos en Streaming (Con Spark)

4 Ruegos, preguntas e historias de abuelo cebolletas

Empecemos por el principio: conceptos

1

Conceptos

• ¿Qué es el Big Data?

• ¿Todas las BBDD NoSQL son BBDD Big Data?

• ¿Qué quiere decir que un problema es horizontalmente escalable y que quiere decir que es verticalmente escalable?

Empezamos por el principio: Conceptos

• ¿Qué es Hadoop?

Prerrequisitos

• La diversidad y cantidad de fuentes requiere un estudio exhaustivo previo.

• Los datos casi nunca están tan “limpios” como nos dicen o creemos

• Un fallo en una fuente no puede parar el proceso


Tecnologías

• Debido al boom del Big Data han salido infinidad de nuevas tecnologías

• Dado que los proyectos Big Data suelen ser proyectos de innovación se busca usar la última versión de la última tecnología

• Aunque tenemos distintas opciones para el almacenamiento distribuido de la información tendemos a querer usar una sóla solución para todo.


Repositorios Distribuidos

• Nombramos como BBDD repositorios distribuidos de datos que no lo son (Elastic Search, HDFS, ….)

• Hay que tener en cuenta la variedad de claves en las BBDD de Clave Valor


HDFS + Parquet

• Una de las soluciones más usadas por su versatilidad y eficiencia.

• Parquet NO convierte a HDFS en una BBDD.

• Aunque Parquet tenga un formato columnar sigue siendo un formato de ficheros.


• Errores típicos:

Escribir directamente a HDFS con formato Parquet:

Las principales herramientas de ETL no distribuidas de Big Data no ofrecen esta posibilidad.

Para salvar la información con formato Parquet hay que usar un esquema compatible con la herramienta que lo procese más tarde

Tendríamos que hacer un proceso que leyera de HDFS para luego ingestar en Parquet.

HDFS + Parquet



Intentar Actualizar/Borrar en Parquet

HDFS + Parquet


file1.parquet file1.parquetProceso Spark

/folder/parquet /tmp/parquet

mv de HDFSBorrado de

HDFS

file1.parquet

Borrado de HDFS


¿Tienes realmente un problema de Streaming?

Streaming


¿De verdad?

¿Tienes la tecnología de ingesta de datos necesaria para ingestar tus datos en Tiempo Real?


¿El cliente tiene claro que el proceso de Machine Learning requerirá de su o de la intervención de un tercero?

Machine Learning


Debido a la inmadurez de algunos algoritmos de Machine Learning usados en entornos Big Data nos tenemos que cercioranos de su performance.

Errores en proyectos Batch usando Spark

2

Introducción


• Aunque se hable de Batch para diferenciar las distintas “patas” de Spark, se hace referencia al core

• Cualquier cambio para mejorar que se haga con estas instrucciones vale para las demás “patas”.

• Se hace referencia principalmente a HDFS pero es extensible a cualquier repositorio de información distribuido (teniendo en cuenta las particularidades de cada uno).

• Se explica todo para Spark 1.6.2 dado que Spark 2.0 acaba de salir.

Excepciones



Mi trabajo de Spark ha fallado por una excepción y la traza de la aplicación no me dice nada útil.

Si el fallo se ubica en actor distribuido (Executor) puede que la traza no sea lo suficientemente verbosa en el Application.

• Actores involucrados en Spark

Excepciones


Driver

Worker-1

Worker-2

Worker-3

SparkMaster Executor-2

Executor-1

Executor-3

Excepciones


• Ayudas

Revisar log de las distintas máquinas virtuales involucradas en un job de Spark

La localización de estos log se define por configuración.

La Spark web es tu amiga ¡úsala!

Excepciones


Última partición infinita



Mi trabajo de Spark se queda trabado en la última partición.

Casi con total seguridad NO es la última partición.

Normalmente está asociado a una mala distribución de las claves.

• Una partición mucho más grande

Última partición infinita


Driver

Executor-1

Executor-2

Executor-3

RDD1 = 10.7G

= 100 Mb

= 10 Gb

Paralelismo


• Ayudas:

No suele haber solución “fácil”

La web de Spark nos puede dar la pista (sobre todo a partir de qué nos pitan el DAG 1.4)

Coalesce/reparttion son nuestros amigos

¡Cuidado con el Shuffle!

Paralelismo


• repartition/coalesce:

= 100 Mb

= 10 Gb

coalesce

= 1,52 Gb

Paralelismo


• Ayudas:

Paralelismo



Al aumentar mi input el tiempo de procesamiento de mi trabajo crece de manera no orgánica con el crecimiento de mis datos.

Es uno de los problemas más típicos cuando ingestamos nuestros datos de manera secuencial, diaria/mensual, dentro de un mismo repositorio de datos, sobre todo HDFS.

Primero revisar memory leaks dentro de nuestras fases.

Puede ser un problema de paralelismo

Paralelismo

• Como paraleliza Spark el trabajo.

HDFS

/user/folder2

/user/folder2

1G

1M 1M 1M

1G

Job1

Job2


1G1G

1M1M 1M

Spark

Paralelismo

• Como paraleliza Spark el trabajo.

HDFS

/user/folder2

/user/folder2

1G

1M 1M 1M

1G

Job1

Job2


1G1G

1M1M 1M

SparkIngesta

1M 1M 1M

1M 1M 1M 1M 1M 1M

1M1M 1M

1M1M 1M 1M1M 1M

Paralelismo


• Soluciones:

Determinar de antemano las unidades mínimas de computación.

Hacer un proceso de “actualización” de los datos

Hay que tener en cuenta los problemas de Actualización de HDFS

Si estamos hablando de HDFS y ficheros en “crudo” llamar periódicamente al método getMerge.

Paralelismo



Al aumentar el tamaño de memoria de mis procesos no estoy notando mejora o al aumentar el número de cores para realizar mis trabajos no estoy encontrando mejora ninguna

Normalmente quiere decir que no has encontrado tu paralelismo ideal para tu trabajo.

Paralelismo

• Pocos cores y mucha memoria


Driver

Executor-1

Executor-2

Executor-3

RDD1 = 5g

= 512 Mb

= 1Gb

2 cores6 Gb

2 cores6 Gb

2 cores6 Gb

Paralelismo

• Sólo aumentamos memoria :(


Driver

Executor-1

Executor-2

Executor-3

RDD1 = 5g

= 512 Mb

= 1Gb

2 cores8 Gb

2 cores8 Gb

2 cores8 Gb

• ¡Solución!

Paralelismo


Driver

Executor-1

Executor-2

Executor-3

RDD1 = 5g

= 512 Mb

= 1Gb

3 cores3 Gb

3 cores3 Gb

3 cores3 Gb

• Muchos cores y poca memoria

Paralelismo


Driver

Executor-1

Executor-2

Executor-3

RDD1 = 5g

= 512 Mb

= 1Gb

3 cores1 Gb

3 cores1 Gb

3 cores1 Gb

• Sólo aumentamos cores :(

Paralelismo


Driver

Executor-1

Executor-2

Executor-3

RDD1 = 5g

= 512 Mb

= 1Gb

4 cores1 Gb

4 cores1 Gb

4 cores1 Gb

• ¡Solución!

Paralelismo


Driver

Executor-1

Executor-2

Executor-3

RDD1 = 5g

= 512 Mb

= 1Gb

3 cores3 Gb

3 cores3 Gb

3 cores3 Gb

Paralelismo


• Ayudas:

No suele ser fácil/automatico encontrar la combinación ideal

Son necesarias varias ejecuciones y jugar con valores máximos para evitar OOM.

Por norma prima el paralelismo (cores) a la memoria (Gigas), siempre que se haga una solución escalable.

Más sencillo lanzando el trabajo sobre Mesos/YARN

Mezcla de datos



Al hacer una fase de combinación, mi trabajo se traba.

Suele ocurrir cuando hacemos operaciones que no son eficientes, groupByKey, al hacer la agregación

Error bastante común para los que vienen del “mundo Hadoop”

Revisar la distribución de las claves.

Mezcla de datos


Odon, F

Infor, H

Odon, F

Infor, F

Odon, H

Odon, F

Infor, H

Odon, F

Infor, H

Infor, H

Infor, H

Odon (F, F, H, F, F)

Infor (H, F, H, H, H, H)

Odon 80,00

Infor 16,66

GroupByKey

Mezcla de datos


• GroupByKey:

Contras

Todos los valores de una misma clave se copian a la misma partición pudiendo dar problemas de memoria

Se multiplica la escritura en disco. (Sí, Spark escribe en disco)

Pros:

Nos permite hacer todo tipo de operaciones (alguna vez es inevitable usar el groupByKey)

Mezcla de datos


• GroupByKey:

Mezcla de datos


Odon, F

Infor, H

Odon, F

Infor, F

Odon, H

Odon, F

Infor, H

Odon, F

Infor, H

Infor, H

Infor, H

Odon (66.66, 3)

Infor (50.0, 2)

aggregateByKey

Odon (100.0, 2)

Infor (0.0, 1)

Infor (0.0 , 2)

Infor (0.0 , 2)

Odon (80.0, 5)

Infor (16.66, 6)

Mezcla de datos


• aggregateByKey:

Contras

No permite hacer todo tipo de operaciones (Sólo aquellas conmutativas y asociativas)

Pros:

Sólo se escribe a disco un valor por clave y partición.

Minimiza al máximo las escrituras a disco (más aún con el proyecto Tugnsten)

Mezcla de datos


• AggregateByKey:

Mezcla de datos


• Ayudas:

Evitar el Shuffle sobre todas las cosas.

Usar la Spark Web cuando se hagan procesos para ver el gráfico del DAG.

Siempre hacer join del RDD más “pequeño”

Mezcla de datos



Al juntar dos RDD mi trabajo se traba.

join es una de las operación más comunes dentro de Spark

Si al hacerlo tenemos problemas de performance tendremos que revisar los partitioner de los RDD involucrados

las variables de broadcast son nuestras amigas, ¡úsalas!

Mezcla de datos


RDD1 = 15g

RDD1 = 1M

Mezcla de datos


Errores en proyectos Streaming usando Spark

3

Introducción


• El tiempo real empieza a ser una realidad en nuestras casuísticas de Big Data

• Auge de nuevas tecnologías de procesamiento en paralelo con naturaleza Streaming

• Aunque hay mejoría en Spark 2.0, y más en futuras versiones de la misma, esta charla se explicará usando Spark 1.6.2 dado que Spark 2.0 acaba de salir

Delay excesivo



Mi trabajo de Spark en Streaming va aumentando el retardo en tiempo hasta que llega a minutos(u horas o dias).

Suele pasar en soluciones en las que se ha diseñado sin pensar en cómo procesa Spark en Streaming.

Pasa en escenarios en los que los datos no crecen de manera orgánica

• ¿Cómo funciona Spark Streaming?(a alto nivel)

Delay excesivo


Batch interval

Reciver

RDD1 RDD2 RDD3 RDD4

RDD1 RDD2 RDD3

RDD5

RDD4

RDD6

RDD5

RDD7

RDD6

Delay excesivo


• Ayudas

Cuando se diseñe la solución hay que tener en cuenta los picos, tanto alto como bajos de nuestro proceso Streaming.

Estimar recursos siendo pesimistas nos suele ayudar, aunque sobredimensionemos nuestro aplicativo

Una vez más, la spark Web es nuestra amiga, ¡úsala!

Ruegos, preguntas e historias de abuelo cebolletas

4

Preguntas

Ruegos, preguntas e historias de abuelo cebolletas

¡Esto es todo amigos!MUCHAS GRACIAS Y ANIMAROS A COMPARTIR CONOCIMIENTO

meetup errores en proyectos big data

Engineering