Codemotion 2016

Como hacer óptimo un proyecto Big Data y no morir en el intento

Noviembre 2016

Jorge López-Malla Matute

[email protected]@jorgelopezmalla

ÍNDICE

1

2

3

Empecemos por el principio: conceptos

Seleccionemos tecnología y afrontemos consecuencias

Retos habituales y soluciones para no tirarse de los pelos

4 Ruegos, preguntas e historias de programador cebolletas

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.

SKILLS

Empecemos por el principio: conceptos

1

Big Data

• ¿Qué es el Big data?

○ Procesamiento de cantidades masivas de información que no pueden ser tratadas de manera tradicional en un tiempo y con un coste razonable

• Pero, ¿qué conlleva técnicamente?

○ Cambios en la forma de afrontar los problemas buscando la escalabilidad horizontal

○ ¿Nuevos roles?

Empezamos por el principio: Conceptos

Escalabilidad horizontal• Un problema es escalable horizontalmente siempre y cuando el aumento del

input se solucione con un aumento del número de recursos no de los propios recursos.


NoSQL

• ¿Qué es NoSQL?○ Nuevos sistemas de RDBMS que rompen con algunas reglas anteriores

rompiendo, en muchos casos el ACID

• Tipos (generales)○ Clave/Valor -> Google Big Table, BerkleyDB○ Columnar -> Apache Cassandra, Apache HBase○ Grafos -> OrientDB, Neo4j○ Documental -> Couchbase, MongoDb,○ ….

• No todas son válidas para el Big Data


Seleccionando tecnología y afrontando las consecuencias Seleccionemos tecnología y afrontemos consecuencias

2

Seleccionando tecnología y afrontando las consecuencias

Big Data Boom

• El Big Data tiene aproximadamente una década.

• La casuística en esa década ha pasado de procesos ETL en Batch a complicados algoritmos de Machine Learning en Tiempo Real

• Esto ha conllevado un boom tecnológico desmedido en los últimos años.

• Muchas tecnologías válidas satisfacen problemas muy concretos de una manera muy eficiente

• ¡Nunca dejarse llevar por el brillo de lo nuevo!


Pautas generales

• Aunque la casuística puede ser tremendamente compleja nos debemos hacer las siguientes preguntas para hacer una buena selección de tecnología:

○ ¿Cual es mi volumen real de información?

○ ¿Como voy a consultar luego esa información?

○ ¿De qué tipo de origen obtenemos la información?

• Valen respuestas a medias pero hay que afrontar consecuencias.

• Esto NO es una guía definitiva.


Volumen

• Si la respuesta a la primera pregunta es: No tanto:

○ NO TIENES UN PROBLEMA DE BIG DATA, SEGURAMENTE VAS A MATAR MOSCAS A CAÑONAZOS.

■ Tecnología sugerida: la que más experiencia tengas Oracle/MySQL.

• Si la respuesta es lo suficiente para que Oracle no sea rentable

○ ¡Tienes un problema Big Data!

■ Tecnología sugerida: Dependerá del problema pero mira primero HDFS + Parquet.


Consulta• Si vamos a procesar FullScan

○ HDFS + Parquet■ Buena compresión, coste de almacenamiento menor.■ Mala consulta parcial. mucho coste de cargas incrementales,

• Si vamos a hacer queries definidas de antemano○ Base de Datos NoSQL columnar/clave valor

■ tiempo de búsqueda inmejorable, por clave, coste de almacenamiento intermedio. No delay en cargas incrementales

■ Mala consulta por algo distinto a la clave o full scan.■ Nos obligan a que todas las queries sean por clave o que por lo menos contenga una

igualdad.

• Si vamos a hacer queries definidas de antemano○ Base de Datos NoSQL Documental con agregación previa

■ Versatilidad, coste de almacenamiento máximo. No delay en cargas incrementales■ Buena consulta por algo distinto a la clave o full scan, siempre que se construya un

indice por ese campo.

• Origen Estático○ Usar procesos Batch

■ Recomendación: Apache Spark

• Origen Streaming○ Apache Kafka es casi una obligación.

○ Procesos ETL:■ Si son sencillos -> Kafka Streams■ Si hay procesado complejo -> Apache Storm, Apache Spark, Apache

Flink

