El Dominio 4 del temario oficial de DP-900 incluye "Describir consideraciones para la ingesta y el procesamiento de datos". El análisis empieza por reunir los datos, así que la diferencia entre ETL y ELT, las canalizaciones y los componentes de Azure Data Factory y las formas de llevar datos a Microsoft Fabric aparecen con regularidad. Son especialmente habituales las preguntas que piden distinguir componentes con nombres parecidos, como los servicios vinculados, los conjuntos de datos y los entornos de ejecución de integración.
Este artículo es un complemento de Servicios de análisis a gran escala de nuestra serie de estudio de DP-900. Partiendo de la introducción a ETL, ELT y Data Factory que se hizo allí, trata cómo elegir entre los dos enfoques, qué hace cada componente de Data Factory, cómo ingieren datos Fabric y Databricks, y HDInsight, que todavía aparece a menudo en materiales antiguos y en preguntas de práctica.
---
¿Qué es la ingesta de datos? ETL y ELT de nuevo
Imagina un centro de distribución de paquetería. Los paquetes se recogen por todo el país (extracción), se clasifican por tamaño y región (transformación) y se colocan en las estanterías del almacén (carga). Si la clasificación se hace antes de que los paquetes entren en el almacén, es ETL; si todo entra primero en el almacén y se clasifica dentro, es ELT.
| Aspecto | ETL (extraer → transformar → cargar) | ELT (extraer → cargar → transformar) | |------|------|------| | Dónde se transforma | Antes de cargar, en un motor de procesamiento aparte | Después de cargar, dentro del almacén analítico | | Datos sin procesar | A menudo solo se guarda el resultado transformado | Los datos sin procesar se conservan tal cual y se transforman cuando hace falta | | Almacén al que encaja | Un almacenamiento de datos relacional con esquema fijo | Almacenes con mucha capacidad de proceso, como lagos de datos y lakehouses | | Ventaja | Solo entran datos limpios | Rápido con grandes volúmenes; los datos se pueden volver a transformar de otra forma más adelante | | Ejemplo | Limpiar los datos con flujos de datos de Data Factory y cargarlos en SQL Database | Copiar archivos sin procesar a un lakehouse y transformarlos después con Spark o SQL |
La transformación suele ejecutarse en paralelo en sistemas distribuidos formados por varios nodos. El lugar donde se guardan los resultados intermedios durante la transformación se llama área de preparación (staging o tabla de staging) y permite validar y limpiar los datos sin cargar el sistema de origen. La ingesta abarca tanto el procesamiento por lotes de datos estáticos reunidos como el procesamiento en streaming de eventos a medida que llegan.
Consejo para el examen: "Copiar primero los datos al almacén analítico y luego transformarlos con la capacidad de proceso del almacén" → ELT. "Limpiar los datos y ajustar su formato antes de cargarlos" → ETL.
---
Los componentes de Azure Data Factory
Azure Data Factory es un servicio de integración de datos (ETL) en la nube para crear flujos de trabajo de movimiento y transformación de datos y ejecutarlos según una programación. Los nombres de sus componentes se parecen lo suficiente como para confundir en el examen, así que usa el diagrama y la tabla para separar sus funciones.
!Componentes de una canalización de Azure Data Factory
| Componente | Función | Analogía | |------|------|------| | Canalización (pipeline) | Agrupación lógica de actividades que juntas realizan una unidad de trabajo | Una ficha de receta | | Actividad | Un paso de procesamiento dentro de una canalización | Cada paso de la receta | | Conjunto de datos (dataset) | Estructura y ubicación de los datos que una actividad usa como entrada o salida | La lista de ingredientes | | Servicio vinculado | Información de conexión a un almacén de datos o servicio de proceso (parecida a una cadena de conexión) | La dirección y el pase del supermercado | | Entorno de ejecución de integración (integration runtime) | El entorno de proceso donde se ejecutan las actividades; el puente entre actividades y servicios vinculados | La cocina donde se cocina | | Desencadenador (trigger) | La condición que inicia una ejecución de la canalización | La hora a la que empiezas a cocinar | | Flujo de datos de asignación | Lógica de transformación diseñada visualmente sin código, que se ejecuta automáticamente en clústeres de Spark | Una receta ilustrada |
Un servicio vinculado responde a "¿dónde y cómo me conecto?", mientras que un conjunto de datos responde a "¿qué datos de ahí dentro?". Por ejemplo, la cadena de conexión de una cuenta de almacenamiento va en un servicio vinculado, y un contenedor y una carpeta concretos de esa cuenta van en un conjunto de datos.
Tres tipos de actividades
Actividades de movimiento de datos: la actividad Copy copia datos entre almacenes locales y en la nube. Actividades de transformación de datos: procesan datos con flujos de datos de asignación, notebooks de Databricks, procedimientos almacenados, consultas Hive de HDInsight y más. Actividades de control: controlan el flujo encadenando pasos en secuencia, bifurcando con If Condition, repitiendo con ForEach o ejecutando otra canalización.
Entornos de ejecución de integración y desencadenadores
| Entorno de ejecución de integración | Uso | |------|------| | Azure | Mover datos entre almacenes en la nube y ejecutar flujos de datos | | Autohospedado | Acceder a datos locales o dentro de una red privada | | Azure-SSIS | Ejecutar tal cual paquetes SSIS (SQL Server Integration Services) existentes |
| Desencadenador | Cuándo se ejecuta la canalización | |------|------| | Programación | A horas e intervalos fijos (por ejemplo, todos los días a las 2 de la madrugada) | | Ventana de saltos constante (tumbling window) | Intervalos fijos que no se solapan; se pueden volver a ejecutar ventanas pasadas | | Evento de almacenamiento | Cuando se crea o elimina un blob | | Evento personalizado | Cuando llega un evento personalizado a través de Event Grid |
También puedes ejecutar una canalización manualmente (a petición) sin desencadenador. Las canalizaciones se pueden implementar mediante CI/CD con Azure DevOps o GitHub, y sus éxitos y fallos se supervisan con Azure Monitor.
Consejo para el examen: "Copiar datos de un SQL Server local con Data Factory" → entorno de ejecución de integración autohospedado. "El componente que contiene la información de conexión" → servicio vinculado. "Ejecutar una canalización cada vez que se sube un archivo" → desencadenador de evento de almacenamiento.
---
Formas de llevar datos a Microsoft Fabric
Fabric ofrece varias formas de llevar datos a OneLake. Si los datos se copian de verdad, y si se mantienen sincronizados, es lo que decide cuál usar.
| Método | Qué hace | Copia datos | Elígelo cuando | |------|------|------|------| | Canalizaciones de Fabric Data Factory | Orquestan movimiento y transformación en varios pasos, en secuencia o en paralelo | Sí | ETL o ELT por lotes típico | | Dataflow Gen2 | Transformación sin código creada con Power Query | Sí | Transformaciones reutilizables sin código | | Accesos directos de OneLake | Hacen referencia a ADLS Gen2, Amazon S3, Google Cloud Storage y otros sin moverlos | No | Los datos deben quedarse en su ubicación original | | Creación de reflejo (mirroring) | Replica de forma continua y casi en tiempo real Azure SQL Database, Cosmos DB, Snowflake y otros | Sí (automática) | Bases de datos operativas listas para análisis sin canalizaciones | | Eventstream | Ingiere en tiempo real eventos de Event Hubs, Kafka e IoT Hub | Sí | Datos de streaming | | Notebooks | Ingesta y transformación directas con código PySpark, Python o SQL | Sí | No hay conector o la lógica es compleja |
Fabric Data Factory es la siguiente generación de Azure Data Factory y usa el mismo modelo de canalizaciones, así que tus conocimientos se mantienen. La diferencia es que donde Azure Data Factory usa servicios vinculados, Fabric usa conexiones. Si el destino es un servicio fuera de Fabric, como Azure SQL Database, o trabajas en un entorno híbrido sin Fabric, usa el servicio independiente Azure Data Factory.
Consejo para el examen: "Consultar datos de Amazon S3 desde un lakehouse de Fabric sin copiarlos" → acceso directo de OneLake. "Seguir replicando una Azure SQL Database de producción en OneLake sin canalizaciones" → creación de reflejo.
---
Ingesta y procesamiento en Azure Databricks y HDInsight
Azure Databricks
En Azure Databricks, las canalizaciones de Lakeflow te permiten declarar qué deben contener las tablas de salida, y Databricks gestiona por ti el orden de ejecución, las dependencias y el procesamiento incremental. Encajan con la ingesta de producción por lotes y en streaming. Para ingestas exploratorias o puntuales, los notebooks de PySpark o SQL leen de API REST, orígenes JDBC y almacenamiento en la nube y escriben en tablas de Delta Lake.
Azure HDInsight
HDInsight ejecuta en Azure, como clústeres administrados, marcos de big data de código abierto como Apache Spark, Hive, LLAP, Kafka, HBase y Hadoop. No aparece en el temario actual, pero los materiales de estudio antiguos y las preguntas lo incluyen a menudo en escenarios como "llevar tal cual a la nube un ecosistema Hadoop existente".
| Servicio | Características | Elígelo cuando | |------|------|------| | Azure Data Factory | Canalizaciones sin código, muchos conectores integrados, conectividad híbrida | Integración de datos fuera de Fabric, orígenes locales | | Fabric Data Factory | Canalizaciones y Dataflow Gen2 dentro de Fabric | Llevar datos a OneLake para analizarlos en Fabric | | Azure Databricks | Basado en Spark, canalizaciones de Lakeflow y notebooks | Procesamiento a gran escala centrado en código, Delta Lake | | Azure HDInsight | Clústeres administrados para marcos de código abierto | Llevar tal cual trabajos existentes de Hadoop, Hive o Kafka |
Consejo para el examen: "Ejecutar trab