Diseño de la lógica de ingesta y la configuración del origen de datos

El diseño de la lógica de ingesta requiere que tome decisiones críticas sobre cómo se mueven los datos de los sistemas de origen a Azure Databricks. Estas decisiones afectan a la actualización de datos, la eficiencia del procesamiento y la confiabilidad del sistema. Antes de seleccionar herramientas o escribir código, debe comprender las características de los orígenes de datos y definir estrategias de extracción que se adapten a sus requisitos empresariales.

En esta unidad, explorará las consideraciones clave de diseño para la lógica de ingesta de datos y la configuración del origen de datos en Azure Databricks. El enfoque aquí se centra en la lógica conceptual y los patrones de diseño: los detalles de implementación y selección de herramientas específicos se tratan en unidades posteriores.

Descripción de los tipos de extracción

El tipo de extracción determina cómo capturas datos desde los sistemas de origen y afecta tanto a la oportunidad como a la eficiencia de la canalización de datos. Azure Databricks admite tres patrones de extracción principales, cada uno adecuado para diferentes escenarios.

Extracción completa

La extracción completa lee todo el conjunto de datos del sistema de origen durante cada ejecución de ingesta.

Este enfoque funciona bien cuando:

• Los sistemas de origen no admiten el seguimiento de cambios
• Los volúmenes de datos son lo suficientemente pequeños como para volver a procesar de forma eficaz
• Debe volver a generar tablas de destino desde cero periódicamente.
• Las relaciones de datos son complejas y una lógica incremental podría ser propensa a errores.

La extracción completa deja de ser práctico a medida que crecen los volúmenes de datos. Reprocesar millones de registros cuando solo se modificaron unos pocos miles desperdicia recursos computacionales y demora a los consumidores posteriores.

Extracción incremental

La extracción incremental procesa solo registros nuevos o modificados desde la última ejecución de ingesta. El motor realiza un seguimiento de los datos que se han procesado y solo consulta las actualizaciones.

Este patrón requiere:

• Indicador fiable de cambio en los datos de origen (timestamp, número de secuencia o columna de versión)
• Gestión de estado para seguir la última posición procesada
• Lógica para controlar los registros de llegada tardía o fuera de secuencia

La extracción incremental mejora significativamente la eficacia de los conjuntos de datos grandes. En lugar de leer millones de filas, es posible que solo procese miles de cambios por ejecución.

Extracción de streaming

La extracción de streaming proporciona una captura de datos casi en tiempo real a través del procesamiento continuo. En lugar de ejecutarse según una programación, los trabajos de streaming permanecen activos y procesan los registros a medida que llegan.

Considere la posibilidad de transmitir cuando:

• Los procesos empresariales requieren una actualización de datos medida en segundos o minutos
• Los sistemas de origen publican eventos en buses de mensajes o cambian feeds
• Debe reaccionar a los eventos a medida que se producen.

La extracción de streaming requiere una infraestructura siempre activada, pero ofrece la menor latencia para la disponibilidad de los datos.

Diseño para la captura de datos modificados

La captura de datos modificados (CDC) es un patrón de extracción especializado que captura cambios individuales de nivel de fila, incluidas inserciones, actualizaciones y eliminaciones. CDC difiere de la extracción incremental simple porque conserva el tipo de operación para cada cambio.

Al diseñar para CDC, tenga en cuenta cómo el sistema de origen genera registros de cambios:

• Registros de transacciones de base de datos: las bases de datos como SQL Server pueden exponer cambios de nivel de fila mediante su característica CDC basada en el registro de transacciones. Los sistemas descendentes, como Azure Databricks, pueden leer estos cambios y procesarlos como parte del pipeline de ingestión.
• Fuentes de datos de cambios: las tablas delta y algunas bases de datos, como Azure Cosmos DB, ofrecen un seguimiento de cambios integrado que revela modificaciones en las filas junto con metadatos.
• Instantáneas periódicas: Algunos sistemas no admiten CDC continuo, por lo que es necesario comparar instantáneas para determinar los cambios.

CDC habilita casos de uso que la extracción incremental simple no puede admitir. Puede replicar con precisión las eliminaciones, mantener los seguimientos de auditoría y procesar actualizaciones que modifican columnas clave.

