Juan Martín Pampliega presenta sobre la construcción de una infraestructura de Big Data escalable y rentable. Explica que evolucionaron su arquitectura para manejar un volumen creciente de datos, reducir tiempos de procesamiento, y mitigar errores. Adoptaron conceptos como la arquitectura Lambda y sistemas distribuidos. Implementaron Kafka, Spark y Cassandra para lograr procesamiento distribuido, robusto y escalable. Aprendieron que es importante probar los sistemas y monitorearlos, y que herramientas no deben usarse
2. Juan Martín Pampliega
Senior Data Engineer, Socialmetrix
Ingeniero Informática, ITBA
Trabajando con proyectos relacionados con la temática de “Big
Data” desde 2011 (Globant/Google, Despegar.com, Socialmetrix).
@juanpampliega
jpampliega@socialmetrix.com
3. Agenda
• Acerca de Socialmetrix
• Razones para evolucionar la
infraestructura
• Conceptos en los que nos basamos
• Nuestra arquitectura
• Lecciones aprendidas
• Dónde aprender más
4. Socialmetrix
Medimos la actividad relacionada a
marcas, compañías y personalidades
en las redes sociales para generar
valor a profesionales de Marketing,
Investigación de Mercado y Producto.
6. Algunos números
• Capturamos +1.000 MM de interacciones en un mes
• Almacenamos +1 TB por mes de datos
• Tenemos en Amazon AWS +200 servidores, + databases,
+ambientes de prueba/staging
8. Big Data – otro nuevo paradigma
Volumen + Velocidad + Variedad
Nuevas Tecnologías (Kafka + Spark + Cassandra + Cloud)
Arquitectura de Procesamiento de
Datos
Distribuida, Robusta y Escalable
9. ¿Por qué construir una arquitectura de Big Data?
• Manejar un volumen de datos creciente y poco constante
• Reducir tiempos de procesamiento hacia “near real-time”
• Costos variables
• Workloads variados: procesamiento batch y real-time,
analytics
• Mitigar la incertidumbre generada por errores o cambios en
el procesamiento
11. Conceptos: sistema de datos distribuído
• Teorema CAP: ante una partición en el sistema solamente
se puede asegurar consistencia o disponibilidad
• La mutabilidad de los datos de un sistema distribuido
causa las limitaciones de consistencia y disponibilidad
• Eliminando la mutabilidad sólo hay lecturas y escrituras (no
se borran los datos)
• query = function(all data)
12. Conceptos: Arquitectura Lambda
• Arquitectura genérica de procesamiento de datos creada
por Nathan Marz de su experiencia trabajando en Twitter y
Backtype
• Posee un único maestro de datos, append only.
• Un componente batch que re-computa todas las vistas en
cada iteración y uno real-time para información con baja
latencia
14. Arquitectura Lambda
• Crear un sistema tolerante a fallos tanto de hardware como
los humanos
• Lecturas y escrituras de baja latencia
• Escalabilidad lineal horizontal
• Facilidad de re-procesos
• Permitir la investigación interactiva de los datos
15. Arquitectura Lambda (críticas)
• Duplicación de lógica
• Duplicación de conocimiento en las herramientas
• Asume que el procesamiento real-time no es confiable
18. Limitaciones encontradas
• Hive
• Lenguaje SQL (orientado a consultas y no a
procesamiento, IDEs poco útiles)
• Herramientas de testing precarias
• Tiempos de ejecución prolongados y variables
• MySQL
• Baja performance para insert or update masivos
• Escalabilidad costosa
• Poca flexibilidad en el particionamiento
20. Desafíos al aplicar los conceptos
• Información duplicada y fuera de orden
• Recursos necesarios para re-procesar todo el histórico de
datos constantemente (Automatizar la asignación de
recursos según el volumen de datos a procesar o re-procesar)
• Evolución de los esquemas (Parquet, Apache Avro, Json)
• Problemas de encoding (MySQL utf8, utf8mb4)
22. Los errores
• Utilizar una herramienta para tareas que no fue diseñada
porque estamos familiarizados con ella
• No guardar los datos crudos (como se obtuvieron del
origen)
• No poner suficiente énfasis en tests y monitoreo
automático
23. Los aciertos
• Buscar como otros resolvieron los problemas que se nos
plantean
• Siempre mantenernos al tanto de los últimos desarrollos en
el área
• Permitir iterar sobre las soluciones ya desarrolladas para
ver como mejorarlas
• Orientarnos a lenguajes fuertemente tipados
24. Recomendaciones
• Utilizar un proveedor de cloud público sobre todo al inicio
de un proyecto
• Monitorear los procesos y aprender los patrones de los
datos
• Usar datasets medianos en Dev y grandes en Staging
25. Recomendaciones
• Ambientes de desarrollo locales y rápidos son tan
importantes como siempre
• Centralizar los logs (ELK: Elasticsearch, Logstash y
Kibana).
• Testing (“… In 58% of the catastrophic failures, the underlying faults could
easily have been detected through simple testing of error handling code …”)
27. Mucha documentación disponible
Lambda Architecture
http://lambda-architecture.net/
Getting Started with Big Data Architecture
http://blog.cloudera.com/blog/2014/09/getting-started-with-big-data-architecture/
Your weekly Hadoop news fix
http://www.hadoopweekly.com/
The Hortonworks Blog
http://hortonworks.com/blog/
Applying the Lambda Architecture with Spark - Jim Scott
http://spark-summit.org/2014/talk/applying-the-lambda-architecture-with-spark
Cloudera Engineering Blog
http://blog.cloudera.com/blog/
Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed
Data-Intensive Systems
http://neverworkintheory.org/2014/10/08/simple-testing-can-prevent-most-critical-failures.html
No solamente me interesa explicar cómo construir la infraestructura de procesamiento de dato si no por qué hoy en día es importante hacerlo
Actualmente siempre se hace referencia a la temática de Big Data hablando de la explosión de las 3 V en los últimos tiempos (Volumen, Velocidad y Variedad)
Pero en muchos casos, con la evolución de las bases de datos tradicionales desde Oracle hasta Teradata ya nos permiten manejar este problema.
Son las nuevas herramientas de manejo y procesamiento las que realmente forman un nuevo paradigma.
Herramientas desarrolladas por empresas de tecnología con fuerte base en la investigación y que principalmente se mueven en el ambiente de la Web
Estas herramientas son distribuidas desde sus inicios y extremadamente performantes
Este nuevo paradigma nos permite desarrollar una arquitectura de procesamiento
Volumen
Cada vez más surge la necesidad de procesar los datos lo más cercano al real-time para poder anticiparse a la competencia y reaccionar con un delay mínimo ante los problemas
Para comenzar no hay costos de licenciamiento o entrenamiento. Casi todo lo necesario para comenzar se encuentra disponible online y solamente se empieza a pagar una vez que las necesidades maduran y se está seguro de la solución