Sugerencias, recomendaciones y características para desarrollar y probar canalizaciones de Delta Live Tables

En este artículo se describen los patrones que puede usar para desarrollar y probar canalizaciones de Delta Live Tables. A través de la configuración de canalización, Delta Live Tables permite especificar configuraciones para aislar las canalizaciones en entornos de desarrollo, pruebas y producción. Las recomendaciones de este artículo se aplican al desarrollo de código de SQL y Python.

Databricks recomienda usar parámetros para escribir código extensible de Delta Live Tables. Esto es especialmente útil para escribir código portátil entre entornos de desarrollo, pruebas y prod. Por ejemplo, puede apuntar las canalizaciones en los datos de prueba con problemas conocidos para probar la resistencia del código. Consulte Control de orígenes de datos con parámetros.

Uso del modo de desarrollo para ejecutar actualizaciones de canalización

Delta Live Tables tiene un botón de alternancia de interfaz de usuario para controlar si las actualizaciones de canalización se ejecutan en modo de desarrollo o producción. Este modo controla cómo se procesan las actualizaciones de canalización, entre las que se incluyen:

• El modo de desarrollo no finaliza inmediatamente los recursos de proceso después de que una actualización se realice correctamente o se produzca un error. Puede reutilizar los mismos recursos de proceso para ejecutar varias actualizaciones de canalización sin esperar a que se inicie un clúster.
• El modo de desarrollo no vuelve a intentarlo automáticamente en caso de error de tarea, lo que le permite detectar y corregir errores lógicos o sintácticos en la canalización inmediatamente.

Databricks recomienda usar el modo de desarrollo durante el desarrollo y las pruebas. Sin embargo, al implementar en un entorno de producción, cambie siempre al modo de producción.

Consulte Modos de desarrollo y producción.

Probar el código fuente de la canalización sin esperar a que se actualicen las tablas

Para comprobar si hay problemas con el código fuente de la canalización, como errores de sintaxis y análisis durante el desarrollo y las pruebas, puede ejecutar una actualización de validación. Dado que una actualización de Validate solo comprueba que el código fuente de la canalización sea correcto sin ejecutar una actualización real en ninguna tabla, puede identificar y corregir problemas más rápidamente antes de ejecutar una actualización de canalización real.

Especificación de un esquema de destino durante todas las fases del ciclo de vida de desarrollo

Todos los conjuntos de datos de una canalización de Delta Live Tables hacen referencia al LIVE esquema virtual, que no es accesible fuera de la canalización. Si se especifica un esquema de destino, el esquema virtual de LIVE apunta al esquema de destino. Debe especificar un esquema de destino para revisar los resultados escritos en cada tabla durante una actualización.

Debe especificar un esquema de destino que sea único para su entorno. Cada tabla de un esquema determinado solo se puede actualizar mediante una sola canalización.

Puede aislar estos entornos mediante la creación de canalizaciones independientes para desarrollo, pruebas y producción con distintos destinos. El uso del parámetro de esquema de destino permite quitar la lógica que usa interpolación de cadenas u otros widgets o parámetros para controlar los orígenes de datos y los destinos.

Consulte Uso del catálogo de Unity con las canalizaciones de Delta Live Tables y Uso de canalizaciones de Delta Live Tables con metastore de Hive heredado.

Uso de carpetas de Git de Databricks para administrar canalizaciones de Delta Live Tables

Databricks recomienda usar carpetas de Git durante el desarrollo, las pruebas y la implementación de canalizaciones de Delta Live Tables en producción. Las carpetas de Git habilitan lo siguiente:

• Realizar un seguimiento de cómo cambia el código con el tiempo.
• Combinar los cambios que realizan varios desarrolladores.
• Prácticas de desarrollo de software, como las revisiones de código.

Databricks recomienda configurar un único repositorio de Git para todo el código relacionado con una canalización.

Cada desarrollador debe tener su propia carpeta de Git de Databricks configurada para el desarrollo. Durante el desarrollo, el usuario configura su propia canalización desde su carpeta Git de Databricks y prueba una nueva lógica mediante conjuntos de datos de desarrollo y ubicaciones aisladas. Después de completar el trabajo de desarrollo, el usuario confirma e inserta los cambios de nuevo en su rama en el repositorio central de Git y abre una solicitud de incorporación de cambios en la rama de pruebas o control de calidad.

La rama resultante debe desprotegirse en una carpeta de Git de Databricks y se debe configurar una canalización mediante conjuntos de datos de prueba y un esquema de desarrollo. Suponiendo que la lógica se ejecuta según lo previsto, se debe preparar una solicitud de incorporación de cambios o una rama de versión para insertar los cambios en producción.

Aunque las carpetas de Git se pueden usar para sincronizar el código entre entornos, la configuración de canalización debe mantenerse actualizada manualmente o usar herramientas como Terraform.

Este flujo de trabajo es similar al uso de carpetas de Git para CI/CD en todos los trabajos de Databricks. Consulte Técnicas de CI/CD con carpetas de Git y Databricks Git (Repositorios).

Segmentar el código fuente para los pasos de ingesta y transformación

Databricks recomienda aislar las consultas que ingieren datos de la lógica de transformación que enriquecen y validan los datos. Si organiza el código fuente para ingerir datos de orígenes de datos de desarrollo o pruebas en un directorio independiente de la lógica de ingesta de datos de producción, puede configurar canalizaciones para varios entornos con conjuntos de datos específicos de esos entornos. Por ejemplo, puede acelerar el desarrollo mediante conjuntos de datos más pequeños para realizar pruebas. Consulte Creación de conjuntos de datos de ejemplo para desarrollo y pruebas.

También puede usar parámetros para controlar los orígenes de datos para el desarrollo, las pruebas y la producción. Consulte Uso de parámetros con canalizaciones de Delta Live Tables.

Dado que las canalizaciones de Delta Live Tables usan el LIVE esquema virtual para administrar todas las relaciones del conjunto de datos, configurando canalizaciones de desarrollo y pruebas con código fuente de ingesta que carga datos de ejemplo, puede sustituir los conjuntos de datos de ejemplo mediante nombres de tabla de producción para probar el código. La misma lógica de transformación se puede usar en todos los entornos.

Creación de conjuntos de datos de ejemplo para desarrollo y pruebas

Databricks recomienda crear conjuntos de datos de desarrollo y pruebas para probar la lógica de canalización con datos esperados y registros potencialmente incorrectos o dañados. Hay varias maneras de crear conjuntos de datos que pueden ser útiles para el desarrollo y las pruebas, incluidos los siguientes:

• Seleccione un subconjunto de datos de un conjunto de datos de producción.
• Use datos anonimizados o generados artificialmente para orígenes que contienen información de identificación personal.
• Cree datos de prueba con resultados bien definidos en función de la lógica de transformación de bajada.
• Anticipe posibles daños en los datos, registros con formato incorrecto y cambios de datos ascendentes mediante la creación de registros que interrumpen las expectativas del esquema de datos.

Por ejemplo, si tiene un cuaderno que define un conjunto de datos mediante el código siguiente:

CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM read_files("/production/data", "json")

Puede crear un conjunto de datos de ejemplo que contenga registros específicos mediante una consulta como la siguiente:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading

En el ejemplo siguiente se muestra el filtrado de datos publicados para crear un subconjunto de los datos de producción para desarrollo o pruebas:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY

Para usar estos conjuntos de datos diferentes, cree varias canalizaciones con los cuadernos que implementan la lógica de transformación. Cada canalización puede leer datos del conjunto de datos LIVE.input_data, pero está configurada para incluir el cuaderno que crea el conjunto de datos específico del entorno.