Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Big Data de verdad, en 4K y en tiempo real; Arquitectura Logtrust

982 views

Published on

Este mes vamos a ver una arquitectura Big Data de verdad (TB por cliente/día) donde se explicara como se lee y escribe tal cantidad de datos, como se procesa y como se muestra al usuario para sacarle verdadero partido.

Los ponentes serán Joaquín Diez (@joaquindiez) y Juan Vicente Herrera (@jvicenteherrera) de Logtrust.

Se explicara como era la arquitectura inicial, todos los problemas surgidos y sus soluciones, los puntos débiles a mejorar y como se administra todo a día de hoy mediante Ansible y la propia herramienta (Logtrust) para la monitorización de todo evento sucedido en la plataforma.

También se explicará la diferencia entre una instalación en nodos físicos y en la nube que es un punto muy sensible a la hora de tratar datos tanto por rendimiento como por seguridad de los mismos.

Published in: Data & Analytics
  • Be the first to comment

Big Data de verdad, en 4K y en tiempo real; Arquitectura Logtrust

  1. 1. Big Data de verdad, en 4K y en tiempo real; Arquitectura Logtrust Juan Vicente Herrera @jvicenteherrera Joaquin Díez Gómez @joaquindiez
  2. 2. BIG DATA en Tiempo Real
  3. 3. ¿Por qué BIG DATA?
  4. 4. All data that is not a fit for a traditional RDBMS, whether used for OLTP or Analytics purposes @eddie_satterly - Splunk
  5. 5. Eventos
  6. 6. BIG DATA en Tiempo Real
  7. 7. Casos de Uso
  8. 8. • Devops • Desarrolladores: detección de errores, análisis de uso de sus aplicaciones (Web, Apps) • Analíticas en Tiempo Real (User & Business) • Detección de anomalías, análisis de tendencias.
  9. 9. • CAPTURAMOS DATOS (Eventos) • ALMACENAMOS • EXTRAER SU VALOR POTENCIAL SIMPLIFICANDO
  10. 10. ¿por que no usar una Base de datos normal? • cuando se tiene un martillo todos los problemas son clavos. • ACID compromete los limites escalabilidad y rendimiento de los sistemas • No todos los datos necesitan almacenamientos ACID • NO ESCALAN EL PROBLEMA RDBMS
  11. 11. • 10 servidores • 8640 eventos por dia ( 1 cada 10 segundos) • 365 dias • = 31.536.000 eventos en 1 año
  12. 12. Big Data Technologies (2011-) Bases de Datos Relacionales (muy estructurados) Sistemas de Archivos Distribuidos (semi-estructurados) Clave/Valor, Columnares y otros (semi-estructurados) MongoDB NOSQL Cassandra CouchDB RDBMS Sharing HDFS Storage Map / Reduce
  13. 13. Vamos a desarrollar nuestra propia tecnología !!!!!!
  14. 14. - Almacenar Datos con y sin estructura - Almacenarlos en su formato Original - Escalable - Tolerante a Fallos - Muy eficiente en escritura y en lectura - Escalabilidad lineal en el rendimiento - Sin degradación del rendimiento según se incrementa el volumen de datos. - Procesar información en Tiempo Real - Un Lenguaje común: SQL OBJETIVO
  15. 15. 19 100.000 EPS Escritura por core (1 hebra) 1.000.000 EPS Lectura por core = 1 Query 2M EPS Ubuntu Linux 8 cores 30GB Memoria 2TB disco EL DATANODO Alcohol Malote Malote 51.000 Millones de Eventos (512 bytes)
  16. 16. ¿Como se consigue esa velocidad? • Eliminando TODO lo que no necesitamos • No Es ACID • Solo se implementa Escritura y Lectura de Datos • Compresión de los datos en crudo. Ratio 12:1 20
  17. 17. 21 Escritura 100.000 *8 = 800.000 EPS Batrasio MetaMalote
  18. 18. 22 Escritura 100.000 *30 = 3.000.000 EPS 60TB = 1.5 Billones de Eventos 30 datanodos Consulta 1M *60 = 60.000.000 EPS
  19. 19. SQL 23 Cluster de Almacenamiento Motor de Correlación Motor de Alertas SQL Motor de Agregación SQL Web App, Busqueda Dashboards, Reporting, Aplicaciones VerticalesSQL API REST Email JIRA PushOver PagerDuty HTTP/JSON MySql
  20. 20. Integración contínua • Hace no mucho… • Integración contínua a medias. Test pero no automatizados ni despliegues automáticos • Despliegues manuales mediante scripts que no cubrían todo el despliegue • Sin gestión de configuración (manual) • Control de versiones mediante git 24
  21. 21. Ansible al rescate • Despliegues mediante Ansible • Gestión de la configuración mediante Ansible • Cifrado mediante Ansible-vault • Despliegues contínuos (Gitlab + Jenkins + Ansible) • Notificaciones de jobs Jenkins mediante Slack (Mucho por mejorar aún) • Migración a GitLab (Mejor gestión de permisos) • Test seguimos mejorándolos: Hemos fichado al primer QA! 25
  22. 22. Infraestructura/Stack • Agnósticos al proveedor gracias a: • Ansible (SSH) • Stack opensource (Ubuntu, Java,NodeJs,Tomcat, Nginx, HAproxy, MongoDB, MySQL, RabbitMQ…) 26
  23. 23. Proveedores actuales • AWS • Azure • VDC (Teléfonica) • VmWare • Bare metal 27
  24. 24. Tipo de instalaciones • OnPremise (Cloud y bare metal). Grandes clientes solo. • Híbridos (Cloud y bare metal): Datos en servidor cliente. • SAS: Solo agente y datos a nuestra nube. 28
  25. 25. Demo Time 29
  26. 26. 30
  27. 27. https://www.logtrust.com/en/category/jobs/

×