¿Cada release de Azure Data Factory se convierte en una batalla de plantillas ARM?
Bajo el editor visual, una Azure Data Factory es puro código JSON: pipelines, datasets, linked services y la plantilla ARM que los despliega. Pasar un cambio de Dev a Prod exige archivos de parámetros, parámetros globales y una plantilla que falla ante el menor conflicto de tipos. Las releases deberían generarse a partir de un modelo, con el rollback incluido.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- Una release a Prod falla en el paso de despliegue ARM, y la solución resulta ser un archivo de parámetros que nadie recuerda haber editado.
- Dev, Test y Prod tienen configuraciones de linked services ligeramente distintas, mantenidas a mano en tres ubicaciones diferentes.
- La definición de un dataset cambió en un pipeline y rompió otro, porque ambos lo compartían y solo se probó uno de ellos.
- Hacer un rollback implica volver a desplegar la plantilla ARM anterior y confiar en que los datasets que referencia sigan existiendo.
Azure Data Factory oculta muy bien su JSON hasta el día de la release. Es entonces cuando la plantilla ARM, los archivos de parámetros, los parámetros globales y las sobrescrituras de linked services quedan al descubierto al mismo tiempo, y un único conflicto de tipos paraliza el despliegue hasta que alguien lo localiza.
Por qué las releases son frágiles
- El pipeline es JSON, se vea o no. El editor visual escribe definiciones de pipelines, datasets y linked services, y el proceso de publicación los compila en una plantilla ARM. Algunos equipos lo encapsulan en Bicep; el artefacto subyacente es exactamente el mismo.
- Las diferencias entre entornos se guardan en archivos de parámetros. Dev, Test y Prod difieren en cadenas de conexión, claves y nombres, y esos archivos se mantienen a mano.
- Las dependencias son implícitas. Datasets y linked services se comparten entre pipelines; modificar uno para un pipeline probado afecta a los que no se han probado.
- El rollback es un redespliegue. Volver atrás exige la plantilla anterior, y todo lo que esta referenciaba debe seguir existiendo.
ADF hace lo que corresponde a un recurso de Azure: se despliega como una plantilla. Las plantillas se diseñaron para aprovisionar infraestructura estática, cuentas de almacenamiento y redes. El esquema de un data warehouse tiene estado y cambia en cada release, y eso no encaja con esa herramienta.
Dónde debe residir la gestión de releases
- En el generador. Si el data warehouse surge de un modelo, una release es la diferencia entre dos estados de ese modelo, y la herramienta sabe de qué depende cada diferencia.
- Con el rollback incluido. Una release generada sabe qué ha cambiado, por lo que el script de reversión existe antes de que la release se ejecute.
- Una comparación, no una suposición. La diferencia entre Test y Prod debe ser un informe, no una sorpresa.
Qué cambia con Datavault Builder
Datavault Builder construye las releases comparando dos estados, con soporte nativo para Git y Gitflow. Un estado puede ser su entorno local, un estado almacenado en Git, otro entorno activo, un archivo zip o una carpeta; la comparación enumera las diferencias y usted elige cuáles desplegar.
- Sin plantillas que mantener. La release es el conjunto de diferencias que usted selecciona, generado para el entorno de destino. Seleccione un producto de datos y la herramienta le propondrá el hub, el satélite, la tabla de staging y el origen que necesita.
- El rollback se genera junto con ella. Cada release incluye su script inverso y la versión del modelo a la que pertenece.
- Los entornos se comparan, no se suponen. Lo que Prod va a recibir es la lista de diferencias entre su estado actual y el que se está desplegando.
- Los cambios de esquema en los orígenes no exigen una release. Las columnas que desaparecen se cargan como null con una advertencia, las que crecen se amplían y una columna nueva es una actualización del mapeo.
- Sus herramientas de CI se mantienen. Azure DevOps o GitHub Actions ejecutan el paquete generado; ya no tienen que entender el data warehouse.
Qué decisión tomar
Audite su proceso de release y cuente dos cosas: los archivos de parámetros y las sobrescrituras por entorno que mantiene, y las releases del último trimestre que fallaron en el paso de la plantilla. Ese es el mantenimiento que una release generada elimina.
Véalo funcionando con una de sus fuentes de datos
Reserve una demo gratuita y traiga el conector que más le cuesta, en dinero o en tiempo.
Tres pasos hacia un pipeline que usted controla
-
Separar el modelo del despliegue
La estructura del data warehouse es un modelo. El despliegue es un script generado para un entorno de destino, no una plantilla mantenida a mano.
-
Generar la release
Datavault Builder compara dos estados, selecciona las diferencias a desplegar y propone las dependencias necesarias. El script de rollback viene incluido.
-
Comparar antes de pasar al siguiente entorno
Es posible comparar dos estados cualesquiera: su entorno local, un estado en Git, otro entorno activo, un archivo zip o una carpeta.
Cómo Datavault Builder elimina las fricciones en la ingesta
-
La ingesta viene integrada
Cargas batch, delta y CDC desde bases de datos, archivos, APIs REST, fuentes NoSQL y Python, recibiendo flujos como Kafka en micro-batches. La misma plataforma que genera el warehouse, sin una segunda factura.
-
Su propio esquema, no el del proveedor
Las tablas de origen se mapean a un modelo Data Vault 2.0 diseñado por usted. Una nueva columna o una tabla renombrada modifica un mapeo, no una cadena de scripts post-carga.
-
Solo se mueven los deltas
Los hubs, links y satélites cargan lo que ha cambiado. Las recargas completas permanecen en staging en lugar de reprocesarse aguas abajo cada noche.
-
El historial se conserva por diseño
Cada cambio se retiene según llega, por lo que el reporting histórico funciona incluso cuando el origen sobrescribe sus propios registros.
-
Código que nunca tendrá que escribir a mano
La carga, historización y linaje se generan desde el modelo en tiempo real y se ejecutan de forma nativa en Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle o PostgreSQL.
-
Una plataforma, hasta nueve herramientas menos
Modelado, ETL, CI/CD, documentación y linaje en un solo lugar. Eso es lo que hace posible pasar del requerimiento a producción en 14,7 minutos.
Reconocido por BARC en The Data Fabric Survey 26
Hable con nuestro experto
Veinte minutos con nuestro Sales Director y una respuesta honesta sobre si esto encaja con su arquitectura.
Matt Collett
Sales Director
Perfecto, elija un horario que le venga bien:
Otros problemas que cubre esta serie
-
Puntos débiles de Azure Data Factory: el coste oculto de los pipelines visuales y de Spark
Azure Data Factory es una buena capa de transporte dentro de Azure y un lugar inadecuado para almacenar la lógica de un data warehouse. Usarlo como suite de modelado y transformación genera lienzos imposibles de interpretar, releases que fallan en plantillas ARM y clústeres Spark para cargas que caben en una consulta SQL. Y cada pipeline queda atado a Azure.
-
¿Cuestan sus Mapping Data Flows de Azure Data Factory más que los datos que mueven?
Los Mapping Data Flows se ejecutan sobre un clúster de Spark gestionado que tarda varios minutos en arrancar y factura por hora de vCore. Para una gran transformación nocturna tiene sentido. Para unos pocos cientos de miles de filas, es un clúster arrancado para hacer lo que una sola sentencia SQL resolvería dentro del data warehouse.
-
¿Ha superado el lienzo de Azure Data Factory la capacidad de gestión de su equipo?
Un pipeline construido mediante arrastrar y soltar se crea rápido, pero se adapta con lentitud. Al superar unas docenas de actividades, el lienzo se convierte en la documentación, las conexiones reemplazan a la lógica de negocio y cada nuevo origen es otra actividad de copia que nadie quiere tocar. La solución no es un lienzo más ordenado, sino un modelo que genere los pipelines.
Preguntas y respuestas
- Es control de versiones más un paso de publicación, y el paquete de utilidades de ADF puede ejecutarlo de forma desatendida en cada merge en lugar de mediante clics en la interfaz. Lo que valida es la plantilla. El artefacto final sigue siendo JSON de pipeline con un archivo de parámetros por entorno, y una referencia que existe en Dev pero no en Prod no se detecta hasta el momento del despliegue. La diferencia es una release generada a partir de un modelo que conoce las dependencias de cada cambio, con el rollback incluido.
- No. Genera el paquete de despliegue de base de datos; Azure DevOps o GitHub Actions siguen ejecutando la release. Lo que desaparece es la plantilla mantenida a mano y los archivos de parámetros por entorno.
- Una columna de origen que desaparece se carga como null con una advertencia en lugar de fallar, y una columna que crece se amplía. Una columna nueva requiere solo actualizar el mapeo. Ninguno de estos casos exige una nueva release de la capa de pipelines.