Procedimientos recomendados de Unity Catalog

En este documento se proporcionan recomendaciones para usar el catálogo de Unity para satisfacer las necesidades de gobernanza de datos de forma más eficaz. Para obtener una introducción a la gobernanza de datos en Azure Databricks, consulte Gobernanza de datos con Azure Databricks. Para obtener una introducción al catálogo de Unity, consulte ¿Qué es el catálogo de Unity?.

Identidades

Las entidades de seguridad (usuarios, grupos y entidades de servicio) deben definirse en el nivel de cuenta de Azure Databricks para que se les asignen privilegios en los objetos protegibles de Unity Catalog. Databricks recomienda usar SCIM para aprovisionar entidades de seguridad en su cuenta de Azure Databricks a través del IdP.

Procedimientos recomendados:

• Evite el aprovisionamiento de SCIM en el espacio de trabajo (y desactive el ya existente). El aprovisionamiento directo de las entidades de seguridad en un área de trabajo debería reservarse para los entornos de trabajo heredados que no sean compatibles con Unity Catalog. Deberías gestionar el aprovisionamiento completamente a nivel de cuenta.

• Defina y administre grupos en el IdP. Deben ser coherentes con las definiciones de grupo organizativo.

  Los grupos funcionan de forma diferente a los usuarios y las entidades de servicio. Aunque los usuarios y las entidades de servicio que agregue a un espacio de trabajo se sincronizan automáticamente con su cuenta de Azure Databricks, los grupos a nivel de espacio de trabajo no se sincronizan. Si tiene grupos locales del área de trabajo, debe migrarlos manualmente a la cuenta, preferiblemente replicandolos en el IdP (si es necesario) y aprovisionándolos en la cuenta.

• Configure grupos para que pueda usarlos de forma eficaz para conceder acceso a los datos y otros elementos protegibles del catálogo de Unity. Evite las concesiones directas a los usuarios siempre que sea posible.

• Use grupos para asignar la propiedad a la mayoría de los objetos protegibles.

• Evite agregar usuarios manualmente a la cuenta o al área de trabajo. Evite modificar grupos en Azure Databricks: use el IdP.

• Use entidades de servicio para ejecutar trabajos. Las entidades de servicio habilitan la automatización del trabajo. Si emplea usuarios para realizar trabajos que modifican datos en producción, corre el riesgo de sobrescribir los datos de producción por accidente.

Para obtener más información, consulte Administrar usuarios, entidades de servicio y grupos y Sincronizar usuarios y grupos de Microsoft Entra ID mediante SCIM.

Roles de administrador y privilegios eficaces

La asignación de roles de administrador y privilegios eficaces como ALL PRIVILEGES y MANAGE requiere cuidado:

• Comprenda los privilegios de los administradores de cuentas, los administradores del área de trabajo y los administradores de metastore antes de asignarlos. Consulte Privilegios de administrador en Unity Catalog.
• Asigne estos roles a grupos siempre que sea posible.
• Los administradores de metastore son opcionales. Asígnelos solo si los necesita. Para obtener instrucciones, consulte (Opcional) Asignar el rol de administrador de metastore.
• Asigne la propiedad del objeto a los grupos, especialmente si se usan objetos en producción. El creador de cualquier objeto es su primer propietario. Los creadores deben reasignar la propiedad a los grupos adecuados.
• Solo los administradores, propietarios y usuarios de metastore con el MANAGE privilegio en un objeto pueden conceder privilegios en ese objeto. Los propietarios de catálogos y esquemas primarios también tienen la capacidad de conceder privilegios en todos los objetos del catálogo o esquema. Actúe con cuidado al asignar la propiedad y el privilegio MANAGE.
• Sea moderado al asignar ALL PRIVILEGES, que incluye todos los privilegios excepto MANAGE.

Asignación de privilegios

Los objetos protegibles del catálogo de Unity son jerárquicos y los privilegios se heredan hacia abajo. Use esta jerarquía de herencia para desarrollar un modelo de privilegios efectivo.

Procedimientos recomendados:

