Compartir vía

Uso de tablas de streaming en Databricks SQL

Databricks recomienda usar tablas de streaming para ingerir datos mediante Databricks SQL. Una tabla de streaming es una tabla registrada en el Unity Catalog con compatibilidad adicional con el procesamiento de datos incremental o streaming. Se crea automáticamente una canalización para cada tabla de streaming. Puede usar tablas de streaming para la carga incremental de datos desde Kafka y el almacenamiento de objetos en la nube.

Nota:

Para obtener información sobre el modo de uso de las tablas de Delta Lake como orígenes y receptores de streaming, consulte Lecturas y escrituras de streaming de tablas de Delta.

Requisitos

Para usar tablas de streaming, es necesario cumplir los siguientes requisitos.

Requisitos del área de trabajo:

Las tablas de streaming creadas en Databricks SQL están respaldadas por canalizaciones sin servidor. El área de trabajo debe admitir canalizaciones sin servidor para usar esta funcionalidad.

Requisitos de proceso:

Debe usar uno de los siguientes:

  • Un almacén de SQL que usa el canal Current.
  • Calcular con el modo de acceso estándar (anteriormente modo de acceso compartido) en Databricks Runtime 13.3 LTS o superior.

  • Proceso con el modo de acceso dedicado (anteriormente modo de acceso de usuario único) en Databricks Runtime 15.4 LTS o posteriores.

    En Databricks Runtime 15.3 y versiones posteriores, no puede usar el proceso dedicado para consultar tablas de streaming que pertenecen a otros usuarios. Puede usar computación dedicada en Databricks Runtime 15.3 y versiones anteriores solo si posee la tabla de streaming. El creador de la tabla es el propietario.

    Databricks Runtime 15.4 LTS y versiones posteriores admiten la consulta de tablas generadas por canalizaciones en un proceso dedicado, incluso si no es el propietario de la tabla. Se puede cobrar por los recursos de proceso sin servidor cuando se usa un proceso dedicado para ejecutar operaciones de filtrado de datos. Consulte Control de acceso detallado en la computación dedicada.

Requisitos de permisos:

  • USE CATALOG y USE SCHEMA privilegios en el catálogo y el esquema en el que se crea la tabla de streaming.
  • El privilegio CREATE TABLE en el esquema en el que se crea la tabla de streaming.
  • Privilegios para acceder a las tablas o ubicaciones que proporcionan los datos de origen de la tabla de streaming.

Creación de tablas de streaming

Una tabla de streaming se define mediante una consulta SQL en Databricks SQL. Al crear una tabla de streaming, los datos que se encuentran actualmente en las tablas de origen se usan para compilar la tabla de streaming. Después de eso, usualmente actualizas la tabla según un horario para extraer los datos añadidos en las tablas de origen y sumarlos a la tabla de streaming.

Al crear una tabla de streaming, se te considera el propietario de la tabla.

Para crear una tabla de streaming a partir de una tabla existente, use la CREATE STREAMING TABLE instrucción , como en el ejemplo siguiente:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT product, price FROM STREAM raw_data;

En este caso, la tabla de streaming sales se crea a partir de columnas específicas de la tabla raw_data, con una planificación para actualizarse cada hora. La consulta usada debe ser una consulta de streaming . Use la palabra clave STREAM para usar la semántica de streaming para leer desde el origen.

Al crear una tabla de streaming mediante la instrucción CREATE OR REFRESH STREAMING TABLE, la actualización inicial de datos y la población comienzan inmediatamente. Estas operaciones no consumen capacidad computacional del almacén de datos DBSQL. En su lugar, las tablas de transmisión se basan en canalizaciones sin servidor para la creación y actualización. El sistema crea y administra automáticamente una canalización sin servidor dedicada para cada tabla de streaming.

Carga de archivos con cargador automático

Para crear una tabla de streaming a partir de archivos de un volumen, use el cargador automático. Use Auto Loader para la mayoría de las tareas de ingesta de datos desde el almacenamiento de objetos en la nube. El cargador automático y las canalizaciones están diseñados para cargar datos cada vez mayores de forma incremental e idempotente a medida que llegan al almacenamiento en la nube.

