Categories
54cuatro

¿El ETL va camino a desaparecer?

Tremendo título marketinero, ¿no?

Por lo general, cuando los gurús pronostican este tipo de cambios tan drásticos suelen equivocarse feo, quedó demostrado durante la pandemia y el término “nueva realidad”.

Los cambios pueden ser graduales, pero rara vez un cambio viene dado por la desaparición completa de algo.

La realidad, es que el #ETL viene presentando varios cambios. Quizás el más significativo es el concepto de #ELT que viene empujado por las arquitecturas de #DataLake.

Escribimos varias notas de ETL y ELT. Pero ahora vamos a hablar del “ETLess” o Zero ETL.

#ZeroETL es un enfoque que busca reducir o eliminar la necesidad de realizar una extracción, transformación y carga (ETL) de datos en un proceso de análisis de datos. O al menos la necesidad de hacerlo de forma manual.

Por ejemplo, #Databricks y #Snowflake vienen trabajando en simplificar los procesos de Extracción, Transformación y Carga. Tanto Snowflake como Databricks tienen soluciones que se enfocan en reducir la complejidad y la necesidad de ETL tradicional.

Snowflake tiene una arquitectura de nube nativa que permite cargar y consultar datos en tiempo real, lo que reduce la necesidad de procesos de transformación y limpieza de datos complejos. También tiene funciones de preparación de datos incorporadas que permiten transformaciones en el momento de la consulta, lo que a menudo elimina la necesidad de ETL previo.

Por otro lado, Databricks cuenta con herramientas como Delta Lake y la funcionalidad de transformación de datos en tiempo real de Spark Streaming, lo que permite trabajar con datos en su estado natural, sin tener que extraerlos, transformarlos y cargarlos en un almacén de datos.

AWS es otro de los grandes impulsores del concepto de Zero ETL. El avance de la #IA hace que muchos expertos pongan las actividades manuales en la mira de la automatización. Pero la realidad es que estamos lejos de tal simplificación. cognitive data

Lo cierto es que los pipelines de datos están confluyendo hacia una mejorar canalización y transporte de la información, haciendo que las necesidades de ETL disminuyan. La práctica de la extracción, que solía ser muy costosa, se está simplificando por medio de conectores prefabricados que permiten integrar miles de plataformas con muy poca configuración de por medio. La transformación es la que sigue siendo un verdadero problema. La transformación implica la limpieza, validación, normalización, agregación y enriquecimiento de los datos para asegurarse de que sean precisos, coherentes y relevantes para su uso previsto. Pero aún la calidad de los datos sigue siendo un verdadero dolor de cabeza.

Desde tiempo atrás a hoy, se han desarrollado técnicas y creado herramientas más avanzadas para mejorar la calidad de los datos. La aparición de herramientas de integración de datos permitió la automatización de muchas tareas de limpieza y transformación de datos, lo que redujo el riesgo de errores humanos y mejoró la eficiencia.

Además, se han creado estándares de calidad de datos y se han establecido mejores prácticas para asegurar la integridad y la precisión de los datos.

Las necesidades de mayor información y el camino de las organizaciones hacia el #DataDriven, hace que la implementación de procesos de calidad de datos sea una tarea crítica para muchas organizaciones que dependen de los datos para tomar decisiones importantes.

Lo bueno es que la inteligencia artificial y el aprendizaje automático están permitiendo nuevas técnicas para mejorar la calidad de los datos, como la identificación de patrones de datos inconsistentes o la corrección automática de errores comunes; pero nace un nuevo problema de calidad relacionado con los sesgos cognitivos.

Los sesgos de datos son errores sistemáticos en la recopilación, el análisis o la interpretación de los datos que pueden generar conclusiones inexactas o incompletas. Los sesgos de datos pueden ser el resultado de diferentes factores, como la falta de representatividad de la muestra, la mala calidad de los datos, la falta de diversidad en los datos, la selección sesgada de las variables o la falta de contexto.

