Proyectos de Big Data

© EDICIONES ROBLE, S.L.

 Indice
Proyectos de Big Data 3
I. Introducción 3
II. Objetivos 4
III. Factores clave 4
3.1 Gobierno del dato 5
3.1.1. Ámbitos del gobierno del dato 6
3.2 Explotación de la información 8
3.3 Calidad del dato 9
3.3.1. Data Profiling 11
3.3.2. Calidad operacional 11
IV. Perfiles 12
4.1 Arquitecto Big Data 12
4.2 Ingeniero de datos 12
4.3 Científico de datos 13
V. Áreas de aplicación 14
5.1 Marketing y ventas 14
5.2 Operaciones 16
5.3 Tecnología 16
VI. Fases de un proyecto Big Data 16
6.1 Ciclo de vida de un proyecto analítico 18
VII. Entornos en un proyecto Big Data 19
7.1 Tipos de entornos 19
7.2 Dimensionamiento 20
VIII. Proyectos de datos 21
8.1 BI a Big Data 21
8.2 Proyectos de ciencia de datos 24
IX. Resumen 27
Ejercicios 30
Caso práctico 30
Se pide 31
Posible solución 31
Recursos 32
Bibliografía 32
Glosario. 32

2/33
 Proyectos de Big Data

Proyectos de Big Data

I. Introducción
1Disclaimer: todo el material generado en esta unidad está basado en material previo del autor,
por lo que los derechos de propiedad del material base son y se mantienen como propiedad
del autor Juan Ramón González.

Existe en la actualidad una gran proliferación de proyectos que se pueden englobar dentro de la
categoría de Big Data, bien porque requieren el tratamiento masivo de datos, bien porque se basan en la
aplicación de aprendizaje automático o porque implican ambas tecnologías.

Gran parte de los proyectos Big Data se consideran no exitosos por parte de las compañías, lo cual está
ralentizando en parte la inversión de las empresas.

Todos los proyectos se pueden considerar no exitosos si no cumplen con los requisitos, la planificación
temporal y el coste estimado. El grado de no éxito depende del grado de desviación en cada uno de los
indicadores clave mencionados anteriormente. Existen factores que resultan muy importantes para el no
éxito de los proyectos. Enumeramos a continuación los aspectos más importantes que impiden tener éxito
a los proyectos Big Data:

Uno de los factores clave es no tener objetivos claros. Muchas empresas quieren subirse al carro del Big
Data, pero no tienen un objetivo de negocio; lo hacen simplemente para poder decir que han implantado
tecnología Big Data. Sin retorno de inversión y sin mejorar la operativa de la compañía, no debemos
lanzar este tipo de proyectos.

Falta de compromiso por parte de la dirección. En muchas empresas los directivos ven la tecnología
Big Data como algo que hay que hacer; esto hace que el respaldo ejecutivo a este tipo de proyectos se
retire al encontrar los primeros obstáculos.

La ausencia de objetivos claros hace que se definan proyectos que no se pueden afrontar en los tiempos
definidos. Definir objetivos a largo y a medio plazo resulta esencial: el Big Data no es una bala de plata.
Es decir, hay que descomponer los proyectos en proyectos afrontables que den resultados en un plazo
de 4 o 6 meses.

Falta de talento. Las compañías no valoran en muchas ocasiones la necesidad de incorporar talento con
experiencia en estas nuevas tecnologías.

3/33
 Proyectos de Big Data

Los procesos internos para el acceso a la información. En muchas ocasiones dificultan la obtención de
los datos para poder explotarlos.

II. Objetivos

El objetivo de este módulo es que el alumno adquiera un conocimiento global sobre todo lo
necesario para poder enfocar un proyecto Big Data. Cuando se termine el módulo, se habrán
adquirido los conocimientos necesarios para analizar:

Los factores clave de un proyecto Big Data.

El tipo de perfiles que deben formar parte del proyecto.
Las fases y el ciclo de vida de un proyecto Big Data y Analytics.
Los diferentes entornos con los que se debe trabajar.

Este módulo tiene un carácter especialmente práctico, pues proporciona una guía sobre cómo
afrontar un proyecto Big Data y de qué elementos deben tenerse en cuenta.

En el epígrafe de “Factores clave” se hace hincapié en los elementos de gobierno y calidad del
dato. En el primero, como las políticas y procesos necesarios para asegurar el correcto uso de la
información y vitales en todo sistema Big Data, ya que cuando en un mismo entorno se integra
información de múltiples sistemas, departamentos y con diferentes tipos de consumidores,
asegurar una política que defina responsabilidades y procesos es obligatorio para el éxito de
cualquier iniciativa. Por su parte, las políticas de calidad del dato tienen que proporcionar un nivel
de calidad definido y medible, ya que sin ellas los procesos sobre los datos no podrían ser fiables
y podrían llevar a una incorrecta toma de decisiones basada en datos erróneos.

Posteriormente, se presentan los diferentes perfiles que forman parte de un proyecto de Big
Data. En este epígrafe se verán las diferentes competencias de cada perfil y cómo en un equipo
multidisciplinar la mezcla de perfiles genera el equipo óptimo para los proyectos.

Finalmente, se presenta el ciclo de vida de un proyecto Big Data. Para ello, se describen
primero las características generales que definen cualquier proyecto y después se presentan las
características y fases específicas de Big Data. Para terminar, se presenta el ciclo de vida de un
proyecto analítico y las diferencias que tienen estos con los proyectos tradicionales.

Con todo ello se da una visión completa del proyecto, desde los factores clave, perfiles y ciclo
de vida de los proyectos de Big Data y Business Analytics.

III. Factores clave

Existen varios factores clave en los proyectos de Big Data. Como en cualquier proyecto de desarrollo de
software, tenemos los factores clave clásicos:

Respaldo ejecutivo.

4/33
 Proyectos de Big Data

Requisitos bien definidos.

Estimaciones realistas.
Definición clara de puestos y responsabilidades.
Definición de la metodología de trabajo.
Planificación realista.
Capacidad técnica de los recursos humanos para desarrollar el proyecto.

Estos son los factores clave de cualquier proyecto de software. Los proyectos Big Data no dejan de ser
proyectos software, pero tienen dos elementos distintivos fruto de su naturaleza de tratamiento masivo de
datos.

En los proyectos de Big Data debemos incluir, por tanto, dos factores adicionales:

El gobierno del dato.

La calidad del dato.

Uno de los objetivos de los proyectos de Big Data, aunque no el único, es tener los datos disponibles en
el menor tiempo posible.

Una de las claves para ser una compañía que basa sus decisiones en los datos es entender rápidamente
el problema basándonos en los datos; esto implica que debemos tener los datos relativos a ese problema
accesibles y actualizados. Si usamos datos para analizar los problemas y tomar decisiones, estos deben ser
datos fiables y de calidad, en cualquier otro caso estaremos ante un grave problema.

Para que podamos hacernos una idea de la envergadura del problema, el coste de la falta de calidad de
los datos le va a suponer 8,2 millones de dólares americanos al año a las compañías, según el estudio de
Gartner2.

