2.

MODELADO DE
DATOS ORIENTADOS A
LA ANALÍTICA Y A LA
TOMA DE DECISIONES
2.1 Construir y diseñar modelos de datos

2.1.1 Diseño dimensional para bases de datos orientadas a la

analítica

Antes de comenzar con la teoría vamos a responder la siguiente pregunta: ¿Qué es

una base de datos? Quizás algunos de ustedes conozcan bien este término, pero para
aquellos que no lo conocen, les brindaremos una pequeña introducción. Supongamos
que usted tiene un negocio de ventas de insumos de telefonía. Inauguró el local hace
solamente un mes y tanto las compras de insumos a proveedores como las ventas las
registra en un cuaderno. Además, en otro cuaderno, lleva un registro de pagos de
boletas y gastos varios. Es decir, ambos cuadernos serían sus bases de datos: la
primera base sirve para administrar compras y ventas, y la segunda, para administrar
sus gastos.
Un día advirtió que administrar dichos cuadernos se hacía muy laborioso y perdía
mucho tiempo, entonces decidió migrar esos cuadernos a Microsoft Excel y elaboró
dos archivos diferentes. Excel le dio resultados durante mucho tiempo, pero su archivo
comenzó a crecer y ya no podía mantener histórico porque su Excel dejaba de
funcionar con millones de registros. Entonces decidió migrar a MySql y desarrollar un
sistema para su comercio que tuviera como base de datos dicho motor. MySql es un
motor de bases de datos relacional y funciona muy bien para sistemas
transaccionales.
Su comercio creció y ahora cuenta con muchos locales por todo el país. El sistema
transaccional es el mismo, pero su base de datos se encuentra en el mismo lugar
central. Los comercios están conectados y tienen acceso a ver la base de datos central.
Su estructura ha crecido y ahora cuenta con gerentes, contadores, personal de recursos
humanos, etc. Usted pide reportes mensuales, por lo tanto, en cada cierre de mes, los
gerentes solicitan a los analistas que preparen los reportes mensuales, que incluso
cruzan datos de más de un año, para hacer comparaciones. Es en este momento
cuando la base de datos transaccional comienza a mostrar sus puntos más débiles,
ya que la misma no había sido desarrollada para un esquema de análisis, sino que
había sido establecida para manejo de transacciones. Esto implica que una persona
que consulta un reporte histórico que involucra tablas del sistema experimenta una
gran demora de respuesta del sistema en los puntos de venta y esto afecta al cliente
que espera una compra rápida para retirarse feliz con su producto (¿cuántas veces le
dijeron que el sistema estaba caído? quizás era por eso).
Aquí es donde nace lo que hoy conocemos como data warehouse (de ahora en
adelante, DW). La idea de desarrollar un DW es, justamente, independizar el entorno
transaccional del analítico. Junto con él aparece el modelado o diseño de datos
dimensional.
En cuanto a la relación de big data con el modelado dimensional, usted seguramente
encontrará mucha información al respecto en la web con opiniones de las más
variadas, entre ellas algunos afirman que el DW ha dejado de existir o dejará de
hacerlo próximamente. Lo cierto es que hoy muchísimas empresas tienen DW y otro
gran número piensan en construir estos entornos, incluso los diferentes vendors siguen
invirtiendo en sus motores de bases de datos para analítica. Por lo tanto, tenemos DW
para muchos años más. A pesar de esta salvedad, es necesario aclarar que dichos
motores mutaron y se adaptaron a las nuevas tendencias y tecnologías; por ejemplo,
agregaron nuevas funcionalidades para agilizar el manejo de los datos.
Por otro lado, el costo de almacenamiento se redujo notablemente y esto llevó a dejar
muchas veces de lado la normalización de los datos (con claves primarias, foráneas,
etc.) para migrar a esquemas desnormalizados, con redundancia en los mismos. Esto
no significa que una técnica esté bien y la otra mal, todo lo contrario; son diferentes
elecciones y cada equipo decide el escenario que mejor se adapte a su caso de uso;
es decir, su infraestructura y motores de bases de datos con fines analíticos.
Tabla 1: Ejemplo simple de normalización
Nombre de tabla: tablaClientes
id_cliente Nombre telefono email
1 Juana 543511 juana@gmail.com
2 Carlos 543512 carlos@gmail.com
3 Josefina 543513 josefina@gmail.com
Fuente: elaboración propia.
Tabla 2: Ejemplo simple de normalización (2)
Nombre de tabla: tablaVisitas
id_visita fecha_visita hora_visita id_cliente_fk*
1 01/05/2020 15:20 1
2 04/05/2020 16:15 1
3 10/05/2020 13:30 2
4 15/11/2019 08:45 3
Fuente: elaboración propia.

(*) la abreviación Fk significa foreign key (clave foránea que vincula una tabla con otra).
Ventajas:

 Brinda integridad.
 Evita redundancia, duplicados, entre otras cosas.
Podemos relacionar las “visitas” con los “clientes” por medio de los campos:

id_cliente (tablaClientes) e id_cliente_fk (tablaVisitas)