Los sesgos de datos pueden tener consecuencias negativas, como la toma de decisiones incorrectas o injustas, la discriminación y la creación de estereotipos. Para evitar los sesgos de datos, es importante tener en cuenta la calidad de los datos, la diversidad de la muestra, la objetividad en la selección de las variables, la transparencia en la metodología y el contexto en el que se recopilaron los datos.

Los sesgos en la data pueden ser un problema serio en cualquier etapa del proceso ETL, ya que pueden llevar a conclusiones incorrectas o discriminación en la toma de decisiones. Para abordar los sesgos de la data, es importante comprender las fuentes de sesgo, incluyendo la selección de datos, la recopilación de datos, el preprocesamiento y la interpretación de los resultados.

Es importante tener en cuenta la necesidad de tener datos no sesgados en todo el proceso ETL para garantizar que los resultados sean precisos y justos. Esto puede implicar la selección cuidadosa de datos de fuentes diversas, la revisión rigurosa de los datos para identificar y abordar cualquier sesgo, y la aplicación de técnicas estadísticas para garantizar la calidad y la integridad de los datos. Además, es esencial que se realice una revisión constante y periódica de la calidad de datos para asegurarse de que los datos sigan siendo precisos y no sesgados a lo largo del tiempo.

De manera que… ¿El ETL va camino a desaparecer?working in power bi

De nuestra parte creemos que no, ni los procesos ETL, ni los ELT, ni ETL inverso, ni nada. Ni cerca están de desaparecer. Nacerán nuevas y mejores técnicas, pero hay que seguir invirtiendo, esforzándonos y mejorando todos los procesos de Extracción, Transformación y Carga; porque para ser Data Driven se necesitan datos limpios.

Van 5 consejos para mejorar tus procesos ETL:

  1. Antes de comenzar cualquier proceso ETL, es importante analizar la fuente de datos y su calidad para determinar si se necesita limpieza o transformación previa. Si la fuente de datos es limpia y consistente, el proceso de ETL será más rápido y eficiente.
  2. Al limitar la cantidad de datos que se procesan durante el proceso ETL, se puede mejorar significativamente el tiempo de ejecución. Esto se puede lograr a través de filtros, consultas selectivas y otras técnicas que permiten seleccionar solo los datos necesarios para el análisis.
  3. El uso de herramientas y tecnologías modernas puede mejorar significativamente la eficiencia de un proceso ETL. Por ejemplo, el uso de plataformas en la nube como AWS o Azure, o herramientas de automatización como Airflow, puede reducir el tiempo y los recursos necesarios para realizar un proceso ETL.
  4. La automatización del proceso ETL puede reducir significativamente el tiempo y los recursos necesarios para completar un proceso de carga. La automatización también puede reducir la posibilidad de errores humanos y mejorar la calidad de los datos.
  5. Es importante monitorear y ajustar el proceso ETL continuamente para mejorar su eficiencia. Esto puede incluir el ajuste de parámetros de configuración, la optimización de consultas y la adición de nuevos filtros para reducir la cantidad de datos procesados.
Categories
54cuatro

Sea en la nube o localmente, comercial u open source, pero avance

Este post trata sobre la demora en la toma de decisiones y esta dedicado a directores y gerentes.Diferencia entre gerente y director de una empresa | OBS Business School

 

Muchas veces nos encontramos hablando con potenciales clientes que se encuentran analizando si implementar en la nube, on premise, una solución comercial o una solución open source.

Cuando se trata de elegir una plataforma para su negocio, hay muchas opciones disponibles. Una de las decisiones más importantes que deben tomar los usuarios es si elegir una plataforma cloud o una plataforma on premise. Ambas opciones tienen sus pros y sus contras, por lo que es importante considerarlos cuidadosamente antes de tomar una decisión.

Pero este analisis, no puede ser eterno. No siempre es posible tomar la decisión correcta, pero es importante recordar que es mejor tomar una decisión y actuar, incluso si resulta ser incorrecta, en lugar de no hacer nada en absoluto. Para eso estamos los proveedores, justamente para arrojar claridad, dar recomendaciones y poder plantear desafíos a las ideas establecidas e incluso presentar nuevas ideas.

