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

    Por favor, demuestra que eres humano mediante la selección la taza.