El Data Analysis Lifecycle que todo Data Analyst debería conocer

data analysis lifecycle

Se acerca el t3chfest 2019 y, como aperitivo, el pasado 25 de febrero tuve el placer de participar en un warm-up del evento dando una charla sobre el ciclo de vida del análisis de datos (Data Analysis Lifecycle). Este meetup se organizó conjuntamente con Developer Circles en las oficinas de Facebook en Madrid.

En la charla compartimos nuestra visión sobre las distintas fases que conforman un ciclo de análisis de datos, haciendo hincapié en la importancia de cada una de ellas de manera individual y en cómo estas etapas están relacionadas entre sí a lo largo de todo el proceso analítico. En este artículo vamos a repasar los tips más importantes visto en este meetup. ¡Vamos a ello!

El ciclo de vida de un análisis de datos se divide en las siguientes etapas:

  1. Toma de requisitos y fuentes de datos
  2. EDA (Exploratory Data Analysis)
  3. Modelo de Datos y Arquitectura
  4. Dataviz
Las 4 fases del ciclo de vida del análisis de datos #dataanalytics #datascience Clic para tuitear

1. Toma de requisitos y fuentes de datos

Partimos del escenario en el cual un Product Owner tiene la necesidad de realizar un análisis sobre un conjunto de datos que disponibiliza a través de varias fuentes.

En esta primera etapa, para la toma de requisitos y requerimientos del análisis han de tomar partido tanto un Data Analyst, que liderará el análisis y la visualización del dato, como un Data Engineer, que será la persona responsable de la transformación e ingesta en el modelo de datos.

Los datos pueden ser disponibilizados a través de distintos tipos de fuentes u orígenes: ficheros de texto en formato csv o tabular (y que podrían ser accesibles a través repositorios cloud como Amazon S3), bases de datos relacionales (Postgre, SQL server, MySQL…), bases de datos analíticas (Redshift, BigQuery…) o bases de datos no relacionales (MongoDB, Cassandra).

Fuente: Keepler

Una vez tomados los requisitos del análisis, y una vez disponibilizadas las distintas fuentes a través de las que realizaremos el análisis, ya tendríamos todo lo necesario para ponernos manos a la obra y empezar a transformar e ingestar los datos de las fuentes sobre un modelo de datos para posteriormente visualizarlo, ¿verdad? Error.

Debemos ser escépticos desde el minuto 0 con los requisitos tomados, las fuentes disponibilizadas e incluso con el análisis/problemática planteado. Poner en duda y trabajar sobre el formato, estructura y calidad de las fuentes, o revisar el planteamiento del ejercicio y de los requisitos, está enfocado a lograr un análisis robusto y de calidad. Pero ser escéptico no implica desconfianza; es fundamental que tanto Product Owner, Data Analyst y Data Engineer trabajen desde el inicio de manera conjunta, comunicativa y transparente en todas las etapas del ciclo para lograr un análisis exitoso

roles analitica de datos
Fuente: Keepler

¿Cómo vamos a trabajar este escepticismo? Mediante EDA (Exploratory Data Analysis).

2. Exploratory Data Analysis (EDA)

Esta etapa es fundamental para ejecutar un buen análisis. Mediante técnicas de análisis exploratorio analizaremos las distintas fuentes, mediremos la calidad y consistencia del dato, confirmaremos (o no) si el análisis planteado por el Product Owner es correcto o tiene sentido. Además, podremos proponer otros prismas de análisis complementarios al inicial que aportarán valor al conjunto del ejercicio.

Conseguiremos ser eficientes y nos ahorraremos disgustos al darnos cuenta en una fase muy temprana del ciclo si el análisis no está correctamente planteado o si las fuentes son inconsistentes o incompletas. No esperaremos a ingestar los datos transformados en un modelo de datos o visualizar los datos de este modelo para darnos cuenta que algo no va bien (con todo el coste que ello conlleva).