Para usar la función read_files en Databricks SQL, usa Auto Loader. En los ejemplos siguientes se muestra el uso de Auto Loader para leer un volumen de archivos JSON en una tabla de streaming:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT * FROM STREAM read_files(
    "/Volumes/my_catalog/my_schema/my_volume/path/to/data",
    format => "json"
  );

Para leer datos del almacenamiento en la nube, también puede usar el cargador automático:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    'abfss://myContainer@myStorageAccount.dfs.core.windows.net/analysis/*/*/*.json',
    format => "json"
  );

Para obtener información sobre Auto Loader, consulte ¿Qué es Auto Loader?. Para más información sobre el uso del cargador automático en SQL, con ejemplos, consulte Carga de datos desde el almacenamiento de objetos.

Ingesta de streaming desde otros orígenes

Para ver un ejemplo de ingestión desde otros orígenes, incluido Kafka, consulte en Carga de datos en canalizaciones.

Ingerir solo nuevos datos

De forma predeterminada, la función read_files lee todos los datos existentes en el directorio de origen durante la creación de la tabla y, a continuación, procesa los registros recién llegados con cada actualización.

Para evitar la ingesta de datos que ya existen en el directorio de origen en el momento de la creación de la tabla, establezca la opción includeExistingFiles en false. Esto significa que solo se procesan los datos que llegan al directorio después de que se procese la creación de la tabla. Por ejemplo:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    '/path/to/files',
    includeExistingFiles => false
  );

Establecer el canal en tiempo de ejecución

Las tablas de streaming creadas mediante almacenes de SQL se actualizan automáticamente mediante una canalización. Las canalizaciones usan el entorno de ejecución en el canal current de forma predeterminada. Consulte las notas de la versión y el proceso de actualización de las canalizaciones declarativas de Spark de Lakeflow para obtener información sobre el proceso de lanzamiento.

Databricks recomienda usar el canal current para cargas de trabajo de producción. Las nuevas características se publican por primera vez en el canal de preview. Puede establecer una canalización en el canal de versión preliminar para probar las nuevas características especificando preview como una propiedad de tabla. Puede especificar esta propiedad al crear la tabla o después de crear la tabla mediante una instrucción ALTER.

En el ejemplo de código siguiente se muestra cómo establecer el canal en versión preliminar en una instrucción CREATE:

CREATE OR REFRESH STREAMING TABLE sales
  TBLPROPERTIES ('pipelines.channel' = 'preview')
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM raw_data;

Programar actualizaciones de tablas de streaming

Puede configurar una tabla de streaming de SQL de Databricks para actualizarse automáticamente en función de una programación definida o desencadenarse cuando se cambian los datos ascendentes.

Para establecer una programación o un desencadenador, realice una de las acciones siguientes:

  • Configure la programación con la SCHEDULE cláusula al crear la tabla de streaming.
  • Configure un desencadenador con la TRIGGER ON UPDATE cláusula al crear la tabla.
  • Agregue o modifique programaciones o desencadenadores con la ALTER STREAMING TABLE instrucción .

Nota:

Como alternativa, cree una tarea en un trabajo que incluya la CREATE OR REFRESH STREAMING TABLE instrucción o REFRESH y la organice como haría con cualquier otro trabajo. Consulte Trabajos de Lakeflow.

Al crear una programación, Azure Databricks crea automáticamente un nuevo trabajo para procesar la actualización.

Para ver la programación, realice una de las siguientes acciones:

  • Ejecute la instrucción DESCRIBE EXTENDED desde el editor de SQL en la interfaz de usuario de Azure Databricks. Consulte DESCRIBE TABLE.
  • Use el Explorador de catálogos para ver la tabla de streaming. La programación aparece en la pestaña Información general, en Estado de actualización. Consulte ¿Qué es el Explorador de catálogos?.

Incluso con una programación de actualización, puede ejecutar una actualización manual en cualquier momento si necesita datos actualizados.

