Cuando vemos una casa bonita, con buena arquitectura , jardinería bien cuidada e iluminación en su punto lo que menos nos preocupa es cómo está la casa en su plomería y en los cables que hacen que esa iluminación y jardín se vean de primera. Al final tenemos contacto con los interiores y la fachada de la casa ¿Por qué debería de importarme? Bueno si en lugar de una casa habláramos de una plataforma increíble de mapas o dashboard… seguramente tendríamos que entender cómo funciona para poder construir uno para nosotros igual de funcional.
En esta columna hablaremos de la arquitectura para proyectos de datos y cómo funciona la plomería que hace viajar los datos desde su fuente hasta los puntos de consumo por los usuarios.
¿El contexto para el «aprovechamiento de los datos» ?
Desde hace un par de años decidimos comenzar nuestros diálogos sobre data science en foros nacionales con un gráfico así. Nuestra urgencia era comunicar por qué les debería de importar aprovechar todos esos datos que las organizaciones generan.
Ahora, no es tan necesario hablar de esto, la transformación digital a vuelto a los datos los protagonistas del cambio. No hay organización respetable que quiera «dejar valor en la mesa» y no esté ocupando un porcentaje de su tiempo en capitalizar el valor de los datos.
Mencionamos esto como contexto de la columna, el aprovechamiento de los datos muchas veces es dialogado de la parte cultural… pero ¿Cómo perderle el miedo a tratar de entenderlo desde la perspectiva técnica? Esperemos esta columna te apoyo a eso
¿Cómo funciona la plomería detrás de un proyecto de aprovechamiento de datos?
Un proyecto de aprovechamiento de datos para medianas y grandes cantidades de datos se puede ilustrar de la siguiente manera.
- Existen datos de negocio de distintas fuentes. Puede ser puntos de venta transaccionales, ventas, información adquirida vía terceros (por ejemplo de clima de IBM o negocios de Google Places), de redes sociales, entre otras
- Estos datos tendrán entrada a nuestros sistemas de información mediante una copia que se dirige a un repositorio de datos denominado «Data Lake» o «Lagos de datos». En este punto la información es de todo tipo y con estructuras diferenciadas
- A partir de ahi es importante limpiar, estructurar e integrar las bases de datos de una manera en que puedan ser «consumibles» para nuestros proyectos de datos. Por ejemplo, si tenemos datos de clima y de negocio, podríamos generar una base de datos a nivel código postal o suburbio y cruzar estos 2 datos enlazados a una misma zona de la ciudad. Este proceso puede suceder via un ETL (Extract – Transform – Load ; Extraer – Transformar – Cargar) que son pasos programados para que los datos puedan ser casi listos para ser usados
- Los datos procesados por el ETL serán ahora información. Esta información podrá ser almacenada en un repositorio llamado «Data Warehouse». A diferencia del «Lago de datos», en este «Warehouse» la información compartirá estructura y habrá una mayor homologación entre los sistemas numéricos en los que se registran las variables
- Estos registros pueden pasar por pasos de «agregación» en donde se hacen sumatorias. Por ejemplo, en el «Warehouse» podríamos tener los registros de toda una semana de una tienda. Pero en la agregación, tendríamos la sumatoria de transacciones por día para poder realizar graficas de resultados diarios
- Esa agregación la podemos llevar directo a plataformas como dashboards o si queremos manejar cierta discrecionalidad en la información podemos manejar «Data Marts». Por ejemplo, si queremos que el área de Logística sólo vea información operativa y no financiera podremos generar un Data Mart para aislar los datos y habilitar la construcción de tableros sólo con los datos que les corresponde visualizar
Te podrá interesar nuestras otras columnas: Qué es un ingeniero de datos en el diseño de perfiles de equipos de datos o cómo construir iniciativas de datos
¿Cómo varía por tecnología?
Estas rutas pueden variar por cada tecnología. Pero es válido decir que la mayoría de estas etapas se podrían cumplir en cada tecnología.
A continuación te compartirnos una imagen muy interesante que encontramos sobre los «pipelines» y contrastes entre:
- AWS (amazon web services). De Lambda y S3 hasta Quicksight
- Microsoft. De AZURE a PowerBI
- Google. De big query a Data studio
Cuéntanos en @DatlasMX ¿Qué arquitectura preferirías o prefieres para tus proyectos de aprovechamiento de datos?
Hasta aqui la columna de hoy, gracias por leerla y te recomendamos suscribirte a nuestro podcast para seguir aprendiendo de datos y analítica. Conoce más en https://linktr.ee/datlas
Equipo Datlas
– Keep it weird-
Otras fuentes
Blog Datlas 
Pingback: 4 Metodologías para proyectos de Data Science – INVESTIGACIÓN DATLAS | Blog de www.datlas.mx
Pingback: 5 Tendencias DE datos para gerentes de analytics – datlas investigación | Blog de www.datlas.mx
Pingback: 1 mes usando la mac mini apple (2020) para data science y edición de multimedia – datlas | Blog de www.datlas.mx
Pingback: Descubre nuestra experiencia desarrollando Dashboards con Microsoft Power BI- COLUMNA DE OPINIÓN DATLAS – Blog Datlas
Pingback: Estándares de calidad para Datos (Data quality standards) – Investigación Datlas – Blog Datlas
Pingback: Los datos, proyectos de datos y su Flujo – Manuales DATLAS – Blog Datlas
Pingback: El poder de los datos en la experiencia del cliente: ¿Cómo implementar una estrategia efectiva? – Datlas Columnas de Opinión – Blog Datlas
Pingback: La Evolución del Almacenamiento en las Bases de Datos a lo Largo del Tiempo – Investigación Datlas – Blog Datlas