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.
Databricks recomienda configurar las canalizaciones declarativas de Lakeflow Spark con Unity Catalog. El uso del catálogo de Unity es el valor predeterminado para las canalizaciones recién creadas.
Las canalizaciones configuradas con el catálogo de Unity publican todas las vistas materializadas definidas y las tablas de streaming en el catálogo y el esquema especificados. Las canalizaciones de Unity Catalog pueden leer otras tablas y volúmenes de Unity Catalog.
Para gestionar los permisos en las tablas creadas por un pipeline del Unity Catalog, utilice GRANT y REVOKE.
Nota:
En este artículo se describe la funcionalidad del modo de publicación predeterminado actual para las canalizaciones. Las canalizaciones creadas antes del 5 de febrero de 2025 pueden usar el modo de publicación antiguo y el esquema virtual LIVE. Consulte el esquema LIVE (heredado).
Requisitos
Para crear tablas de streaming y vistas materializadas en un esquema de destino en el catálogo de Unity, debe tener los permisos siguientes en el esquema y el catálogo primario:
- Privilegios
USE CATALOGen el catálogo de destino. - Privilegios
CREATE MATERIALIZED VIEWyUSE SCHEMAen el esquema de destino si la canalización crea vistas materializadas. - Privilegios
CREATE TABLEyUSE SCHEMAen el esquema de destino si la canalización crea tablas materializadas. - Si la canalización crea nuevos esquemas, debe tener los privilegios
USE CATALOGyCREATE SCHEMAen el catálogo de destino.
Requisitos de proceso para ejecutar una canalización habilitada para el catálogo de Unity:
- El recurso de proceso debe configurarse con el modo de acceso estándar. No se admite el proceso dedicado. Consulte Modos de acceso.
El cómputo necesario para consultar las tablas creadas por canalizaciones mediante el catálogo de Unity (incluidas las tablas de streaming y las vistas materializadas) incluye alguna de las siguientes:
- Almacenes de SQL
- Proceso con modo de acceso estándar en Databricks Runtime 13.3 LTS o superior.
- Proceso del modo de acceso dedicado, si el control de acceso específico está habilitado en el proceso dedicado (es decir, se ejecuta en Databricks Runtime 15.4 o versiones posteriores y el proceso sin servidor está habilitado para el área de trabajo). Para obtener más información, consulte Control de acceso granular en la computación dedicada.
- Proceso en modo de acceso dedicado desde 13.3 LTS hasta 15.3, solo si el propietario de la tabla ejecuta la consulta.
Se aplican limitaciones de proceso adicionales. Consulte la sección siguiente.
Limitaciones
A continuación se muestran las limitaciones del uso de Unity Catalog con canalizaciones:
- De forma predeterminada, solo el propietario de la canalización y los administradores del área de trabajo pueden ver los registros de controladores del proceso que ejecuta una canalización habilitada para Unity Catalog. Para permitir que otros usuarios accedan a los registros de controladores, consulte Permitir a los usuarios que no son administradores ver los registros de controladores desde una canalización habilitada para catálogo de Unity.
- Las canalizaciones existentes que usan el metastore de Hive no se pueden actualizar para usar el catálogo de Unity. Para migrar una canalización existente que escribe en metastore de Hive, debe crear una nueva canalización y volver a ingerir datos de los orígenes de datos. Consulte Creación de una canalización de Unity Catalog mediante la clonación de una canalización de metastore de Hive.
- No se puede crear una canalización habilitada para Unity Catalog en un área de trabajo asociada a una tienda de metadatos creada durante la versión preliminar pública de Unity Catalog. Consulte Actualización a la herencia de privilegios.
- No se admiten los JAR. Solo se admiten bibliotecas de Python de terceros. Consulte Administración de dependencias de Python para canalizaciones.
- No se admiten las consultas del lenguaje de manipulación de datos (DML) que modifican el esquema de una tabla de streaming.
- Una vista materializada creada en una canalización no se puede usar como origen de streaming fuera de esa canalización, por ejemplo, en otra canalización o en un cuaderno de bajada.
- Los datos de las vistas materializadas y las tablas de streaming se almacenan en la ubicación de almacenamiento del esquema contenedor. Si no se especifica una ubicación de almacenamiento de esquema, las tablas se almacenan en la ubicación de almacenamiento del catálogo. Si no se especifican ubicaciones de almacenamiento de esquema y catálogo, las tablas se almacenan en la ubicación de almacenamiento raíz del metastore.
- La pestaña Historial del Explorador de catálogos no muestra el historial de las vistas materializadas.
- La propiedad
LOCATIONno se admite al definir una tabla. - Las canalizaciones habilitadas para el catálogo de Unity no se pueden publicar en el metastore de Hive.
- La compatibilidad con UDF de Python está en versión preliminar pública.
Nota:
Los archivos subyacentes que admiten vistas materializadas pueden incluir datos de tablas ascendentes (incluida la posible información de identificación personal) que no aparecen en la definición de vista materializada. Estos datos se agregan automáticamente al almacenamiento subyacente para admitir la actualización incremental de las vistas materializadas.
Dado que los archivos subyacentes de una vista materializada podrían arriesgarse a exponer datos de tablas ascendentes que no forman parte del esquema de la vista materializada, Databricks recomienda no compartir el almacenamiento subyacente con consumidores descendentes que no son de confianza.
Por ejemplo, supongamos que una definición de vista materializada incluye una COUNT(DISTINCT field_a) cláusula . Aunque la definición de la vista materializada solo incluye la cláusula de agregado COUNT DISTINCT, los archivos subyacentes contendrán una lista de los valores reales de field_a.
¿Puedo usar canalizaciones de metastore de Hive y Unity Catalog juntas?
El área de trabajo puede contener canalizaciones que usan Unity Catalog o el metastore de Hive. Sin embargo, una sola canalización no puede escribir en el metastore de Hive y en Unity Catalog. Las canalizaciones existentes que escriben en el metastore de Hive no se pueden actualizar para usar Unity Catalog. Para migrar una canalización existente que escribe en metastore de Hive, debe crear una nueva canalización y volver a ingerir datos de los orígenes de datos. Consulte Creación de una canalización de Unity Catalog mediante la clonación de una canalización de metastore de Hive.
Las canalizaciones existentes que no usan el catálogo de Unity no se ven afectadas por la creación de nuevas canalizaciones configuradas con el catálogo de Unity. Estas canalizaciones continúan conservando los datos en el metastore de Hive mediante la ubicación de almacenamiento configurada.
A menos que se especifique lo contrario en este documento, todos los orígenes de datos existentes y la funcionalidad de canalización se admiten con canalizaciones que usan el catálogo de Unity. Las interfaces de Python y SQL son compatibles con pipelines que utilizan Unity Catalog.
Tablas inactivas
Cuando se configura una canalización para conservar los datos en el catálogo de Unity, la canalización administra el ciclo de vida y los permisos de la tabla.
Las tablas pueden volverse inactivas si se quita su definición de un pipeline. La siguiente actualización de canalización marca como inactiva la entrada correspondiente en una tabla de transmisión o vista materializada.
Si cambia el esquema o catálogo predeterminado de la canalización y no usa nombres de tabla completos en el código fuente de la canalización, la siguiente ejecución de canalización crea la vista materializada o la tabla de streaming en el nuevo catálogo o esquema, y la vista materializada anterior o la tabla de streaming en la ubicación antigua se marca como inactiva.
Todavía puede consultar tablas inactivas, pero la canalización ya no las actualiza. Para limpiar las vistas materializadas o las tablas de streaming, explícitamente DROP la tabla. Las tablas inactivas se eliminarán cuando se elimine la canalización.
- Puede recuperar tablas eliminadas en un plazo de 7 días mediante el
UNDROPcomando . - Para mantener el comportamiento heredado en el que se elimina la entrada de la vista materializada o de la tabla de streaming de Unity Catalog durante la próxima actualización de la canalización, establezca la configuración de la canalización
"pipelines.dropInactiveTables": "true". Los datos reales se conservan durante un período para que se puedan recuperar si se eliminan por error. Los datos se pueden recuperar dentro de los 7 días agregando la vista materializada o la tabla de streaming a la definición de la canalización.
Al eliminar la canalización por completo (en lugar de quitar una definición de tabla del origen de la canalización), también se eliminan todas las tablas definidas en esa canalización. La interfaz de usuario le pide que confirme la eliminación de una canalización.
Escribir tablas en el catálogo de Unity desde una canalización
Para escribir las tablas en Unity Catalog, debe configurar la canalización para que funcione con ella a través del área de trabajo. Al crear una canalización, seleccione Catálogo de Unity en Opciones de almacenamiento, seleccione un catálogo en el menú desplegable Catálogo y seleccione un esquema existente o escriba el nombre de un nuevo esquema en el menú desplegable Esquema de destino. Para más información sobre los catálogos de Unity, consulte ¿Qué son los catálogos en Azure Databricks?. Para obtener información sobre los esquemas en el catálogo de Unity, consulte ¿Qué son los esquemas en Azure Databricks?.
Ingesta de datos en una canalización de Unity Catalog
La tubería configurada para usar Unity Catalog puede leer datos de:
- Tablas administradas y externas de Unity Catalog, vistas, vistas materializadas y tablas de streaming.
- Tablas y vistas de metastore de Hive.
- Cargador automático mediante la función
read_files()para leer desde ubicaciones externas de Unity Catalog. - Apache Kafka y Amazon Kinesis.
A continuación se muestran ejemplos de lectura de tablas de catálogo de Unity y metastore de Hive.
Ingesta por lotes desde una tabla de catálogo de Unity
SQL
CREATE OR REFRESH MATERIALIZED VIEW
table_name
AS SELECT
*
FROM
my_catalog.my_schema.table1;
Pitón
@dp.materialized_view
def table_name():
return spark.read.table("my_catalog.my_schema.table")
Transmisión de cambios desde una tabla de Catálogo de Unity
SQL
CREATE OR REFRESH STREAMING TABLE
table_name
AS SELECT
*
FROM
STREAM(my_catalog.my_schema.table1);
Pitón
@dp.table
def table_name():
return spark.readStream.table("my_catalog.my_schema.table")
Ingesta de datos del metastore de Hive
Una canalización que usa El catálogo de Unity puede leer datos de tablas de metastore de Hive mediante el catálogo de hive_metastore:
SQL
CREATE OR REFRESH MATERIALIZED VIEW
table_name
AS SELECT
*
FROM
hive_metastore.some_schema.table;
Pitón
@dp.materialized_view
def table3():
return spark.read.table("hive_metastore.some_schema.table")
Ingesta de datos del cargador automático
SQL
CREATE OR REFRESH STREAMING TABLE table_name
AS SELECT *
FROM STREAM read_files(
"/path/to/uc/external/location",
format => "json"
)
Pitón
@dp.table(table_properties={"quality": "bronze"})
def table_name():
return (
spark.readStream.format("cloudFiles")
.option("cloudFiles.format", "json")
.load(f"{path_to_uc_external_location}")
)
Compartir vistas materializadas
De forma predeterminada, solo el propietario de la canalización tiene permiso para consultar los conjuntos de datos creados por la canalización. Puede proporcionar a otros usuarios la capacidad de consultar una tabla mediante instrucciones GRANT y puede revocar el acceso de consulta mediante instrucciones REVOKE. Para obtener más información sobre los privilegios en el catálogo de Unity, consulte Administrar privilegios en el catálogo de Unity.
Conceder selección en una tabla
GRANT SELECT ON TABLE
my_catalog.my_schema.table_name
TO
`user@databricks.com`
Revocar selección en una tabla
REVOKE SELECT ON TABLE
my_catalog.my_schema.table_name
FROM
`user@databricks.com`
Concesión de privilegios de vista materializada o creación de una tabla de creación
GRANT CREATE { MATERIALIZED VIEW | TABLE } ON SCHEMA
my_catalog.my_schema
TO
{ principal | user }
Visualización del linaje de una canalización
El linaje de las tablas definidas en canalizaciones está visible en el Explorador de catálogos. La interfaz de usuario del linaje de Catalog Explorer muestra las tablas ascendentes y descendentes para las vistas materializadas o las tablas de streaming en una canalización habilitada para Unity Catalog. Para más información sobre el linaje del catálogo de Unity, consulte Visualización del linaje de datos mediante el catálogo de Unity.
Para una vista materializada o una tabla de streaming en una canalización habilitada para Unity Catalog, la interfaz de usuario del linaje de Catalog Explorer también se vinculará a la canalización que produjo la vista materializada o la tabla de streaming si la canalización es accesible desde el área de trabajo actual.
Agregar, cambiar o eliminar datos en una tabla de streaming
Puede usar instrucciones del lenguaje de manipulación de datos (DML), incluidas instrucciones insert, update, delete y merge, para modificar las tablas de streaming publicadas en el Catálogo de Unity. La compatibilidad con consultas DML en tablas de streaming permite casos de uso como la actualización de tablas para el cumplimiento del Reglamento general de protección de datos (RGPD).
Nota:
- No se admiten instrucciones DML que modifican el esquema de tabla de una tabla de streaming. Asegúrese de que las instrucciones DML no intenten evolucionar el esquema de la tabla.
- Las instrucciones DML que actualizan una tabla de streaming solo se pueden ejecutar en un clúster compartido de Unity Catalog o en un almacenamiento de SQL mediante Databricks Runtime 13.3 LTS y versiones posteriores.
- Dado que el streaming requiere orígenes de datos de solo anexión, si el procesamiento requiere streaming desde una tabla de streaming de origen con cambios (por ejemplo, por instrucciones de DML), establezca la marca skipChangeCommits al leer la tabla de streaming de origen. Cuando se establezca
skipChangeCommits, se omitirán las transacciones que eliminen o modifiquen registros de la tabla de origen. Si el procesamiento no requiere una tabla de streaming, puede usar una vista materializada (que no tiene la restricción de solo anexión) como tabla de destino.
A continuación se muestran ejemplos de instrucciones DML para modificar registros en una tabla de streaming.
Elimine los registros con un identificador específico:
DELETE FROM my_streaming_table WHERE id = 123;
Actualice los registros con un identificador específico:
UPDATE my_streaming_table SET name = 'Jane Doe' WHERE id = 123;
Publicar tablas con filtros de fila y máscaras de columna
Los filtros de fila permiten especificar una función que se aplica como filtro cada vez que un examen de tabla captura filas. Estos filtros garantizan que las consultas posteriores solo devuelven filas para las que el predicado de filtro se evalúa como true.
Las máscaras de columna permiten enmascarar los valores de una columna cada vez que un examen de tabla captura filas. Las consultas futuras para esa columna devuelven el resultado de la función evaluada en lugar del valor original de la columna. Para obtener más información sobre el uso de filtros de fila y máscaras de columna, consulte Filtros de fila y máscaras de columna.
Administración de filtros de fila y máscaras de columna
Los filtros de fila y las máscaras de columna en vistas materializadas y tablas de streaming deben agregarse, actualizarse o quitarse a través de la instrucción CREATE OR REFRESH.
Para obtener una sintaxis detallada sobre cómo definir tablas con filtros de fila y máscaras de columna, consulte Referencia del lenguaje SQL de Pipeline y Referencia del lenguaje Python de las Canalizaciones Declarativas Lakeflow Spark.
Comportamiento
A continuación se muestran detalles importantes al usar filtros de fila o máscaras de columna en una canalización:
-
Actualizar como propietario: cuando una actualización de canalización actualiza una vista materializada o una tabla de streaming, las funciones de filtro de fila y máscara de columna se ejecutan con los derechos del propietario de la canalización. Esto significa que la actualización de la tabla usa el contexto de seguridad del usuario que creó la canalización. Las funciones que comprueban el contexto del usuario (como
CURRENT_USERyIS_MEMBER) se evalúan mediante el contexto de usuario del propietario de la canalización. -
Consulta: al consultar una vista materializada o una tabla de streaming, las funciones que comprueban el contexto del usuario (como
CURRENT_USERyIS_MEMBER) se evalúan mediante el contexto de usuario del invocador. Este enfoque aplica controles de acceso y seguridad de datos específicos del usuario en función del contexto del usuario actual. - Al crear vistas materializadas sobre tablas de origen que contienen filtros de fila y máscaras de columna, la actualización de la vista materializada siempre es una actualización completa. Una actualización completa vuelve a procesar todos los datos disponibles en el origen con las definiciones más recientes. Este proceso comprueba que las directivas de seguridad de las tablas de origen se evalúan y se aplican con los datos y definiciones más actualizados.
Observability
Use DESCRIBE EXTENDED, INFORMATION_SCHEMA, o el Explorador de catálogos para examinar los filtros de fila y las máscaras de columna existentes que se aplican a una vista materializada o a una tabla de streaming determinada. Esta funcionalidad permite a los usuarios auditar y revisar las medidas de acceso y protección de datos en vistas materializadas y tablas de streaming.