big data

1. Maestría en Analítica de datos
Big Data
Clase N ° 05 | Procesos ETL
Introducción a tipos de datos y
representación - Carga
Comenzamos a las:
Bogotá, 3 de agosto de 2021

2. Anteriormente en: Big Data
• Qué es Big Data.
• Definición parcial.
• Programación para el análisis de datos
• Repaso Python (bibliotecas y paradigmas de programación).
• POO (Programación orientada a objetos).
• Propósito de la analítica de Big Data.
• Proveer la arquitectura adecuada para el manejo de grandes volúmenes
de datos.
• Manipulación.
• Procesamiento.
• Análisis.
• Tipos de análisis.
• Pasado: ¿Qué ocurrió?
• Descriptivo (Revelar relaciones).
• Diagnóstico (Revelar patrones).
• Futuro: ¿Qué ocurrirá ?, Qué es mejor ?, Qué acción tomar?
• Predictiva (revelar tendencia / perspectiva).
• PrescriptivaRevelar dirección / principios).
• ETL (Extraer, transformar, cargar).
• Etapas
• Extraer.
• Transformar.
• Cargar.
• Herramientas
• Tipos de datos.
• Datos estructurados.
• Datos semiestructurados y no estructurados.
• Bases NoSQL.
• Definición.
• Aplicación.
• Tipos de bases NoSQL
• Clave - Valor
• Documentales
• Procesamiento de datos
• Mapa - Reducir.
• Arquitectura Mapa reducido.
• Computo distribuido.
• Computo paralelo.
• Arquitecturas y marcos de trabajo para cómputo distribuido y / o paralelo.
• Herramientas y tecnologías actuales en Big Data.
• Investigación y presentación.

3. Contenido
• ETL - Carga de datos según su nivel de estructuración
• Datos estructurados, semiestructurados y no-estructurados
• Estrategias de carga según la naturaleza de los datos
• Introducción a Bodegas de Datos (Data Warehouses)
• Introducción a Lagos de Datos (Data Lakes)
• Requerimientos aplicables a herramientas ETL

4. Datos estructurados Datos semiestructurados Datos no estructurados
Los valores se obtienen / extraen
mediante direccionamiento directo sin
ningún procesamiento adicional para el
análisis. Los datos se ordenan dentro
de un repositorio formateado,
generalmente una base de datos.
Todos los elementos de datos se
pueden almacenar en tablas SQL (filas
y columnas). Claves relacionales
permiten una consulta sencilla y un
mapeo preestablecido.
Ejemplo: Datos relacionales en bases
de datos SQL, almacenes de datos y
data marts.
Información que no puede ser
representado por una base de datos
relacional pero exhibe notable
propiedades organizativas.
Accesible mediante acceso secuencial
o jerárquico a elementos de datos. El
procesamiento adicional es necesario
para extraer valores específicos de
representaciones en bruto.
Las representaciones relacionales se
pueden "serializar" para conseguir
representaciones semiestructuradas, lo
que a su vez reduce los requisitos de
almacenamiento.
Ejemplo: JSON, XML. Bases de datos
NoSQL
Información sin una estructura
homogénea predefinida. No hay
modelo de datos, por lo que no es
adecuado para una flujo de trabajo
basado en representaciones
relacionales.
Es el enfoque más común en los
sistemas informáticos recientes y es la
elección más frecuente para
inteligencia de negocios y aplicaciones
de Big Data.
Ejemplo: documentos de oficina, PDF,
registros en lenguaje natural (BLOG y
microblogging publicaciones), archivos
multimedia, registros, etc.
Repaso: Niveles de estructuración de los datos

5. ETL: carga de datos según su nivel de
estructuración

6. ETL: carga
• El proceso de carga (dentro de ETL) consiste en almacenar los datos
transformados en su representación final (listos para el análisis de datos)
en los componentes de almacenamiento del sistema de información de
destino.
• Existen dos métodos principales para cargar datos en un almacén:
• Carga completa: volcado de datos completo, se lleva a cabo la primera vez que se
carga una fuente de datos en el destino.
• Carga incremental: los cambios detectados entre los datos de destino y de origen
se aplican dentro de algún intervalo preestablecido. La última fecha de extracción
se registra para que solo se carguen datos agregados (o actualizados) después de
la misma. Hay dos tipos de cargas incrementales, según el volumen de los datos:
• Carga incremental en streaming: apropiada para pequeños volúmenes de datos
• Carga incremental por lotes (batch): apropiada para grandes volúmenes de datos