Por otra parte, el endurecimiento de las políticas sobre la protección de datos, así como la regulación
general europea de protección de datos, puede implicar multas de hasta 22 millones de dólares, lo que
implica que el gobierno del dato no solo es importante para garantizar la calidad del dato y su trazabilidad,
sino también una obligación legal.
2Parsionate. Omnichannel Excellence. “Digital Transformation. Digitalisation is changing
companies – worldwide and across industries”. [En línea] URL disponible en: https://parsionat
e.com/en/focus/digital-transformation/

3.1 Gobierno del dato

El gobierno del dato es el responsable de garantizar los siguientes puntos clave dentro de la compañía:

Validar la integridad y veracidad de las fuentes y orígenes de los datos, tanto internos como
externos.
Definir la política de evaluación de las fuentes y dar a cada una de ellas un valor de calidad de la
fuente.

5/33
 Proyectos de Big Data

Definir los responsables de los datos.

Definir el acceso a los datos, teniendo en cuenta los perfiles de los empleados y el uso que van a
hacer de los datos.
Garantizar la disponibilidad de los datos.
Garantizar en todo momento que se cumplen las normativas legales vigentes.
Garantizar que las políticas definidas sobre los datos se cumplen, incluyendo los cursos sobre
estas políticas a los empleados, y garantizar su conocimiento y aplicación.
Definir métricas y procesos que garanticen que las políticas se cumplen.
Garantizar la realización de auditorías sobre los datos.

3.1.1. Ámbitos del gobierno del dato

Visión y estrategia

Conocer los objetivos a corto, medio y largo plazo de la implantación de un plan de gobierno del
dato. Estos objetivos deben estar alineados con los objetivos estratégicos de la empresa para asegurar
que el plan de gobierno del dato cubre las necesidades de negocio y de IT definidas.

Políticas y procedimientos

Conocer los procedimientos actuales de demanda informacional y si existen procedimientos de

gobierno del dato o calidad, junto con los roles actuales y responsables de la información. En este
ámbito, es necesario definir todas las políticas y procedimientos necesarios para asegurar un correcto
flujo de la información, desde la generación de necesidad, demanda de información, evolución de los
sistemas, etc.

Estructura organizativa

Dentro del ciclo de vida del dato, definir los actores principales tales como owners, stakeholders y
consumers y su relación con los flujos de información.

6/33
 Proyectos de Big Data

Gestión de contenidos

Generación del inventario de información, donde se defina la información disponible, la información

necesaria pero todavía no disponible y el grado de criticidad de cada uno de los datos. En función de
esa criticidad, se definirán los niveles de gobierno del dato que se vayan a implementar, así como los
criterios de gobernabilidad necesarios en cada nivel. No es lo mismo el nivel de gobierno que aplicar a
datos core de la empresa, que tienen información privada de los clientes, que datos estadísticos
perimetrales de bajo uso.

En este ámbito se incluye también la gestión de datos maestros, referente a la gestión y mantenimiento
de los datos que son maestros para la empresa, es decir, aquellos datos que son referencia para todos
los demás y tienen una evolución o cambios menores con el tiempo.

Calidad del dato

Estudio de las políticas y necesidades de calidad de información, qué procesos de control y

rectificación se aplican y sobre qué datos son necesarios. Se verá en mayor detalle en el epígrafe
dedicado a la calidad del dato.

Seguridad y privacidad

En cada nivel de gobierno definido, es necesario conocer los requisitos de seguridad que se van a
implementar, tales como cifrado, encriptación, enmascaramiento, etc.

Es especialmente importante tener cuidado de que las políticas de seguridad y privacidad no

solamente se cumplan en los entornos productivos como desarrollo e integración, donde habitualmente
es más fácil encontrarse casos donde no se aplican.

Consumo de información y analítica avanzada

Se define qué elementos se usan, qué roles y con qué tipología se consumen los datos, tanto
internamente por parte del cliente como por parte de usuarios externos. Se incluyen en este apartado las
posibilidades de analítica avanzada y tecnología Big Data.

En este apartado se describen los perfiles de consumidores de información, qué necesidades tienen, y
se plantean las soluciones necesarias para darles cobertura.

Arquitectura de la información

En el ámbito de gobierno es necesario definir la arquitectura técnica necesaria para dar cobertura a
todas las capacidades que hemos visto anteriormente. Existen diferentes plataformas de gobierno del
dato que ayudan a automatizar las tareas vistas anteriormente.

7/33
 Proyectos de Big Data

Figura 1. Ámbitos del gobierno del dato. Fuente: elaboración propia.

3.2 Explotación de la información

Hemos visto anteriormente, en el ámbito del gobierno de consumo de información y analítica avanzada,
que se definen el tipo de consumidor de información y las herramientas de soporte. En las organizaciones
existen habitualmente estos tres tipos de perfiles:

Usuario estándar

Usuario de negocio con necesidad de consumo de información corporativa en forma de informe o

cuadro de mando.

Usuario avanzado (Power User)

Usuario avanzado capaz de generar sus propios informes adaptados a sus necesidades.

Analista de datos

Usuario avanzado encargado de generar estudios ad-hoc de mayor complejidad, normalmente con
bases matemáticas. Dentro del ámbito de la analítica, existen usuarios capaces de utilizar herramientas
avanzadas para realizar sus propios cruces de información, enriquecimiento de datos y generar sus
propios estudios.

En función de todo esto, las tipologías de consumo de información son:

Informe corporativo

Debe tener como finalidad generar un repositorio donde se podrá compartir y democratizar toda la
información viva de la compañía para solventar cualquier necesidad de información, la cual estará
debidamente organizada según las áreas y las políticas de acceso y privacidad pertinentes.

8/33
 Proyectos de Big Data

Autoconsumo

Información utilizada en el día a día por los analistas de diferentes vicepresidencias y áreas de
negocio para dar respuesta a todas aquellas preguntas que surgen continuamente en el negocio. La
capacidad e independencia para construir tanto sus informes como sus propias consultas a modo de
autoconsumo es una de sus ventajas.

Analítica

Analistas matemáticos que generarán los modelos estadísticos necesarios en su operativa, modelos
de predicción u otras técnicas.

3.3 Calidad del dato

La calidad del dato es clave y se refiere a la capacidad de la compañía de garantizar su precisión,
consistencia y completitud para que el dato pueda ser utilizado por cualquier persona (por supuesto
autorizada) dentro de una compañía. Es decir, que el dato refleja de manera fiel y exacta aquello que
representa, y no solo eso, sino de manera consistente en el tiempo. La calidad del dato no es algo estático,
sino que hay que garantizarla a lo largo del tiempo.

Anotación: Actividades de este rol

Las actividades de este rol las podemos sintetizar como sigue:

Definir la política de estandarización de datos, que debe seguir la política del gobierno
del dato.
Definir y garantizar, mediante procesos de parseo, que los datos cumplen los formatos
establecidos.
Limpieza del dato: eliminar aquellos datos que no están dentro de los valores permitidos,
asignar valores por defecto, limpiar outlayer.
Integridad del dato: que no haya duplicados, que todos los datos cumplan con la
política del gobierno del dato.
Implementar las políticas de acceso a los datos.
Enriquecimiento del dato, desde las fuentes autorizadas por la política del gobierno del
dato.