¿Cómo vamos a realizar este EDA? Mediante lenguajes como R o Python y a través de plataformas como RStudio o Jupyter Notebook.

herramientas EDA
Fuente: Keepler

Este ejercicio lo dividiremos en dos partes: por un lado mediremos la calidad/consistencia del dato mediante técnicas de data cleansing, y por otro lado, comprobaremos si el planteamiento del análisis es correcto a través de visualizaciones/plots de librerías como matplotlib (python) o ggplot (R )

Las inconsistencias en el modelo o errores de formato los dividimos en dos grupos:

  • Datos con errores de formato: NA’s, datos erróneos, formatos erróneos, constantes, duplicados, categorización errónea…
  • Datos con errores de intuición: Outliers, segmentación errónea… Son datos que contradicen el planteamiento, escenario o hipótesis inicial del análisis.

Mediante plots comprobaremos el contexto de los datos y comprobaremos si está alineado con el análisis.

Veamos un ejemplo sencillo con la imagen a continuación que corresponde a una visualización de un dataset con información histórica de los Juegos Olímpicos. Se podría haber planteado inicialmente analizar el papel de hombres y mujeres en la historia de los juegos partiendo de la base que siempre ha habido participación de ambos sexos. En este gráfico de ggplot podemos observar que las mujeres empezaron a participar en los Juegos a partir de 1912, contradiciendo la premisa inicial y teniendo que replantear el ejercicio.

visualización dataset
Fuente: Keepler

¿Qué conseguimos tras el EDA?

  • Analizamos las distintas fuentes de datos.
  • Limpiamos y normalizamos los datos: mejoramos calidad del dato.
  • Vemos si en análisis es viable o no.
  • Profundizamos en los datos: aportamos valor proponiendo un análisis 2.0.
  • Aumentamos el conocimiento del dato.
  • Aumentamos el conocimiento del contexto del dato.
  • Allanamos el camino para definir el modelo y su arquitectura.

Genial, ¿verdad?

Hemos tomado nota del análisis a realizar y de los requerimientos, se nos han disponibilizado las fuentes que hemos explorado, limpiado y estudiado. Ahora sí que podemos avanzar con garantías a la siguiente etapa: el modelo de datos.

3. Modelo de datos y arquitectura

Según la cantidad de datos a explotar, la tipología del análisis a realizar y la naturaleza de las fuentes, debemos elegir: nuestro modelo de datos, la base de datos a través de la cual consultaremos la información y la arquitectura sobre la que se asentará el modelo.

Nuestro modelo puede ser un modelo relacional (modelo en estrella o copo de nieve), enfocado a análisis con bajas volumetrías de datos, o columnar (tablón) si nuestro análisis es a gran escala (teras de datos).

Los análisis sobre modelos relacionales suelen realizarse a través de una base de datos OLTP (OnLine Transaction Processing) como MySQL o PostgreSQL. De cara a analizar grandes volumetrías de datos debemos utilizar bases de datos analíticas (OLAP, On-Line Analytical Processing) como Amazon Redshift o Google BigQuery.

Según la volumetría de datos tenemos tres tipologías de arquitectura: Datamart, Datawarehouse (DWH) y Datalake:

arquitecturas analitica datos
Fuente: Keepler

Un Datamart es una estructura sobre un modelo relacional de baja volumetría que explotaremos mediante bases de datos OLTP. Un DWH es un conjunto de Datamarts relacionados entre sí (en una única base de datos) cuya volumetría implicaría la necesidad de un análisis mediante una base de datos analítica. Un Datalake es una infraestructura con gran cantidad de datos que pueden o no estar estructurados. Si bien es cierto que en un Datalake pueden convivir Datamarts y DWH, su base principal es un filesystem. Un ejemplo de filesystem es el repositorio S3 de AWS.