Tabla 3: Ejemplo simple de tabla desnormalizada creada bajo una de las tantas
técnicas de desnormalización
Nombre de la tabla: tablaVisitas
id_visita fecha_visita hora_visita id_cliente nombre telefono email
1 01/05/2020 15:20 1 Juana 543511 juana@gmail.com
2 04/05/2020 16:15 1 Juana 543511 juana@gmail.com
3 10/05/2020 13:30 2 Carlos 543512 carlos@gmail.com
4 15/11/2019 08:45 3 Josefina 543513 josefina@gmail.com
Fuente: elaboración propia.

Ventajas:

 Evita cruces de datos entre tablas (joins).

 Mejora la performance.
 Aumenta velocidad para consultas y reportes.
También es válido evaluar el uso de bases de datos columnares, las mismas nos
brindan cierta ventaja en modelos no normalizados. En la actualidad, son bastante
utilizadas para analítica y big data.
A partir de lo mencionado anteriormente, podemos afirmar que el modelado
dimensional nunca está de más y sus conceptos siguen vigentes. Más allá del
crecimiento en volumen de los datos, es necesario contar con este conocimiento para
poder evaluar diferentes alternativas y presentar mejoras. En big data no todas las
teorías se amoldan a todos los casos de usos, es muy importante ser flexibles y saber
elegir la mejor opción en base a recursos y necesidades.
El modelado dimensional trabaja bajo el fundamento de analizar un proceso de
negocio mediante hechos y dimensiones o, llamado de otra forma, métricas y
perspectivas. Es un diseño que permite dar respuesta a preguntas como:
a) ¿Cuál fue el monto promedio gastado por clientes en compras online el último
trimestre?
b) ¿Cuál es el empleado con más ventas en la última semana en la sucursal Nro. 1?
c) ¿Qué comercios electrónicos registraron mayor cantidad de visitas en el rubro
electrónico el último black friday?
En la mayoría de los casos, los hechos son valores numéricos y se caracterizan por
ser el principal foco a evaluar dentro de una pregunta analítica. Su nivel de detalle
describe la granularidad (por ejemplo, la métrica puede estar agregada por día o a
nivel de transacción sin ningún tipo de agrupamiento). El hecho siempre es evaluado
por una o más perspectivas o puntos de vistas diferentes, a los cuales llamamos
dimensiones.
Frente a dichas preguntas y definiciones, podemos entonces realizar las siguientes
distinciones que nos permitirían evaluar un modelo conceptual (y, quizás, el modelo
lógico):
La pregunta a) nos permite diferenciar la métrica (o hecho) “monto promedio de
compra” y las dimensiones “tiempo” y “clientes”.
La pregunta b) nos permite diferenciar la métrica “cantidad de ventas” y las
dimensiones “tiempo”, “sucursales” y “empleados”.
La pregunta c) nos permite diferenciar la métrica “cantidad de visitas” y las
dimensiones “tiempo” (ya que para saber cuándo fue el último black friday necesito
moverme en la línea de tiempo), “rubros” y “comercios”.
Si tomamos la pregunta c) y diseñamos un diagrama (simple) de tablas orientadas a
analítica (OLAP) tendríamos el siguiente modelo físico:
Figura 1: Modelo

DIM_RUBROS DIM_COMERCIOS

rubro_sk comercio_sk

rubro comercio

rubro_familia comercio_categoria

rubro_bk Comercio_bk
FACT_VISITAS
tiempo_sk
comercio_sk
rubro_sk
DIM_TIEMPO
cantidad_visitas
tiempo_sk
fecha
anio
mes
dia
Fuente: elaboración propia.

Previamente, los datos de los diferentes orígenes deberán ser extraídos,

transformados (quizás con algunas reglas de negocio) y cargados (ETL) a estas tablas.
Dicho proceso de carga suele ser configurado para ejecutarse en una ventana de
tiempo específica.
Supongamos que la tabla de hechos ha sido cargada con un nivel de agregación diaria
(mayor granularidad), en donde cada registro implica la cantidad de visitas en un día
para un rubro y comercio. También definimos la fecha del último black friday entre los
días 15 y 21 de diciembre de 2019.
Ahora, siempre y cuando el modelo haya sido desarrollado bajo un motor que nos
permita utilizar SQL para analizar los datos, podemos responder a la pregunta con la
siguiente consulta (traemos los 5 comercios con más visitas):

SELECT comercio as Comercio, sum(cantidad_vistias) AS Cantidad_Visitas

FROM FACT_VISITAS f
INNER JOIN DIM_TIEMPO t ON f.tiempo_sk = t.tiempo_sk
INNER JOIN DIM_RUBROS r on f.rubro_sk = r.rubro_sk
INNER JOIN DIM_COMERCIOS c on f.comercio_sk = c.comercio_sk
WHERE t.fecha BETWEEN ‘2019-12-15’ and ‘2019-12-21’
AND r.rubro = ‘Electronica’
ORDER BY sum(cantidad_vistias) DESC
LIMIT 5