Respecto a las políticas de calidad, es importante asegurar que cumplen las siguientes reglas:

9/33
 Proyectos de Big Data

Figura 2. Características de una política de calidad del dato. Fuente: elaboración propia.
Completitud

En algunos casos, los datos que no están son irrelevantes, pero cuando se vuelven necesarios para un
proceso del negocio, estos se vuelven críticos.

Relevancia

Las políticas de datos tienen que asegurar en mayor grado los datos más críticos, y pueden ser más
laxos en datos menos importantes. La relevancia mide la importancia dada al dato y su calidad, de forma
que estén correlacionadas.

Confiabilidad

Este atributo de la calidad de datos permite conocer si estos están disponibles cuando se requiere, es
decir, que el dato está disponible con la calidad esperada en el momento en que se necesita.

10/33
 Proyectos de Big Data

Validez

Representa la capacidad para detectar datos anómalos, de forma que los datos siempre tengan el
grado de validez acordado.

Oportunidad

Define que la calidad del dato debe tener unos SLA definidos. Es decir, la calidad no tiene por qué
ser perfecta, pero sí conocida y medible. A su vez, esta característica indica que la calidad debe
aplicarse lo más cerca posible del origen y hacer disponibles los datos de forma inmediata y con la
calidad definida.

En cuanto a los procesos de calidad, existen dos ramas de procesos principales: Data Profiling
y calidad operacional.

3.3.1. Data Profiling

Consiste en analizar de forma periódica la calidad de las bases de datos disponibles, con el objetivo de
detectar problemas de calidad y ejecutar labores correctivas.

En el profiling se generan reglas de validación que se aplican de forma masiva sobre las bases de datos
para después iniciar un programa correctivo.

Habitualmente se hace uso de herramientas de Data Quality, que ayudan sistematizando estas labores.

3.3.2. Calidad operacional

Consiste en asegurar la entrada de información con un nivel de calidad medible y controlado, para evitar
la entrada al sistema de información potencialmente errónea por encima de unos niveles marcados.

Las reglas de calidad se aplican en los procesos de carga y modifican el workflow de carga de forma
directa.

Se aplican mediante herramientas de Data Quality o haciendo uso de la tecnología de tratamiento de

datos disponible.

Finalmente, es importante destacar que los procesos de calidad en proyectos analíticos son ligeramente
diferentes:

Data Profiling se utiliza para encontrar nulos, diferencias de formato y valores anómalos. Se
ejecuta de forma periódica para dar un nivel base de calidad.

11/33
 Proyectos de Big Data

La calidad operacional se aplica en los procesos de carga, especialmente en aquellos de baja

latencia, para asegurar que un error en las fuentes de datos no genera una degradación de los
modelos.
El proceso de EDA (analítica exploratoria) busca detectar nuevos problemas de calidad y
corregirlos.
La labor correctiva previa a la aplicación del modelo es clave.
Procesos de calidad específicos del estudio o aplicación de modelos específicos.
Industrializar el proceso de calidad en la puesta en producción del modelo.

IV. Perfiles
Hemos visto que uno de los factores clave del éxito de un proyecto es tener perfiles cualificados. Vamos
a comentar los diferentes perfiles que hay que tener en cuenta a la hora de afrontar un proyecto de Big
Data.

4.1 Arquitecto Big Data

Son los responsables de definir la arquitectura del ecosistema Big Data: definen qué herramientas
de todas las que existen en el ecosistema vamos a utilizar y cómo van a interactuar entre ellas.
Son los responsables del diseño del dato de lagos: definen qué datos están en el lago para el
tratamiento por lotes y qué datos están en bases de datos NoSQL para su rápido acceso.
No solo definen las herramientas que vamos a usar, sino también las políticas y configuraciones
para obtener los rendimientos esperados.
La arquitectura se define en dos ámbitos, global y de proyecto:

Arquitectura global. En este caso, los arquitectos definen las herramientas del
ecosistema Big Data que deben usarse en todos los proyectos que se implementen;
cuál es la arquitectura de datos en el lago de datos (qué normas y estructura deben
tener); las herramientas que aseguren que se cumple con el gobierno del dato y la
política de seguridad. Definen cómo serán las herramientas de control del cambio, las
normas de uso de cada herramienta y las mejores prácticas.
Arquitectura proyecto. En este caso, definen cómo se usarán las herramientas de la
arquitectura global (las que sean de utilidad para el proyecto) y si se necesitan
herramientas adicionales (siempre previo consenso con arquitectura global) para
incorporarlas a la solución del proyecto y definir servicios adicionales de ser
necesarios.

Este perfil tiene un amplio conocimiento práctico de todas o casi todas las tecnologías (suele contar con
entre tres o cuatro años de experiencia específica en Big Data y al menos otros cinco en arquitectura
software).

4.2 Ingeniero de datos

12/33
 Proyectos de Big Data

Es el responsable de implementar el proyecto siguiendo la arquitectura definida. Es difícil encontrar un

ingeniero de datos que domine todas las tecnologías, falta experiencia, pero sí tendrá la experiencia
necesaria en las áreas clave.

Su ámbito de conocimientos comprende:

Herramientas de ingesta: Sqook, Flume, Kafka…

Transformación y consulta del dato: Hive, Pig, Impala, Hadoop, Spark, SparkSQL.
Análisis NRT: Spark Streaming, Storm.
Almacenamiento: HDFS, NoSQL (MongoDB, HBase, Cassandra).
Sistema operativo Linux.

4.3 Científico de datos

Un científico de datos es un profesional que debe contar con tres tipos de conocimiento:

a. Conocimientos (amplios) de matemáticas y estadística.

b. Habilidades tecnológicas y de hacking; tiene conocimientos técnicos para programar, capturar
datos y moverse en el ecosistema Big Data (sobre todo por el lago de datos, para explorar y
transformar los datos).
c. Conocimiento del negocio. Debe conocer el negocio, debe saber qué es importante para cada
problema de negocio.

13/33
 Proyectos de Big Data

Figura 3. Habilidades de un científico de datos. Fuente: elaboración propia.

En función de los conocimientos y habilidades que tenga el científico de datos, podemos definir las
siguientes zonas:

Zona de peligro

Cuando solo se tienen conocimientos tecnológicos y de negocio. Falta el rigor matemático y es

posible que las conclusiones sean erróneas.

Analista tradicional

Conoce el negocio y tiene conocimientos matemáticos. Es el perfil del analista de negocio o

funcional.

Aprendizaje automático

Cuando se tienen conocimientos técnicos y matemáticos. Pueden hacer modelos, pero al desconocer
el negocio estos no serán eficaces.

Científico de datos

Cuando tiene los tres tipos de conocimientos. Puede explorar y analizar los datos con la visión de
negocio y puede aplicar aprendizaje automático.

Resulta muy complicado encontrar este perfil en el mercado actualmente, por eso son tan valorados. La
mayoría de las compañías contratan a profesionales con sólidos conocimientos de matemáticas,
estadística y aprendizaje automático y los forman en el negocio, ya que esta parte es más sencilla, de las
tres características, de aprender.

V. Áreas de aplicación
Son numerosas las áreas de aplicación de estas tecnologías dentro de las compañías, de modo que
comentaremos las más habituales.

