Proyectos de Big Data

© EDICIONES ROBLE, S.L.

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

2/29
 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.

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

3/29
 Proyectos de Big Data

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.
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.

4/29
 Proyectos de Big Data

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: [Link]
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.
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.

5/29
 Proyectos de Big Data

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.

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.

6/29
 Proyectos de Big Data

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.

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:

7/29
 Proyectos de Big Data

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.

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:

8/29
 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.

9/29
 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.
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.

10/29
 Proyectos de Big Data

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

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).

11/29
 Proyectos de Big Data

c. Conocimiento del negocio. Debe conocer el negocio, debe saber qué es importante para cada problema
de negocio.

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.

12/29
 Proyectos de Big Data

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.

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.

13/29
 Proyectos de Big Data

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.

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.

14/29
 Proyectos de Big Data

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.

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.

15/29
 Proyectos de Big Data

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.

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.

16/29
 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.

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.

17/29
 Proyectos de Big Data

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.

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:

18/29
 Proyectos de Big Data

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.

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.

19/29
 Proyectos de Big Data

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.

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.

20/29
 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.

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.

21/29
 Proyectos de Big Data

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:

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.

22/29
 Proyectos de Big Data

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.

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.

23/29
 Proyectos de Big Data

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.
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.

24/29
 Proyectos de Big Data

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.

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.

25/29
 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.

Resumiendo, algunos de los problemas encontrados fueron:

Se definió el plan de gobierno del dato integral, pero no llegó a ponerse en práctica.

26/29
 Proyectos de Big Data

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.

27/29
 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.

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.

28/29
 Proyectos de Big Data

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.

29/29