Construyendo una infraestructura

de Big Data rentable y escalable

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

Juan Martín Pampliega

• Acerca de Socialmetrix

• Razones para evolucionar la

infraestructura

• Conceptos en los que nos basamos

• Nuestra arquitectura

• Lecciones aprendidas

• Dónde aprender más

Agenda

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.

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

¿Por qué

evolucionar la

infraestructura?

Big Data – otro nuevo paradigma

Volumen + Velocidad + Variedad

Nuevas Tecnologías (Kafka + Spark + Cassandra + Cloud)

Arquitectura de Procesamiento de Datos

Distribuida, Robusta y Escalable

¿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

Conceptos

Importantes

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)

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

Arquitectura Lambda

Tiempo promedio de respuesta?

Cantidad de tweets en cierta hora?

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

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

Nuestra

arquitectura

Arquitectura inicial

S3

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

Evolución de la arquitectura

S3

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)

Lecciones

Aprendidas

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

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

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

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

Dónde aprender

más

Mucha documentación disponibleLambda 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

Muchas Gracias!

¿Preguntas?

jobs@socialmetrix.com