No te cierres a nuevas ideas y perspectivas. Mantén una mente abierta y está dispuesto a considerar nuevas opciones y perspectivas antes de tomar una decisión.

Si usted está pensando en migrar a la #nube, todas las nubes populares tienen servicios similares. Algunas nubes tienen ventajas en algunos servicios, y otras en otros. Algunos tienen mejores costos en algunos servicios, y otras en otros.

Si usted opta por quedarse en su #datacenter puede usar #hyperV o #vmware, y ambas son soluciones valiosas. Quizás crea que no puede generar un #datalake en el on-premise, y esto es incorrecto. Cloudera es una solución que da soporte comercial a plataformas de código abierto.

Cloudera ofrece una amplia gama de productos y soluciones, desde su plataforma de análisis de #BigData #Cloudera Enterprise hasta herramientas de ciencia de datos y aprendizaje automático. Todos estos productos están diseñados para ser escalables, seguros y de fácil uso, y están respaldados por un equipo de soporte y desarrollo altamente capacitado.

Si esta dudando o demorando una decisión, piense en término de portabilidad

La portabilidad se refiere a la capacidad de un sistema o aplicación para ser ejecutado en diferentes entornos o plataformas sin necesidad de realizar cambios significativos en su código o configuración.

Siguiendo el ejemplo anterior. Supongamos que va a implementar un lago de datos, pero no esta seguro si hacerlo en #AWS para no generar un vendor lockin, construya una arquitectura que use componentes standard y que eso le permita el día que quiera irse a #Azure.

El vendor lock-in es una situación en la que un cliente o usuario está atrapado o “bloqueado” con un proveedor o vendedor específico debido a la interdependencia entre el producto o servicio que el proveedor ofrece y la infraestructura tecnológica del cliente. En este escenario, el cliente puede tener dificultades para cambiar de proveedor o dejar de utilizar el producto o servicio sin sufrir costos significativos o interrupciones en su operación diaria.

Si usted utiliza un servicio 100% de propiedad intelectual de un vendor, claramente puede tener ventajas asociadas en cuanto a su rapidez en la implementación, performance, simplicidad, etc. Pero el lado B, suele ser que cualquier solución compleja montada sobre sistemas de este tipo, quedan cautivas. Por eso, un arquitecto empresarial debe considerar que tan complejo sería mover un software, una aplicación, una plataforma, un conjunto de datos, o lo que fuere, de una nube a otra, incluso que tan complejo sería que la operación fuera #multicloud.

Evitar el vendor lockin es parte de una buena arquitectura. En lugar de depender de un solo proveedor de nube, el multicloud permite a las organizaciones elegir los servicios que mejor se adapten a sus necesidades específicas y utilizarlos en conjunto para obtener la mejor solución para su negocio. Planear una plataforma multicloud, es una práctica que recomendamos. Las funciones de un Director de proyectos según la guía del PMBOK 6ta  edición - La Oficina de Proyectos de Informática

La idea de este post, es incentivarlo a que de una manera u otra, capitalice la experiencia de partners, de arquitectos y técnicos que sabrán indicarle que decisión tomar, y que junto a un buen diseño de la arquitectura, su decisión estará segura porque siempre podrá moverse, evolucionar, cambiar y mejorar.

Categories
54cuatro

Manejar Synapse con Azure DevOps

Introducción

Synapse es una plataforma de #LakeHouse de #Azure. Permite armar un #datawarehouse, un #datalake e incluso correr scripts con desarrollos de #ML.

#AzureDevOps es un producto de Microsoft que proporciona funciones de control de versiones, informes, gestión de requisitos, gestión de proyectos, compilaciones automatizadas, pruebas y gestión de versiones.

Para la administración de los desarrollos que corren en la plataforma de #Synapse, es de vital importancia entender el enfoque CI/CD para un pipeline de data.

El enfoque sobre cómo manejar CI/CD con Azure Synapse difiere bastante de su enfoque de “desarrollo de software”. La única rama que puede usar para implementar su código es la rama de publicación (workspace_publish). Esta rama se creará/actualizará cuando presione publicar en su interfaz de usuario de Synapse, después de realizar cualquier cambio.