Tabla 4: Resultado
Comercio Cantidad_Visitas
El buen pastor 15.250.030
Mercado Electrónico 11.000.392
Electronic Mart 9.765.476
Jhonny Market 5.005.698
La casa de los Repuestos 2.986.349
Fuente: elaboración propia.

El diseño propuesto (esquema de estrella) nos permite evaluar los hechos (cantidad
de visitas) desde distintas perspectivas (rubros, comercios y tiempo). Las tablas se
relacionarán entre sí mediante sus surrogate keys (SK) o claves subrogadas (únicas),
mientras que la relación de las dimensiones con sus respectivos modelos
transaccionales se representará mediante las business keys o claves de negocio (no
siempre presentes).
Como se mencionó previamente, el diseño dependerá de las técnicas y teorías que se
tomen en cuenta para el desarrollo del modelo de datos. Encontrará, para esto, gran
variedad de información al respecto en los libros de referencia y la web. Por supuesto
que detrás del diseño existe una extensa teoría acerca de técnicas y arquitecturas que
no vamos a examinar a nivel de detalle en esta lectura, por lo que si usted desea
especializarse en el tema le recomendamos consultar los libros de referencia
mencionados al final de la lectura.
Acabamos de representar un modelo de datos OLAP (online analytical processing) que,
más allá de algunas semejanzas, difiere de un modelo de datos OLTP (online transaction
processing) en muchos aspectos, entre los cuales podemos nombrar:

 Los modelos o sistemas OLAP están orientados a la analítica y la toma de

decisiones, mientras que los modelos o sistemas OLTP son útiles para transacciones y datos
operacionales.
 Los modelos o sistemas OLAP poseen esquemas cuyos datos se refrescan por lotes
(batch), en cambio los sistemas OLTP están construidos para soportar inserciones,
actualizaciones y borrar datos de manera inmediata.

 Los modelos OLAP, generalmente, se encuentran desnormalizados y no se

recomienda tener muchas dimensiones, mientras que en la mayoría de los sistemas OLTP
encontramos una base de datos normalizada.
2.1.2 Data warehouse y data lake

Big data es un término que involucra muchas tecnologías y arquitecturas. A veces sus
términos pueden parecer complejos e incluso hay quienes confunden algunos de ellos,
tal es el caso de data warehouse y data lake.
Como vimos anteriormente, el término de data warehouse está estrechamente ligado a
bases de datos con fines analíticos. Es un repositorio central en donde se guardan los
datos de toda la organización (en uno o más modelos). Su llenado se realiza mediante
procesos de extracción, transformación y carga (ETL) que se encargan de llevar los
datos desde los sistemas de origen, como así también de realizar su limpieza y curado
(quita de nulos, caracteres no válidos, formateo de fechas, entre otros casos).
Finalmente, este proceso depositará los datos transformados dentro de las tablas de
hechos y dimensiones correspondientes.
Figura 2: Ejemplo de data warehouse
Fuente: elaboración propia.

Existe una amplia teoría relacionada a los procesos ETL, pero no profundizaremos en
este aspecto. Si usted desea conocer más al respecto puede consultar el excelente libro
escrito por Ralph Kimball en 2004 llamado “The Data Warehouse ETL Toolkit: Practical
Techniques for Extracting, Cleaning, Conforming, and Delivering Data”.
Pocos años atrás, era común que un proyecto de inteligencia de negocios o BI (business
intelligence) llevara meses de desarrollo, por lo tanto, si uno quería tener reportes o
dashboards estables e íntegros a nivel corporativo para tomar decisiones, dependía de
los tiempos del negocio y del área de sistemas correspondiente que llevaba a cabo el
desarrollo del proceso desde sus orígenes hasta su despliegue. Por ende, existía un
gran porcentaje de proyectos de BI que fracasaban debido a la falta de
involucramiento de las áreas de negocio o niveles directivos que debían ser claros en
sus necesidades para el desarrollo de BI agregara el valor que se pretendía.
A medida que el volumen de datos aumentó y estos se hicieron más variados y
complejos, el DW quedó chico y los procesos de BI se convirtieron en flujos de trabajo
pocos ágiles frente a las necesidades de información de ya no solo niveles directivos
o gerenciales, sino de analistas, científicos de datos y desarrolladores. Estos nuevos
usuarios, muchas veces, necesitan contar con los datos de forma inmediata (apenas
llegan desde el origen) y no pueden esperar a correr todos los procesos involucrados
en la carga del DW. Consecuentemente, necesitamos más que un DW para crear una
arquitectura de datos moderna.
Con el uso constante de la nube y el avance de las tecnologías de big data, nace el
concepto de data lake (James Dixon, fundador de Pentaho). Según la definición de
Gartner en su sitio web

Un Data Lake es un concepto que consiste en una colección de

instancias de almacenamiento de varios activos de datos. Estos activos
se almacenan en una copia casi exacta o incluso exacta del formato de
origen y se suman a los almacenes de datos originales (Gartner Inc.,
s.f., https://www.gartner.com/en/information-
technology/glossary/data-lake [traducción propia]).