5.1 Marketing y ventas

El área de marketing es una de las áreas más activas dentro del campo de Big Data, tanto en la parte
online como en la tradicional.

14/33
 Proyectos de Big Data

Las empresas son conscientes de que entender de manera profunda al cliente es clave para poder
proporcionarle un servicio personalizado. Uno de los conceptos clave y obsesión de casi todos los
directivos es ser una compañía centrada en el cliente.

Entendamos mejor este concepto. Los supermercados venden diversos productos; el cliente, cuando va
a la compra, selecciona los que quiere y los compra. Esta aproximación está basada en el producto, pero
actualmente las empresas que se centran en el cliente venden de otra manera. Pensemos en Amazon.
Cuando nos conectamos, en general no tenemos que buscar un producto sino que Amazon, como nos
conoce, nos dice qué nos puede interesar y en caso de hacer una búsqueda rápidamente nos recomienda
productos asociados y similares. Esto es estar centrado en el cliente, dar a cada cliente lo que quiere y no
que sea el cliente quien tenga que buscar los productos.

Por ello, las empresas están implantando proyectos en esta área. Enumeramos algunos de ellos:

Mapas de calor en las tiendas físicas

Las empresas quieren entender cómo se mueven los clientes en sus tiendas, los que miran los
escaparates, para analizar quién entra y quién no se siente atraído lo suficiente como para entrar. Dentro
de la tienda, dónde se para el cliente o el tiempo que pasa en cada sección es información clave para
poder optimizar la experiencia de los clientes.

Optimización de promociones

Las empresas, desde el conocimiento del cliente, deben optimizar sus promociones, saber qué
promoción es la adecuada para cada cliente y los diferentes productos.

Venta cruzada

Estos proyectos analizan la actividad del cliente dentro de la compañía y la comparan con los clientes
similares y sus compras; de esta manera, podemos saber qué productos es más probable que le
interesen.

Redes sociales

Desde medir el impacto de sus campañas en redes sociales a saber quiénes hablan de ellos y cómo
(bien o mal) o identificar a los influencers .

Clasificación de clientes en función de los diferentes objetivos de negocio

Con el objetivo de poder ofrecer a cada segmento aquello en lo que tiene interés. Un ejemplo es
segmentar a los clientes para identificar a aquellos que pueden estar interesados en un nuevo producto.

En general, los departamentos de marketing quieren tener todos los datos que genera un cliente cuando
interactúa con la empresa, independientemente del canal.

15/33
 Proyectos de Big Data

5.2 Operaciones
Los departamentos de operaciones tienen diferentes objetivos según el sector y la empresa. Enumeramos
los más comunes:

Identificar fraudes. Las empresas quieren saber qué transacciones son ilícitas, empresas
financieras, empresas de seguros de salud, coches, hogar...
Identificar devoluciones. Para poder ajustar los recursos en logística y optimizar stocks.
Optimización de stocks. Cuánto voy a vender de cada producto.
Qué clientes se van a ir o me van a abandonar.
Por qué motivo se van a ir.
Mantenimiento predictivo de fábricas, flotas de coches, etc.

5.3 Tecnología
Los departamentos de tecnologías, en general, están implantando soluciones Big Data en las siguientes
áreas:

Business Intelligence. En esta área se implanta para poder ejecutar más rápido procesos que
actualmente requieren mucho tiempo y recursos de máquina. Las tecnologías Big Data permiten
ejecutar estos procesos de manera más eficiente y con menor coste.
Abaratamiento de costes. El coste de las licencias de herramientas tradicionales es alto; las
tecnologías Big Data son baratas si las comparamos con las herramientas tradicionales y nos
garantizan la escalabilidad.
Mantenimiento predictivo de los centros de datos.
Nuevos proyectos de industria 4.0 e IOT. Las tecnologías Big Data son excelentes para este
tipo de proyectos en los que tenemos que tratar en tiempo real gran variedad y volumen de datos.

VI. Fases de un proyecto Big Data

Los proyectos Big Data tienen las fases de cualquier proyecto de software:

Definición de requisitos.
Definición de la arquitectura.
Implementación.
Pruebas.
Aceptación.

Cada proyecto se desarrollará con una metodología específica, bien sea tradicional o con metodologías
ágiles más comunes en este tipo de proyectos.

16/33
 Proyectos de Big Data

Si bien están las fases clásicas de un proyecto de software, cuando trabajamos con Big Data tenemos
también las siguientes grandes fases en un proyecto:

Fuentes de datos

El primer paso es siempre identificar las fuentes de datos que van a ser parte del proyecto. Debemos
estudiar el problema o proyecto en detalle e identificar todas las fuentes que aportan información o son
necesarias para poder solucionar el problema. Es muy frecuente que a la hora de identificar las fuentes
se asuma que los datos que contienen son datos limpios y precisos, pero esto en muchos casos no
sucede, y no están tampoco estandarizados. Hay que tenerlo siempre en cuenta porque podemos tener
que dedicar mucho tiempo a esta actividad. Otra cuestión importante es el acceso al dato; en muchas
ocasiones olvidamos las políticas de accesos y esto, si bien tiene solución, nos puede provocar
retrasos.

Adquisición de datos o ingesta

Esta fase consiste en almacenar los datos de las fuentes de datos en nuestro lago de datos. Usamos
herramientas del ecosistema como Sqoop (para traer los datos desde bases de datos estructuradas),
Flume y Kafka (para traer los datos de fuentes de datos no estructuradas) y otras herramientas que o
bien existen en el mercado o hemos desarrollado.

Almacenamiento del dato

Nuestro lago de datos se puede almacenar en HDFS, pero también podemos usar otras tecnologías
como bases de datos NoSQL, que ya hemos visto.

Tratamiento del dato

Debemos transformar los datos en conocimiento. Podemos usar Hadoop (Map/reduce); herramientas
del ecosistema que nos permiten abstraernos de Map/reduce y tratar los datos con scrips o SQL, en
este caso usaríamos Hive o Pig (las herramientas traducen el código a Map/reduce); o podemos usar
Spark (en este caso el tratamiento se haría principalmente en la memoria y haría uso de disco solo
cuando no fuese posible tratar todos los datos en memoria). Dentro del tratamiento del dato es
importante identificar la necesidad de disponibilidad del dato, es decir, si podemos usar procesos batch
o debemos usar tiempo real; en este caso usaríamos Spark Streaming, Storm o Flink.

Visualización

Una vez transformado el dato, debemos trabajar los datos en crudo para transformarlos en
información y conocimiento. Lo visualizamos usando las numerosas herramientas que existen en el
mercado, entre las que podemos mencionar Power BI, Tableau o Qlik. Estas herramientas se usan
normalmente para construir cuadros de mando para los directivos. La visualización, en caso de
proyectos de sistemas, se refiere al interfaz de usuario y en este caso usaremos las tecnologías clásicas:
Javascript, Angular, ds3, etc.

17/33
 Proyectos de Big Data

Cada una de estas fases usa un tipo de tecnología y el trabajo de los arquitectos es definir qué
herramientas utilizar para cada una de ellas, sin olvidar la calidad y el gobierno del dato.

