Conferencia MySQL, NoSQL & Cloud: Construyendo una infraestructura de big data rentable y escalable
-
Upload
socialmetrix -
Category
Technology
-
view
112 -
download
2
Transcript of Conferencia MySQL, NoSQL & Cloud: Construyendo una infraestructura de big data rentable y escalable
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
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