Big Data, Small Dashboard - Andrea Maietta - Codemotion Milan 2016
Codemotion 2016
-
Upload
jorge-lopez-malla -
Category
Technology
-
view
387 -
download
0
Transcript of 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.
Empezamos por el principio: Conceptos
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
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!
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.
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.
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.
• 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
• 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
Retos habituales y soluciones para no tirarse de los pelos
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
Retos habituales y soluciones para no tirarse de los pelos
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.
Retos habituales y soluciones para no tirarse de los pelos
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!.
Retos habituales y soluciones para no tirarse de los pelos
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.
Retos habituales y soluciones para no tirarse de los pelos
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.
Retos habituales y soluciones para no tirarse de los pelos
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.
Retos habituales y soluciones para no tirarse de los pelos
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
Retos habituales y soluciones para no tirarse de los pelos
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.
Retos habituales y soluciones para no tirarse de los pelos
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