7. Estrategias de carga según la naturaleza de
los datos
Datos Estructurados
• Data warehouses
• Schema en snowflake o constelación.
Se crean datamarts para suplir
requerimientos de información de
procesos operativos. Suelen usar
esquemas en estrella (star)
• Una de las estructuras más usadas
para el análisis rápido de datos es el
cubo OLAP (procesos analíticos en
línea).
• Proporciona consultas analíticas
multidimensionales de forma rápida
en poco tiempo.
Datos semiestructurados o no-estructurados
• Lagos de datos: requeridos cuando
los datos se extraen de diversos
tipos de fuentes (estructurado,
semiestructurado, no estructurado)
• Enfoque de almacenamiento: datos
lagos
• Los datos generalmente se registran
como unidades de información (p.ej
BLOB) junto con tablas estructuradas
(enfoques combinados), y se acceden
de acuerdo a los requerimientos de
cada proceso operacional o analítico.

8. * Data Lake Vs Data Warehouse : Which one should you go for ? https://www.grazitti.com/blog/data-lake-vs-data-warehouse-which-one-should-you-go-for/
Bodegas de Datos vs. Lagos de Datos
Los datos son
procesados y
organizados en un
único schema antes
de ser almacenados
en la bodega de
datos
El análisis se lleva a
cabo sobre los datos
preparados en la
bodega de datos
Los datos crudos y
no-estructurados
se almacenan en
el lago de datos
Los datos
contenidos en el
lago de datos son
seleccionados y
organizados
cuando son
requeridos

9. Introducción a bodegas de datos (Data Warehouses)

10. Flujo de trabajo en analítica de datos usando
Bodegas de Datos (data warehouses)

11. Bodegas de datos (data warehouses) -
definiciones
• Data warehouse (bodega de datos): repositorio de datos integrado* y
centralizado sobre un aspecto de la organización. Los usuarios pueden
establecer parámetros y criterios para la agrupación o clasificación de
registros de forma asistida. Componentes:
• Tabla de hechos: datos principales relacionados con la lógica del negocio.
• Tabla de dimensiones: datos de apoyo (p.ej., detalles adicionales de registros en
la tabla de hechos, códigos, diccionarios)
• Granularidad: nivel de detalle de los datos contenidos en la bodega, dependiendo
de las necesidades del proceso de analítica.
• Datamart: estructura generada como un subconjunto de una bodega de
datos, contiene lo requerido por un aspecto específico de la lógica del
negocio, al que se acude frecuentemente en procesos operativos o de
analítica de datos.
* Los datos provienen de multiples sistemas de información

12. Schemas Estrella vs. Snowflake
• Las tablas de dimensiones en estrella no están
normalizadas, las tablas de dimensiones en
snowflake están normalizadas.
• Los schemas snowflake utilizarán menos espacio
para almacenar tablas de dimensiones, pero son
más complejos.
• los schemas en estrella relacionan la tabla de
hechos con las tablas de dimensiones, lo que
resultará en consultas SQL más fáciles y rápidas.
• Los schemas snowflake no tienen datos
redundantes, por lo que son más fáciles de
mantener.
• Los schemas snowflake presentan características
favorables para las bodegas de datos, los
esquemas en estrella son mejores para
datamarts con relaciones sencillas.
Schema estrella Schema copo de nieve
• Otro schema de uso frecuente en
bodegas de datos y datamarts es el
de “constelación” (o “galaxia”), que
vincula, de manera más flexible,
múltiples tablas de hechos

13. ETL: Carga en Bodegas de Datos
Aspectos de implementación
• El proceso de carga es exigente en términos de tiempo de
ejecución y complejidad de la representación, pero es de
importancia crítica dado que proporciona la entrada para
los procesos de análisis.
• La carga de las tablas de hechos y de las tablas de
dimensiones es bastante similar en términos operativos
• Sin embargo, las tablas de dimensiones deben ser cargadas antes
de cargar las tablas de hechos, manteniendo la consistencia del
modelo de datos.

14. ETL: Carga DW - Tareas de carga
• La carga de tablas de hechos y de dimensiones no es el
último paso en la creación de la base de datos
• La estructura de los datos se pueden modificar después de la
carga sin afectar el patrón de solicitudes de los usuarios
finales
• Estas modificaciones se suelen llamar “graceful mods”, e incluyen:
• Agregar un hecho o dimensión de una tabla de hechos existente del mismo
nivel de granularidad
• Agregar un atributo a una dimensión existente
• Incrementar la granularidad de las tablas de dimensiones y de hechos
existentes

15. Introducción a los lagos de datos (Data Lakes)

