#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”.
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.
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.
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
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.
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.
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
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.
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.
Limpieza: vamos a acomodar los datos de manera de poder ver la informacion para pasar al siguiente punto.
Explorar los datos: visualizar los datos desde distintos ángulos para determinar que tengamos info de ventas, facturación, entregas, y campañas de marketing.
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.
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.
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.
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:
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.
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.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