6.1 Ciclo de vida de un proyecto analítico

Dentro de un proyecto Big Data, si este conlleva labores analíticas, el ciclo de vida cambia ligeramente,
como vemos en la figura 4.

Figura 4. Ciclo de vida de un proyecto analítico. Fuente: elaboración propia.

Aquí se pueden ver tres etapas principales:

Aprovisionamiento

Poner, desde el área de tecnología, a disposición del equipo analista las estructuras de datos origen
necesarias para el posterior análisis, cumpliendo los estándares de calidad y seguridad necesarios. Es
importante distinguir entre movimiento de datos y acceso a los datos. Habitualmente, en esta etapa se
realizan dos procesos:

Captura. Ingesta de datos desde fuentes internas o externas. Enrutamiento de fuentes en

streaming. Persistencia de datos raw en modelo de datos corporativo.
Limpieza. ETL y reglas de negocio para la validación de los datos en datasets de análisis.
Separación de datos en erróneos y correctos.

18/33
 Proyectos de Big Data

Proceso iterativo de análisis

Proceso iterativo de análisis de datos y analítica enfocado a obtener un modelo que cubra las
necesidades estipuladas. Este proceso conlleva pruebas, análisis y refinamiento de los modelos hasta
obtener los resultados deseados. El ciclo iterativo conlleva las siguientes fases:

Transformar. Los datos disponibles desde el área de IT se tratan, se filtran y se convierten

en los datasets necesarios para la aplicación de modelos. Habitualmente, en esta etapa se
realizan los procesos de analítica exploratoria (EDA).
Modelar. Aplicación de hipótesis y modelos.
Analizar. Análisis de los resultados obtenidos, cálculo de las métricas de error y acierto.
Visualizar y comunicar. Presentación de resultados, puntos fuertes y débiles de los
resultados y vías de mejora. Es vital en esta tarea ser capaces de convertir los resultados
analíticos o matemáticos en un lenguaje de negocio que el usuario pueda entender para definir
con él la siguiente iteración de trabajo.

Industrialización

Incorporación del modelo en estructura corporativa, incluyendo: validación de procesos, control de

errores, automatización, inclusión de resultados en estructuras corporativas, inclusión en gestión de
procesos corporativos.

VII. Entornos en un proyecto Big Data

7.1 Tipos de entornos

Por la naturaleza de los proyectos Big Data, es importante que estudiemos los entornos y
configuraciones necesarios a la hora de desarrollar un proyecto Big Data. No todos los entornos son
imprescindibles, aunque sí deseables, y debemos tenerlo en cuenta para nuestro presupuesto de proyecto.

Desarrollo unitario

El se realiza en el ordenador de cada desarrollador. Cada desarrollador tiene su entorno de desarrollo

local. Una buena práctica que se está extendiendo es el uso de dockers; anteriormente se usaban
máquinas virtuales.

19/33
 Proyectos de Big Data

Clúster de desarrollo

La finalidad de este clúster es que los desarrolladores, una vez han probado su código, realicen las
pruebas en un clúster real. Normalmente los entornos de desarrollo no simulan la complejidad del
entorno distribuido de manera fiel. Es importante tener una buena política de ejecución en paralelo (esto
también se puede conseguir usando dockers ) ya que, si bien podemos configurar el clúster para que
ejecute varios procesos en paralelo, la realidad es que esto no resulta muy efectivo y puede generar
cuellos de botella.

Clúster de producción

Es el clúster donde se ponen las aplicaciones en producción. Solo las aplicaciones o releases
aprobadas pueden ir a producción.

Clúster de QA

Es un espejo del clúster de producción (aunque de dimensiones más pequeñas), donde se hacen las
pruebas de aceptación de las aplicaciones y las pruebas de migración de versiones de las herramientas
del ecosistema Big Data.

7.2 Dimensionamiento
Es importante dimensionar bien el tamaño de los clústers; para ello, debemos tener en cuenta:

El espacio en disco que ocupan todas las herramientas que vamos a instalar.
El volumen de datos que vamos a manejar. Hay que tener en cuenta que HDFS tiene factor de
replicación 3. Asimismo, debemos tener en cuenta:

Los datos de partida, es decir, los datos históricos que tenemos.

El volumen de datos que se va a manejar diariamente.
El número de días o meses de los que queremos tener datos en nuestro clúster.

Adicionalmente, si trabajamos con Spark, como trabaja en memoria debemos tener en cuenta que carga
los datos en memoria RAM. Esta carga se hace también con factor de replicación para ser tolerante a
fallos.

Dimensionar la memoria RAM es más complejo, ya que no todos los datos se cargan en memoria para
cada operación, es decir, se carga el RDD o Dataframe con los datos necesarios para cada operación, y
calcular este volumen es complejo. Una técnica es dimensionar al menos un 30 % más del Dataset más
grande (teniendo en cuenta el factor de replicación). En muchas ocasiones esto no es posible y en ese caso
Spark usará el almacenamiento físico, pero se degradará su rendimiento. Esto se puede ver de manera
sencilla con las herramientas de administración.

20/33
 Proyectos de Big Data

VIII. Proyectos de datos

En este epígrafe vamos a ver tres tipos diferentes de proyectos, en función de su naturaleza.

8.1 BI a Big Data

Estos proyectos son muy habituales dentro de las compañías, por diversos motivos:

Los sistemas de BI tardan mucho. Existen procesos que tardan demasiado y esto impide que los
datos estén disponibles a tiempo.
La empresa quiere ir migrando su dataware house a tecnología Big Data por un motivo
estratégico y de costes.

Beneficios:

Agilidad.
Ahorro de costes.
Facilidad de acceso a los datos.
Evitar silos de datos que están actualmente en diferentes almacenes de datos y datamart (con
visiones parciales de negocio).

La figura 5 ilustra las herramientas más comunes en cada una de las fases.

Figura 5. Fases de un proyecto Big Data.

Fuente: elaboración propia.

Requisitos: en este tipo de proyectos debemos definir los requisitos por niveles y es muy importante
identificar, en cada nivel, el grado de detalle necesario.

21/33
 Proyectos de Big Data

Primer nivel

Las fuentes de datos. En esta fase identificamos las fuentes de datos, tanto externas como internas.
Debemos identificar y justificar su inclusión.

Segundo nivel

Campos y valores de cada una de las fuentes. Debemos identificar no solo el campo sino también los
formatos, los niveles de agregación, campos claves y claves secundarias.

Tercer nivel

Nivel de armonización y limpieza. En este nivel definimos cómo se van a limpiar los datos, formatos
de fecha y hora, nombres de países, si vamos a generar campos adicionales (es muy típico generar año
y mes para facilitar la unión de tablas), qué hacer si hay duplicados o datos que faltan, etc.

Cuarto nivel

Procesado y enriquecimiento del dato. En este paso se define cómo se van a ir enriqueciendo los
datos, teniendo en cuenta las diferentes fuentes de datos. Típicamente estos requisitos identifican
nuevos campos que se calculan a partir de los datos de las diferentes fuentes.

Quinto nivel

