Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se proporciona información general sobre la sintaxis y el comportamiento heredados del esquema virtual LIVE.
El LIVE esquema virtual es una funcionalidad heredada de las canalizaciones declarativas de Spark de Lakeflow y se considera obsoleto. Todavía puede usar el modo de publicación heredado y el esquema virtual LIVE para las canalizaciones que se crearon con este modo.
Databricks recomienda migrar todas las canalizaciones al nuevo modo de publicación. Tiene dos opciones para la migración:
- Mueva tablas (incluidas las vistas materializadas y las tablas de streaming) de una canalización heredada a una canalización que use el modo de publicación predeterminado. Para obtener información sobre cómo mover tablas entre canalizaciones, consulte Movimiento de tablas entre canalizaciones.
- Habilite el modo de publicación predeterminado en una canalización que actualmente usa el modo de publicación heredado. Consulte Habilitar el modo de publicación por defecto en una canalización.
Ambos métodos son migraciones unidireccionales. No se pueden volver a migrar tablas al modo heredado.
La compatibilidad con el esquema virtual heredado LIVE y el modo de publicación heredado se quitarán en una versión futura de Azure Databricks.
Nota:
Las canalizaciones del modo de publicación heredadas se indican en el campo Resumen de la interfaz de usuario de configuración de canalizaciones declarativas de Spark de Lakeflow. También puede confirmar que una canalización usa el modo de publicación heredado si el target campo está establecido en la especificación JSON de la canalización.
No puede usar la interfaz de usuario de configuración de canalización para crear nuevas canalizaciones con el modo de publicación heredado. Si necesita implementar nuevas canalizaciones mediante la sintaxis de LIVE heredada, póngase en contacto con el representante de la cuenta de Databricks.
¿Qué es el esquema virtual LIVE?
Nota:
El LIVE esquema virtual ya no es necesario para analizar la dependencia del conjunto de datos en el modo de publicación predeterminado para canalizaciones declarativas de Spark de Lakeflow.
El esquema LIVE es un concepto de programación en las Canalizaciones Declarativas de Lakeflow Spark que define un límite virtual para todos los conjuntos de datos creados o actualizados en una canalización. Por diseño, el esquema de LIVE no está vinculado directamente a conjuntos de datos de un esquema publicado. En su lugar, el esquema de LIVE permite planear y ejecutar lógica en una canalización aunque un usuario no quiera publicar conjuntos de datos en un esquema.
En el modo de publicación heredado de canalizaciones, puede usar la palabra clave LIVE para hacer referencia a otros conjuntos de datos de la canalización actual para lecturas, por ejemplo, SELECT * FROM LIVE.bronze_table. En el modo de publicación predeterminado para las nuevas canalizaciones declarativas de Spark de Lakeflow, esta sintaxis se omite silenciosamente, lo que significa que los identificadores no calificados usan el esquema actual. Consulte Definir el catálogo y el esquema de destino.
Modo de publicación heredado para canalizaciones
El LIVE esquema virtual se utiliza con el modo de publicación legado para las canalizaciones declarativas de Lakeflow Spark. Todas las tablas creadas antes del 5 de febrero de 2025 usan el modo de publicación heredado de forma predeterminada.
En la tabla siguiente se describe el comportamiento de todas las vistas materializadas y las tablas de streaming creadas o actualizadas en una canalización en el modo de publicación heredado:
| Opción de almacenamiento | Ubicación de almacenamiento o catálogo | Esquema de destino | Comportamiento |
|---|---|---|---|
| Hive metastore | Ninguno especificado | Ninguno especificado | Los metadatos y los datos del conjunto de datos se almacenan en la raíz de DBFS. No se registran objetos de base de datos en el metastore de Hive. |
| Hive metastore | Una URI o una ruta de archivo al almacenamiento de objetos en la nube. | Ninguno especificado | Los metadatos y los datos del conjunto de datos se almacenan en la ubicación de almacenamiento especificada. No se registran objetos de base de datos en el metastore de Hive. |
| Hive metastore | Ninguno especificado | Un esquema existente o nuevo en el metastore de Hive. | Los metadatos y los datos del conjunto de datos se almacenan en la raíz de DBFS. Todas las vistas materializadas y las tablas de transmisión de la canalización se publican en el esquema especificado en el metastore de Hive. |
| Hive metastore | Una URI o una ruta de archivo al almacenamiento de objetos en la nube. | Un esquema existente o nuevo en el metastore de Hive. | Los metadatos y los datos del conjunto de datos se almacenan en la ubicación de almacenamiento especificada. Todas las vistas materializadas y las tablas de transmisión de la canalización se publican en el esquema especificado en el metastore de Hive. |
| Catálogo de Unity | Catálogo existente de Unity Catalog. | Ninguno especificado | Los metadatos y los datos del conjunto de datos se almacenan en la ubicación de almacenamiento predeterminada asociada al catálogo de destino. No se registran objetos de base de datos en el catálogo de Unity. |
| Catálogo de Unity | Catálogo existente de Unity Catalog. | Un esquema existente o nuevo en el catálogo de Unity. | Los metadatos y los datos del conjunto de datos se almacenan en la ubicación de almacenamiento predeterminada asociada al esquema o catálogo de destino. Todas las vistas materializadas y las tablas de transmisión de la canalización se publican en el esquema especificado en Unity Catalog. |
Actualización del código fuente desde el esquema LIVE
Las canalizaciones configuradas para ejecutarse con el nuevo modo de publicación predeterminado ignoran sin notificación la sintaxis del esquema LIVE. De forma predeterminada, todas las lecturas de tabla usan el catálogo y el esquema especificados en la configuración de canalización.
Para la mayoría de las canalizaciones existentes, este cambio de comportamiento no tiene ningún impacto, ya que el comportamiento del esquema virtual heredado LIVE también dirige las lecturas al catálogo y al esquema especificados en la configuración de canalización.
Importante
El código heredado con lecturas que aprovechan el catálogo y el esquema predeterminados del espacio de trabajo requiere actualizaciones del código. Tenga en cuenta la siguiente definición de vista materializada:
CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data
En el modo de publicación heredado, una lectura no calificada de la tabla raw_data usa el catálogo y el esquema predeterminados del área de trabajo, por ejemplo, main.default.raw_data. En el nuevo modo de canalización predeterminado, el catálogo y el esquema usados de forma predeterminada son los configurados en la configuración de canalización. Para asegurarse de que este código sigue funcionando según lo previsto, actualice la referencia para usar el identificador completo de la tabla, como en el ejemplo siguiente:
CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM main.default.raw_data
Trabajar con el registro de eventos para canalizaciones de modo de publicación heredado del Unity Catalog
Importante
El TVF event_log está disponible para canalizaciones de modo de publicación heredado que publican tablas en el Unity Catalog. El comportamiento predeterminado de las nuevas canalizaciones publica el registro de eventos en el catálogo de destino y el esquema configurados para la canalización. Consulte Consulta del registro de eventos.
Las tablas configuradas con metastore de Hive también tienen compatibilidad y comportamiento diferentes en el registro de eventos. Consulte Trabajar con el registro de eventos para canalizaciones de metastore de Hive.
Si la canalización publica tablas en Unity Catalog con el modo de publicación heredado, debe usar la event_logfunción con valores de tabla (TVF) para capturar el registro de eventos de la canalización. Para recuperar el registro de eventos de una canalización, pase el identificador de canalización o un nombre de tabla a la TVF. Por ejemplo, para recuperar los registros de eventos de la canalización con el identificador 04c78631-3dd7-4856-b2a6-7d84e9b2638b:
SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")
Para recuperar los registros de eventos de la canalización que creó o posee la tabla my_catalog.my_schema.table1:
SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))
Para llamar a la TVF, deberá usar un clúster compartido o una instancia de SQL Warehouse. Por ejemplo, puede usar el editor de SQL conectado a una instancia de SQL Warehouse.
Para simplificar la consulta de eventos de una canalización, el propietario de la canalización puede crear una vista a través de la TVF event_log. En el ejemplo siguiente, se crea una vista sobre el registro de eventos de una canalización. Esta vista se usa en las consultas de registro de eventos de ejemplo incluidas en este artículo.
Nota:
- El TVF
event_logsolo puede ser llamado por el propietario de la canalización. - No se puede usar la
event_logfunción con valores de tabla en una canalización o consulta para acceder a los registros de eventos de varias canalizaciones. - No se puede compartir una vista creada a través de la función con valores de tabla
event_logcon otros usuarios.
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");
Reemplace por <pipeline-ID> el identificador único de la canalización. Puede encontrar el ID en el panel Detalles de la Canalización en la interfaz de usuario de Canalizaciones Declarativas de Spark de Lakeflow.
Cada instancia de una ejecución de canalización se denomina actualización. A menudo, querrá extraer información de la actualización más reciente. Ejecute las consultas siguientes para buscar el identificador de la actualización más reciente y guardarlo en la vista temporal latest_update_id. Esta vista se usa en las consultas de registro de eventos de ejemplo incluidas en este artículo:
CREATE OR REPLACE TEMP VIEW latest_update AS SELECT origin.update_id AS id FROM event_log_raw WHERE event_type = 'create_update' ORDER BY timestamp DESC LIMIT 1;