Ocultar datos confidenciales

Puede usar tablas de streaming para ocultar datos confidenciales de los usuarios que acceden a la tabla. Un enfoque consiste en definir la consulta para que excluya las columnas o filas confidenciales por completo. Como alternativa, puede aplicar máscaras de columna o filtros de fila en función de los permisos del usuario que consulta. Por ejemplo, podría ocultar la tax_id columna para los usuarios que no están en el grupo HumanResourcesDept. Para ello, use la sintaxis ROW FILTER y MASK durante la creación de la tabla de streaming. Para obtener más información, consulte Filtros de fila y máscaras de columna.

Actualización de una tabla de streaming

Las actualizaciones se pueden programar automáticamente al crear la tabla de streaming. También puede actualizar manualmente las tablas de streaming. Incluso si tiene una actualización programada, puede llamar a una actualización manual en cualquier momento. Las actualizaciones se gestionan con la misma canalización que se creó automáticamente junto con la tabla de streaming.

Para actualizar una tabla de streaming:

REFRESH STREAMING TABLE sales;

Puede comprobar el estado de la actualización más reciente con DESCRIBE TABLE EXTENDED.

Nota:

Es posible que tenga que actualizar la tabla de streaming antes de usar consultas de viaje en el tiempo.

Funcionamiento de la actualización

Una actualización de tabla de streaming solo evalúa las nuevas filas que han llegado desde la última actualización y anexa solo los nuevos datos.

Cada actualización usa la definición actual de la tabla de streaming para procesar estos nuevos datos. La modificación de una definición de tabla de streaming no vuelve a calcular automáticamente los datos existentes. Si una modificación no es compatible con los datos existentes (por ejemplo, cambiar un tipo de datos), se producirá un error en la siguiente actualización.

En los ejemplos siguientes se explica cómo los cambios en una definición de tabla de streaming afectan al comportamiento de actualización:

  • Al quitar un filtro no se volverán a procesar las filas filtradas previamente.
  • Cambiar las proyecciones de columna no afectará a la forma en que se procesaron los datos existentes.
  • Las uniones con instantáneas estáticas utilizan el estado de la instantánea durante el procesamiento inicial. Los datos de llegada tardía que habrían coincidido con la instantánea actualizada se omitirán. Esto puede provocar que se omitan hechos si las dimensiones son tardías.
  • La modificación del CAST de una columna existente producirá un error.

Si los datos cambian de forma que no se puedan admitir en la tabla de streaming existente, puede realizar una actualización completa.

Actualización completa de una tabla de streaming

Las actualizaciones completas vuelven a procesar todos los datos disponibles en el origen con la definición más reciente. No se recomienda llamar a actualizaciones completas en orígenes que no conserven todo el historial de los datos ni tengan períodos de retención cortos, como Kafka, porque la actualización completa trunca los datos existentes. Es posible que no pueda recuperar datos antiguos si los datos ya no están disponibles en el origen.

Por ejemplo:

REFRESH STREAMING TABLE sales FULL;

Cambiar la programación de una tabla de streaming

Puede configurar una tabla de streaming de SQL de Databricks para actualizarse automáticamente en función de una programación definida o desencadenarse cuando se cambian los datos ascendentes. En la tabla siguiente se muestran las distintas opciones para programar actualizaciones.

Método Description Ejemplo de caso de uso
Manual Actualización a petición mediante una instrucción SQL REFRESH o a través de la interfaz de usuario del área de trabajo. Desarrollo, pruebas, actualizaciones ad hoc.
TRIGGER ON UPDATE Defina la tabla de streaming para actualizar automáticamente cuando cambien los datos ascendentes. Cargas de trabajo de producción con SLA de frescura de datos o períodos de actualización impredecibles.
SCHEDULE Defina la tabla de streaming para actualizar en intervalos de tiempo definidos. Requisitos de actualización predecibles y basados en tiempo.
Tarea SQL en un trabajo La actualización se orquesta a través de Lakeflow Jobs. Canalizaciones complejas con dependencias entre sistemas.