La rama de trabajo real, donde se integran todas las solicitudes de extracción para implementar nuevas funciones, es la rama de colaboración (rama principal). Esta es también la base para sus publicaciones automatizadas.

El pipeline CI

La construcción ya está prácticamente hecha, porque todo ya está preparado como una solución lista para la implementación. Esta es la razón por la que solo necesita empaquetar su código con fines de trazabilidad y reutilización.

El pipeline CD

Esta tarea también es bastante fácil, porque puede usar una tarea predefinida llamada “Implementación del espacio de trabajo de Synapse”. Aquí solo necesita insertar su Workspace de destino, autenticarse a través de Service Connection (Suscripción). Además, debe desactivar los disparadores para una compilación limpia, pero también hay una tarea previa a la compilación para usar en Azure DevOps llamada “toggle-triggers-dev”.

Azure Synapse Analytics Security, Governance, and CI / CD

CI/CD

Y ahora ambos juntos en una canalización yaml completamente funcional. El activador siempre se activa cuando se publica una nueva plantilla de Synapse en nuestra rama de publicación.

Categories
54cuatro

El enfoque de la arquitectura Medallion

El enfoque Medallion, que es promovido principalmente por #Databricks, también es adecuado para todas las demás plataformas.

Sirve como un modelo de cómo puede construir una estructura unificada para Data Lakehouses en tres capas.

 

#Medallion, es un modelo de arquitectura en el cual su patrón de diseño se basa en la organización de un #datalake en 3 capas, una capa de Datos Sin Procesar (#Raw), una capa de Datos Filtrados, Limpios, Enriquecidos y una capa de Datos de Negocios.

Esta arquitectura garantiza la coherencia, el aislamiento y la permanencia a medida que los datos pasan por múltiples niveles de validación y transformación antes de almacenarse en un diseño optimizado para un análisis eficiente.

La división de las 3 capas nos permite asegurar que los datos brutos de los sistemas de origen se almacenan en la capa de bronce dentro de un almacenamiento que puede ser on-premise o en la nube.

En la capa de plata, estos datos se agregan y limpian técnicamente y de esa manera los datos quedan en un esquema optimizado.

En el tercer nivel, los datos se preparan y agregan para el negocio, no tanto para la optimización técnica sino para la lógica empresarial.

Categories
54cuatro

Data Mesh. ¿Qué es?

Se viene hablando mucho sobre data mesh, y existen muy buenas explicaciones respecto al tema.

Muy buen video Zhamak Dehgani

#DataMesh o Malla de Datos, es un término que hace mención a la evolución de los pipelines de datos, abordado desde 4 dimensiones:

  • Propiedad y arquitectura descentralizada de datos orientada al dominio
  • Datos como producto.
  • Infraestructura de datos de autoservicio como plataforma
  • Gobierno federado.

Cada principio impulsa una nueva visión lógica de la arquitectura técnica y la estructura organizativa.

Para entender que es un #dominio, sugerimos leer acerca de DDD (domain driven design).

Objetivo de la Malla de Datos

En la actualidad existen 2 grandes modelos de gestión de datos, el #EDW (Datawarehouse) y el #Datalake, y aunque se impulsa un concepto híbrido denominado #lakehouse, la realidad es que sigue existiendo complejidades asociadas a las fallas constantes de los #ETL, un incremento exponencial de los #data #pipelines y eso genera cada día mayor necesidad de administración.

La malla de datos reconoce y respeta las diferencias entre estos dos planos: la naturaleza y la topología de los datos, los diferentes casos de uso, las personas individuales de los consumidores de datos y, en última instancia, sus diversos patrones de acceso. Sin embargo, intenta conectar estos dos planos bajo una estructura diferente: un modelo invertido y una topología basada en dominios y no en una pila de tecnología.- con un enfoque en el plano de datos analíticos.

El objetivo de la malla de datos es crear una base para obtener valor de los datos analíticos y los hechos históricos a escala . La escala se aplica al cambio constante del panorama de datos , la proliferación de fuentes de datos y consumidores , la diversidad de transformación y procesamiento que requieren los casos de uso , la velocidad . de respuesta al cambio .