Calculo de métricas o KPI. En este nivel se define de manera exacta cómo calcular todas las métricas
finales. Se identifican los campos del nivel anterior (el cuarto) que van a formar parte de cada métrica,
así como la fórmula para calcularlo. En ocasiones, en lugar de una fórmula, se define un proceso que
hay que implementar.

Requisitos transversales

Política de seguridad y gobierno del dato.

22/33
 Proyectos de Big Data

Vamos a ver ahora cómo evoluciona el dato, viéndolo por capas en función de su enriquecimiento:

Figura 6. Capas dentro de un lago de datos. Fuente: elaboración propia

Una vez tenemos los datos calculados, con los KPI, existen diferentes opciones:

Ingestarlos de vuelta en el sistema que se utiliza actualmente para el visionado, es decir, del
que se alimentan los cuadros de mando. Esta técnica se conoce como “up ingest” o ingestar
el dato de vuelta.

Visualizarlos, usando las nuevas herramientas de visualización, más potentes y sencillas que
las usadas de manera tradicional.

23/33
 Proyectos de Big Data

Los perfiles clave en estos proyectos son:

Analista funcional, que es el encargado de hablar con negocio para definir todos los
requisitos.
Arquitecto Big Data, que es el encargado de definir cada una de las diferentes herramientas del
ecosistema Big Data que se van a utilizar.
Desarrollador Big Data, que es el encargado de implementar los requisitos de acuerdo con la
arquitectura.
Ingenieros de pruebas, que pueden ser los desarrolladores, aunque es importante que un
desarrollador no valide su propio código. Deben escribir los planes de pruebas que deben
validar tanto el analista funcional como el arquitecto.

8.2 Proyectos de ciencia de datos

Los proyectos donde el objetivo es la construcción de un sistema predictivo, es decir, un sistema
basado en aprendizaje automático, hay que afrontarlos de manera diferente.

Lo primero que es importante destacar en este tipo de proyectos es que están liderados por el área de
negocio o por la alta dirección. Es decir, en general tienen un carácter táctico o estratégico.

Estos proyectos pueden tener varios objetivos:

Mejora en la toma de decisiones

Queremos saber qué es lo más probable para poder tomar mejores decisiones. Este tipo de proyectos
son normalmente regresiones.

Mejorar un proceso

Negocio identifica un proceso en el que cree que puede mejorar usando el aprendizaje automático;
por ejemplo, queremos saber a qué clientes les puede interesar un nuevo producto. Queremos mejorar
nuestro proceso de detección de fraude o riesgos.

24/33
 Proyectos de Big Data

Mejorar en procesos digitales

En este caso, la empresa que tiene un sistema, por ejemplo de e-mail marketing, quiere desarrollar un
sistema que identifique los intereses de cada cliente para poder ofrecerles aquellos productos o servicios
en los que están interesados.

Cuando negocio ha definido cuál es el objetivo del proyecto, debe identificar varios aspectos que son
fundamentales:

Qué precisión
El primer aspecto fundamental es qué precisión o qué métricas debe alcanzar el modelo para ser útil a
negocio. Ponemos varios ejemplos para entender mejor este punto:

Pongamos que negocio quiere conocer las ventas del próximo mes; con esta información
puede definir no solo los inventarios necesarios sino también la cantidad de empleados que
debe contratar. Los procesos actuales que sigue la compañía tienen una desviación del 14 %
aproximadamente. Para que este sistema sea válido para la toma de decisiones, debe tener una
precisión de al menos el 10 %.
Pongamos que el equipo de marketing lanza campañas a 15.000 potenciales clientes, pero
tiene un éxito de solo el 4 %. El sistema debe en este caso ser capaz de encontrar un conjunto
de clientes potenciales, como máximo de 15.000, pero en el que al menos un 6 % compre el
producto.

Lo que estamos describiendo, de manera informal, es el retorno de la inversión; es decir, cuánto

puedo ganar si el sistema mejora un tanto por ciento mi proceso actual.

Fuentes de datos

El segundo aspecto son las fuentes de datos para solucionar el problema. Como hemos visto
anteriormente, los científicos de datos son expertos en estadística y aprendizaje automático, pero no en
negocio. Por ello, es clave que se identifiquen las fuentes de datos y los datos que son o pueden ser
relevantes para el problema.

Con esta información podemos poner en marcha un proyecto de aprendizaje automático. Vamos a ver
los pasos que debemos seguir:

25/33
 Proyectos de Big Data

Construcción del set de datos

Este es el punto de partida de cualquier proyecto basado en datos. Debemos evaluar cuánto esfuerzo
y qué perfiles necesitamos para la construcción del conjunto de datos. El esfuerzo puede ser casi 0, si
hablamos de obtener los datos de una base de datos o de un lago de datos mediante un script Hive o
SQL, o muy alto si tenemos que obtener datos de diferentes fuentes, internas y externas, y tratar con
diferentes tipos de datos (recordemos que existen los estructurados, semiestructurados y no
estructurados). Por ejemplo, si queremos identificar los tipos de coches que pasan por un determinado
punto de la carretera donde tenemos una cámara, debemos etiquetar cada imagen con el tipo de coche;
este esfuerzo debemos tenerlo en cuenta. Otro caso muy común es que las fuentes de datos sean
diferentes y debamos hacer una labor importante para obtener los datos.

Limpieza del set de datos

En esta fase debemos limpiar los datos y agregarlos. Normalmente no todos los datos son válidos,
hay valores que faltan o datos que no tienen sentido para el negocio. En esta fase también definimos
cómo vamos a unir las diferentes fuentes, cómo vamos a tratar las variables categóricas, política de
datos faltantes, valores por defecto o normalización de variables.

Estudio del set de datos

En esta fase se estudian los datos, correlaciones con la variable objetivo, distribuciones, poder
predictor de las variables (cuáles son más importantes). Si tenemos un conjunto de datos suficiente, si
es un conjunto de datos balanceado o no balanceado. En el caso de un conjunto de datos no
balanceado, debemos construir un conjunto de datos de entrenamiento que lo sea, es decir, que
proporcione suficientes ejemplos de ambas clases para que el algoritmo pueda aprender (este problema
se da en clasificación).

Prueba de modelos sobre el set de datos

En función del problema que tengamos, debemos identificar qué algoritmos son los más idóneos para
resolverlo. Siempre tenemos, como referencia para identificar si hemos tenido éxito, las métricas
identificadas por negocio. Normalmente se comienza por los algoritmos más sencillos, como regresión
lineal, y se van probando diferentes algoritmos hasta obtener los resultados esperados por negocio. No
es muy aconsejable comenzar por algoritmos de caja negra como redes neuronales, ya que estos
algoritmos no nos permiten saber qué variables son las más importantes.

Evaluación de modelos

En esta fase aplicamos siempre validación cruzada, ya que el objetivo de cualquier algoritmo es
funcionar de manera óptima con ejemplos que el algoritmo no ha visto. Es decir, que el algoritmo no
tenga bajo aprendizaje o sobreaprendizaje.

26/33
 Proyectos de Big Data

Ingeniería de características

En las primeras iteraciones no se suelen obtener los resultados esperados por negocio, por ello es
necesario explorar los datos, inferir nuevas variables y hablar con negocio para identificar más variables
que son importantes para resolver el problema.

Necesidad de un set de datos más grande