Actualización manual

Para actualizar manualmente una tabla de streaming, puede llamar a una actualización desde Databricks SQL o usar la interfaz de usuario del área de trabajo.

Instrucción REFRESH

Para actualizar una canalización mediante Databricks SQL:

  1. En el icono editor de consultas.Editor de SQL, ejecute la instrucción siguiente:

    REFRESH MATERIALIZED VIEW <table-name>;

Para obtener más información, vea REFRESH (MATERIALIZED VIEW o STREAMING TABLE).

Interfaz de usuario del área de trabajo

Para refrescar una canalización en la interfaz de usuario del área de trabajo:

  1. En el área de trabajo de Azure Databricks, haga clic en el icono Flujos de trabajo.Trabajos y canalizaciones.
  2. Seleccione la canalización que desea actualizar en la lista.
  3. Haga clic en el botón de Inicio.

A medida que se actualiza la canalización, verá actualizaciones en la interfaz de usuario.

Desencadenador al actualizar

La TRIGGER ON UPDATE cláusula actualiza automáticamente una tabla de streaming cuando cambian los datos de origen ascendentes. Esto elimina la necesidad de coordinar las programaciones entre canalizaciones. La tabla de streaming se mantiene actualizada sin necesidad de que el usuario sepa cuándo finalizan los trabajos ascendentes ni mantener una lógica de programación compleja.

Este es el enfoque recomendado para las cargas de trabajo de producción, especialmente cuando las dependencias ascendentes no se ejecutan en programaciones predecibles. Una vez configurada, la tabla de streaming supervisa sus tablas de origen y se actualiza automáticamente cuando se detectan cambios en cualquiera de los orígenes ascendentes.

Limitaciones

  • Límites de dependencia ascendente: una tabla de streaming puede supervisar un máximo de 10 tablas ascendentes y 30 vistas ascendentes. Para más dependencias, divida la lógica entre varias tablas de streaming.
  • Límites del área de trabajo: Puede existir un máximo de 1000 tablas de streaming con TRIGGER ON UPDATE por área de trabajo. Póngase en contacto con el soporte técnico de Databricks si se necesitan más de 1000 tablas de streaming.
  • Intervalo mínimo: el intervalo de activación mínimo es de 1 minuto.

En los ejemplos siguientes se muestra cómo establecer un desencadenador al actualizar al definir una tabla de streaming.

Creación de una tabla de streaming con desencadenador al actualizar

Para crear una tabla de transmisión en tiempo real que se actualice automáticamente cuando cambien los datos de origen, incluya la cláusula TRIGGER ON UPDATE en la instrucción CREATE STREAMING TABLE.

En el siguiente ejemplo se crea una tabla de streaming que lee los pedidos de los clientes y se actualiza cada vez que se actualiza la tabla de origen orders.

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

Limitación de la frecuencia de actualización

Si los datos ascendentes se actualizan con frecuencia, use AT MOST EVERY para limitar la frecuencia con la que la vista se actualiza y limita los costos de proceso. Esto es útil cuando las tablas de origen se actualizan con frecuencia, pero los consumidores finales no necesitan datos en tiempo real. La palabra clave INTERVAL es obligatoria antes del valor de tiempo.

En el ejemplo siguiente se limita la tabla de streaming para actualizarse como máximo cada 5 minutos, incluso si los datos de origen cambian con más frecuencia:

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

Actualización programada

Las programaciones de actualización se pueden definir directamente en la definición de la tabla de streaming para actualizar la vista en intervalos de tiempo fijos. Este enfoque es útil cuando se conoce la cadencia de actualización de datos y se desea un tiempo de actualización predecible.

Cuando hay una programación de actualización, puede seguir ejecutando una actualización manual en cualquier momento si necesita datos actualizados.

Databricks admite dos sintaxis de programación: SCHEDULE EVERY para intervalos simples y SCHEDULE CRON para programación precisa. Las SCHEDULE palabras clave y SCHEDULE REFRESH son semánticamente equivalentes.