Modelo de Data Mesh

Malla de datos

Descripción de los pilares

  • Propiedad y arquitectura descentralizada de datos orientada al dominio: este punto hace referencia a la transferencia de la propiedad de los datos a los responsables de dominio. Un experte de dominio según DDD es aquel con conocimientos específicos sobre un sector/área de la compañia, como gerencias, departamentos, etc. Esta transferencia hace que los expertos de dominios, sean los dueños y por ende se delega en ellos la responsabilidad de asegurar la calidad y seguridad de la data.
  • Datos como producto: en este punto, el objetivo es que los dominios sean capaces de generar sus productos de datos. Bajo un concepto de Product Owner, la idea es que cada responsable pueda mantener, validar y mejorar la calidad de la información; buscando que además la información sea colaborativa y pueda ser consumida por diferentes actores interesados.
  • Infraestructura de datos de autoservicio como plataforma: este ítem busca la simplificación de la gestión de la plataforma, permitiendo a los usuarios especialistas de dominios poder trabajar sobre la data sin depender de especialistas.
  • Gobierno federado: la importancia de la gobernanza no puede quedar de lado. Este punto refiere a la necesidad de cumplir con los puntos de seguridad/compliance/políticas corporativas, con el objetivo de asegurar la privacidad, el cumplimiento normativo y la seguridad.

Contactate

Categories
54cuatro

Todo sobre PCS el framework para Data Science de Berkeley

Como continuidad del post de MLOPS, queremos mencionar sobre PCS.

En simples palabras podemos afirmar que PCS es un framework de Data Science, creado por Bin Yua y Karl Kumbiera, del Departamento de Estadísticas de Berkeley. Es una especie de MLOPS con sustentos científicos.

Las siglas #PCS vienen de #predictability, #computability, y #stability (#predictibilidad, #computabilidad y #estabilidad).

Pero veamos de que sirve PCS.

¿Cuál es el objetivo de PCS?

Este framework esta compuesto por un flujo de trabajo denominado DSLC (data science lifecycle) que busca proporcionar resultados responsables, confiables, reproducibles y transparentes en todo el ciclo de vida de la ciencia de datos.

PCS busca generar una metodología para el correcto abordaje de proyectos de data science, teniendo en cuenta como abordar un nuevo requerimiento, como recabar la informacion, como procesarla y lógicamente, como hacer de esa data informacion de valor.

Como analistas de datos, podemos encontrarnos con proyectos disimiles. Desde analítica de cadenas proteicas, hasta fraude bancario. Detección temprana de cáncer hasta aumento de venta en e-commerce. Exploración petrolera hasta detección de spam. En fin, podemos analizar cualquier cosa.

Cuando involucramos la matemática en nuestros análisis todo se transforma en Ciencia de Datos, y es por eso que PCS es una buena base para lograr estandarizar procesos tanto para analizar datos financieros, como imágenes, o voz u otros.

¿Cómo funciona PCS?

El flujo de trabajo de PCS utiliza la predictibilidad como una verificación de la realidad y considera la importancia de la computación en la recopilación / almacenamiento de datos y el diseño de algoritmos.

De esta manera aumenta la previsibilidad y la computabilidad con un principio de estabilidad general para el ciclo de vida de la ciencia de datos.

El ciclo de ciencia de datos, contiene 8 pasos concatenados que nacen desde un requerimiento (pregunta de dominio), y continua con un #pipeline basado en la recopilación de datos desde los orígenes de datos (bases de datos, redes sociales, imágenes, audios, etc), la limpieza y procesamiento de esa data recolectada, la exploración, y el modelado.

El tipo de modelado va a depender del tipo de dato que tengamos, la frecuencia, su calidad, etc.

Podemos pensar en un modelado habitual en #datawarehouse o en un modelo mas ligado a un #datalake. Posteriormente a esto se efectuaran los análisis sobre esos modelos, se interpretaran los resultados y finalmente se actualizaran los conocimientos.

Ciclo de vida de Data Science

La estabilidad amplía las consideraciones de incertidumbre estadística para evaluar cómo las llamadas del juicio humano impactan los resultados de los datos a través de las perturbaciones de los datos y del modelo / algoritmo.