Desde el punto de vista analítico, trabajar con plataformas cloud como AWS, Google Cloud Platform o Azure de Microsoft contemplamos estas ventajas:

  • Coste por uso: control de costes, solo de la infraestructura que realidad utilizas.
  • Privacidad y seguridad: plataformas físicamente muy seguras en la que existe una responsabilidad compartida con la plataforma. El usuario es responsable de gestionar la seguridad en el acceso y distribución de los datos (data governance).
  • Escalabilidad: se disponibiliza más o menos potencia de cómputo según la volumetría de datos sobre la que realizar el análisis, en la muchos casos de forma automática.

Ya tenemos transformados e ingestados nuestros datos en el modelo y arquitectura definida. Siguiente paso: visualización del dato.

4.Dataviz

Podemos optar por tres vías para analizar y visualizar nuestra información:

tipos dataviz
Fuente: Keepler
Modelo autogestionado

Hace referencia a las herramientas de Business Intelligence comerciales (Microstrategy, Power BI, Tableau…) mediante las cuales se pueden realizar análisis a distintos niveles de detalle. Están pensadas para todo tipo de usuarios, ya tengan mayor o menor background técnico o de negocio. Son herramientas que vienen preparadas con un conjunto de suites (all in one) con las que trabajaremos sin necesidad de tener que realizar desarrollos a medida en primera instancia. Es, por lo tanto, un modelo “rígido”. De todos modos, las herramientas son cada día más completas y nos ofrecen cada vez mayores funcionalidades.

dataviz autosgestionado

Según el nivel de análisis y expertise de usuario final, las visualizaciones las podemos definir en tres grupos:

  • Dashboards: Análisis alto nivel para todo tipo de usuarios.
  • Documents/Reports: Nivel intermedio de análisis con información más detallada. Se requiere expertise medio de la herramienta y el modelo de datos/negocio.
  • Autoconsumo: Enfocado para análisis a medida de nuestro modelo de datos/entorno. Se requiere un alto nivel de conocimiento de la herramienta, del modelo y del contexto del dato.
Modelo Do It Yourself (DIY)

En contrapartida a las herramientas de BI, el modelo DIY está enfocado en realizar visualizaciones ad hoc que requieren un desarrollo completo (por ejemplo, D3.js). Pensado más para un frontal web o análisis particular que para un informe enfocado a la consulta y productivizado cuyos datos evolucionan a una línea temporal.

dataviz DIY

Modelo híbrido

Por último, existe una metodología para realizar visualizaciones y análisis que ocupa un lugar intermedio entre los dos puntos que hemos visto anteriormente. Con librerías como Shiny de RStudio desarrollaremos visualizaciones interactivas a medida en un entorno plataformado mediante el cual podremos administrar las fuentes y a los usuarios.

dataviz hibrido

¿Y ahora, qué?

Si bien es cierto que hemos llegado al final de nuestro análisis con éxito y hemos dado respuesta a las preguntas que nos planteaba el Product Owner inicialmente, el análisis como tal no tiene porqué haber llegado a su final.

En el futuro se podrían disponibilizar nuevas fuentes de datos cambiando el escenario inicial a todos los niveles o se podría cambiar el enfoque del análisis ante un nuevo contexto de los datos, impactando a alguna de las fases directamente, y reactivando todo el proceso.

En definitiva, un análisis puede ser dinámico, cambiante y evolucionar a lo largo del tiempo.

ciclo analitica datos
Fuente: Keepler

Bola extra

¡El 15 de marzo estaremos en el t3cfhest! No os perdáis las charlas de nuestros compañeros Data Scientists:

Por último, te compartimos la presentación del meetup que te hemos desarrollado en este post: Data Analysis Lifecycle, por Marcos Sobrino.

Imagen: pexels

Data Analyst en Keepler. “Ingeniero apasionado de los datos y el BI. Como Data Analyst, la parte que más me gusta de mi trabajo es poder encontrar la mejor forma de analizar y mostrar la información. En los proyectos de los que formo parte, considero indispensable formar un equipo basado en la confianza y la buena comunicación entre los especialistas en las distintas áreas”

Port Relacionados

¿Qué opinas?

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.