• Comprenda la diferencia entre USE CATALOG (o USE SCHEMA) y BROWSE:

  • USE CATALOG | SCHEMA concede la capacidad de ver los datos en el catálogo o el esquema. Por sí solos, estos privilegios no conceden SELECT ni READ en los objetos dentro del catálogo o esquema, pero son un requisito previo para conceder ese acceso a los usuarios. Conceda estos privilegios solo a los usuarios que deben poder ver los datos en el catálogo o el esquema.
  • USE CATALOG | SCHEMAAl restringir el acceso a un catálogo o esquema, impide que los propietarios de objetos (por ejemplo, un creador de tablas) asignen accidentalmente acceso a ese objeto (tabla) a los usuarios que no deben tener acceso. Es habitual crear un esquema por equipo y conceder USE SCHEMA y CREATE TABLE solo a ese equipo (junto con USE CATALOG en el catálogo primario).
  • BROWSE se puede conceder ampliamente en el nivel de catálogo para permitir a los usuarios ver los metadatos asociados a los objetos del catálogo.

• Comprenda la diferencia entre la propiedad del objeto y el MANAGE privilegio:

  • El propietario de un objeto tiene todos los privilegios en el objeto, como SELECT y MODIFY en una tabla, así como el permiso para conceder privilegios en el objeto protegible a otras entidades de seguridad y transferir la propiedad a otras entidades de seguridad.
  • Los propietarios pueden conceder el privilegio MANAGE para delegar capacidades de propiedad en un objeto a otras entidades de seguridad.
  • Los propietarios de catálogos y esquemas pueden transferir la propiedad de cualquier objeto del catálogo o esquema.
  • Es mejor configurar la propiedad o conceder el MANAGE privilegio en todos los objetos a un grupo responsable de la administración de concesiones en el objeto.

• Reserve el acceso directo de MODIFY a las tablas de producción para las entidades de servicio.

Para obtener más información, consulte Administrar privilegios en el catálogo de Unity.

Metastores

A continuación se muestran reglas y procedimientos recomendados para crear y administrar metastores:

• Solo se puede tener un metastore por región. Todas las áreas de trabajo en esa región comparten el mismo metastore. Para compartir datos entre regiones, vea uso compartido entre regiones y multiplataforma.

• Los metastores proporcionan aislamiento regional, pero no están pensados como unidades predeterminadas de aislamiento de datos. El aislamiento de datos normalmente comienza en el nivel de catálogo. Sin embargo, si prefiere un modelo de gobernanza más centralizado, puede crear un almacenamiento administrado basado en metastore. Para obtener recomendaciones, consulte Almacenamiento administrado.

• El rol de administrador de metastore es opcional. Para obtener recomendaciones sobre si se va a asignar un administrador de metastore opcional, consulte Roles de administrador y privilegios eficaces.

Importante

No registre tablas a las que se accede con frecuencia como tablas externas en más de un metastore. Si lo hace, los cambios realizados en el esquema, las propiedades de la tabla, los comentarios y otros metadatos que se producen como resultado de las escrituras en metastore A no se registrarán en absoluto con metastore B. También puede causar problemas de coherencia con el servicio de confirmación de Azure Databricks.

Catálogos y esquemas

Los catálogos son la unidad principal de aislamiento de datos en el modelo típico de gobernanza de datos del catálogo de Unity. Los esquemas agregan una capa adicional de organización.

Procedimientos recomendados para el uso de catálogos y esquemas:

• Organice los datos y los objetos de IA en catálogos y esquemas que reflejen divisiones y proyectos de la organización. A menudo, esto significa que los catálogos corresponden a un ámbito de entorno, equipo, unidad de negocio o alguna combinación de estos. Esto facilita el uso de la jerarquía de privilegios para administrar el acceso de forma eficaz.
• Cuando los entornos de trabajo y los datos tienen los mismos requisitos de aislamiento, puede enlazar un catálogo a un área de trabajo específica. Cuando sea necesario, cree catálogos que se puedan limitar a un conjunto limitado de áreas de trabajo.
• Asigne siempre la propiedad de catálogos y esquemas de producción a grupos, no a usuarios individuales.
• Conceda USE CATALOG y USE SCHEMA solo a los usuarios que deben poder ver o consultar los datos contenidos en ellos.

