Sesión presentada en SG Virtual por Leonardo Micheloni

1. Leonardo Micheloni
@leomicheloni
Azure Analytics

2. Quién soy?
• Desarrollador de software hace 15 años
• Trabajabo en Kinetica Solutions
• Actualmente estamos utilizando estas herramientas

3. De qué vamos a hablar?
• Captura y análisis de datos en tiempo real
• Azure
• Variantes
• Ventajas
• Costos

4. Planteo del problema
• Necesidad de recibir y analizar una gran cantidad de datos
• De diversos orígenes
• A diferentes tasas de arribo
• Manipulación de los datos (contar, agrupar, seleccionar, etc.)
• Posibles escenarios
• Análisis de tráfico en grandes ciudades
• Comportamiento de clientes
• IoT
• Medición de audiencias

5. Qué podríamos hacer?
• Solución custom
• Implica mucha inversión de hardware
• Si es un éxito hay que conseguir más hardware
• Si falla tenemos que arreglarlo nosotros
• Centralizado geográficamente
• Usar una solución de terceros (Azure)
• Podemos escalar a demanda
• No falla
• Disponibilidad geográfica

6. Qué ofrece Azure?
• Event hubs
• Hadoop
• Stream analytics
• DocumentDb
• Web sites
• Máquinas virtuales
• Otros sistemas

7. Qué ofrece Azure?

8. Por qué PAAS?
Aplicaciones
Data
Runtime
O/S
Virtualización
Servidores
Networking
IAAS
Aplicaciones
Data
Runtime
O/S
Virtualización
Servidores
Networking
Aplicaciones
Data
Runtime
O/S
Virtualización
Servidores
Networking
PAAS SAAS

9. Características
• Permite inyectar eventos a gran escala
• Publish / suscriber
• Millones de eventos
• Halo, Minecraft, Xbox 360
• HTTP / AMQP
• SAS
Evet hubs

10. Publish Suscriber
• Más adecuado para este tipo de escenarios que las colas
• Arquitectura basada en particiones en lugar de base de datos
• Existen clientes para las principales plataformas
• Es trivial crear un cliente
Event hubs

11. Millones de eventos
• Up to 1GB/s input
• Up to 100.000 sources / event hub
• Thoughput: 1MB per unit, up to 1000 units per secound
• Consumer groups
• Storage 84GB / day
• Retention policy 1 up to 7 day (pedidos especiales hasta 20 días)
• 2.8 c/u$s por millón de eventos
Event hubs

12. Particiones
• Definen las lecturas simultáneas
• Partition key
• Hasta 32
• Pedidos especiales hasta 1000
Event hubs

13. Retention policy
• Se retienen los eventos hasta ser consumidos
• 24 horas por defecto sin costo adicional
• Días adicionales tienen costo hasta 7 días (especial 30)
• Checkpoint en caso de falla se retoma, se puede “rebobinar”
• Up to 84GB
Event hubs
Checkpoint

14. HTTP / AMQP
• Soporta el estándar AMQP
• Interoperable con múltiples plataformas
• Java
• PHP
• IoT
• Posibilidad de usar HTTP
Event hubs

15. SAS
• Posibilidad de definir la seguridad por cadena de conexión
• Se define una key para un nivel de lectura o escritura
Event hubs

16. Demo
Event hubs

17. Stream Analytics

18. Qué es Stream Analytics
• PaaS (Platform as a Service)
• Motor de procesamiento a gran escala (hasta 1GB/s)
• Real-time streaming.
• Fuerte integración con EventHub (Out of the Box)
• Agrupación y agregación de datos.
Stream Analytics

19. Stream Analytics
Stream Analytics

20. Características
• Captura, procesa y agrega datos en tiempo real.
• Sin pérdida de datos.
• Troughput de hasta 1GB x seg (millones de eventos).
• Alta disponibilidad y capacidad de recuperación.
• Bajo costo en desarrollo y en administración
• 3 componentes principales:
• Inputs
• Queries
• Outputs
Stream Analytics

21. Captura (inputs)
• Múltiples, en simultáneo
• Tipos de input:
• Data de referencia
• Data de streaming (Event-hubs, IoT, Blobs)
Stream Analytics

22. Transformación (queries)
• SQL-Like queries.
• Multiple input, multiple outputs.
• Agrupamiento basado en ventanas (Tumbling, Hopping, Sliding)
Stream Analytics

23. Transformación (queries)
Stream Analytics

24. Windowing - conceptos
• Agrupamiento basado en ventanas (Tumbling, Hopping, Sliding)
• Windows de tamaño fijo
• El Timestamp de output representa el fin de la ventana
• Requiere agrupamiento.
Stream Analytics

25. Tumbling Windows
• Cantidad de lecturas de sensor por device cada 10 segundos.
Stream Analytics
SELECT sensorId, COUNT(*) AS Count
FROM SensorReadings TIMESTAMP BY time
GROUP BY sensorId, TumblingWindow(second, 10)