En otras palabras, un data lake es un repositorio de archivos de distintos tipos y

tamaños en su estado crudo o puro; es decir, con una estructura idéntica o casi idéntica
a su sistema de origen. Los datos presentes en este repositorio deberían estar
gobernados y controlados en alguno de sus estadios para no convertir el data lake en
un data swamp (pantano de datos), en donde los datos se encuentren desorganizados
y sin curar, ya que esto haría que los mismos sean inutilizables o inentendibles para
los diversos usuarios.
Con la aparición de data lake, los procesos ETL pasaron a llamarse procesos ELT
porque, en primer lugar, se extraen los datos desde sus orígenes y, posteriormente, se
cargan en el data lake y, recién allí, sufrirán transformaciones y limpieza (extract, load
and transform).
Los data lakes poseen ciertas ventajas sobre los DW:
o Podemos almacenar datos estructurados, no estructurados y semiestructurados.
o Nos da cierta agilidad ante los cambios de esquemas de los archivos de origen
(por ejemplo, si a un archivo de formato Json resultante de una de las aplicaciones de
origen se le agrega un nuevo campo en su estructura).
o Los datos en su estado crudo están rápidamente disponibles para los usuarios que
lo necesiten.
o Menores costos.
o Mayor flexibilidad para realización de análisis.
o Los datos en el data lake no necesariamente deben ser accedidos únicamente
mediante consultas SQL, sino que se puede llegar a ellos de modo programático con
múltiples lenguajes de programación (según la tecnología del repositorio).
Como cierre de ambos conceptos (data warehouse y data lake), diremos que el DW no
está en peligro de extinción, sino que actualmente forma parte de los proyectos de big
data en una versión más completa al trabajar en sinergia con el data lake. Para
aquellos datos que precisen ser analizados ya una vez curados tenemos el DW; ahora,
si la necesidad es contar con ellos en tiempo real o casi en tiempo real (NRT) debemos
ir directamente a los archivos en crudo en el data lake o a motores de datos en tiempo
real.

2.1.3 Modelado semántico

Anteriormente hemos mencionado el modelo conceptual, lógico y físico. Ahora

indagaremos un poco más sobre el modelado semántico y su importancia para el
análisis de datos. Quizás este sea el menos nombrado de los modelados.
Una vez que los datos fueron cargados al DW o al data lake, su estructura mantiene
en gran porcentaje el esquema que arrastra desde su origen, más allá de algunas
transformaciones o agregados que se le puede haber realizado en su procesamiento.
Lo más probable es que nadie entienda esa estructura de datos salvo que exista
alguna documentación al respecto.
Aquí algunos ejemplos:
Figura 3: Dataset NBA 2013

Fuente: adaptado de Kaggle, 2019.

Figura 4: Fragmento de archivo Json

Fuente: Amazon Web Services Inc., 2020, https://docs.aws.amazon.com/es_es/cloud9/latest/user-

guide/aws-cloud9-ug.pdf

El modelado semántico nos brinda la posibilidad de darle un sentido de negocio a los

datos desde la perspectiva del usuario. Aquí es donde colocamos nombres de
columnas comprensibles para el usuario, dándole mayor claridad a los mismos con
el fin de lograr uniformidad a lo largo de todo el repositorio de datos (sea un DW o un
data lake). Esta estrategia facilita al usuario la tarea de localizar campos comunes a
varias tablas, mediante la utilización de un solo nombre.
Para lograr que el modelado semántico sea exitoso, necesitará involucrar a los
usuarios de negocio, como así también al equipo de gobierno de datos.

2.1.4 Lenguajes de consultas

Los lenguajes de consultas nos permiten interactuar con los datos (en expresión de
máquina) mediante un lenguaje más amigable e intuitivo para el ser humano.
Permiten mayor interacción sin necesidad de utilizar un código de programación (en
la mayoría de los casos) y esto nos ahorra esfuerzos innecesarios.
Existen diversas formas de consultar datos, de acuerdo con las características de la
base de datos o su estructura. Quizás el lenguaje más conocido sea SQL (ver ejemplo
de consulta SQL en la unidad 2.1.1). Este se utiliza, quizás, en todas las bases de
datos relacionales con pequeñas modificaciones según el proveedor del motor. Sus
fundamentos están desarrollados en base al álgebra relacional y la teoría de
conjuntos. Sin embargo, existen otros lenguajes, a saber:

 MDX (multidimensional expressions): utilizado en Microsoft Analysis Services

(fundaron las bases de la herramienta Power BI) para consultas sobre modelos
multidimensionales.

Figura 5: Ejemplo de lenguaje MDX

SELECT
{ [Measures].[Sales Amount],
[Measures].[Tax Amount] } ON COLUMNS,
{ [Date].[Fiscal].[Fiscal Year].&[2002],
[Date].[Fiscal].[Fiscal Year].&[2003] } ON ROWS
FROM [Adventure Works]
WHERE ( [Sales Territory].[Southwest] )
Fuente: Microsoft (2020). SELECT Statement Example. Recuperado de https://docs.microsoft.com/en-
us/analysis-services/multidimensional-models/mdx/mdx-query-the-basic-
query?view=asallproducts-allversions

 HQL (hive query language): utilizado en Hive para analizar datos estructurados de
