Este documento describe el uso de datos históricos para predecir el uso del servicio de alquiler de bicicletas Citi Bike en Nueva York. Se analizan factores como el clima y la estación del año que podrían afectar el uso. Se propone utilizar un modelo de aprendizaje automático como Random Forest entrenado con datos de 2017 para predecir el uso en 2018 y validar la precisión de la predicción. Finalmente, se discuten consideraciones sobre la preparación de los datos de entrada para el modelo, como la codificación de variables cíclic
3. Quiénes somos
✓ + de 35 profesionales
✓ +de 12 años en el mercado corporativo IT
✓ Cobertura Regional en Latinoamérica
✓ Clientes de más de 10 años
✓ Crecimiento sostenido interanual
✓ Innovación y Conocimiento (ADN)
Dirección de Servicios de
Infraestructura
Dirección de Middleware e
Integraciones
Dirección de Desarrollo, IOT e
Innovación Digital
✓ Implementación de proyectos de Integración de
aplicaciones
✓ Consultoría s/ arquitecturas complejas – On premise
y Cloud
✓ Assessment de infraestructura y Middleware
✓ Tuning de performance y seguridad
✓ Consolidación de servidores
✓ Soporte y mantenimiento de plataformas
✓ Desarrollo de Apps Mobile y Web
✓ Desarrollo de integraciones (3 capas)
✓ Desarrollo e implementación de proyectos IOT
4. ➢ Estamos transitando la era de la innovación (Supervivencia del
más Rápido)
➢ La Transformación digital dejo de ser un tema a futuro para las
empresas para transformarse en algo OBLIGATORIO.
➢ Cualquier estrategia de Transformación digital debe estar basada
en una Estrategia de los Datos
➢ Los datos son el Combustible de la transformación
➢ Los datos hablan de alguna manera de cual es el comportamiento
digital de una persona o una empresa.
➢ El desafío del manejo de los datos es convertirlos en valor para la
empresa; transformar esa información no estructurada, que no
tiene un parámetro y que está disgregada en diferentes sistemas y
formatos.
➢ La necesidad incentiva la innovación y en Latinoamérica están
dadas las condiciones para salir a cultivarla….
¿Por qué nos acercamos a Denodo?
5. Agenda• Arquitecturas lógicas de provisión de datos: hacia un
lago de datos virtual
• ¿Qué es la Virtualización de Datos?
• Arquitectura de Referencia
• El ciclo del científico de datos
• Demostración práctica
• Ejemplos de Clientes
• Siguientes Pasos
• Q&A
7. 7
Complejidad creciente de los datos
Complejidad en los datos
▪ Datos nuevos y heredados, en todas las estructuras imaginables
▪ Generados e integrados, desde batch a real-time
▪ Datos tradicionales de aplicaciones empresariales, web, third-parties
▪ Nuevas fuentes de datos: sensores, social media, IoT
Complejidad en las soluciones de gestión de datos
▪ Custom, de software vendors, open source
▪ Arquitecturas multi-plataforma, distribuidas y heterogeneas; on
premise o en la nube; de relacionales a Hadoop
▪ Híbridas y diversas al extremo
8. 8
“Logical Data Warehouse”: hacia arquitecturas lógicas
Adopt the Logical Data Warehouse Architecture to Meet Your
Modern Analytical Needs”. Henry Cook, Gartner April 2018
9. 9
“Logical Data Warehouse”: hacia arquitecturas lógicas
Adopt the Logical Data Warehouse Architecture to Meet Your
Modern Analytical Needs”. Henry Cook, Gartner April 2018
12. 12
Capa unificada de integración y de provisión de datos al negocio
4. Acceso desde cualquier
herramienta / protocolo / API
5. Metadatos, gobierno y seguridad
centralizada
6. 90% de reducción del time to
market para provisionar datos al
negocio, ahorro significativo en
costes
1. Único punto lógico de acceso a
datos – independencia de la
ubicación de los datos
2. Datos entregados en una forma
amigable para el negocio – capa
semántica
3. Datos adaptados a las
necesidades de cada línea de
negocio, tipo de usuario y
aplicación
13. 13
Capa Virtual de Provisión de Datos
Development
Lifecycle Mgmt
Monitoring & Audit
Governance
Security
Development Tools
and SDK
Scheduled Tasks
Data Caching
Query Optimizer
JDBC/ODBC/ADO.Net SOAP / REST WS
U
Customer 360
View
Virtual Data
Mart View
J
Application
Layer
Business
Layer
Unified View Unified ViewUnified ViewUnified View
A
J
J
Derived View Derived View
J
JS
Transformation
& Cleansing
Data
Source
Layer
Base
View
Base
View
Base
View
Base
View
Base
View
Base
View
Base
View
Abstraction
14. 14
Una arquitectura moderna de virtualización de datos
DATA CATALOG
Discover - Explore - Document
{ API ACCESS }
RESTful / OData
GraphQL / GeoJSONSQL
DATA VIRTUALIZATION
CONNECTIVITY
Traditional
DB & DW
150+
data
adaptersCloud
Stores
Hadoop
& NoSQL OLAP Files Apps Streaming SaaS
Query
Optimization
SecurityAI/ML Governance
Semantic
Layer
Real Time
Acceleration
Caching
DATA OPS
Deployment
Cloud PaaS
Containers/K8
On-Prem
Monitoring
Scheduling
Version Control
DEVELOPMENT
MODELING
DELIVERY
16. 16
El lago de datos – Arquitectura I
Distributed File System
Almacenamiento distribuido y económico
para grandes volúmenes de datos
• Múltiples formatos (Parquet, CSV, JSON, etc)
• Ejemplos:
• On-prem: HDFS
• Cloud native: AWS S3, Azure ADLS, Google GCS
17. 17
El lago de datos – Arquitectura II
Distributed File System
Execution Engine
Motor de ejecución masivamente
paralelo y escalable
• Ejecución más económica que en una
arquitectura tradicional de EDW
• Desacoplado del almacenamiento
• No require HW especializado
• Ejemplos:
• SQL-on-Hadoop engines: Spark, Hive, Impala, Drill,
Dremio, Presto, etc.
• Cloud native: AWS Redshift, Snowflake, AWS
Athena, Delta Lake, GCP BigQuery
18. 18
El lago de datos – Arquitectura III
Distintos niveles de curación de datos
• La ingesta de datos se hace normalmente en modo
crudo y no son válidos para los usuarios finales
• Los datos se transforman, limpian, etc. y se mueven
a diferentes “zonas” con distintos niveles de curación
• Los usuarios finales solo acceden a los datos curados
(“refined zone”)
• Normalmente la carga se hace con ELT como
estrategia más económica que el ETL tradicional
• Se utiliza el motor de proceso del lago para la
transformación
• No se require HW de staging adicional
Raw zone Trusted zone Refined
Zone
Distributed File System
Execution Engine
19. 19
El rol de la Virtualización en el Lago de Datos
La Virtualización de Datos puede utilizarse:
• Como Catálogo de Datos del data lake
• descubrimiento y la exploración de los datos
• Para ofrecer datos curados en la “Refined zone”
mediante data marts virtuales
• Como capa de provisión de datos multi-
consumidor:
• SQL, REST, GraphQL, etc.
• Como “Sandbox”
• poder jugar con los datos sin necesidad de
subirlos al lago
Raw zone Trusted zone Refined
Zone
Distributed File System
Execution Engine
20. 20
Arquitectura de Referencia de un Data Lake Virtual
Connect, Introspect, Design, Combine & enhance, Logic to Physical, Intelligent store, Refresh, Expose, Governed &
Secured
21. 21
Flujo de Trabajo típico de un Científico de Datos
• Típico flujo de trabajo de un científico
de datos
• Entender las necesidades de negocio y los requisitos
para el análisis
• Identificar datos útiles para el análisis
• Almacenar datos en el lago
• Limpiar y preparar datos en un formato útil
• Analizar los datos
• Preparar los datos de entrada al algoritmo de data
science
• Ejecutar algoritmos de data science (ML, etc.)
• Iterar el proceso hasta conseguir “insights”
de valor para el negocio
• Visualizar y compartir resultados
22. 22
Flujo de Trabajo típico de un Científico de Datos
80% del tiempo – Identificar, precargar y
preparar los datos
10% del tiempo – Análisis
10% del tiempo – Visualización
23. 23
Mejores Prácticas: Modelo Colaborativo IT - Científicos de Datos
2) Los Data Scientists
/ Citizen analysts
utilizan el Data
Catalog para el
descubrimiento y la
exploración de datos
Enterprise
Systems
Hadoop
E
T
L
Enterprise
Data Warehouse
NoSQL
Data Virtualization
4) Los Data Scientist / Citizen
Analysts pueden proponer la
operacionalización de los modelos o
de los resultados del análisis
5) Los Data Engineers
revisan y generan nuevas
vistas si es necesario,
optimizan el rendimiento,
teniendo en cuenta la
seguridad y el gobierno de
los datos
1) Los Data Engineers
exponen vistas de
datos curadas a los
Citizen Analysts y
Data Scientists
3) Los Data Scientists /
Citizen analysts preparan
los datos y generan sus
modelos predictivos y de
ML (enfoque virtual y/o
físico)
24. 24
Descubrimiento y Exploración de datos en el Lago
1- Los científicos de datos utilizan el Data
Catalog para identificar los datsets válidos
para el análisis que pueden estar en el
lago o en otras fuentes
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
25. 25
Transformación y combinación de datos
2 – Transformación de Datos, Limpieza,
Combinación, construcción del modelo virtual final,
adaptación de los datos a los algoritmos de data
science
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
26. 26
Materialización de datos en el lago (opcional)
3 – (Opcional) Materializar
el modelo construido si se
require mediante Remote
Tables
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
“Remote Table”
27. 27
Análisis mediante herramientas científicas (ML, etc.)
4 – Análisis de los datos (ya curados, adaptados a los
algoritmos de data science): R (RJDBC), Scala
(JDBC), Spark ML Lib (JDBC), Python (ODBC),
etc. Iteraciones sobre el modelo para su optimización
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
28. 28
Operacionalización de los modelos
5 – Creación de vistas finales para
operacionalización del modelo.
Máximo rendimiento y escalabilidad: Query
Push-down, Query Acceleration & Cost
Based Optimization + MPP
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
29. 29
Publicación de resultados a los usuarios de negocio
6 – Data Catalog
6 – Publicación de
resultados herramientas BI
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
30. 30
Gobierno y seguridad centralizada del lago de datos
6 – Data Catalog
Auditoría
Acceso por
roles
Seguridad
Gobierno
Compliance
Trazabilidad
Cloud
Migración
Agilidad
TTM
Mitigar
riesgos
Adopción
7 – Valor adicional
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
6 – Publicación de
resultados
35. 35
Factores externos
¿Qué factores pueden influir en el uso de este servicio de alquiler
de bicicletas?
• Climatológicos
• Temperatura
• Lluvia
• Nieve
• Temporales
• Estación del año
• Día de la semana
• Fines de semana, vacaciones
37. 37
¿Cómo realizar una predicción de uso del servicio?
• Vamos a intentar predecir el uso de las bicicletas a diario
• Utilizando observaciones para realizar la predicción (día del año, día de
la semana, si ha llovido o no, si ha nevado, temperatura, etc.)
• Entrenamos al sistema con datos pasados que contienen valores de
estas observaciones y las métricas de uso reales para estos valores
• Por ejemplo: January 1st, no rain, max temp 48 F → 16,009 rides
• Utilizaremos datos del 2017 para entrenar al Sistema
• Comprobaremos la fiabilidad de la predicción tratando de predecir el
uso del servicio en 2018, año para el cual contamos con los valores
reales de uso del servicio y podemos compararlos
• Validamos con datos del 2018
• Comparamos la predicción con los datos reales y podemos
comprobar la calidad de la misma
38. 38
Algoritmo de ML “Random Forests”
El algortimo que vamos a utilizer es un
árbol de decisión aleatorio: Random
Forest
Genera multiples árboles de decision en
base a los valores que se le proporcionan
en la fase de adiestramiento.
Este método se utiliza también para
clasificación
La mayoría de las librerías de ML disponen
de una implementación de este método:
• En nuestra libería SciKit-learn el método
es: RandomForestRegressor
39. 39
¿Cómo funciona el algoritmo de “Ramdon Forests”?
Proporcionamos datos de entrada para múltiples variables y el valor resultante de
salida.
El algoritmo genera un árbol por cada grupo de valores de entrada y salida
Valor de Salida
(número de
alquileres)
Valores numéricos de entrada
40. 40
Preparación de datos para el algoritmo de ML
Los valores de entrada para las observaciones que alimentan el algoritmo de árboles
aleatorios (RandomForstRegressor) han de ser numéricos
Los valores numéricos han de tener consistencia para poder ser válidos
• Por ejemplo, si consideramos meses, éstos pueden ser representados como números de la
siguiente forma:
Jan = 1, Feb = 2, …, Dec = 12
• ¿Serían valores adecuados para el algoritmo?
• Un sistema computacional puede inferir que dado que Junio (6) es igual a 3x2, ello
implica que las observaciones en Junio tienen triple de peso que las mismas
observaciones realizadas en Febrero (2).
• De modo que no basta que los valores sean numéricos, tienen que tener sentido también
Los valores numéricos de entrada han de ser procesados para prepararlos para el
algoritmo de data science
41. 41
Observaciones cíclicas: valores trigonométricos
Hay observaciones que son cíclicas de por sí: horas del día,
días del año, etc.
Por ejemplo, los días del año van de 1 a 365 y a continuación
vuelven a fluctar entre el mismo rango de valores:
• Del mismo modo que hemos visto con los meses del año, utilizar
valores del 1 al 365 puede confundir al algoritmo.
• Más aún, valores que en principio son muy diferentes deberían
ofrecer información similar, por ejemplo: 360 (Dec 26th) y 2 (Jan
2th), ambos son días del invierno.
¿Cómo modelar esta naturaleza cíclica de forma numérica?
Podemos valernos de una función trigonométrica para
obtener valores entre -1 y 1:
cos((getDayOfYear(date)*((2*pi())/365)))
De este modo Dec 26th = 0.996 y Feb 5th = 0.999
42. 42
Observaciones categóricas: “One Hot encoding”
Observaciones categóricas, del tipo “día de la
semana”, son difíciles de codificar como números.
• El Jueves (4) no vale el doble que el Martes (2) si
utilizamos 1 a 7 para los días de la semana.
Una forma major para representar estos valores
categóricos es utilizar una notación binaria (1 o 0)
para cada possible valor:
• Is_thursday is 1 on Thursdays, 0 otherwise
Para representar estas observaciones necesitamos
crear una nueva columna para cada día de la
semana, y utilizar expresiones del tipo:
CASE WHEN (d_dow = 4) THEN 1 ELSE 0 END AS is_thursday
50. 50
Autodesk: Managing a Data Lake with Denodo
DATA
VIRTUALIZATION
Virtual Schemas
(JDBC, ODBC,
API, JSON, XML)
- Virtualize, materialize, cache,…
- No silos: dependencies between copies are governed by Denodo
- All Denodo capabilities available: combine with other sources,
expose data using SQL, REST, OData,…
- Abstract underlying repository (e.g. move part of the workload to
Athena) without affecting consumers, and maintaining governance
51. 51
$1.5TRILLION
is the economic value of goods flowing through
our distribution centers each year, representing:
2.8%
of GDP for the 19 countries where
we do business
%2.0
of the World’s GDP
1983 100 GLOBAL 768 MSF
Founded Most sustainable corporations
$87B
Assets under management on four continents
MILLION
employees under Prologis’ roofs
1.0
Prologis
52. 52
Step 1: Expose Data to Data Scientists
Prologis: Data Science Workflow
DATA
VIRTUALIZATION
Cache
Data Services
Application DatabaseEDWCloud Data Lake
53. 53
Step 2: Operationalization of Model Scoring
Prologis: Data Science Workflow
DATA
VIRTUALIZATION
Cache
Application DatabaseEDWCloud Data Lake
Web Service (Python Model Scoring)
AWS Lambda
54. ➢ Para optimizar originación de clientes.
- Donde y cuando pautar, perfil, palabras claves
- Denodo puede exponer fuentes diversas de datos internas y externas de manera estandarizada, listas para
ingestión por los sistemas de AI/ML
➢ Para calificación de riesgo para aquellos clientes que no posean historial crediticio
- Correlacionando la huella digital del cliente mediante ML (redes sociales, apps, tipo de teléfono, geolocalización)
- Denodo puede componer información de diferentes fuentes y proveer una huella digital lista para ser
consumida por una red neuronal que correlacione dicha huella con la probabilidad de repago del crédito. Al
mismo tiempo puede exponer esa misma información como API para ser consumida por otras aplicaciones
internas / externas
➢ Para optimizar algoritmos de cobranzas, detección de anomalías y prevención de fraude en tiempo real.
➢ Gobernanza de datos, Cumplimientos regulatorios, acceso para inversores
➢ Montado de arquitecturas API o app móviles sobre sistemas heredados, M&A, grupo empresarios
Algunos casos de uso de AI / ML en Fintech (Lending)
56. 56
“Overhead” sobre el acceso directo a las fuentes
Data Virtualization Overhead: Direct vs Denodo with single source
TPCDS Benchmark Tests using JDBC with IBM Netezza as data source with 10
Gbps LAN network
Results in seconds
Las consultas se delegan a las
fuentes con un overhead
mínimo en la capa de
virtualización de datos
57. 57
Estrategia “Dynamic Query Optimization + MPP Processing”
System Execution Time
#Rows transferred
through the network
Optimization Techniques
No Rewriting >10 min 593M Simple federation
Data Movement +
MPP
>4 min 293M Data Movement to the cluster
Dynamic Query
Opt.
51 sec 9M Aggregation Push-down
MPP Query Accel. 11 sec 9M
Aggregation push-down + MPP integration (Impala 8
nodes)
3M rows returned
(sales by customer)
1. Partial Aggregation
push down
Maximizes source processing
Dramatically Reduces network
traffic
3. On-demand data transfer
Denodo automatically generates
and upload Parquet files
2. Integrated with Cost Based Optimizer
Based on data volume estimation and
the cost of these particular operations,
the CBO can decide to move all or part
Of the execution tree to the MPP
Hist. Sales
3 Billion rows
Customer
3 M rows
join
group by
Customer
country
3 M rows
(sales by customer from previous
year)group by
customer ID
group by
customer ID
Sales
(290 million rows)
union
9M rows
compressed in
parquet files and
transferred in
parallel
3 M rows
(customers)
4. Fast parallel execution
Support for Spark, Presto, Hive and Impala
For fast analytical processing in
inexpensive Hadoop-based solutions
59. 59
Ventajas de un lago de datos virtual
1. Acelera los proyectos de Big Data
• Da soporte al ciclo completo del “data scientist”: desde la ingesta,
preparación, transformación, enriquecimiento, limpieza y entrega de
datos a las herramientas de data science (ML, etc.) y publicación de
los resultados para compartirlos con negocio
2. Trazabilidad de los datos Extremo a Extremo para gestión ágil
de cambios
• Desde el origen hasta los servicios de datos listos para consumo
• Fácil iteración para realizar cambios y mejorar el proceso
3. Fácil transición a tecnologías Big Data para cualquier usuario de
negocio (Capa genérica de provisión de datos)
• Interfaces SQL para herramientas de BI tradicionales (Qlik, Tableau, Power BI,
etc.)
• Los usuarios de negocio pueden beneficiarse de los contenidos del lago, no
sólo los científicos de datos
60. 60
Ventajas de un lago de datos virtual (II)
4. Modelo Unificado de Datos (Canónico) / Capa Semántica (“Refined
Zone”)
• Datos más consistentes, informes más fiables
• Repositorios virtuales de datos curados y gobernados desde datos
del lago o desde otras fuentes
5. Catálogo de datos listos para consumo
• Para una ágil exploración y descubrimiento de datos tanto para
científicos de datos como para analistas de negocio
• Habilita “Data marketplaces”
6. La arquitectura lógica permite el aprovechamiento de sistemas
“best-of-breed”, facilita los cambios
• Aprovecha los repositorios existentes, no es necesario copiar
todo al lago
• Arquitectura “Future-proof”: la abstracción permite una fácil
migración de unas tecnologías a otras
61. 61
Ventajas de un lago de datos virtual (III)
7. Seguridad y Reglas de Acceso Centralizadas
• Único punto para la definición de la seguridad y las reglas de acceso
• Simplifica la arquitectura de seguridad del lago
8. Posibilidad de definir dominios de confianza (Trust domains)
• Distintas reglas de gobernanza en función del tipo de
acceso/usuario: Sanboxes, Datos Curados, etc.
• Soporte para Bi-modal BI
65. ¡Gracias por vuestra participación!
Próximo webinar : “Mejorar la toma de decisiones y reducir costes con el Logical Data Warehouse ”
Anastasio Molano
SVP, Technology and Solutions
DENODO
Mario Bianchi
Gerente Unidad de Desarrollo
VAULT IT
Hernán Peroceschi
Gerente Comercial
VAULT IT
www.denodo.com
info.la@denodo.com
(+34) 912 77 58 55
www.vault-it.com.ar/
info@vault-it.com.ar
+54 11 5368 9353