Compartir a través de

Desarrollo de canalizaciones de Delta Live Tables

  • Artículo

El desarrollo y la prueba del código de canalización difieren de otras cargas de trabajo de Apache Spark. En este artículo se proporciona información general sobre la funcionalidad admitida, los procedimientos recomendados y las consideraciones al desarrollar código de canalización. Para obtener más recomendaciones y mejores prácticas, consulte Aplicación de las mejores prácticas de desarrollo de software & DevOps a las canalizaciones de Delta Live Table.

Nota

Debe agregar código fuente a una configuración de canalización para validar el código o ejecutar una actualización. Consulte Configuración de una canalización de Delta Live Tables.

¿Qué archivos son válidos para el código fuente de canalización?

El código de canalización de Delta Live Tables puede ser Python o SQL. Puede tener una combinación de archivos de código fuente de Python y SQL que respaldan una sola canalización, pero cada archivo solo puede contener un lenguaje. Consulte Desarrollo de código de canalización con Python y Desarrollo de código de canalización con SQL.

Puede usar cuadernos y archivos de área de trabajo al especificar código fuente para una canalización. Los archivos del área de trabajo representan scripts de Python o SQL creados en el IDE preferido o en el editor de archivos de Databricks. Consulte ¿Qué son los archivos del área de trabajo?.

Si desarrolla código de Python como módulos o bibliotecas, debe instalar e importar el código y, a continuación, llamar a métodos desde un cuaderno de Python o un archivo de área de trabajo configurados como código fuente. Consulte Administración de dependencias de Python para canalizaciones de Delta Live Tables.

Nota

Si necesita usar comandos SQL arbitrarios en un cuaderno de Python, puede usar el patrón de sintaxis spark.sql("<QUERY>") para ejecutar SQL como código de Python.

Las funciones del catálogo de Unity permiten registrar funciones arbitrarias definidas por el usuario de Python para su uso en SQL. Consulte las funciones definidas por el usuario (UDFs) en el catálogo de Unity .

Introducción a las características de desarrollo de Delta Live Tables

Delta Live Tables amplía y aprovecha muchas características de Azure Databricks y presenta nuevas características y conceptos. En la tabla siguiente se proporciona una breve introducción a los conceptos y características que admiten el desarrollo de código de canalización:

Característica Descripción
Modo de desarrollo Las nuevas canalizaciones están configuradas para ejecutarse en modo de desarrollo de forma predeterminada. Databricks recomienda usar el modo de desarrollo para el desarrollo y las pruebas interactivas. Consulte Modos de desarrollo y producción.
Validación Una actualización de Validate comprueba la exactitud del código fuente de la canalización sin ejecutar una actualización en ninguna tabla. Consulte Comprobación de errores de una canalización sin esperar a que las tablas se actualicen.
Cuaderno Los cuadernos configurados como código fuente para una canalización de Delta Live Tables proporcionan opciones interactivas para validar el código y ejecutar actualizaciones. Consulte Desarrollo y depuración de canalizaciones de Delta Live Tables en cuadernos.
Parámetros Aproveche los parámetros del código fuente y las configuraciones de canalización para simplificar las pruebas y la extensibilidad. Consulte Uso de parámetros con canalizaciones de Delta Live Tables.
Conjuntos de recursos de Databricks Los conjuntos de recursos de Databricks permiten mover configuraciones de canalización y código fuente entre áreas de trabajo. Consulte Conversión de una canalización de Delta Live Tables en un proyecto de Databricks Asset Bundle.

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 los orígenes que contienen PII.
  • Cree datos de prueba con resultados bien definidos en función de la lógica de transformación subsiguiente.
  • 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 cómo filtrar los 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 distintos conjuntos de datos, cree varias canalizaciones con los cuadernos que implementan la lógica de transformación. Cada canalización puede leer datos del conjunto de datos input_data, pero está configurada para incluir el cuaderno que crea el conjunto de datos específico del entorno.