Para obtener más información sobre la sintaxis y el uso de la SCHEDULE cláusula , vea CREATE STREAMING TABLE cláusula SCHEDULE.

Cuando se crea una programación, se configura automáticamente un nuevo trabajo de Databricks para procesar la actualización.

Para ver la programación, realice una de las siguientes acciones:

  • Ejecute la instrucción DESCRIBE EXTENDED desde el editor de SQL en la interfaz de usuario de Azure Databricks. Consulte DESCRIBE TABLE.
  • Use el Explorador de catálogos para ver la tabla de streaming. La programación aparece en la pestaña Información general, en Estado de actualización. Consulte ¿Qué es el Explorador de catálogos?.

En los ejemplos siguientes se muestra cómo crear una tabla de streaming con una programación:

Programar cada intervalo de tiempo

En este ejemplo se programa una actualización una vez cada 5 minutos:

CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE EVERY 5 MINUTES
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

Programación mediante cron

En este ejemplo se programa una actualización cada 15 minutos, en la hora trimestral de la zona horaria UTC:

CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

Tarea SQL en un trabajo

Las actualizaciones de tablas de transmisión se pueden orquestar mediante trabajos de Databricks creando tareas SQL que incluyen REFRESH STREAMING TABLE comandos. Este enfoque integra las actualizaciones de la tabla de streaming en los flujos de trabajo de orquestación de trabajos existentes.

Hay dos maneras de crear un trabajo para actualizar las tablas de streaming:

  • En el Editor de SQL: escriba el REFRESH STREAMING TABLE comando y haga clic en el botón Programar para crear un trabajo directamente desde la consulta.
  • En la interfaz de usuario de trabajos: cree un nuevo trabajo, agregue un tipo de tarea SQL y adjunte una consulta SQL o un cuaderno con el REFRESH STREAMING TABLE comando .

En el ejemplo siguiente se muestra la instrucción SQL dentro de una tarea SQL que actualiza una tabla de streaming:

REFRESH STREAMING TABLE catalog.schema.sales;

Este enfoque es adecuado cuando:

  • Las canalizaciones complejas de varios pasos tienen dependencias entre sistemas.
  • Se requiere la integración con la orquestación de trabajos existente.
  • Se requieren alertas y supervisión a nivel de tarea.

Las tareas de SQL usan el SQL Warehouse adjunto al trabajo y el cómputo sin servidor que ejecuta el refresco. Si el uso de la programación basada en definiciones de tabla de streaming cumple los requisitos, cambiar a TRIGGER ON UPDATE o SCHEDULE puede simplificar el flujo de trabajo.

Adición de una programación a una tabla de streaming existente

Para establecer la programación después de la creación, use la sentencia ALTER STREAMING TABLE.

-- Alters the schedule to refresh the streaming table when its upstream
-- data gets updated.
ALTER STREAMING TABLE sales
  ADD TRIGGER ON UPDATE;

Modificación de una programación o desencadenador existente

Si una tabla de streaming ya tiene una programación o un desencadenador asociado, use ALTER SCHEDULE o ALTER TRIGGER ON UPDATE para cambiar la configuración de actualización. Esto se aplica si cambia de una programación a otra, un desencadenador a otro o si cambia entre una programación y un desencadenador.

En el ejemplo siguiente se cambia una programación existente para actualizarse cada 5 minutos:

ALTER STREAMING TABLE catalog.schema.my_table
  ALTER SCHEDULE EVERY 5 MINUTES;

Eliminar una programación o un disparador

Para quitar una programación, use ALTER ... DROP:

ALTER STREAMING TABLE catalog.schema.my_table
  DROP SCHEDULE;

Seguir el estado de una actualización

Puede ver el estado de una actualización de tabla de streaming viendo la canalización que gestiona la tabla de streaming en la interfaz de usuario de Pipelines o consultando la Información de Actualización proporcionada por el comando DESCRIBE EXTENDED para la tabla de streaming.

DESCRIBE TABLE EXTENDED <table-name>;

