Transformación de datos
En este artículo se proporciona una introducción e información general sobre la transformación de datos con Azure Databricks. La transformación de datos o la preparación de datos es un paso clave en todas las cargas de trabajo de ingeniería, análisis y aprendizaje automático de datos.
Los patrones de ejemplo y las recomendaciones de este artículo se centran en el trabajo con tablas de almacén de lago, que están respaldadas por Delta Lake. Dado que Delta Lake ofrece las garantías de ACID de un almacén de lago de Databricks, es posible que observe un comportamiento diferente al trabajar con datos en otros formatos o sistemas de datos.
Databricks recomienda ingerir los datos en un almacén de lago en estado sin procesar o casi sin procesar, y después aplicar las transformaciones y el enriquecimiento como un paso de procesamiento independiente. Este patrón se conoce como arquitectura medallion. Consulte ¿Qué es la arquitectura de la casa del lago medallion?.
Si sabe que los datos que necesita transformar aún no se han cargado en un almacén de lago, consulte Ingesta de datos en un almacén de lago de Databricks. Si está intentando encontrar datos del almacén de lago con los que escribir transformaciones, consulte Detección de datos.
Todas las transformaciones comienzan escribiendo una consulta de lote o de flujo con respecto a un origen de datos. Si no está familiarizado con la consulta de datos, consulte Consulta de datos.
Una vez que haya guardado los datos transformados en una tabla Delta, puede usar esa tabla como tabla de características para ML. Consulte Ingeniería de características y servicio.
Nota:
En estos artículos se tratan las transformaciones en Azure Databricks. Azure Databricks también admite conexiones a muchas plataformas comunes de preparación de datos. Consulte Conexión a partners de preparación de datos con Partner Connect.
Transformaciones de Spark frente a transformaciones de almacén de lago
Este artículo se centra en la definición de tranformaciones en su relación con la T en ETL o ELT. El modelo de procesamiento de Apache Spark también usa la palabra transformación de forma relacionada. Brevemente: en Apache Spark, todas las operaciones se definen como transformaciones o acciones.
- Transformaciones: agregar cierta lógica de procesamiento al plan. Algunos ejemplos incluyen la lectura de datos, combinaciones, agregaciones y conversión de tipos.
- Acciones: desencadenar la lógica de procesamiento para evaluar y generar un resultado. Algunos ejemplos son las escrituras, la visualización o la vista previa de los resultados, el almacenamiento en caché manual o la obtención del recuento de filas.
Apache Spark usa un modelo de ejecución retardada, lo que significa que no se evalúa ninguna de las lógicas definidas por una colección de operaciones hasta que se desencadena una acción. Este modelo tiene una ramificación importante a la hora de definir canalizaciones de procesamiento de datos: solo usar acciones para volver a guardar los resultados en una tabla de destino.
Dado que las acciones representan un cuello de botella de procesamiento para la optimización de la lógica, Azure Databricks ha agregado numerosas optimizaciones además de las ya presentes en Apache Spark para asegurar una ejecución óptima de la lógica. Estas optimizaciones tienen en cuenta todas las transformaciones desencadenadas por una acción determinada a la vez y encuentran el plan óptimo basándose en el diseño físico de los datos. El almacenamiento manual de los datos en caché o la devolución de los resultados de la vista previa en las canalizaciones de producción pueden interrumpir estas optimizaciones y provocar un aumento significativo de los costes y la latencia.
Por lo tanto, podemos definir una transformación de almacén de lago como cualquier colección de operaciones aplicadas a una o más tablas de almacén de lago que dan como resultado una nueva tabla de almacén de lago. Tenga en cuenta que, aunque las transformaciones como las combinaciones y las agregaciones se tratan por separado, puede combinar muchos de estos patrones en un único paso de procesamiento y confiar en los optimizadores de Azure Databricks para encontrar el plan más eficiente.
¿Cuáles son las diferencias entre el procesamiento por flujos y el procesamiento por lotes?
Aunque el procesamiento por lotes y el procesamiento de flujos usan en gran medida la misma sintaxis en Azure Databricks, cada uno tiene su propia semántica específica.
El procesamiento por lotes permite definir instrucciones explícitas para procesar una cantidad fija de datos estáticos y no cambiantes como una sola operación.
El procesamiento de flujos permite definir una consulta sobre un conjunto de datos ilimitado y en continuo crecimiento y después procesar los datos en pequeños lotes incrementales.
Las operaciones por lotes en Azure Databricks usan Spark SQL o DataFrames, mientras que el procesamiento de flujos aprovecha Structured Streaming.
Puede diferenciar los comandos por lotes de Apache Spark de los de Structured Streaming fijándose en las operaciones de lectura y escritura, como se muestra en la tabla siguiente:
| Apache Spark | Structured Streaming | |
|---|---|---|
| Leer | spark.read.load() |
spark.readStream.load() |
| Escribir | spark.write.save() |
spark.writeStream.start() |
Las vistas materializadas suelen ajustarse a las garantías del procesamiento por lotes, aunque se usa Delta Live Tables para calcular los resultados de forma incremental cuando es posible. Los resultados devueltos por una vista materializada son siempre equivalentes a la evaluación por lotes de la lógica, pero Azure Databricks intenta procesar estos resultados de forma incremental cuando es posible.
Las tablas de flujos siempre calculan los resultados de forma incremental. Dado que muchos orígenes de datos de flujos solo conservan los registros durante un periodo de horas o días, el modelo de procesamiento usado por las tablas de flujos asume que cada lote de registros de un origen de datos solo se procesa una vez.
Azure Databricks es compatible con el uso de SQL para escribir consultas de flujos en los siguientes casos de uso:
- Definición de tablas de flujos en Unity Catalog usando Databricks SQL.
- Definición del código fuente para canalizaciones de Delta Live Tables.
Nota:
También puede declarar tablas de flujos en Delta Live Tables mediante código de Structured Streaming de Python.
Transformaciones por lotes
Las transformaciones por lotes funcionan en un conjunto bien definido de recursos de datos en un momento dado específico. Las transformaciones por lotes pueden ser operaciones únicas, pero a menudo forman parte de trabajos programados o canalizaciones que se ejecutan con regularidad para mantener actualizados los sistemas de producción.
Transformaciones incrementales
Los patrones incrementales suelen suponer que el origen de datos es de solo anexión y tiene un esquema estable. En los artículos siguientes se proporcionan detalles sobre los matices de las transformaciones incrementales en tablas que experimentan actualizaciones, eliminaciones o cambios de esquema:
- API de APLICAR CAMBIOS: Simplifique la captura de datos modificados con Delta Live Tables
- Uso de la fuente de distribución de datos de cambios de Delta Lake en Azure Databricks
- Actualización del esquema de tabla de Delta Lake
- Lecturas y escrituras en streaming de tablas delta
Transformaciones en tiempo real
Delta Lake destaca por proporcionar un acceso casi en tiempo real a grandes cantidades de datos para todos los usuarios y aplicaciones que consultan su almacén de lago, pero debido a la sobrecarga que supone la escritura de archivos y metadatos en el almacenamiento de objetos en la nube, no se puede alcanzar una verdadera latencia en tiempo real para muchas cargas de trabajo que escriben en los receptores de Delta Lake.
Para aplicaciones de procesamiento de flujos de latencia extremadamente baja, Databricks recomienda elegir sistemas de origen y receptor diseñados para cargas de trabajo en tiempo real como Kafka. Puede usar Azure Databricks para enriquecer los datos, incluyendo agregaciones, combinaciones a través de flujos y combinaciones de datos en flujo con datos de dimensiones que cambian lentamente almacenados en el almacén de lago.