Para obtener más información sobre cómo conceder privilegios en catálogos y esquemas, consulte Asignación de privilegios.

Almacenamiento administrado

Las tablas y volúmenes administrados, objetos cuyo ciclo de vida es totalmente administrado por el catálogo de Unity, se almacenan en ubicaciones de almacenamiento predeterminadas, conocidas como almacenamiento administrado. Puede configurar el almacenamiento administrado en el nivel de metastore, catálogo o esquema. Los datos se almacenan en la ubicación más baja disponible en la jerarquía. Para más información, consulte Jerarquía de ubicación de almacenamiento administrado y Especificación de una ubicación de almacenamiento administrada en el catálogo de Unity.

Procedimientos recomendados para ubicaciones de almacenamiento administradas:

• Dé preferencia al almacenamiento de nivel de catálogo como la unidad principal de aislamiento de datos.

  El almacenamiento de nivel de metastore era necesario en los primeros entornos de Unity Catalog, pero ya no es necesario.

• Si decide crear una ubicación administrada de nivel de metastore, use un contenedor dedicado.

• No use un contenedor al que se pueda acceder desde fuera del catálogo de Unity.

  Si un servicio externo o un principal accede a los datos en la ubicación de almacenamiento gestionado, eludiendo el Unity Catalog, se comprometen el control de acceso y la auditabilidad en tablas y volúmenes gestionados.

• No reutilice un contenedor que sea o se haya usado para el sistema de archivos raíz de DBFS.

• Si tiene cargas de trabajo de almacenamiento intensivas, no use una sola cuenta de almacenamiento ni un contenedor para el almacenamiento administrado y otras ubicaciones externas.

  las cuentas re:[ADLS] admiten 20 000 solicitudes por segundo de forma predeterminada. Esto puede hacer que se limiten y se ralenticen las cargas de trabajo. El uso de varios contenedores en la misma cuenta de almacenamiento no cambia este límite de toda la cuenta. Es por eso que debe distribuir el almacenamiento entre varias cuentas de almacenamiento.

  Este seccionamiento no sería visible para los usuarios finales de Unity Catalog.

Tablas administradas y externas

El catálogo de Unity administra completamente las tablas administradas, lo que significa que Unity Catalog administra tanto la gobernanza como los archivos de datos subyacentes para cada tabla administrada. Siempre están en formato Delta o Apache Iceberg.

Las tablas externas son tablas cuyo acceso desde Azure Databricks está administrado por Unity Catalog, pero cuyo ciclo de vida de datos y diseño de archivos se administran mediante el proveedor de nube y otras plataformas de datos. Al crear una tabla externa en Azure Databricks, especifique su ubicación, que debe estar en una ruta de acceso definida en una ubicación externa del catálogo de Unity.

Uso de tablas administradas:

• Para la mayoría de los casos de uso. Databricks recomienda tablas y volúmenes administrados, ya que permiten aprovechar al máximo las funcionalidades de gobernanza del catálogo de Unity y las optimizaciones de rendimiento, entre las que se incluyen:

  • Compactación automática
  • Optimización automática
  • Lecturas de metadatos más rápidas (almacenamiento en caché de metadatos)
  • Optimizaciones inteligentes del tamaño de archivo

  La nueva funcionalidad de Azure Databricks da prioridad a las tablas administradas.

• Para todas las tablas nuevas.

Usar tablas externas:

• Si ya está usándolos y va a hacer una actualización del metastore de Hive en Unity Catalog.

  • El uso de tablas externas puede proporcionar una actualización rápida y sin problemas de "un solo clic" sin mover datos.
  • Databricks recomienda migrar finalmente tablas externas a tablas administradas.

• Si tiene requisitos de recuperación ante desastres para estos datos que no pueden cumplir las tablas administradas.

  Las tablas administradas no se pueden registrar en varios metastores en la misma nube.