Además, esta metodología considera procedimientos de inferencia que se basan en PCS, a saber, intervalos de perturbación de PCS y pruebas de hipótesis de PCS, para investigar la estabilidad de los resultados de los datos en relación con la formulación de problemas, limpieza de datos, decisiones de modelado e interpretaciones.

Ejemplo de un Caso de Uso

Guiados por el pipeline del grafico, vamos a simular una situación real, para hacer feliz a un gerente comercial:

Un gerente feliz
  1. Pregunta de Dominio: un responsable comercial de una fabrica de Sommiers quiere conocer que cadena de retail es la que mas productos vende y cual será la que mayor proyección de ventas tendrá el próximo año.
  2. Recopilación de Datos: con herramientas de orquestación vamos a buscar datos provenientes de sistemas de ventas, finanzas, logística y también de las redes sociales.
  3. Limpieza: vamos a acomodar los datos de manera de poder ver la informacion para pasar al siguiente punto.
  4. Explorar los datos: visualizar los datos desde distintos ángulos para determinar que tengamos info de ventas, facturación, entregas, y campañas de marketing.
  5. Modelado: con toda la informacion recolectada y luego de confiabilizarla, vamos a modelar nuestra fuente de procesamiento de datos que fue nutrida por los pasos anteriores.
  6. Análisis Post Modelado: desde este nuevo origen de datos vamos a generar nuevos análisis, con mayores capacidades, corriendo análisis con algoritmos de Predicción de Ventas, Fidelización de Clientes usando Machine Learning.
  7. Interpretación: los algoritmos nos van a dar 2 tipos de resultados. Por un lado su performance, con lo que vamos a determinar si la informacion que tenemos es adecuada, o si necesitamos mas o mejor data. Y por otro lado en caso de que el algoritmo tenga buena performance vamos a lograr nuevos insights de negocios. Por ejemplo, determinar que una cadena de retail fue el que mas vendió durante el año en curso, pero que por sus campañas en redes sociales y el crecimiento YoY otra cadena será la que mas venda el año entrante.
  8. Actualizar conocimientos: Con esos outputs, vamos a poder tener nuevos insights que alimenten una nueva estrategia comercial, a partir de lo cual podemos ofrecer descuentos, u otros incentivos a la cadena de retail que creemos que será nuestro mejor socio.

Conclusiones

En este artículo, se unifican tres principios de la ciencia de datos: predictibilidad, computabilidad y estabilidad.
En resumen, este nuevo marco conceptual y práctico para formular procedimientos basados en ciencia de datos, recolectando y procesando informacion, y mostrando resultados valiosos de cara al negocio.

Queres bajarte el paper original de la universidad de Berkeley:


Contactate

Categories
54cuatro

Porque utilizar un Datalake?

Hace un tiempo compartimos un vídeo diferenciando un datalake de un datawarehouse. Pueden verlo aquí.

También venimos impulsando la adopción de #DataOps como metodología para trabajar nuestros datos. Pero en esta nota queremos hacer hincapié en los lagos de datos, tan de moda en estos momentos.

¿Porque Utilizar un Lago de datos?​

Un lago de datos es un depósito de almacenamiento que contiene datos “crudos”. Esto quiere decir que son almacenados en su formato nativo hasta que sean requeridos.

De esta manera, es de vital importancia resguardar estos datos dado que:

  • Todos los datos tienen un valor potencial.​
  • La acumulación de datos permite que se vayan enriqueciendo los reportes y análisis que se vayan a realizar en un futuro.​
  • Los datos se guardan sin un esquema definido, de manera que almacenarlos en su formato nativo no conlleva mucho esfuerzo.​
  • Los esquemas son establecidos y las transformaciones son hechas al momento de la consulta. ​
  • Las aplicaciones y los usuarios interpretan los datos cuando los consideran necesario.

El reto es combinar datos transaccionales almacenados en bases de datos relacionales con datos menos estructurados​, para poder servir los datos correctos a las personas correctas en el momento correcto en el formato correcto​