su metastore. Muy similar a SQL.
 CQL (Cassandra query language): propia del motor de datos Cassandra.
 LINQ: Lenguaje de consultas utilizado en los frameworks de desarrollo .net.
 GraphQL: es un lenguaje de consultas para APIs.
 Cypher Query Language: utilizado para base de datos de grafos (Ej: Neo4j).

Las llamadas bases de datos NoSql no poseen un único lenguaje de consulta

predefinido, sino que cada motor se adapta a sus características y permite navegar
por los documentos mediante su lenguaje particular, como así también mediante
alguno de los tantos lenguajes de programación más utilizados (Node.Js, Python,
Java, etc.).
Las bases de datos NoSql nos dan una mayor flexibilidad cuando hay un cambio en
el esquema de los datos; por ejemplo, si en el origen se decide dividir un número de
ticket con el siguiente formato “XXXX-XXXXXX” en dos campos diferentes: campo
prefijo del ticket (cuatro primeros caracteres antes del guion) y campo número del
ticket (6 caracteres restantes después del guion). Un alter table en una base de datos
relacional con muchos registros puede llevar mucho tiempo, mientras que si
trabajamos con una base de datos no relacional simplemente deberíamos modificar
el fragmento de código correspondiente para distinguir los viejos documentos (con
formato XXXX-XXXXXX) de los nuevos (con prefijo y número por separado).
Por otro lado, si estamos trabajando bajo Hadoop mediante programación
MapReduce, podemos decir que su lenguaje de consulta está en el medio de un
lenguaje de consultas declarativo y una consulta API totalmente imperativa.

2.2 Cómo construir una arquitectura de datos moderna

2.2.1 Arquitecturas y enfoques para modelado de datos

Esta sección apunta específicamente a que usted pueda diseñar y delinear

arquitecturas de datos modernas para big data que le permita escalar y cumplir con
los objetivos de negocio de una manera ágil.
Como primera instancia, es necesario que analice detenidamente su caso de uso, su
necesidad y, en base a ello, comenzar a diagramar las partes involucradas en su
esquema. Por ejemplo, supongamos el siguiente caso de uso: analizar los consumos
realizados mediante nuestra app de billetera virtual. De manera descriptiva podemos
afirmar que la información necesita ser analizada diariamente mediante reportes y
formato tabular (para análisis particulares).
Con esta introducción del caso ya podemos comenzar a diagramar nuestro proceso al
separar algunas premisas:

 Los datos no necesitan ser visualizados en tiempo real, sino con un refresco diario.
 Nuestro sistema de origen es la base de datos alimentada por la app de la
billetera virtual.
 La ingesta a nuestro data lake puede estar dada en tiempo real o NRT (casi tiempo
real) por si en un futuro se necesita analizar la información en periodos inferiores al día.
 La capa de consumo o de presentación al usuario será por medio de tablas y
reportes.
En arquitecturas modernas es de suma importancia poder desacoplar las partes
involucradas; por ejemplo, separar almacenamiento de su motor de procesamiento,
separar la ingesta de la exploración, etc.
Como primera instancia habrá que decidir si la infraestructura se encontrará
localmente (on-premises) o será brindada por alguno de los proveedores de servicios
en la nube. Si la elección es tenerlo on-premises, habrá que decidir si configuraremos
todo lo necesario nosotros o trabajaremos con alguna distribución paga (por ejemplo:
Cloudera). Si la elección es contratar alguno de los proveedores en la nube, será muy
importante decidir qué servicios utilizaremos y cuánto de ello administraremos en
base a nuestras políticas y presupuesto.
Entonces aquí comenzamos a evaluar un poco más cada una de esas partes y
crearemos, en lo posible, una matriz que nos permita visualizar opciones, ventajas y
desventajas, sus parámetros correspondientes y, si es posible, los costos
aproximados.
De una manera simple y resumida podemos destacar algunas especificaciones:

 Origen de datos: la app de la billetera virtual. Supongamos que los datos pueden
ser consultados mediante API desde sus endpoints correspondientes ya que, por
políticas de seguridad, no nos permiten acceder a la base de datos de manera
directa.
 Almacenamiento (data lake): elegimos la plataforma que mejor se adapte a
nuestras necesidades dado su costo y recursos. Puede ser HDFS, AWS S3, Google
Storage, Azure BLOB storage.
 Ingesta de datos: alguna herramienta que nos permita traer los datos desde el
origen hacia nuestro data lake. Puede ser algún script de desarrollo propio bajo
su lenguaje de programación elegido o alguna herramienta elaborada para tal
fin, como por ejemplo NIFI, Airflow o, en su defecto, algunas de las herramientas
brindadas por los diferentes proveedores en la nube. Según el volumen habrá que
evaluar la utilización de alguna herramienta de manejo de mensajes o colas para
desacoplar las cargas (por ejemplo, Kafka).
 Procesamiento: recordemos que no es necesario el procesamiento en tiempo real,