• Si los lectores externos o escritores deben poder interactuar con los datos desde fuera de Databricks.

  Normalmente, debería evitar incluso el acceso externo a las tablas externas registradas en Unity Catalog. Al hacerlo, se salta el control de acceso, la auditoría y el linaje de Unity Catalog. Se recomienda usar tablas administradas y compartir datos entre regiones o proveedores de nube mediante delta sharing. Si debe permitir el acceso externo a tablas externas, limítelo solo a lecturas, con todas las escrituras realizándose a través de Azure Databricks y Unity Catalog.

• Debe admitir tablas que no sean de Delta o que no sean de Iceberg, como Parquet, Avro, ORC, etc.

Más recomendaciones para usar tablas externas:

• Databricks recomienda crear tablas externas mediante una ubicación externa por esquema.
• Databricks recomienda no registrar tablas como tablas externas en más de un metastore debido al riesgo de que haya problemas de coherencia. Por ejemplo, un cambio en el esquema de un metastore no se registrará en el segundo metastore. Use Delta Sharing para compartir datos entre metastores. Consulte Uso compartido multiplataforma y entre regiones.

Consulte también Introducción a las tablas de Azure Databricks.

Volúmenes administrados y externos

El catálogo de Unity administra completamente los volúmenes administrados, lo que significa que Unity Catalog administra el acceso a la ubicación de almacenamiento del volumen en la cuenta del proveedor de nube. Los volúmenes externos representan datos existentes en ubicaciones de almacenamiento que se administran fuera de Azure Databricks, pero registrados en el Catálogo de Unity para controlar y auditar el acceso desde Azure Databricks. Cuando se crea un volumen externo en Azure Databricks, se especifica su ubicación, que debe estar en una ruta de acceso definida en una ubicación externa del catálogo de Unity.

Uso de volúmenes administrados:

• Para la mayoría de los casos de uso, para aprovechar al máximo las funcionalidades de gobernanza del catálogo de Unity.
• Si desea crear tablas a partir de archivos de un volumen sin ejecutar las declaraciones COPY INTO ni CTAS (CREATE TABLE AS).

Usar volúmenes externos:

• Para registrar áreas de destino de los datos sin procesar producidos por sistemas externos para aceptar su procesamiento en las primeras fases de las canalizaciones ETL y otras operaciones de ingeniería de datos.
• Para registrar ubicaciones de almacenamiento provisional para la ingesta, por ejemplo, mediante Auto Loader, COPY INTOo declaraciones CTAS.
• Proporcione ubicaciones de almacenamiento de archivos para que los científicos de datos, los analistas de datos y los ingenieros de aprendizaje automático usen como parte de su análisis de datos exploratorios y otras tareas de ciencia de datos cuando los volúmenes administrados no son una opción.
• Para conceder a los usuarios de Azure Databricks acceso a archivos arbitrarios generados y almacenados en el almacenamiento en la nube por otros sistemas, por ejemplo, grandes colecciones de datos no estructurados (como archivos image, audio, vídeo y PDF) capturados por sistemas de vigilancia o dispositivos IoT, o archivos de biblioteca (JAR y archivos de rueda de Python) exportados desde sistemas de administración de dependencias locales o canalizaciones de CI/CD.
• Para almacenar datos operativos, por ejemplo, el registro de eventos o archivos de verificación, cuando los volúmenes administrados no son una opción.

Mas recomendaciones para usar volúmenes externos:

• Databricks recomienda crear volúmenes externos a partir de una ubicación externa dentro de un esquema.

Sugerencia

Para los casos de uso de ingesta en los que los datos se copian en otra ubicación (por ejemplo, mediante Auto Loader o COPY INTO), use volúmenes externos. Use tablas externas cuando desee consultar datos en contexto como una tabla, sin que haya ninguna copia implicada.

Consulte también Volúmenes administrados frente a volúmenes externos y ubicaciones externas.

Ubicaciones externas