○ Resto de procesado■ Recomendación: Apache Spark por madurez y comunidad.

● Seguramente Flink se adapte mejor pero está un poco verde


Tipo de Origen

• Lamentablemente, en España se matan muchas moscas a cañonazos

• No nos podemos dejar cegar por el brillo de nuevas versiones, requieren madurez.

• No hay una tecnología de almacenamiento/ Procesamiento definitiva.

• Si buscamos soluciones óptimas necesitamos sistemas híbridos.○ Hay que duplicar la información.

○ No gusta en ninguna empresa, toca luchar o asumir pérdida de rendimiento

• Solución de almacenamiento más habitual HDFS+Parquet, aunque esto hace prácticamente imposibles las queries en tiempo real.


Conclusiones


3

• Aunque empiezan a dejar de ser POCs muchos proyectos Big Data no tienen definición cerrada.

• Suelen incluir a muchos departamentos dentro de una empresa.

• Pedir desde un primer momento la defición del usuario final.

• Dejar clara las consecuencias de las decisiones técnicas desde el primer momento

• Mostrar los avances al cliente lo más periódicamente posibles para poder tomar cambios de rumbo con sentido


Indefinición de objetivos

• El volumen de los datos es fundamental para llevar a buen puerto un proyecto Big Data

• No es necesaria una cantidad exacta, saber si hablamos de GB o de Tb suele ser suficiente

• Son necesarios tanto el volumen total como el volumen de ingesta.

• La periodicidad de los datos marca fases críticas como la ingesta.


Volumen y periodicidad de datos

• En todos los proyectos es importante tener un buen entorno de pruebas.

• La combinación de muchas tecnologías en constante evolución es el día a día de los proyectos Big Data.

• Invertir tiempo en automatizar las pruebas de integración.

• ¡Mucho ojo con las versiones y las compatibilidades!.


Entornos de pruebas

• Factor secundario, en el mejor de los casos, en la mayoría de tecnologías Big Data.

• Preferencia por la seguridad perimetral

• Al tener seguridad perimetral muchos de los Casos de Uso, sobre todo de explotación y representación de datos pueden quedar pequeños.

• Kerberos es la solución casi universal.

• Contar con la seguridad desde el principio es fundamental para no duplicar tecnologías.


Seguridad

• Usamos múltiples fuentes de distintos sistemas/organizaciones

• Un dato malo no puede parar la ingesta de una fuente.

• Nunca están tan “limpios” como prometen.

• Invertir tiempo siempre en automatizar una fase de saneamiento del dato.

• Cuidado con los DUMP de DataWarehouse.


Ingesta de datos

• La información casi siempre llega de manera incremental y de distintas fuentes

• Si usamos una BD NoSQL no hay mayor problema.

• Si usamos HDFS….

○ Definir un dato que determine la unidad mínima de procesamiento

○ Definir un proceso por partes en base a esa unidad.■ Usar carpetas temporales.■ Si usamos tambien parquet: usar la carpetas como datos.

○ Cuidado con los errores en el procesado.


Ingesta de datos

• Analiza si tú Casos de Uso tiene una casuística Streaming

• Si has decidido que sí, habla con la gente de sistemas de la empresa y vuelve a analizar.

• Las fuentes de información suelen ser fuentes ya existentes y es muy difícil que te dejen tocar sistemas en producción.

• Intentar ser lo menos intrusivo posible.

• Si no se puede ninguna de las opciones, ver la viabilidad de un proceso batch cada X segundos


Casos de Uso de Streaming

• Analiza si tú Casos de Uso tiene una casuística Machine Learning

• Si has decidido que sí, habla con tus data scientist y vuelve a analizarlo.

• Dejar claro al cliente que los procesos de Machine Learning requieren mucho tiempo de estudio de datos por parte humana.

• No deslumbrarnos con los algoritmos recién implementados en las librerías de Machine Learning.

• Llevar a los data scientist a todas las demos con cliente.


Casos de Uso de Machine Learning

Ruegos, preguntas e historias de programador cebolleta

4

Ruegos preguntas e historias de programador cebolletas

¿Preguntas?

¡Esto es todo amigos!

MUCHAS GRACIAS Y ANIMAROS A COMPARTIR CONOCIMIENTO

[email protected] ARE HIRING

@StratioBD

Technology

Codemotion 2016