La problemática Big Data ha dejado de ser una nueva moda y se ha asentado como una nueva realidad en nuestro día a día, y la tecnolgía se ha adaptado a esta nueva realidad permitiendonos afortar problemas complejos de una manera sencilla y casi transaparete. Pero, ¿y nosotros, hemos cambiado la forma de ver los proyectos y de atacar la solución?¿seguimos tratando de solucionar esta nueva problemática con la misma metodología?¿Seguimos creyendo que el Big Data nos va a solucionar todos nuestros problemas por arte de magia? Esta charla versará sobre como, según la experiencia del ponente en distintos proyectos de distintas áreas de negocio, se han cambiado la forma de afrontar estos y de como se han solucionado los distintos problemas a la hora de afrontar un proyecto Big Data.

1. Como hacer óptimo
un proyecto Big
Data y no morir en
el intento
Noviembre 2016

2. Jorge López-Malla Matute
jlopezm@stratio.com
@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

3. Presentación
Presentación
JORGE LÓPEZ-MALLA
Tras trabajar con algunas
metodologías tradicionales
empecé a centrarme en el
mundo del Big Data, del cual
me enamoré. Ahora soy
arquitecto Big Data en Stratio y
he puesto proyectos en
producción en distintas partes
del mundo.
SKILLS

4. Empecemos por el
principio: conceptos
1

5. 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

6. 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.
Empezamos por el principio: Conceptos

7. 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
Empezamos por el principio: Conceptos

8. Seleccionando
tecnología y
afrontando las
consecuencias
Seleccionemos tecnología y afrontemos consecuencias
2

9. 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!

11. Seleccionando tecnología y afrontando las consecuencias
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.

12. Seleccionando tecnología y afrontando las consecuencias
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.

13. Seleccionando tecnología y afrontando las consecuencias
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.

14. • 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
Seleccionando tecnología y afrontando las consecuencias
Tipo de Origen

15. • 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.
Seleccionando tecnología y afrontando las consecuencias
Conclusiones

16. Retos habituales y
soluciones para no
tirarse de los pelos
3

17. • 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
Retos habituales y soluciones para no tirarse de los pelos
Indefinición de objetivos

18. • 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.
Retos habituales y soluciones para no tirarse de los pelos
Volumen y periodicidad de datos

19. • 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!.
Retos habituales y soluciones para no tirarse de los pelos
Entornos de pruebas

20. • 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.
Retos habituales y soluciones para no tirarse de los pelos
Seguridad

21. • 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.
Retos habituales y soluciones para no tirarse de los pelos
Ingesta de datos

22. • 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.
Retos habituales y soluciones para no tirarse de los pelos
Ingesta de datos

23. • 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
Retos habituales y soluciones para no tirarse de los pelos
Casos de Uso de Streaming

24. • 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.
Retos habituales y soluciones para no tirarse de los pelos
Casos de Uso de Machine Learning

25. Ruegos, preguntas e
historias de
programador
cebolleta
4

26. Ruegos preguntas e historias de programador cebolletas
¿Preguntas?

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

28. people@stratio.com
WE ARE HIRING
@StratioBD