Los objetos protegibles de ubicación externa, mediante la combinación de credenciales de almacenamiento y rutas de acceso de almacenamiento, proporcionan un control seguro y la auditabilidad del acceso al almacenamiento. Es importante evitar que los usuarios accedan directamente a los contenedores registrados como ubicaciones externas, eludiendo el control de acceso proporcionado por el Catálogo de Unity.

Para usar ubicaciones externas de forma eficaz:

• Asegúrese de limitar el número de usuarios con acceso directo a cualquier contenedor que se use como ubicación externa.

• No monte cuentas de almacenamiento en DBFS si también se usan como ubicaciones externas. Databricks recomienda la migración de montajes en ubicaciones de almacenamiento en la nube a ubicaciones externas en Unity Catalog mediante Catalog Explorer.

• Conceda la capacidad de crear ubicaciones externas solo a los administradores que tienen la tarea de configurar conexiones entre unity Catalog y almacenamiento en la nube, o a ingenieros de datos de confianza.

  Las ubicaciones externas proporcionan acceso desde el catálogo de Unity a una ubicación ampliamente abarcada en el almacenamiento en la nube, por ejemplo, un cubo o contenedor completo (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net) o una subpath amplia (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog). La intención es que un administrador de la nube pueda participar en la configuración de algunas ubicaciones externas y, a continuación, delegar la responsabilidad de administrar esas ubicaciones a un administrador de Azure Databricks en su organización. El administrador de Azure Databricks puede organizar aún más la ubicación externa en áreas con permisos más pormenorizados mediante el registro de volúmenes externos o tablas externas en prefijos específicos en la ubicación externa.

  Dado que las ubicaciones externas abarcan tanto, Databricks recomienda conceder el permiso CREATE EXTERNAL LOCATION solo a un administrador que tenga la tarea de configurar conexiones entre Unity Catalog y el almacenamiento en la nube, o a ingenieros de datos de confianza. Para proporcionar a otros usuarios acceso más pormenorizado, Databricks recomienda registrar tablas o volúmenes externos sobre ubicaciones externas y conceder a los usuarios acceso a los datos mediante volúmenes o tablas. Dado que las tablas y volúmenes son elementos secundarios de un catálogo y un esquema, los administradores de catálogos o esquemas tienen el control final sobre los permisos de acceso.

  También puede controlar el acceso a una ubicación externa mediante el enlace a áreas de trabajo específicas. Consulte (Opcional) Asignar una ubicación externa a áreas de trabajo específicas.

• No conceda permisos generales READ FILES ni WRITE FILES en ubicaciones externas a los usuarios finales.

  Los usuarios no deben usar ubicaciones externas para nada, sino para crear tablas, volúmenes o ubicaciones administradas. No deben usar ubicaciones externas para el acceso basado en rutas de acceso para la ciencia de datos u otros casos de uso de datos no tabulares.

  Para el acceso basado en rutas a datos no tabulares, se utilizan volúmenes. El acceso del URI en la nube a los datos de la ruta del volumen se rige por privilegios concedidos en el volumen, no por los privilegios concedidos en la ubicación externa donde se almacena el volumen.

  Los volúmenes permiten trabajar con archivos mediante comandos SQL, dbutils, API de Spark, API REST, Terraform y una interfaz de usuario para examinar, cargar y descargar archivos. Además, los volúmenes ofrecen un montaje FUSE al que se puede acceder en el sistema de archivos local en /Volumes/<catalog_name>/<schema_name>/<volume_name>/. El montaje FUSE permite a los científicos de datos e ingenieros de aprendizaje automático acceder a archivos como si estuvieran en un sistema de archivos local, según sea necesario para muchas bibliotecas de sistema operativo o aprendizaje automático.

  Si debe conceder acceso directo a los archivos de una ubicación externa (para explorar archivos en el almacenamiento en la nube antes de que un usuario cree una tabla o volumen externo, por ejemplo), puede conceder READ FILES. Los casos de uso para la concesión de WRITE FILES son poco frecuentes.