Identificación de las características del tipo de archivo de origen

Cuando los datos llegan como archivos en lugar de provenir de sistemas transaccionales, el formato de archivo influye en el diseño del procesamiento. Cada formato tiene características distintas que afectan al procesamiento.

Formatos basados en texto

Los archivos CSV y JSON son formatos de origen comunes, ya que son legibles por el usuario y son ampliamente compatibles. Sin embargo, presentan desafíos para un procesamiento eficaz:

• Variabilidad del esquema: los archivos pueden tener órdenes de columna incoherentes, campos que faltan o variaciones de tipo de datos
• Sin eficacia de compresión: los formatos de texto normalmente consumen más almacenamiento que las alternativas binarias
• Sobrecarga de análisis: cada valor requiere la conversión de texto a tipo durante las lecturas.

Use formatos basados en texto cuando los sistemas de origen solo puedan producir estos formatos o cuando los volúmenes de datos sean lo suficientemente pequeños como para que no se apliquen problemas de eficiencia.

Formatos de columnas

Los archivos Parquet y ORC almacenan datos en formato columnar, lo que permite consultas analíticas eficaces. Estos formatos ofrecen:

• Compresión: el almacenamiento en columnas logra mejores relaciones de compresión mediante la agrupación de valores similares
• Poda de columnas: Las consultas solo leen las columnas que necesitan, lo que reduce la E/S
• Esquema incrustado: el archivo contiene metadatos que describen los nombres y tipos de columna.

Diseñe su ingesta para favorecer los formatos de origen en columnas cuando tenga control sobre cómo los sistemas ascendentes exportan los datos.

Formatos semiestructurados

Los archivos XML y JSON anidados representan datos jerárquicos que no se ajustan a una estructura tabular plana. Al ingerir datos semiestructurados:

• Planee la extracción o definición de esquemas.
• Determine si se va a aplanar la estructura o conservar el anidamiento.
• Tenga en cuenta las distintas estructuras de documento dentro del mismo origen.

Consideraciones sobre la conexión del origen de datos

La configuración del origen de datos define cómo Azure Databricks se conecta y autentica con sistemas de origen. El diseño debe abordar los patrones de seguridad de conexión, administración de credenciales y acceso.

Orígenes de almacenamiento de objetos en la nube

El almacenamiento en la nube (Azure Data Lake Storage, Amazon S3 o Google Cloud Storage) actúa como la zona de aterrizaje más común para la ingesta. Al configurar conexiones de almacenamiento:

• Utilice las ubicaciones externas del catálogo de Unity para gobernar el acceso a las rutas de almacenamiento.
• Configure los métodos de autenticación adecuados (identidad administrada, entidades de servicio o credenciales de almacenamiento).
• Diseñar estructuras de carpetas que admiten un procesamiento incremental eficaz.

La estructura de carpetas afecta significativamente a la eficacia de la forma en que Azure Databricks puede identificar y procesar archivos nuevos. Tenga en cuenta estos patrones:

Creación de particiones basada en fechas: organice los archivos por jerarquía de fechas para habilitar la eliminación de particiones durante las lecturas incrementales:

/data/sales/year=2025/month=11/day=28/
/data/sales/year=2025/month=11/day=29/

Esta estructura permite que las consultas examinen solo las particiones de fecha pertinentes en lugar de enumerar todos los archivos.

Organización basada en origen: al ingerir desde varios orígenes, separe los datos por el sistema de origen para simplificar la lógica de procesamiento:

/landing/erp/orders/
/landing/crm/customers/
/landing/web/clickstream/

Carpetas de estado de procesamiento: use carpetas independientes para realizar un seguimiento del estado de procesamiento de archivos:

/incoming/     # New files arrive here
/processing/   # Files currently being processed
/archive/      # Successfully processed files
/failed/       # Files that failed processing

Al diseñar estructuras de carpetas, tenga en cuenta lo siguiente:

• Sobrecarga de detección de archivos: estructuras planas con miles de archivos ralentizan las operaciones de enumeración. Las estructuras con particiones reducen los archivos que Azure Databricks deben enumerar.
• Compatibilidad del cargador automático: Azure Databricks Auto Loader realiza un seguimiento eficaz de los nuevos archivos en el almacenamiento en la nube. Estructura las carpetas para alinearse con la forma en que Auto Loader detecta y controla los archivos.
• Extracción de columnas de partición: use la creación de particiones de estilo hive (key=value) para que Azure Databricks pueda extraer automáticamente valores de partición como columnas sin analizar el contenido del archivo.

Orígenes de base de datos

La conexión a bases de datos transaccionales requiere consideraciones diferentes que el almacenamiento en la nube:

• Conectividad de red entre Azure Databricks y el servidor de bases de datos.
• Credenciales de autenticación almacenadas de forma segura (mediante secretos en lugar de valores codificados de forma rígida).
• Agrupación de conexiones y consulta pushdown capacidades.
• Impacto en el rendimiento del sistema de origen durante la extracción.

Orígenes de streaming

Los buses de mensajes y los flujos de eventos (como Azure Event Hubs u otras plataformas de mensajería comunes) requieren:

• Detalles y autenticación de la conexión del intermediario.
• Configuración del grupo de consumidores para el procesamiento paralelo.
• Gestión de compensaciones para monitorear la posición de consumo.
• Integración del registro de esquema para la validación de formato de mensaje.

Orígenes de aplicaciones SaaS

Las aplicaciones empresariales como Salesforce, ServiceNow o SAP exponen datos a través de API con características únicas:

• Límites de velocidad de API que restringen el rendimiento de extracción.
• Estrategias de paginación para grandes conjuntos de resultados.
• Flujos de autenticación (OAuth, claves de API o basados en certificados).
• Funcionalidades disponibles de seguimiento de cambios o webhook.

Aplicación de un marco de diseño controlado por requisitos

El diseño de ingesta eficaz comienza con el análisis de requisitos antes de seleccionar tipos de extracción o formatos de archivo. Use el siguiente marco repetible para guiar las decisiones de diseño.

Paso 1: Recopilar requisitos

Antes de tomar decisiones técnicas, responda a estas preguntas clave:

Categoría de requisito	Preguntas para responder
Volumen de datos	¿Cuántos datos existen en el origen? ¿Cuánto cambia entre ejecuciones? ¿Cuál es la tasa de crecimiento?
Requisitos de latencia	¿Cómo se deben actualizar los datos para los consumidores de nivel inferior? ¿Hay acuerdos de nivel de servicio para cumplir?
Capacidades de origen	¿La fuente admite seguimiento de cambios, CDC o solo extracción completa? ¿Qué formatos de archivo pueden producir?
Calidad de los datos	¿Cuál es la confiabilidad de los datos de origen? ¿Qué validación o limpieza se necesita?
Restricciones de red	¿Qué ancho de banda existe entre el origen y Azure Databricks? ¿Hay requisitos de firewall o VPN?
Implicaciones de costos	¿Cuáles son los costos de proceso, almacenamiento y transferencia de datos de diferentes enfoques?

Paso 2: Mapear requisitos al tipo de extracción

Use el análisis de requisitos para seleccionar el patrón de extracción adecuado:

Si sus requisitos indican...	A continuación, elija...
Volumen de datos pequeño (< 100 000 filas), sin seguimiento de cambios disponible, recompilación simple aceptable	Extracción completa
Gran volumen de datos, existe un indicador de cambio confiable (marca de tiempo/secuencia), frescura horaria o diaria suficiente	Extracción incremental
Se requiere frescura en tiempo real o casi en tiempo real, la fuente publica eventos, infraestructura de transmisión disponible	Extracción en streaming
Es necesario capturar eliminaciones y tipos de operaciones, se requiere registro de auditoría y la fuente admite la captura del registro de transacciones.	Extracción de CDC

Paso 3: Seleccionar el formato de archivo de origen

Cuando controle el formato de origen o necesite elegir un formato de zona de aterrizaje, coincida con el formato de sus necesidades:

Si su escenario implica...	A continuación, prefiera...
Grandes conjuntos de datos analíticos, consultas en columnas, necesitan compresión	Parquet
Interoperabilidad con muchos sistemas, se necesita legibilidad humana	CSV o JSON
Estructuras de datos jerárquicas o anidadas	JSON o XML
Streaming de alta frecuencia con evolución del esquema	Avro con registro de esquema

Paso 4: Validar el diseño

Antes de implementarlo, compruebe que el diseño aborda estos problemas:

• El tipo de extracción cumple los requisitos de latencia. Si no es así, los consumidores de nivel inferior reciben datos obsoletos, lo que puede provocar decisiones empresariales incorrectas o infracciones del Acuerdo de Nivel de Servicio.

• El enfoque escala para manejar el crecimiento proyectado de los datos. Si no es así, las canalizaciones que funcionan actualmente pueden producir errores o ralentizarse prohibitivamente a medida que aumentan los volúmenes de datos.

• Las funcionalidades del sistema de origen admiten el patrón elegido. Si no es así, la canalización produce un error en tiempo de ejecución o requiere soluciones alternativas costosas que agregan complejidad.

• Las estimaciones de costos están dentro de restricciones presupuestarias. Si no es así, la solución puede ser técnicamente sólida, pero financieramente impredecible para su uso en producción.

• Se prevé realizar controles de calidad de los datos del oleoducto. Si no es así, los datos dañados o no válidos se propagan a los sistemas de bajada, lo que provoca errores o análisis incorrectos.

Aplicar el marco: un ejemplo práctico

Una plataforma de comercio electrónico debe ingerir datos de pedidos. Los pedidos se almacenan en una base de datos postgreSQL y la empresa requiere informes por hora.

Paso 1: Recopilación de requisitos:

• Volumen: 50 000 nuevos pedidos diariamente, 2 millones de filas totales, 15% crecimiento anual.
• Latencia: Una hora de frescura aceptable para informes.
• Origen: PostgreSQL admite consultas basadas en marca de tiempo, pero no CDC nativos.
• Calidad: los datos de origen se validan en la entrada; limpieza mínima necesaria.
• Red: conectividad directa a través de Azure Private Link.
• Costo: Minimizar el uso de proceso; los costos de almacenamiento son secundarios.

Paso 2: Mapear al tipo de extracción:

Gran volumen con columna de marca de tiempo confiable y requisito de latencia por hora → Extracción incremental.

¿Por qué no los otros?

• Extracción completa: Reprocesar 2 millones de filas por hora desperdicia cálculo cuando solo cambian ~2000 pedidos por hora.
• Streaming: la latencia de una hora no justifica el costo de la infraestructura de streaming siempre activada.
• CDC: PostgreSQL no expone un CDC nativo del registro de transacciones, y el caso de uso no requiere seguimiento de eliminaciones ni de tipos de operación.

Paso 3: Seleccionar formato de archivo:

Los datos llegan a Azure Data Lake Storage para procesar → Parquet para un almacenamiento en columnas eficaz. Diseño particionado por fecha para el descubrimiento incremental → /landing/orders/year=2025/month=11/day=28/.

¿Por qué no los otros?

• CSV/JSON: tamaños de archivo más grandes, sin ventajas de compresión y rendimiento de consultas más lento para cargas de trabajo analíticas.
• Avro: Más adecuado para la transmisión con evolución de esquema; la ingesta por lotes no necesita sus funciones orientadas a la transmisión.
• XML: añade complejidad al análisis sin beneficios para los datos tabulares estructurados.

Paso 4: Validar el diseño:

• ✓ El incremental por hora cumple los requisitos de latencia de una hora.
• ✓ El procesamiento solo cambia las escalas de manera eficiente con el crecimiento.
• ✓ La columna PostgreSQL order_updated_at permite consultas incrementales.
• ✓ El procesamiento de miles frente a millones de filas reduce los costos de proceso.

Decisión final: extracción incremental mediante la columna order_updated_at timestamp, programada cada hora, almacenando los datos como archivos Parquet en Azure Data Lake Storage.

Sobre la base de esta base basada en requisitos, está listo para evaluar las herramientas específicas y los métodos de carga que implementan su diseño de ingestión.