Aplicación de DataOps a Azure Data Factory

SE APLICA A: Azure Data Factory Azure Synapse Analytics

Sugerencia

Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. ¡Obtenga más información sobre cómo iniciar una nueva evaluación gratuita!

Azure Data Factory es el servicio ETL y de integración de datos de Microsoft en la nube. En este documento se proporciona una guía para DataOps en la factoría de datos. No pretende ser un tutorial completo sobre CI/CD, Git o DevOps. En su lugar, encontrará la guía del equipo de factoría de datos para lograr DataOps en el servicio con referencias a vínculos de implementación detallados sobre procedimientos recomendados de implementación de factoría de datos, administración de factorías y gobernanza. Al final de este documento hay una sección de recursos con vínculos a tutoriales.

¿Qué es DataOps?

DataOps es un proceso que las organizaciones de datos practican para la administración de datos colaborativa con la finalidad de proporcionar un valor más rápido a los responsables de la toma de decisiones.

Gartner proporciona esta definición clara de DataOps:

DataOps es una práctica de administración de datos colaborativa centrada en mejorar la comunicación, la integración y la automatización de los flujos de datos entre los administradores y consumidores de datos en una organización. El objetivo de DataOps es ofrecer valor más rápidamente mediante la creación de una entrega predecible y la administración de los cambios de datos, modelos de datos y artefactos relacionados. DataOps utiliza la tecnología para automatizar el diseño, la implementación y la administración de la entrega de datos con los niveles adecuados de gobernanza y emplea metadatos para mejorar la usabilidad y el valor de los datos en un entorno dinámico.

¿Cómo se consigue DataOps en Azure Data Factory?

Azure Data Factory proporciona a los ingenieros de datos un paradigma de canalización de datos basado en la visualización para crear fácilmente proyectos de integración de datos y ETL a escala de nube. Data Factory se basa en integraciones nativas con herramientas maduras de control de versiones como GitHub y Azure DevOps, así como en el ecosistema Azure más amplio, para proporcionar muchas características integradas que facilitan DataOps, como colaboración enriquecida, gobernanza y relaciones entre artefactos.

En concreto, una vez que traiga su propio repositorio de GitHub o Azure DevOps a la factoría de datos, el servicio proporciona opciones de interfaz de usuario integradas intuitivas para comandos comunes, como confirmaciones, guardar artefactos y control de versiones. El servicio también ofrece la opción de proporcionar procedimientos recomendados de CI/CD y de inserción de código en el repositorio para proteger la integridad y el estado del entorno de producción.

"Código" en Azure Data Factory

Todos los artefactos de Azure Data Factory, tanto si son canalizaciones, servicios vinculados, desencadenadores, etc., tienen representaciones de "código" correspondientes en JSON detrás de la integración de la interfaz de usuario visual. Estos artefactos actúan de conformidad con los estándares de las plantillas de Azure Resource Manager. Para encontrar el código, haga clic en el icono de corchete situado en la parte superior derecha del lienzo. El "código" JSON de ejemplo tendría el siguiente aspecto:

Modo activo y control de versiones de Git

Cada factoría tiene un solo origen de verdad: canalizaciones, servicios vinculados y definiciones de desencadenador almacenadas en el servicio. Este origen de verdad es lo que ejecuta la canalización y lo que determina los comportamientos de los desencadenadores. Si está en modo real, cada vez que haga alguna publicación, modificará directamente el origen único de verdad. En la imagen siguiente se muestra el aspecto del botón Publicar todo en modo real.

El modo real puede ser práctico para una sola persona que trabaja en proyectos paralelos, ya que permite a los desarrolladores ver efectos inmediatos de sus cambios en el código. Sin embargo, no se recomienda para equipos de desarrolladores que trabajan en proyectos a nivel de producción. Existen, entre otros, peligros de errores tipográficos, eliminación accidental de recursos críticos o publicación de códigos no probados. Al trabajar en proyectos y plataformas críticos, considere la posibilidad de incorporar un repositorio de Git y usar el modo Git en la factoría de datos para simplificar el proceso de desarrollo. El control de versiones y las funcionalidades de inserción en el repositorio validada del modo Git le ayudan a evitar prácticamente la mayoría de los accidentes asociados a usar directamente el modo real.