• Evite conflictos de superposición de rutas de acceso: nunca cree volúmenes o tablas externos en la raíz de una ubicación externa.

  Si crea volúmenes o tablas externos en la raíz de la ubicación externa, no puede crear volúmenes o tablas externos adicionales en la ubicación externa. En su lugar, cree volúmenes o tablas externos en un subdirectorio dentro de la ubicación externa.

Solo debe usar ubicaciones externas para hacer lo siguiente:

• Registre tablas y volúmenes externos mediante los comandos CREATE EXTERNAL VOLUME o CREATE TABLE.
• Registre una ubicación como almacenamiento administrado. El privilegio CREATE MANAGED STORAGE es una condición previa.
• Explore los archivos existentes en el almacenamiento en la nube antes de crear una tabla o volumen externo en un prefijo específico. El privilegio READ FILES es una condición previa. Asigne este privilegio con moderación. Consulte la recomendación de la lista anterior para obtener más información.

Ubicaciones externas frente a volúmenes externos

Antes de publicar volúmenes, algunas implementaciones del Catálogo de Unity asignaban READ FILES acceso directamente a ubicaciones externas para la exploración de datos. Con la disponibilidad de volúmenes que registran archivos en cualquier formato, incluidos los datos estructurados, semiestructurados y no estructurados, no hay ninguna razón real para usar ubicaciones externas para nada más que crear tablas, volúmenes o ubicaciones administradas. Para obtener información detallada sobre cuándo usar ubicaciones externas y cuándo usar volúmenes, consulte Volúmenes administrados y externos y ubicaciones externas.

Uso compartido entre regiones y multiplataforma

Solo se puede tener un metastore por región. Si desea compartir datos entre áreas de trabajo en regiones diferentes, use Databricks-to-Databricks Delta Sharing.

Procedimientos recomendados:

• Utiliza tu metastore regional único para todas las etapas del ciclo de vida del desarrollo de software y unidades de negocio, por ejemplo, desarrollo, pruebas, producción, ventas y marketing. Asegúrese de que las áreas de trabajo que requieren acceso frecuente a datos compartidos se encuentran en la misma región.
• Usa Databricks-to-Databricks Delta Sharing entre regiones de la nube o proveedores de nube.
• Use Delta Sharing para las tablas a las que se accede con poca frecuencia, ya que es responsable de los costes de salida entre regiones de la nube. Si debe compartir datos a los que se accede con frecuencia entre regiones o proveedores en la nube, consulte: Supervisar y administrar los costos de salida de Delta Sharing (para proveedores).

Tenga en cuenta las siguientes limitaciones al usar el uso compartido de Databricks a Databricks:

• Los gráficos de linaje se crean a nivel de metastore y no cruzan los límites de la región ni de la plataforma. Esto se aplica incluso si un recurso se comparte entre metastores dentro de la misma cuenta de Databricks: la información de linaje del origen no es visible en el destino y viceversa.
• El control de acceso se define en el nivel de metastore y no cruza los límites de la región ni de la plataforma. Si un recurso tiene privilegios asignados a él y ese recurso se comparte con otro metastore de la cuenta, los privilegios de ese recurso no se aplican al recurso compartido de destino. Debe conceder privilegios en el recurso compartido de destino en el destino.

Configuraciones de proceso

Databricks recomienda usar directivas de proceso para limitar la capacidad de configurar clústeres en función de un conjunto de reglas. Las directivas de proceso permiten limitar a los usuarios a la creación de clústeres habilitados para catálogo de Unity, específicamente clústeres que usan el modo de acceso estándar (anteriormente modo de acceso compartido) o el modo de acceso dedicado (anteriormente modo de acceso único o asignado).

Solo los clústeres que usan uno de estos modos de acceso pueden acceder a los datos en el Catálogo de Unity. Todos los recursos de cómputo sin servidor y los recursos de DBSQL admiten Unity Catalog.

Databricks recomienda el modo de acceso estándar para todas las cargas de trabajo. Use el modo de acceso dedicado solo si el modo de acceso estándar no admite la funcionalidad necesaria. Consulte Modos de acceso.