Como alternativa, puede ver la tabla de streaming en el Explorador de catálogos y ver el estado de actualización allí:

  1. Haga clic en el icono Datos.Catálogo en la barra lateral.
  2. En el árbol del Explorador de catálogos de la izquierda, abra el catálogo y seleccione el esquema donde se encuentra la tabla de streaming.
  3. Abra el elemento Tablas en el esquema seleccionado y haga clic en la tabla de streaming.

Desde aquí, puede usar las pestañas en el nombre de la tabla de streaming para ver y editar información sobre la tabla de streaming, entre las que se incluyen:

  • Estado e historial de actualización
  • Esquema de tabla
  • Datos de ejemplo (requiere un proceso activo)
  • Permissions
  • Linaje, incluyendo las tablas y canalizaciones de las que dependa esta tabla de streaming
  • Información sobre el uso
  • Monitores que creó para esta tabla de streaming

Tiempos de espera para las actualizaciones

Las actualizaciones de tablas de streaming se ejecutan con un tiempo de espera que limita cuánto tiempo se pueden ejecutar. En el caso de las tablas de streaming creadas o actualizadas a partir del 14 de agosto de 2025, el tiempo de espera se captura al actualizar ejecutando CREATE OR REFRESH.

  • Si se establece un STATEMENT_TIMEOUT, se usa ese valor. Consulte STATEMENT_TIMEOUT.
  • De lo contrario, se utiliza el tiempo de espera del almacén SQL para ejecutar el comando.
  • Si el almacén no tiene configurado un tiempo de espera, se aplica un valor predeterminado de 2 días.

El tiempo de espera se usa en la creación inicial, pero también en las actualizaciones programadas siguientes.

En el caso de las tablas de streaming que se actualizaron por última vez antes del 14 de agosto de 2025, el tiempo de espera se establece en 2 días.

Ejemplo: Establecimiento de un tiempo de espera para una actualización de tabla de streaming Puede controlar explícitamente cuánto tiempo se permite ejecutar una actualización de tabla de streaming estableciendo un tiempo de espera de nivel de instrucción al crear o actualizar la tabla:

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH STREAMING TABLE my_catalog.my_schema.my_st
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

Esto configura la tabla de streaming que se actualizará cada 12 horas y, si una actualización tarda más de 6 horas, agota el tiempo de espera y espera la siguiente actualización programada.

Cómo controlan los tiempos de espera de las actualizaciones programadas

Los tiempos de espera solo se sincronizan cuando explícitamente se ejecuta CREATE OR REFRESH.

  • Las actualizaciones programadas continúan usando el tiempo límite capturado durante la última ejecución CREATE OR REFRESH.
  • El cambio del tiempo de espera de almacenamiento por sí solo no afecta a las actualizaciones programadas existentes.

Importante

Después de cambiar un tiempo de espera de almacenamiento, vuelva a ejecutar CREATE OR REFRESH para aplicar el nuevo tiempo de espera a futuras actualizaciones programadas.

Control del acceso a las tablas de streaming

Las tablas de streaming admiten controles de acceso enriquecidos para admitir el uso compartido de datos, a la vez que evitan exponer datos potencialmente privados. Un propietario de la tabla de streaming o un usuario con el MANAGE privilegio puede conceder SELECT privilegios a otros usuarios. Los usuarios con SELECT acceso a la tabla de streaming no necesitan SELECT acceso a las tablas a las que hace referencia la tabla de streaming. Este control de acceso permite el uso compartido de datos al tiempo que controla el acceso a los datos subyacentes.

También puede modificar el propietario de una tabla de streaming.

Conceder privilegios a una tabla de streaming

Para conceder acceso a una tabla de streaming, use la GRANT instrucción :

GRANT <privilege_type> ON <st_name> TO <principal>;

privilege_type puede ser:

  • SELECT: el usuario puede SELECT la tabla de streaming.
  • REFRESH: el usuario puede REFRESH la tabla de streaming. Las actualizaciones se ejecutan mediante los permisos del propietario.

En el ejemplo siguiente se crea una tabla de streaming y se conceden privilegios de selección y actualización a los usuarios:

CREATE MATERIALIZED VIEW st_name AS SELECT * FROM source_table;

-- Grant read-only access:
GRANT SELECT ON st_name TO read_only_user;

-- Grand read and refresh access:
GRANT SELECT ON st_name TO refresh_user;
GRANT REFRESH ON st_name TO refresh_user;

Para más información sobre la concesión de privilegios en objetos protegibles de Unity Catalog, consulte Privilegios de Unity Catalog y objetos protegibles.

Revocar privilegios de una tabla de streaming

Para revocar el acceso desde una tabla de streaming, use la REVOKE instrucción :

REVOKE privilege_type ON <st_name> FROM principal;

Cuando se revocan privilegios en una tabla de origen al propietario de la tabla de streaming o a cualquier otro usuario al que se le haya concedido SELECT o MANAGE privilegios en la tabla de streaming, o se elimina la tabla de origen, el propietario de la tabla de streaming o el usuario al que se le ha concedido acceso todavía puede consultar la tabla de streaming. Sin embargo, se produce el siguiente comportamiento:

  • El propietario de la tabla de streaming u otros usuarios que han perdido el acceso a una tabla de streaming ya no pueden REFRESH la tabla de streaming, y la tabla de streaming quedará obsoleta.
  • Si se automatiza con una programación, la siguiente tarea programada REFRESH falla o no se ejecuta.

En el ejemplo siguiente se revoca el privilegio SELECT de read_only_user:

REVOKE SELECT ON st_name FROM read_only_user;

Cambiar el propietario de una tabla de streaming

Un usuario con MANAGE permisos en una tabla de streaming definida en Databricks SQL puede establecer un nuevo propietario a través del Explorador de catálogos. El nuevo propietario puede ser ellos mismos o una entidad de servicio en la que tienen el rol de usuario de la entidad de servicio.

  1. En el área de trabajo de Azure Databricks, haga clic en el icono Datos.Catálogo para abrir el Explorador de catálogos.

  2. Seleccione la tabla de streaming que desea actualizar.

  3. En la barra lateral derecha, en Acerca de esta tabla de streaming, busque el Propietario y haga clic en el icono del lápiz para editar.

    Nota:

    Si recibe un mensaje que le indica que actualice el propietario cambiando el usuario 'Ejecutar como' en la configuración de la canalización, entonces la tabla de transmisión se define en las canalizaciones declarativas de Spark de Lakeflow, no en Databricks SQL. El mensaje incluye un vínculo a la configuración de canalización, donde puede cambiar la opción Ejecutar como usuario.

  4. Seleccione un nuevo propietario para la tabla de streaming.

    Los propietarios automáticamente tienen privilegios MANAGE y SELECT en las tablas de streaming que poseen. Si va a establecer un principal de servicio como propietario de una tabla de streaming que posee y no tiene explícitamente SELECT o MANAGE privilegios en la tabla de streaming, este cambio provocaría que pierda todo el acceso a la tabla de streaming. En este caso, se le pedirá que proporcione explícitamente esos privilegios.

    Seleccione Conceder ADMINISTRAR y SELECT para aplicar estos en Guardar.

  5. Haga clic en Guardar para cambiar el propietario.

Se actualiza el propietario de la tabla de streaming. Todas las actualizaciones futuras se ejecutan con la identidad del nuevo propietario.

Cuando el propietario pierde privilegios en las tablas de origen

Si cambia el propietario y el nuevo propietario no tiene acceso a las tablas de origen (o se revocan los privilegios sobre las tablas de origen subyacentes), los usuarios aún pueden consultar la tabla de streaming. Sin embargo:

  • No pueden REFRESH la tabla de streaming.
  • Se producirá un error en la siguiente actualización programada de la tabla de streaming.

La pérdida de acceso a los datos de origen impide que se lean las actualizaciones, pero no invalida inmediatamente la tabla de streaming existente.

eliminar permanentemente registros de una tabla de streaming

Importante

La compatibilidad con la instrucción REORG con tablas de streaming se encuentra en versión preliminar pública.