En ocasiones, el problema que tenemos no es que necesitemos más variables, sino que no tenemos
un conjunto de datos lo suficientemente grande como para que el algoritmo pueda aprender de manera
correcta. En este escenario, debemos obtener más datos. Por ejemplo, si estamos con una serie
temporal, conseguir otro año más de datos o, en el caso de detección de tipos de coches, etiquetar más
imágenes.

Debemos tener en cuenta que este tipo de proyectos son muy intensivos en cálculos. Los entornos
necesarios vienen definidos por tres factores fundamentales:

1. La cantidad de ejemplos en el conjunto de datos.

2. Las variables de cada ejemplo.
3. El algoritmo seleccionado.

Es habitual encontrarnos en situaciones en las que no hemos definido de manera correcta las
necesidades de computación y cada prueba nos puede llevar entre tres y nueve horas. Este factor es
importante y las alternativas más habituales son usar GPU (actualmente por 800 € tenemos GPU muy
potentes) o servicios en la nube.

En este tipo de proyectos, por su naturaleza no determinística, no es posible decir si vamos a cumplir
con los requisitos de negocio antes de comenzarlos. Este riesgo siempre existe y hay que tenerlo en cuenta.
Por ello, una práctica habitual es realizar una prueba de concepto antes de lanzar el proyecto completo; de
esta manera, podemos saber en un espacio de entre tres semanas y dos meses, según la complejidad, si
podemos resolver el problema que plantea negocio.

IX. Resumen

Un gran número de proyectos que se desarrollan en Big Data se definen como proyectos no
exitosos. Los principales factores clave para ello son:

Objetivos tecnológicos no alineados con negocio.

Objetivos no claros.
Falta de visión del programa Big Data a largo y medio plazo.
Falta de compromiso de la dirección.
Falta de talento.

27/33
 Proyectos de Big Data

Los procesos internos para el acceso a la información, en muchas ocasiones, dificultan

la obtención de los datos para poder explotarlos.

Profundizando más en los proyectos, los anteriores factores podemos situarlos más en la parte
estratégica y organizacional. Dentro de los proyectos Big Data, debemos contemplar dos factores
clave para el éxito:

Calidad del dato, que tiene como objetivo garantizar la consistencia, completitud y
precisión del dato.
Gobierno del dato, que tiene como objetivo garantizar la veracidad del dato, gestión de
accesos, políticas que garanticen la disponibilidad del dato, políticas que garanticen el
cumplimiento de todas las normativas aplicables, políticas de trazabilidad y auditoría.

Hemos comentado la importancia del talento para poder afrontar un proyecto Big Data con
garantías. Enumeramos los perfiles que se deben tener en cuenta a la hora de abordar un proyecto
Big Data:

Arquitecto Big Data. Definir las herramientas que vamos a utilizar de todas las que
existen en el ecosistema Big Data, si usaremos la nube o soluciones desplegadas en
nuestro centro de datos. Definir cómo se configuran e interactúan todas las herramientas
dentro de la arquitectura.
Ingeniero de datos. Especialista en una o varias de las tecnologías Big Data, es el
responsable de la implementación del proyecto.
Científico de datos. Es el responsable de limpiar los datos, identificar las características
claves y seleccionar los modelos con mayor precisión para resolver el problema.

Todo proyecto Big Data se compone de cinco fases que debemos tener en cuenta:

a. Fuentes de datos. El primer paso es siempre identificar las fuentes de datos que van a
ser parte del proyecto; debemos estudiar el problema o proyecto en detalle e identificar
todas las fuentes que aportan información o son necesarias para poder solucionar el
problema. Recordemos que debemos asegurar la calidad del dato y cumplir con la
política del gobierno del dato.
b. Adquisición de datos o ingesta. Esta fase consiste en almacenar los datos de las
fuentes de datos en nuestro lago de datos.
c. Almacenamiento del dato. Nuestro lago de datos se puede almacenar en HDFS, pero
también podemos usar otras tecnologías como bases de datos NoSQL, que ya hemos
visto.
d. Tratamiento del dato. Debemos transformar los datos en conocimiento, es decir,
cumplir con los requisitos definidos. Para ello podemos usar diferentes tecnologías:
Hadoop, Hive, Pig, Spark.
e. Visualización. Una vez transformado el dato, debemos trabajar los datos en crudo para
transformarlos en información y conocimiento, debemos visualizar los datos para
facilitar el análisis y la toma de decisiones basada en datos.

Una vez conocemos las fases de un proyecto Big Data, es importante tener en cuenta los
entornos necesarios para poder afrontar un proyecto Big Data.

28/33
 Proyectos de Big Data

El desarrollo unitario se realiza en el ordenador de cada desarrollador, cada

desarrollador tiene su entorno de desarrollo local. Una buena práctica que se está
extendiendo es el uso de dockers, anteriormente se usaban máquinas virtuales.
Clúster de desarrollo. La finalidad de este clúster es que los desarrolladores, una vez
han probado su código, realicen las pruebas en un clúster real. Normalmente los
entornos de desarrollo no simulan la complejidad del entorno distribuido de manera fiel.
Es importante tener una buena política de ejecución en paralelo (esto también se puede
conseguir usando dockers ) ya que, si bien podemos configurar el clúster para que
ejecute varios procesos en paralelo, la realidad es que no resulta muy efectivo y puede
generar cuellos de botella.
Clúster de producción. Es el clúster donde se ponen las aplicaciones en producción;
solo las aplicaciones o releases aprobadas pueden ir a producción.
Clúster de QA. Es un espejo del clúster de producción (aunque de dimensiones más
pequeñas), donde se hacen las pruebas de aceptación de las aplicaciones y las pruebas
de migración de versiones de las herramientas del ecosistema Big Data.

No son pocas las empresas que tienen un único clúster tanto para desarrollo como para
producción, lo cual genera problemas ya que tenemos un conflicto claro de recursos. Si es
posible, hay que intentar evitarlo y tener al menos dos clústers: el de producción y el de desarrollo
(es más sencillo usar el de desarrollo para pruebas y calidad que tener uno solo).

Los proyectos de Big Data se pueden clasificar en dos grandes grupos: aquellos que se basan
en la captación masiva de datos (internos y externos), agregación, tratamiento, obtención de
conocimiento y visualización para la toma de decisiones; y aquellos basados en la creación de
modelos predictivos.

29/33
 Proyectos de Big Data

Ejercicios

Caso práctico
Un cliente del sector público en Colombia quería abordar un proyecto de gobierno del dato. Había
generado un plan estratégico donde se habían definido diez objetivos marco. Uno de ellos era hacer un
mejor uso de la información, convirtiéndola en un activo, y generar nuevas capacidades basadas en los
datos.

En definitiva, el cliente quería extraer mayor valor, generar más beneficio de los datos de los que
disponía y detectar nuevas fuentes de datos que pudieran ser de interés para su negocio.

Para arrancar la iniciativa, el área de innovación contrató una consultoría de gobierno del dato para
definir el programa de gobierno que debía regir su actividad en los siguientes tres años. El área de
innovación era una dirección intermedia, con un poder de ejecución limitado, pero a cargo de todos los
proyectos de transformación del cliente.