Nota

En el modo Git, el botón Publicar o Publicar todo se reemplazará por Guardar o Guardar todo, y los cambios se confirmarán en sus propias ramas (sin cambiar directamente las bases de código activas).

Configuración de la integración de GitHub y Azure DevOps

En Azure Data Factory, se recomienda encarecidamente almacenar el repositorio en GitHub o Azure DevOps. El servicio es totalmente compatible con ambos métodos y la elección de qué repositorio usar depende de los estándares de cada organización. Hay dos métodos para configurar un nuevo repositorio o para conectarse a uno ya existente: mediante Azure Portal o la creando uno desde la interfaz de usuario de Azure Data Factory Studio.

Creación de una factoría de Azure Portal

Al crear una nueva factoría de datos en Azure Portal, el repositorio de Git predeterminado es Azure DevOps. También puede seleccionar GitHub como repositorio y configurar sus opciones.

En Azure Portal, seleccione el tipo de repositorio y escriba los nombres de repositorio y rama para crear una nueva factoría integrada de forma nativa con Git.

Imposición del uso de Git con Azure Policy en la organización

El uso de Git en los proyectos de Azure Data Factory es un procedimiento totalmente recomendable. Incluso si no se va a implementar un proceso completo de CI/CD, la integración de Git con ADF permite guardar los artefactos de recursos en su propio entorno de espacio aislado (rama de Git), donde se puede probar los cambios independientemente del resto de las ramas de la factoría. Puede usar Azure Policy para imponer el uso de Git en la factoría de la organización.

Azure Data Factory Studio

Después de crear la factoría de datos, también puede conectarse al repositorio mediante Azure Data Factory Studio. En la pestaña Administrar, verá la opción de configurar el repositorio y sus opciones.

Mediante un proceso guiado, se le dirige a través de una serie de pasos para ayudarle a configurar y conectarse fácilmente al repositorio que prefiera. Una vez configurado completamente, puede empezar a trabajar de forma colaborativa y guardar ahí los recursos.

Integración continua y entrega continua (CI/CD)

CI/CD es un paradigma de desarrollo de código donde se inspeccionan y prueban los cambios a medida que pasan por varias fases: desarrollo, prueba, ensayo, etc. Después de revisarse y probarse en cada fase, se publican finalmente en bases de código reales de los entornos de producción.

La integración continua (CI) es la práctica de probar y validar automáticamente los cambios que realiza un desarrollador en el código base. La entrega continua (CD) significa que, después de que las pruebas de integración continua se realicen correctamente, los cambios se llevan a la siguiente fase de forma ininterrumpida.

Como se explicó anteriormente de forma breve, "código" en Azure Data Factory adopta la forma de JSON de las plantillas de Azure Resource Manager. Por lo tanto, los cambios que pasan por el proceso de integración y entrega continuas (CI/CD) comprenden adiciones, eliminaciones y ediciones de blobs JSON.

Ejecuciones de canalización en Azure Data Factory

Antes de hablar de CI/CD en Azure Data Factory, primero es necesario hacerlo de cómo el servicio ejecuta una canalización. Antes de que la factoría de datos ejecute una canalización, hace lo siguiente:

• Extrae la definición publicada más reciente de la canalización y sus recursos asociados, como conjuntos de datos, servicios vinculados, etc.
• La compila en acciones: si la factoría de datos la ejecutó recientemente, recupera las acciones de las compilaciones almacenadas en caché.
• Ejecuta la canalización.

La ejecución de la canalización conlleva los pasos siguientes:

• El servicio toma la instantánea de un momento dado de la definición de canalización.
• Mientras dura la canalización, las definiciones no cambian.
• Incluso si las canalizaciones se ejecutan durante mucho tiempo, no se ven afectadas por los cambios subsiguientes realizados después de iniciarse. Si durante la ejecución publica cambios en el servicio vinculado, las canalizaciones, etc., estos cambios no afectan a las ejecuciones en curso.
• Al publicar los cambios, las ejecuciones subsiguientes iniciadas después de la publicación usan las definiciones actualizadas.

Publicación en Azure Data Factory

Con independencia de si va a implementar canalizaciones con Azure Release Pipeline para automatizar la publicación o con la implementación manual de plantillas de Resource Manager, en el back-end, la publicación es una serie de operaciones de creación y actualización que se realizan sobre conjuntos de datos, servicios vinculados, canalizaciones y desencadenadores, para cada uno de los artefactos. El efecto es el mismo que hacer llamadas directamente a las API REST subyacentes.

De las acciones se desprenden algunas cosas:

• Todas estas llamadas API son sincrónicas, lo que significa que la llamada solo se devuelve cuando la publicación se realiza correctamente o produce un error. No habrá un estado de implementación parcial para el artefacto.
• Las llamadas API son en gran medida secuenciales. Se intenta paralelizar las llamadas y, al mismo tiempo, mantener las dependencias referenciales de los artefactos. El orden de las implementaciones es: servicio vinculado -> conjunto de datos/entorno de ejecución de integración -> canalización -> desencadenador. Este orden garantiza que los artefactos dependientes puedan hacer referencia correctamente a sus dependencias. Por ejemplo, las canalizaciones dependen de los conjuntos de datos, por lo que la factoría de datos las implementa después de estos.
• La implementación de servicios vinculados, conjuntos de datos, etc., son independientes de las canalizaciones. Hay situaciones en las que la factoría de datos actualiza los servicios vinculados antes que una canalización. Se hablará de esta situación en la sección Cuándo detener un desencadenador.
• La implementación no eliminará los artefactos de las factorías. Debe llamar explícitamente a las API de eliminación de cada tipo de artefacto (canalización, conjunto de datos, servicio vinculado, etc.) para limpiar una factoría. Consulte el script posterior a la implementación de muestra de Azure Data Factory para ver un ejemplo.
• Incluso si no ha tocado una canalización, un conjunto de datos o un servicio vinculado, se sigue invocando una llamada API de actualización rápida a la factoría.

Desencadenadores de publicación

• Los desencadenadores tienen los estados iniciado o detenido.
• No se pueden realizar cambios en un desencadenador en modo iniciado. Debe detener un desencadenador antes de publicar los cambios.
• Puede invocar la API de creación o actualización de un desencadenador en un desencadenador en modo iniciado.
  • Si cambia la carga, se produce un error en la API.
  • Si la carga permanece sin cambios, la API se ejecuta correctamente.
• Este comportamiento tiene un profundo efecto sobre cuándo detener un desencadenador.

Cuándo detener un desencadenador

Cuando se trata de la implementación en una factoría de datos de producción, donde desencadenadores activos inician las ejecuciones de canalización todo el tiempo, la pregunta es "¿Debemos detenerlos?".

La respuesta corta es que solo en los siguientes escenarios se debería considerar detener el desencadenador:

• Debe detener el desencadenador si va a actualizar las definiciones del desencadenador, incluidos campos como la fecha de finalización, la frecuencia y la asociación de canalización.
• Se recomienda detener el desencadenador si va a actualizar los conjuntos de datos o los servicios vinculados a los que se hace referencia en una canalización real. Por ejemplo, si va a rotar las credenciales para SQL Server.
• Puede optar por detener el desencadenador si la canalización asociada produce errores y está sobrecargando sus servidores.

Estos son algunos puntos que se deben tener en cuenta en relación con la detención de desencadenadores:

• Como se explica en la sección Ejecuciones de canalización en Azure Data Factory, cuando un desencadenador inicia una ejecución de canalización, toma una instantánea de la canalización, el conjunto de datos, el entorno de ejecución de integración y las definiciones de servicio vinculados. Si la canalización se ejecuta antes de que los cambios se introduzcan en el back-end, el desencadenador inicia una ejecución con la versión anterior. En la mayoría de los casos, esta acción es correcta.
• Como se explica en la sección Publicación de desencadenadores, cuando un desencadenador está en estado iniciado, no se puede actualizar. Por lo tanto, si necesita cambiar los detalles sobre la definición del desencadenador, detenga el desencadenador antes de publicar los cambios.
• Como se explica en la sección Publicación en Azure Data Factory, las modificaciones en los conjuntos de datos o los servicios vinculados se publican antes que los cambios en la canalización. Para asegurarse de que las ejecuciones de canalización usan las credenciales correctas y se comunican con los servidores adecuados, se recomienda detener también el desencadenador asociado.

Preparación de los cambios de "código"

Se recomienda seguir estos procedimientos recomendados para las solicitudes de incorporación de cambios.

• Cada desarrollador debe trabajar en sus propias ramas individuales y, al final del día, crear solicitudes de incorporación de cambios en la rama principal del repositorio. Consulte los tutoriales sobre las solicitudes de incorporación de cambios en GitHub y DevOps.
• Cuando los encargados de proteger el código aprueban las solicitudes de incorporación de cambios y combinan los cambios en la rama principal, el proceso de CI/CD puede iniciarse. Hay dos métodos sugeridos para promover los cambios en todos los entornos: automatizado y manual.
• Cuando esté listo para iniciar las canalizaciones de CI/CD, puede hacerlo normalmente mediante la versión de Azure Pipeline o realizar implementaciones de canalizaciones individuales específicas mediante esta utilidad de código abierto de Azure Player.

Implementación automatizada de cambios

Para ayudar con las implementaciones automatizadas, se recomienda usar el paquete npm de utilidades de Azure Data Factory. El uso del paquete npm ayuda a validar todos los recursos de una canalización y a generar las plantillas de ARM para el usuario.

Para empezar a trabajar con el paquete npm de utilidades de Azure Data Factory, consulte Publicación automatizada para la integración y entrega continuas.

Implementación manual de cambios

Después de volver a combinar su rama con la rama de colaboración principal del repositorio de Git, puede publicar manualmente los cambios en el servicio de Azure Data Factory real. El servicio proporciona control de la interfaz de usuario sobre la publicación desde factorías que no son de desarrollo con la opción Deshabilitar publicación (desde ADF Studio).

Implementación selectiva

La implementación selectiva se basa en una característica de GitHub y Azure DevOps, conocida como elección por conveniencia (cherry pick). Esta característica le permite implementar solo determinados cambios, pero no otros. Por ejemplo, un desarrollador ha realizado cambios en varias canalizaciones, pero para la implementación actual, es posible que solo queramos implementar cambios en una.

Siga los tutoriales de Azure DevOps y GitHub para seleccionar las confirmaciones pertinentes para la canalización que necesita. Asegúrese de que todos los cambios, incluidos los cambios pertinentes realizados en los desencadenadores, los servicios vinculados y las dependencias asociados a la canalización, se hayan elegido por conveniencia.

Cuando se hayan elegido los cambios por conveniencia y se hayan combinado con la canalización de colaboración principal, puede iniciar el proceso de CI/CD para los cambios propuestos. Información adicional sobre cómo corregir, elegir por conveniencia o usar marcos externos para la implementación selectiva, como se describe en la sección Pruebas automatizadas de este artículo.

Pruebas unitarias

Las pruebas unitarias son una parte importante del proceso de desarrollo de nuevas canalizaciones o edición de artefactos de factoría de datos existentes, que se centra en probar los componentes del código. Data Factory permite realizar pruebas unitarias individuales a nivel de artefacto de flujo de datos y de canalización mediante la característica de depuración de la canalización.

Al desarrollar flujos de datos, podrá obtener información sobre cada transformación y cambio de código individual mediante la característica de vista previa de datos para lograr pruebas unitarias antes de implementar los cambios en producción.