por lo tanto, podríamos elegir alguna herramienta que nos permita un
procesamiento más al estilo batch o por lotes. Por ejemplo, alguna de las
mencionadas anteriormente (NIFI, Airflow) o, según el volumen, habrá que ver si
es necesario desarrollos en SPARK.
 Modelo de datos y consumo: dado que no es necesario contar con una base de
datos para tiempo real, Hive podría ser buena opción para modelar los datos o,
en su defecto, alguna de las herramientas brindadas por los proveedores en la
 nube (AWS Athena, Google Bigquery). Por el momento, al ser el primer caso de
uso, no analizaremos la implementación de una herramienta para DW.
En cuanto a la visualización de reportes, habrá que evaluar la compra de algún
producto (Tableau, Looker, Power BI) o desarrollar reportes a medida con algunas de
las librerías de visualización disponibles para algunos lenguajes de programación.
Otros aspectos a considerar
Deberemos tener en cuenta la infraestructura para el procesamiento (clústeres y su
mantenimiento), seguridad, scheduler (Oozie, por ejemplo), control de flujos, calidad
de los datos, infraestructura, servicios de red, control de código fuente, integración y
despliegue continuo, ciclo de vida de los datos (y formatos), metadatos y gobierno de
datos.
Como puede apreciar, existe una amplia gama de aristas a tener en consideración al
momento de desplegar un proyecto de big data; sin embargo, al igual que ocurre con
proyectos de desarrollo de software, el crecimiento es paulatino y avanza a medida
que el proyecto progresa y toma forma.
Hemos visto las especificaciones básicas, sin navegar en los detalles más profundos
de cada rama. Podemos comenzar a delinear un esquema simple de la arquitectura
requerida para nuestro caso de ejemplo.

Figura 6: Arquitectura de ejemplo

Fuente: elaboración propia.

Podríamos tomar este bosquejo inicial como un patrón a completar a medida que se
seleccionen las herramientas a utilizar en cada capa; por ejemplo, si decidimos crear
una arquitectura local (on-premises) que administre y configure completamente la
infraestructura y las herramientas para el desarrollo del caso, podríamos proponer la
siguiente arquitectura:
Figura 7: Arquitectura de ejemplo (2)

Fuente: elaboración propia.

Una vez definida e implementada la arquitectura, el desafío de lograr la integridad en
los datos es una tarea compleja cuando los tipos de datos son variados. Podemos
diferenciar patrones según la carga de trabajo. El libro de Mohanty, Jagadeesh y
Srivatsa (2013) nombra alguno estos patrones según la carga de trabajo:
 Análisis de datos en tiempo real.
 Ingesta de datos de alta velocidad.
 Análisis de enlaces (entre diferentes estados del dato).
 Detección de eventos fuera de lo normal.
 Análisis de texto.
 Análisis de series de tiempo.
 Análisis con mayor profundidad.
Según el patrón detectado y el caso de uso específico, los datos pueden ser modelados
en diferentes instancias del proceso, pasando por distintos motores de bases de datos
según la velocidad en que se desee contar con la información y la velocidad con la
que se ingesta. El modelado de datos no es el mismo para un motor de base de datos
en tiempo real con datos prácticamente en crudo, que para un DW que tiene datos ya
sumarizados, por ejemplo.
Un modelo de datos bien diseñado posee los siguientes beneficios:
 Disminución de costos.
 Mejora la performance en cuanto a tiempos de respuesta de las consultas.
 Mantiene la integridad de los datos.
 Mejora la experiencia de usuario.
 Contribuye con la calidad de los datos.
Dos de los tipos de modelado más utilizados para big data en la actualidad son el
modelado dimensional (descripto en la unidad 1) y el modelado data vault. Este último
hace énfasis en la trazabilidad de los datos y no requiere grandes procesamientos
para lograr la integridad de los mismos. Su diseño está compuesto por elementos
Hubs, Links y Satélites.
Figura 8: Arquitectura Data Vault

Fuente: Linstedt y Olschimke en Starzyk (s.f.). Building a Scalable Data Warehouse with Data Vault 2.0.
Recuperado de https://pl.qibit.tech/otwieramy-skarbiec-danych-data-vault-dla-ciekawskich/

Figura 9: Diseño lógico Data Vault

Fuente: Linstedt, D. y Olschimke, M. (2015). Satellites on hubs and links (logical design).

Un tipo de modelado que no es tan utilizado en la actualidad es el modelado de datos

mediante grafos. Un ejemplo claro del mismo es el modelo de las redes sociales.
Figura 10: Modelado de grafos de películas y actores

Fuente: Lee, J., Wei, T. y Kumar Mukhiya, S. (2018). Labeled graph model of movies and actors.
Recuperado de
https://subscription.packtpub.com/book/big_data_and_business_intelligence/9781788620901/5/ch05l
vl1sec38/graph-data-models

2.2.2 Procesos involucrados en la creación de un modelo

En esta sección nos enfocaremos en modelos exclusivos para análisis. No