El proyecto consistía en tres fases:

Análisis de la situación actual. Analizar la estructura de datos que actualmente tiene el cliente, para
encontrar los puntos críticos, y analizar con las diferentes áreas de negocio e IT los requisitos y
necesidades en el ámbito del dato. En función de esto, se define el punto de madurez actual.
Definición del modelo objetivo. Se define el escenario objetivo al que el cliente debe aspirar y la
distancia entre el grado de madurez actual y el grado de madurez futuro al que deben aspirar. En
este apartado, además, se debían definir las primeras políticas y procedimientos de gobierno del
dato que marcaran las bases para los futuros proyectos.
Roadmap de proyectos. En función de la distancia entre la madurez actual y futura, definir el plan
de proyectos consensuado a tres años para evolucionar del estado actual al futuro. En esta fase
debían definirse quickwins, requisitos técnicos y caso de uso para implantar.

El proyecto arrancó en la línea de las fases definidas, pero durante la definición del modelo objetivo, los
objetivos del cliente pivotaron. La importancia de definir un modelo objetivo óptimo que rigiera la línea de
trabajo de los siguientes tres años cambió: el objetivo principal se convirtió en definir las políticas y
procedimientos y generar un inventario informacional de todos los datos que tenía la entidad.

A pesar de los problemas que esto acarreó, se desarrollaron los trabajos completos y se presentó tanto
el modelo objetivo como el roadmap consensuado a la alta dirección. Uno de los mensajes clave que se
transmitió en el proyecto era que la iniciativa de gobierno del dato no podía entenderse como un proyecto
sino como un proceso de mejora, cuya fase crítica eran los tres años definidos, donde debía darse el
cambio cultural, el cambio organizacional y tecnológico necesario.

Pasados los meses, las diferentes iniciativas no se iniciaron. En los siguientes presupuestos aprobados,
no se liberó ninguna partida para el ámbito de gobierno del dato y durante dos años el plan definido y
consensuado no se llevó a cabo.

El proyecto, a priori, estaba bien enfocado y bien ejecutado, pero en realidad no se pudo considerar un
éxito ya que el cliente no implantó finalmente una política de gobierno del dato.

30/33
 Proyectos de Big Data

Resumiendo, algunos de los problemas encontrados fueron:

Se definió el plan de gobierno del dato integral, pero no llegó a ponerse en práctica.
Los cambios tecnológicos que debían seguir al plan de transformación no se abordaron
siguiendo las recomendaciones marcadas sino con una aproximación de coste 100 %, es decir,
minimizar toda inversión en el plan de gobierno debido a que no existía presupuesto para ello.
Los aspectos de calidad del dato implicaban aspectos legales que dificultaron enormemente
poder implantar políticas agresivas de corrección de información.

Se pide
¿Cuáles crees que fueron las causas que hicieron que el proyecto no pudiera llevarse a una fase de
implantación del plan de gobierno del dato?

Posible solución
Algunas de las causas fueron:

Aproximación basada en el proyecto y no en el proceso. Es decir, a pesar de informar y

comunicar que la política de gobierno del dato es un proceso que debe apoyarse en proyectos
para madurar, se le dio un enfoque completo de proyecto, sin abordar cambios culturales
posteriores.
Falta de presupuesto para abordar las siguientes fases del plan. La falta de presupuesto no es
tanto una causa en sí misma, sino una consecuencia, debido a un mal sponsor del proyecto,
como veremos a continuación.
El sponsor en un proyecto de gobierno del dato debe ser un perfil de alta dirección, capaz de
transmitir los cambios organizativos y de estrategia definidos en el plan y empujar hacia la
consecución de los cambios.
Aproximación técnica generalista primando el coste tecnológico sobre la eficiencia. Se esperaba
desarrollar toda la política de forma manual, evitando cualquier inversión técnica, pero
incrementando exponencialmente el coste en servicios. Una política de gobierno del dato debe
basarse en la eficiencia y buscar los mecanismos para que su integración sea lo más suave
posible, evitando grandes cargas de trabajo manuales. Habitualmente se requieren herramientas
que faciliten la adopción y ejecución del plan. Una aproximación “manual” va a requerir tal
esfuerzo de implantación que hará inviable la ejecución del plan propuesto.
Beneficio: es necesario disponer de una medida clara del beneficio aportado, ya sea en reducción
de costes, nuevos servicios, agilidad, mitigación de riesgo… y cada proyecto dentro del proceso
de gobierno debe tener definidos de forma muy clara el impacto y el beneficio que aporta en los
ejes de gobierno.

31/33
 Proyectos de Big Data

Recursos

Bibliografía
Data Lake Development with Big Data. : Pasupuleti, P.; Purra, B. O'Reilly Media; 2015.
Data Lake for Enterprises. : John, T.; Misra, P. Packt Publishing; 2017.
The Enterprise Big Data Lake, Delivering on the Promise of Hadoop and Data Science
in the Enterprise . : Gorelik, A. O'Reilly Media; 2016.
Understanding the Chief Data Officer. : Steele, J. 2nd edition. O'Reilly Media; 2017.

Glosario.

Consumers: Consumidores de información.

CRM: Sistemas de gestión comercial.

Data Owner: Dueño del dato, se trata de la persona con máxima responsabilidad sobre la
información.

Data Stewarship: Custodio del dato, es el encargado de aplicar las políticas definidas por el
Data Owner.

Datamart: Vista de los datos, normalmente de un Datawarehouse, enfocada en una visión

específica para un área de negocio.

Datawarehouse: Es un repositorio unificado para todos los datos que recogen los diversos
sistemas de una empresa. Habitualmente el Datawarehouse o DWH se refiere al repositorio de
datos estructurados y explotados con sistemas de Business Intelligence tradicional.

ERP: Sistemas de información gerenciales que integran y manejan muchos de los negocios
asociados con las operaciones de producción y de los aspectos de distribución de una
compañía.

Industria 4.0: El nuevo paradigma de digitalización y transformación que se está dando

dentro del sector de la industria, con la aplicación de Big Data, Analytics y sensorización.

32/33
 Proyectos de Big Data

KPI: Indicador clave de rendimiento. Se usa para definir elementos medibles y monitorizables.

NoSQL: Toda base de datos que no sigue el paradigma SQL y que puede manejar
información no estructurada.

NRT: Near-real-time, se refiere a los procesos en streaming en Big Data que proporcionan una
respuesta con muy baja latencia, pero no llegan al nivel de un tiempo real puro.

Release: Salida a producción de una versión de producto.

SLA: Acuerdo de nivel de servicio, sirve para definir y medir la calidad de un proceso.

SQL: Lenguaje de consultas de la mayoría de las bases de datos relacionales. Bases de datos
SQL son las bases de datos tradicionales o transaccionales que manejan datos estructurados.

Stakeholders: Significa “interesados” y es un término usado para definir todas las áreas
interesadas en un proyecto.

Streaming: Capacidad de procesamiento de datos en el momento en el que llegan. A

diferencia de un sistema batch, donde el tiempo de procesamiento se marca de forma fija a una
hora o intervalos, en streaming el tiempo de procesamiento se define con la llegada de los datos o
eventos.

33/33