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.

1. Big Data de verdad, en
4K y en tiempo real;
Arquitectura Logtrust
Juan Vicente Herrera @jvicenteherrera
Joaquin Díez Gómez @joaquindiez

3. BIG DATA en Tiempo Real

4. ¿Por qué BIG DATA?

5. All data that is not a fit for a
traditional RDBMS, whether used
for OLTP or Analytics purposes
@eddie_satterly - Splunk

6. Eventos

10. BIG DATA en Tiempo Real

11. Casos de Uso

12. • 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.

13. • CAPTURAMOS DATOS (Eventos)
• ALMACENAMOS
• EXTRAER SU VALOR POTENCIAL
SIMPLIFICANDO

14. ¿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

15. • 10 servidores
• 8640 eventos por dia ( 1 cada 10 segundos)
• 365 dias
• = 31.536.000 eventos en 1 año

16. 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

17. Vamos a desarrollar nuestra propia
tecnología !!!!!!

18. - 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

19. 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)

20. ¿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

21. 21
Escritura 100.000 *8 = 800.000 EPS
Batrasio
MetaMalote

22. 22
Escritura 100.000 *30 = 3.000.000 EPS
60TB = 1.5 Billones de
Eventos
30 datanodos
Consulta 1M *60 = 60.000.000 EPS

23. 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

24. 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

25. 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

26. Infraestructura/Stack
• Agnósticos al proveedor gracias a:
• Ansible (SSH)
• Stack opensource (Ubuntu,
Java,NodeJs,Tomcat, Nginx, HAproxy,
MongoDB, MySQL, RabbitMQ…)
26

27. Proveedores actuales
• AWS
• Azure
• VDC (Teléfonica)
• VmWare
• Bare metal
27

28. 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

29. Demo Time
29

30. 30

31. https://www.logtrust.com/en/category/jobs/