Data Factory - wandent/mutual-wiki GitHub Wiki
[[TOC]]
El componente principal en Azure Data Factory para describir procesos de integraciones de datos es el pipeline. Basicamente, describe la coordinación de varios otros pipelines, o la coordinación de tareas de carga, controle de flujo o transformación de datos.
En el modelo propuesto, si tiene para cada escenario de integración de datos, un pipeline que coordina los procesos desde la ingesta a el área de land, la transformación a datos confiables y el refinamiento.
Un pipeline es construído a partir de várias actividades coordinadas por un flujo de controle. Los tipos de actividades pueden ser:
- Coordinación de otros pipelines de integración.
- Databricks jobs, Batch jobs.
- Cargas de datos.
- Coordinación con Azure Functions para implementación de lógica compleja.
- Pipelines de datos sencillos, sin usar lógica de negocio compleja
- Batch
- Databricks Job
- Machine Learning
- Pipelines pueden pasar variables por entre las tareas y otros pipelines pueden utilizar las mismas variables para cambiar su comportamiento o pasar al pipeline llamador
Internamente Azure Data Factory aprovisiona el motor de cómputo necesario a ejecutar cada tipo de actividadem, a este motor llamamos de Integration Runtime. Revise la documentación para ver en cuales escenarios necesitamos de cada tipo. Como una descripción breve:
-
Auto-Resolve IR
- El servicio automáticamente aprovisiona el Integration runtime en el ambiente Azure para generar los recursos de cómputo necesarios a la ejecución de las tareas.
-
Self-Hosted IR
-
El motor de integration runtime es instalado manualmente, específicamente para integrar procesos en Data Factory con ambientes cerrados en redes privadas, o con el entorno On-Premises
-
https://docs.microsoft.com/en-us/azure/data-factory/concepts-integration-runtime
-
Necesita puerto 443 abierto en el firewall para comunicación con Azure Data Factory
-
En producción, debe de ser instalado en múltiples maquinas virtuales, para que opere como múltiples nodos apalancando una mejor escalabilidad y redundancia.
-
El Integration Runtime debe de ser instalado en la red mas cercana de las fuentes de datos o servidores que consumirán los recursos.
-
Sobre programación de databricks jobs con Data Factory y operacionalización de streaming
Puntos importantes sobre el proceso de desarrollo de los pipelines:
-
Todos los Azure Data Factory pipelines (a excepción delos que usan SSIS Runtime) son archivos Json internamente.
-
El código fuente debe de estar en un repositorio (git/Azure DevOps) para que Data Factory puede sincronizar y si necesario reverter a una otra versión.
-
Integración con Git/Azure DevOps: https://docs.microsoft.com/en-us/azure/data-factory/author-visually
-
CI/CD: https://docs.microsoft.com/en-us/azure/data-factory/continuous-integration-deployment
-
- Esto se aplicaría a procesos que carguen una gran cantidad de datos usando pipelines de copia datos en data factory. Efectivamente, se resume a utilizar un storage intermedio para inicialmente cargar los datos desde la fuente de una sola vez y después hacer la carga a la fuente de datos destino. Efectivamente staging es un recurso utilizado para acelerar procesos de carga moviendo gran parte de el esfuerzo de transformación de datos a un storage intermedio en la nube, y permitiendo que Azure Data Factory pueda escalar para cargas masivas de datos.
- Datos rechazados pueden ser enviados a una carpeta configurada en el pipeline, para actividades de copia.
- Databricks jobs pueden hacer lo mismo dentro de el código, por defecto cada carpeta en el area de Trusted/Refined deberá de tener una subcarpeta bad para los datos rechazados.
En Azure Data Factory los siguientes patrones de seguridad deberán de ser observados: Connections/Linked Services
-
SAS Token
-
Access Token
-
API key
-
SQL Server - SQL Authentication
-
Managed Service Identity – MSI https://docs.microsoft.com/en-us/azure/data-factory/concepts-roles-permissions https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
-
En algunos escenarios, específicamente utilizando storages ubicados en vnets distintas, Data Factory (cuando habilitado en la cuenta de storage) podrá comunicarse transparentemente (sin uso de vnet) desde que se autentique y que tenga permiso en el storage por intermedio de su Managed Service Identity.
https://docs.microsoft.com/en-us/azure/data-factory/data-factory-service-identity
https://docs.microsoft.com/en-us/azure/data-factory/data-movement-security-considerations
https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security
On premises / Private network to cloud ADF with Integration Runtime
- Incremental load
- Watermarked based (https://docs.microsoft.com/en-us/azure/data-factory/tutorial-incremental-copy-powershell)
- (si necesario) Ajustar el numero de Data Integration Units (antes DMUs) en cada copy data task. Cada unidad es una medida de poder de computación usado para leer, procesar y grabar los datos en su destino.
- Ajustar el paralelismo de acuerdo con la capacidad de los datos fuente para leer y grabar hacía el destino, y que el destino soporte múltiples grabaciones. Si alguno de ellos convirtiesen en un cuello de botella la configuración puede empeorar el rendimiento.
- Mantenga un control sobre las dependencias cuando paralelizando operaciones de copia de datos entre los pipelines.
https://docs.microsoft.com/pt-br/azure/data-factory/copy-activity-performance
- Telemetry and monitoring
- Data Factory Internal monitoring https://docs.microsoft.com/en-us/azure/data-factory/monitor-visually
https://docs.microsoft.com/en-us/azure/data-factory/monitor-programmatically
Pack for automating monitoring of ADF https://azuremarketplace.microsoft.com/en-us/marketplace/apps/Microsoft.AzureDataFactoryAnalytics?src=azserv&tab=Overview
- Design Patterns https://www.pass.org/Community/PASSBlog/tabid/1476/entryid/885/Introducing-Azure-Data-Factory-Design-Patterns.aspx
- Continuous Integration https://www.youtube.com/watch?v=WhUAX8YxxLk