El servicio proporciona comentarios reales e interactivos de las actividades de canalización en la interfaz de usuario al depurar y realizar pruebas unitarias en Azure Data Factory.

Pruebas automatizadas

Hay varias herramientas disponibles para las pruebas automatizadas que puede usar con Azure Data Factory. Dado que el servicio almacena los objetos como entidades JSON, puede ser conveniente usar NUnit, el marco de pruebas unitarias .NET de código abierto, con Visual Studio. Consulte la publicación Configuración de pruebas automatizadas para Azure Data Factory que proporciona una explicación detallada de cómo configurar un entorno de pruebas unitarias automatizadas para la factoría. (Un agradecimiento especial a Richard Swinbank por dejarnos usar este blog).

Como parte del proceso de CI/CD, los clientes también pueden ejecutar canalizaciones de PRUEBA con PowerShell o la CLI de AZ en los pasos previos y posteriores a la implementación.

Uno de los puntos fuertes de la factoría de datos se encuentra en su parametrización de conjuntos de datos. Esta característica permite a los clientes ejecutar las mismas canalizaciones con diferentes conjuntos de datos para asegurarse de que su nuevo desarrollo cumple todos los requisitos de origen y destino.

Otros marcos de CI/CD para Azure Data Factory

Como se ha descrito anteriormente, la integración de Git integrada está disponible de forma nativa mediante la interfaz de usuario de Azure Data Factory, incluida la combinación, la bifurcación, la comparación y la publicación. Sin embargo, hay otros marcos de CI/CD útiles que son populares en la comunidad de Azure, que proporcionan mecanismos alternativos para ofrecer funcionalidades similares. La metodología de Git de Azure Data Factory se basa en plantillas de ARM, mientras que los marcos como ADFTools de Kamil Nowinski adoptan un enfoque diferente al basarse en artefactos JSON individuales de la factoría. Los ingenieros de datos que son expertos en Azure DevOps y prefieren trabajar en ese entorno (frente al enfoque de interfaz de usuario basado en ARM que el servicio ofrece de forma predeterminada) pueden encontrar que este marco les funciona bien y también sirve para escenarios comunes, como implementaciones parciales. Este marco también puede simplificar el control de desencadenadores cuando la implementación se realiza en entornos que tienen estados de desencadenador en ejecución.

Gobernanza de datos en Azure Data Factory

Un aspecto importante de la eficacia de DataOps es la gobernanza de datos. En el caso de las herramientas ETL de integración de datos, proporcionar el linaje de los datos y las relaciones entre artefactos puede aportar información importante para que un ingeniero de datos comprenda el impacto de los cambios posteriores. Data Factory proporciona vistas de artefacto relacionadas integradas que constituyen la implementación de la factoría.

La integración nativa con Microsoft Purview proporciona además linaje, análisis de impacto y catalogación de datos.

Microsoft Purview proporciona una solución unificada de gobernanza de datos que le ayuda a administrar y gobernar los datos locales, de varias nubes y de software como servicio (SaaS). Le permite crear fácilmente un mapa holístico actualizado del panorama de sus datos con detección automatizada de datos, clasificación de datos confidenciales y linaje de datos de principio a fin. Estas características permiten que los consumidores de datos accedan a una administración de datos valiosa y confiable.

Con la integración nativa en el Catálogo de datos de Purview, la factoría de datos permite la búsqueda y detección sencillas de recursos de datos que se usan en las canalizaciones de integración de datos en toda la amplitud del patrimonio de datos de la organización.

Puede usar la barra de búsqueda principal de Azure Data Factory Studio para buscar recursos de datos en el catálogo de Purview.

Contenido relacionado

• Publicación automatizada para CI/CD en Azure Data Factory
• Control de código fuente en Azure Data Factory
• Biblioteca de vídeos de Azure Data Factory con vídeos útiles sobre el uso de CI/CD en la factoría de datos
• Revisión de la factoría de datos en Git