16. Flujos ELT en grandes organizaciones
• Los sistemas actuales más complejos o de mayor tamaño integran
bodegas de datos con data lakes como aspecto necesario de diseño
• El contenido de la bodega de datos se traduce al lago de datos mediante la
traducción de representaciones estructuradas a semiestructuradas usando
formatos como JSON
• Proceso con lagos de datos:
• Extracción
• Carga (data lake)
• Transformación (según requerimientos de usuario)
• Carga (streaming vs. dataflow basado en triggers o intervalos)
• Ejemplo: Integración de servicios en Chicago usando MongoDB
• https://www.mongodb.com/customers/city-of-chicago

17. Lagos de datos: Definiciones y arquitecturas
https://www.dragon1.com/terms/data-lake-definition

18. Lagos de datos: consideraciones de diseño y
uso
• Un lago de datos no es un “tiradero de datos"
• Por lo tanto, los datos debe tener un orden, incluso si el
información subyacente es semi-estructurada o desestructurada
• Este orden es impuesto por la lógica del negocio, y es
sugerido por el proveedor del lago de datos. Ejemplo:
• Métodos de validación para archivos en proceso de carga
• Contenedores en Microsoft BLOB
• Data
• Valid
• Invalid

19. Comercial y "abierto" ejemplos
Data Warehouses
• Teradata
• Oracle
• Amazon RedShift (Amazon Web
Services)
• SQL Server sobre Azure
• Cloudera
• MarkLogic
• ...
Data Lakes
• Lago de Datos de IBM
• Servicios de Almacenamiento
de Azure (Microsoft BLOB)
• MongoDB
• TIBCO
• Talend
• ...

20. Estructura de un lago de datos en Azure
• La estructura de un lago de datos
en Azure es sencilla, consta de:
• Una cuenta en los servicios de
almacenamiento de Azure
• Una lista de contenedores asociados
a la cuenta
• Una lista de piezas de datos
dispuesta como objetos binarios de
gran tamaño (BLOBs), tablas,
archivos compartidos (NFS, SMB) o
colas.

21. Integración de datos en el proceso analítico
Ejemplo según Talend https://www.talend.com/es/resources/etl-tools/

22. Requerimientos aplicables a
herramientas ETL

23. Consideraciones sobre herramientas ETL
(ELT) en el mercado
• Una herramienta de ETL debería funcionar correctamente con las últimas
innovaciones y adaptarse fácilmente a nuevas tecnologías.
• Las buenas herramientas de ETL podrán integrarse con tecnologías serverless,
Spark, Snowflake, machine learning, etc., y adaptarse rápidamente a nuevas
tecnologías que aún no conocemos.
• La escalabilidad es muy importante al elegir herramientas
• Escalado horizontal/vertical
• La portabilidad es una capacidad importante de las herramientas de ETL,
pero que muchas veces se pasa por alto. Por ejemplo:
• El ecosistema Apache Hadoop está avanzando a gran velocidad. En 2014 y 2015 la
norma era MapReduce, pero a finales de 2016 Spark se convirtió en la nueva
solución por defecto. Si en su día había optado por de programación a mano,
resultaba imposible portar ese código de MapReduce a Spark. Las principales
herramientas de ETL permiten este tipo de cambios sin problemas

24. Requerimientos de las herramientas ETL I
• Leer y escribir a partir del espectro completo de fuentes de datos que se
requiera, estén ubicadas en la nube o en un sistema on-premises.
• Realizar procesos de transformación de datos (ordenar, filtrar y agregar).
• Brindar capacidades integradas de calidad y gobernanza de datos, como
eliminación de duplicados, correspondencias y perfiles.
• Incluir herramientas de colaboración.
• Con ello resultará más fácil reutilizar elementos de desarrollo anteriores; los flujos
de integración de datos resultantes pueden ser más eficientes.
• Una única tarea puede alimentar varios destinos en lugar de tener una serie de
flujos de integración de datos repitiendo el trabajo para diferentes sistemas
objetivo.
https://www.talend.com/es/resources/etl-tools/

25. Requerimientos de las herramientas ETL II
• Con el cambio a los “sistemas en la nube” (cloud), la capacidad de adaptarse a
procesos CI/CD (Continuous Integration/Delivery) es una necesidad.
• La herramienta de ETL debería poder operar en cualquier entorno, en
infraestructuras locales, cloud o híbridas.
• Una herramienta de ETL debería poder adaptarse a nuevos proveedores sin
problemas. Por ejemplo:
• Portar una bodega de datos de Redshift a Snowflake según ofertas o requerimientos
• Usar AWS como proveedor de cloud durante un trimestre, pero usar Azure al siguiente.
Es importante disponer de una herramienta de ETL que funcione en un entorno
multi-cloud y sepa adaptarse a nuevos proveedores y entornos de despliegue
modificando simplemente algunos componentes, pero conservando la lógica del
negocio y de la transformación.
https://www.talend.com/es/resources/etl-tools/