contemplaremos modelos en tiempo real ya que, generalmente, mantienen el estado
crudo de los datos.
Como ya mencionamos anteriormente, nuestro modelo puede estar normalizado o
desnormalizado según el caso de uso, la estrategia seleccionada y las tecnologías con
las que haya sido desarrollado.
En cuanto a modelos orientados al análisis, podemos diferenciar una serie de pasos
o procesos que nos ayudarán a generar un modelo exitoso:
1. En primera instancia, necesitamos hacer un relevamiento profundo. Para esto nos
plantearemos las preguntas que necesitamos responder con los datos que colectemos
para resolver un caso de uso puntual, ya sea objetivo del negocio o problema
detectado. La pregunta no debe ser extensa y debe ser lo más clara posible. Por
ejemplo:
Ante el objetivo de la organización (cadena de locales deportivos) de incrementar las ventas
en los canales digitales (web, app), ¿Cuáles son los clientes que todavía no realizaron compras
por medios digitales? ¿Qué porcentaje implican estas compras no digitales sobre el total de
compras? ¿Qué patrones de consumo tienen estos clientes?”
2. Una vez realizadas las preguntas, podemos comenzar a analizar de qué fuente
obtendremos los datos que respondan a estas preguntas. Además, identificaremos
nuestras métricas y perspectivas (como ya mencionamos en secciones previas).
3. En este paso definiremos el lapso de tiempo que necesitamos de información, ya
que para su obtención debemos tener en claro si necesitamos solamente los datos del
último mes, de los últimos años o, simplemente, los datos desde el momento en que
se ponga en marcha el proyecto. Por ejemplo, si queremos analizar ventas históricas,
será necesario definir cuántos años (si en las métricas existe la comparación entre un
año y otro).
4. Recolectar los datos en el estado más crudo posible para permitirnos ampliar
nuestro análisis en caso de ser requerido. Aquí son evaluadas particiones para los
datos, el tipo de almacenamiento, tiempos de ingesta, herramientas, entre otros.
5. Posterior a la recolección de datos, usted deberá comenzar el análisis de los mismos
para darle cierto significado y valor al negocio. Es aquí donde usted verifica que los
datos respondan a las preguntas que se planteó en primera instancia; por lo tanto,
deberá poner en juego su poder analítico y de desarrollo al crear nuevas tablas,
datasets, vistas y campos calculados.
Según el perfil de la persona o equipo que analice los datos se utilizarán diferentes
herramientas. Si su rol es el de un ingeniero de datos, lo ideal es que esos modelos
de datos desarrollados queden disponibles para otros usuarios y para nuevos
modelos que lo necesiten en un futuro.
Si el análisis no responde las preguntas planteadas, tendrá que validar si cuenta con
toda la información o necesita recolectar nuevos datos.

2.2.3 Metadatos, logs y categorías de modelos de datos

Como hemos observado a lo largo del módulo, los datos pueden presentarse en
múltiples formatos, estructuras, tamaños. Gran porcentaje de las aplicaciones que
utilizamos actualmente (sean para web, app o de escritorio) generan registros de
trazabilidad y control que son almacenados en archivos de logs. Estos archivos son
analizados constantemente en tiempo real para detectar fallas en los sistemas, alertar
sobre caída de los servicios, detectar cuellos de botella, problemas de latencia,
seguridad, entre cientos de casos más. Generalmente estos logs tienen mucha
información completamente desestructurada y necesitan una base de datos no
relacional para ejecutar su análisis inmediato.
Una arquitectura de big data seguramente incluirá análisis de datos sobre logs. Para
ello, necesitará evaluar las herramientas que posibilitarán tal tarea. Además, quizás
desee contar con la posibilidad de generar reportes más elaborados sobre dichos logs,
no solo con lo analizado en tiempo real, sino con modelos que le permitan observar
los datos desde otra perspectiva al cruzar información con otras fuentes y orígenes.
En la actualidad, existe gran variedad de stacks o sets de herramientas que permiten
realizar análisis sobre logs. Entre ellas podemos nombrar ELK-Elasticsearch, Logstash
y Kibana. También suelen utilizarse Graylog, Splunk, FluenD, entre otros.

Figura 11: Plataforma big data analytics para análisis de logs

Fuente: Linstedt, D. y Olschimke, M. (2015). Big Data Imperatives: Enterprise 'Big Data' Warehouse,
'BI' Implementations and Analytics.

Figura 12: Ejemplo de dashboard en Kibana (ELK)

Fuente: Elasticsearch B.V. (s.f.). Dashboard. Recuperado de
https://www.elastic.co/guide/en/kibana/current/dashboard.html

Otro aspecto importante dentro de big data son los metadatos. Podemos definirlos
como los datos acerca de los datos. Sí, es una definición extraña, pero es su
significado. A cualquier información que nos brinde datos acerca de los datos la
llamamos metadatos.
Existen tres tipos de metadatos:
 Metadatos descriptivos: permite a los usuarios interpretar los datos al brindar