Zonas de un lago de datos​

Dentro de un datalake, existen zonas.

Zona Datos Crudos

  • Extracción de una copia del origen de datos en su formato nativo​
  • Inmutable al cambio​
  • Retención histórica de manera indefinida.​
  • Acceso a datos limitado a unas cuantas personas.​
  • A partir de ellos es posible regenerar cualquier proceso de transformación o analítico.​

Zona Temporal

  • Utilizada de manera selectiva​
  • Separación de “datos nuevos” de “datos sin procesar” para garantizar la coherencia de los datos​
  • Datos transitorios de baja latencia (Speed Layer)​
  • Validaciones de calidad de datos.​

Zona de Datos Maestros

  • Datos de Referencia​

Zona de Entrega de Usuario

  • Datos generados manualmente​

Zona de Preparación de Datos

  • Zona de preparación para un propósito o aplicación particular .​

Zona de estandarización de Datos Crudos

  • Datos crudos que varían en formato o esquema, como por ejemplo JSON que son estandarizados en columnas y renglones.

Zona de Archivo de datos

  • Archivo activo basado en políticas de tiempo asociadas a los datos, manteniéndolos disponibles para su consulta en caso de que se requiera.​

Sandbox Analítico

  • Lugar de trabajo para la exploración de datos, ciencia de datos y analítica.​

Zona de Entrega de Usuario

  • Datos generados manualmente​ (XLS, DOC, PDF, etc)

Zona de Preparación de Datos

  • Zona de preparación para un propósito o aplicación particular .​
  • Los procesos que lo ameriten pueden ser promovidos a la zona de datos curados.​

Zona de Datos Curados

  • Datos limpios y transformados, organizados para su optima entrega.​
  • Soporta esquemas de autoservicio.​
  • Seguridad estandarizada, gestión del cambio y gobierno.​

​En base al detalle explicado mas arriba, es necesario identificar las capas de un datalake, y realizar un modelo de gobernanza para que un lago de datos no se convierta en un pantano.

Capas del lago de datos

Governance? Que es?

El gobierno de datos refiere a la administración de los sistemas de datos, incluyendo, la organización, procesos, procedimientos, administración, responsabilidades, compliance y documentación de los sistemas de datos dentro de las organizaciones.

Existe una metodología llamada DAMA, una organización que gestiona un manual de buenas prácticas, el DMBoK (similar al PMBok del PMP Institute) que permite establecer lineamientos para el Data Governance, tal como se ve en la siguiente figura:

En una entrada posterior exploraremos en profundidad el tema governance, incluyendo herramientas para gestionarlo.

Pero continuando con el tema #Datalake….

Casos de Uso Datalake​

Experimentos de Ciencia de datos​

  • Soluciones aisladas para la preparación inicial de datos, experimentación y análisis.​
  • Migración de prueba de concepto a la solución operativa.​
  • Se integra con proyectos de código abierto como Hive, Pig, Spark, Storm, etc.​

Área de preparación de datos en el Data Warehouse​

  • Estrategia ETL.​
  • Reduce la necesidad de almacenamiento en una Plataforma relacional al utilizar el lago de datos como un área de preparación de datos.​
  • Uso practico de datos almacenados en lago de datos​
  • Aplicación de transformaciones de datos en el lago de datos.​

Esto son solo 2 casos de usos de utilidad, pero lógicamente existen múltiples usos validos para un datalake. Así también, existen un sinfín de arquitecturas posibles para el armado de un datalake, junto con una gran cantidad de herramientas, modelos y procesos disponibles. El armado de un lago de datos, requiere de un entendimiento previo del objetivo final, el conocimiento de la organización y posteriormente el planeamiento del despliegue.


En #54cuatro, somos una consultora especializada en la gestión de datos y partner #DataPlatform Gold de Microsoft. Vea nuestro perfil en Microsoft Partners.


Contactate
Categories
54cuatro

Videoblog: Datalake vs Datamart vs Datawarehouse

No te pierdas este video para entender las diferencias entre #Datalake vs #Datamart vs #Datawarehouse.

Contactate

    Please prove you are human by selecting the car.