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

1. Construyendo una infraestructura
de Big Data rentable y escalable
Juan Martín Pampliega

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

7. ¿Por qué
evolucionar la
infraestructura?

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

10. Conceptos
Importantes

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

13. Arquitectura Lambda
Tiempo promedio de
respuesta?
Cantidad de tweets
en cierta hora?

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

16. Nuestra
arquitectura

17. Arquitectura inicial
S3

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

19. Evolución de la arquitectura
S3

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)

21. Lecciones
Aprendidas

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 …”)

26. Dónde aprender
más

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

28. Muchas Gracias!
¿Preguntas?
jobs@socialmetrix.com