información acerca de su contenido, su creador, fechas de publicación, entre otras
características.
 Metadatos estructurales: nos brindan información acerca de su estructura,
organización, relación con otras fuentes, sus claves, entre otras características.
 Metadatos administrativos: nos brindan información acerca de su fecha de
creación y modificación, los permisos que posee, tamaño, accesos, entre otras
características.

La administración de los metadatos es una tarea esencial del equipo de gobierno de

datos. Una falta de interpretación o una interpretación débil de los mismos provocará
inconsistencias en una infraestructura de datos orientada a self-service y provocará
dudas en los usuarios finales a la hora de interpretar los modelos presentados en las
diferentes capas de consumo. Dichos usuarios deberán acudir constantemente al
equipo de gobierno para comprender los datos que se encuentran en análisis.
Para cerrar este punto, en cuanto a las categorías o tipos de modelos de datos que se
nos pueden presentar en un proyecto de big data, podemos mencionar:
 Modelos de datos jerárquicos: utilizan estructura de árbol para representar
los datos mediante una única raíz y registros hijos. Por ejemplo:

Figura 12: Modelo de datos jerárquicos

Vehículo
s
Auto Moto Camione
s s s
Gasoi Gas
l
Fuente: elaboración propia.

 Modelos relacionales: relaciones entre tablas consideradas entidades de

negocio. Por ejemplo:

Figura 13: Modelos relacionales

tablaEmpleados tablaRoles
id nombre rol
1 Marcos 100 id rol
2 Maria 200 100 Desarrollador
3 Jésica 100 200 Arquitecto

Fuente: elaboración propia.

 Modelos orientados a objetos: permite almacenar archivos de video, audio,

imágenes, entre otros.

 Modelos no estructurados y semi estructurados: por ejemplo, archivos en

formato Json o .xml, entre otros.

2.2.4 Bases de datos de gran escala

Supongamos que su sitio web (o su app) posee gran cantidad de visitas al día y usted
quiere analizar los clics que se realizaron sobre los anuncios promocionales de
descuentos que se publicaron este último mes. El sitio es global y los anuncios reciben
alrededor de 3500 clics por segundo de diferentes usuarios en todo el planeta. El
volumen aproximado de almacenamiento mensual que implica ronda cerca de los 8Tb
mensuales. Como CEO de su empresa usted desea analizar los datos en tiempo real
y, además, debe poder crear reportes semanales y mensuales para observar si las
promociones realmente dan resultado. Sin embargo, no debe dejar de lado los costos
que le implicará este análisis, además, el usuario final no debería experimentar
ninguna demora al consultar el sitio.
En estos casos será necesario desarrollar una arquitectura que nos permita desacoplar
las necesidades de datos en caliente de los datos en frío mediante un almacenamiento
diferente para cada caso. Por ejemplo, para los datos en caliente se podría utilizar una
base de datos de caché tipo Redis y para los datos en frío se podría utilizar Hive
montado sobre HDFS para poder realizar consultas ad-hoc.
En conclusión, cada arquitectura tendrá su impronta según el caso de uso de negocio
que se analice. Siempre tendrá que contemplar la temperatura y volumen de los datos
antes de desarrollar cualquier arquitectura de big data. En otras palabras, deberá
dedicar parte de su tiempo para analizar los diferentes patrones que se nos pueden
presentar en la ingesta, almacenamiento y consumo de los datos.

Referencias

Amazon Web Services Inc. (2020). AWS Cloud 9. Guía del usuario [documento en línea].
Recuperado de https://docs.aws.amazon.com/es_es/cloud9/latest/user-guide/aws-
cloud9-ug.pdf
Elasticsearch B.V. (s.f.). Dashboard. Recuperado de
https://www.elastic.co/guide/en/kibana/current/dashboard.html
Gartner Inc. (s.f.). Data Lake. Recuperado de https://www.gartner.com/en/information-
technology/glossary/data-lake
Kaggle Inc. (2019). Start with more than a blinking cursor. Recuperado de
https://www.kaggle.com/
Lee, J., Wei, T. y Kumar Mukhiya, S. (2018). Labeled graph model of movies and actors.
Recuperado de
https://subscription.packtpub.com/book/big_data_and_business_intelligence/97817
88620901/5/ch05lvl1sec38/graph-data-models
Linstedt, D. y Olschimke, M. (2015). Building a Scalable Data Warehouse with Data Vault
2.0. New York: Elsevier Science.
Microsoft (2020). SELECT Statement Example. Recuperado de
https://docs.microsoft.com/en-us/analysis-services/multidimensional-
models/mdx/mdx-query-the-basic-query?view=asallproducts-allversions
Mohanty, S., Jagadeesh, M. y Srivatsa, H. (2013). Big Data Imperatives: Enterprise 'Big
Data' Warehouse, 'BI' Implementations and Analytics. Nueva York: Apress.
Starzyk, L. (s.f.). Otwieramy skarbiec danych? Data vault dla ciekawskich. Recuperado de
https://pl.qibit.tech/otwieramy-skarbiec-danych-data-vault-dla-ciekawskich/