Nota:

  • El uso de una instrucción REORG con una tabla de streaming requiere Databricks Runtime 15.4 y versiones posteriores.
  • Aunque puede usar la REORG instrucción con cualquier tabla de streaming, solo es necesario al eliminar registros de una tabla de streaming con vectores de eliminación habilitados . El comando no tiene ningún efecto cuando se usa con una tabla de streaming sin vectores de eliminación habilitados.

Para eliminar físicamente los registros del almacenamiento subyacente para una tabla de streaming con vectores de eliminación habilitados, como para el cumplimiento del RGPD, se deben realizar pasos adicionales para asegurarse de que una VACUUM operación se ejecuta en los datos de la tabla de streaming.

Para eliminar físicamente los registros del almacenamiento subyacente:

  1. Actualice los registros o elimine los registros de la tabla de streaming.
  2. Ejecute una instrucción REORG en la tabla de streaming y especifique el parámetro APPLY (PURGE). Por ejemplo, REORG TABLE <streaming-table-name> APPLY (PURGE);.
  3. Espere a que pase el período de retención de datos de la tabla de streaming. El período de retención de datos predeterminado es siete días, pero se puede configurar con la propiedad delta.deletedFileRetentionDuration tabla. Consulte Configurar la retención de datos para consultas de viajes en el tiempo.
  4. REFRESH la tabla de streaming. Consulte Actualizar una tabla de streaming. En un plazo de 24 horas a partir de la REFRESH operación, las tareas de mantenimiento de canalización, incluida la VACUUM operación necesaria para asegurarse de que los registros se eliminan permanentemente, se ejecutan automáticamente.

Supervisar ejecuciones mediante el historial de consultas

Puede usar la página del historial de consultas para acceder a los detalles y perfiles de consulta que pueden ayudarle a identificar consultas de bajo rendimiento y cuellos de botella en la canalización utilizada para ejecutar las actualizaciones de su tabla de streaming. Para obtener información general sobre el tipo de información disponible en los historiales de consultas y los perfiles de consulta, consulte Historial de consultas y Perfil de consulta.

Importante

Esta característica está en versión preliminar pública. Los administradores del área de trabajo pueden controlar el acceso a esta característica desde la página Vistas previas . Consulte Administración de versiones preliminares de Azure Databricks.

Todas las instrucciones relacionadas con las tablas de streaming aparecen en el historial de consultas. Puede usar el filtro desplegable Instrucción para seleccionar cualquier comando e inspeccionar las consultas relacionadas. Todas las CREATE instrucciones van seguidas de una REFRESH instrucción que se ejecuta de forma asincrónica en una tubería. Las instrucciones REFRESH suelen incluir planes de consulta detallados que proporcionan información sobre la optimización del rendimiento.

Para acceder a las instrucciones REFRESH en la interfaz de usuario del historial de consultas, siga estos pasos:

  1. Haga clic en el icono Historial. En la barra lateral izquierda, abra la interfaz de usuario del historial de consultas .
  2. Active la casilla REFRESH en el filtro desplegable instrucción.
  3. Haga clic en el nombre de la instrucción de consulta para ver los detalles de resumen, como la duración de la consulta y las métricas agregadas.
  4. Haga clic en Ver perfil de consulta para abrir el perfil de consulta. Consulte Perfil de consulta para obtener más información sobre cómo navegar por el perfil de consulta.
  5. Opcionalmente, puede usar los vínculos de la sección Origen de consulta para abrir la consulta o canalización relacionada.

También puede acceder a los detalles de la consulta mediante vínculos en el editor de SQL o desde un cuaderno asociado a un almacén de SQL.

Acceso a tablas de streaming desde clientes externos

Para acceder a tablas de transmisión desde clientes externos de Delta Lake o Iceberg que no admiten API abiertas, se puede usar el modo de compatibilidad. Modo de compatibilidad crea una versión de solo lectura de la tabla de streaming a la que puede acceder cualquier cliente Delta Lake o Iceberg.

Recursos adicionales

  • Last updated on