26. Hopping Windows
• Cada 5 segundos,
cantidad de lecturas de
sensor y la temperatura
promedio en los últimos
10 segundos
Stream Analytics
SELECT sensorId, COUNT(*) AS Count, AVG(temp)
FROM SensorReadings TIMESTAMP BY time
GROUP BY sensorId, HoppingWindow(second, 10, 5 )

27. Sliding Windows
• Temperatura es mayor a
75 para un total de 5
segundos
Stream Analytics
SELECT sensorId, MIN(temp) as temp
FROM SensorReadings
TIMESTAMP BY time
GROUP BY sensorId, SlidingWindow(second, 5)
HAVING MIN(temp) > 75

28. Outputs
• Son el resultado del procesamiento en las queries
• Múltiples posibles
Stream Analytics

29. Outputs
Stream Analytics

30. Configuración
• Event Ordering Policy
• Late Arrival tolerance Window
• Out of Order tolerance window
• Action (Adjust – Drop)
Stream Analytics

31. Out of Order/ Late Arrival
Stream Analytics
En query
...TIMESTAMP BY...
Por default:
Timestamp by
Enqueue timestamp
Evento 1
15:43 (-3)
Evento 2
15:42 (-3)
En query
...TIMESTAMP BY...
Evento 3
TIMESTAMP: 15:43:25 (-3)
Encolado:
15:43.26 NUEVO TIMESTAMP (AJUSTADO): 15:43:29 (-3)
Causas:
• Clock Skews
• EH Clock Skews
• Network Delay

32. Escalabilidad
• Escalabildad:
• Streaming Units (1 MB/s Cada SU) (Hasta 48)
• Pricing:
Stream Analytics

33. No tan bueno
• Esencial manejo desde el portal
• Deployment por PS con json
• El SAQL es limitado
• Puede tener latencia asociada
Stream Analytics

34. Demo
Event hubs

35. ¿Qué es DocumentDB?
• Database as a service
• NoSql ->
• Key-value store
• Column store
• Graph databases
• Document store
• Diseñado para aplicaciones escalables y altamente performantes
DocumentDb
✔

36. Azure Data Services – antes...
DocumentDb
Fuente: http://channel9.msdn.com

37. Azure Data Services - después...
DocumentDb
Fuente: http://channel9.msdn.com

38. Alternativas de terceros:
DocumentDb
• Más orientadas a IAAS que PAAS
• "desventajas" de IAAS: sharding a mano, al igual que la replicación
• PAAS -> todo manejado dentro de Azure
• Escalabidad on-demand controlada

39. Modelo de recursos
DocumentDb

40. Interacción con DocumentDB
DocumentDb
• RESTful http interface
• SDK (.Net, Node, Python, JS)
• Queries -> gramática SQL (extensibilidad con Javascript)

41. Javascript para lógica de negocio
DocumentDb
• DocumentDb fue escrito pensado y optimizado para Javascript
• Se pueden escribir UDF, SP y Triggers en Javascript
• Transacciones integradas al lenguaje (los procedures se ejecutan
dentro de una transacción implícita)

42. Schema-free
DocumentDb
• Schema-free REAL
• No se definen índices (campos se indizan automáticamente, no hay
inferencia de schema)
• Posibilidad de customizar los índices

43. Digresión: el teorema CAP
DocumentDb• Un sistema distribuido no puede garantizar, simultáneamente:
• Consistency
• Availability
• Partition network tolerance
• Con esto en mente, un sistema distribuido puede ser:
• "CP" -> consistente pero NO disponible bajo una partición de red
• "AP" -> disponible pero NO consistente bajo una partición de red
• "CA" -> imposible!
{A, B, C} -> {A,B} {C}

44. "tunnable consistency"
DocumentDb
• 4 niveles de consistencia de datos
• Eventual consistency
• Strong consistency
• Bounded staleness consistency
• Session consistency

45. ¿Cómo escala?
DocumentDb
• Collections -> 10gb de capacidad de storage
• Performance levels
• RequestUnit (RU) -> mide lo que tarda en procesar un request
• 1 RU -> read json de 1kb con 10 properties
• Esto asumiendo Session Consistency
• x-ms-request-charge se incluye en los responses

46. Quotas
DocumentDb
• 5 DocumentDB accounts
• 100 base de datos por account
• 100 colecciones por base de datos
• 500.000 usuarios (entre todas las DB)
• 25 SP, triggers y UDF (cada uno) por colección
• 10GB por colección
• Tamaño máximo de documento json: 512KB

47. Demo
DocumentDb

48. MVA
http://blog.sysfore.com/the-a-z-of-microsoft-azure-
services/
Recursos Continúa Aprendiendo
Microsoft Virtual Academy
http://aka.ms/academia
Channel 9
http://aka.ms/canal9