Procedimientos recomendados de Unity Catalog

Este documento proporciona recomendaciones para utilizar Unity Catalog y Delta Sharing para satisfacer sus necesidades de gobierno de datos.

Catálogo de Unity es una solución de gobernanza específica para los datos y la inteligencia artificial en la plataforma de Databricks. Ayuda a simplificar la seguridad y gobernanza de los datos proporcionando un lugar central para administrar y auditar el acceso a los datos. Delta Sharing es una plataforma de uso compartido de datos segura que le permite compartir datos en Azure Databricks con usuarios externos a su organización. Usa Unity Catalog para administrar y auditar el comportamiento de uso compartido.

Bloques de creación de gobernanza de datos y aislamiento de datos

Para desarrollar un modelo de gobernanza de datos y un plan de aislamiento de datos que funcionen para su organización, es útil comprender los principales bloques de creación que están disponibles al crear la solución de gobernanza de datos en Azure Databricks.

En el diagrama siguiente se muestra la jerarquía de datos principal en Unity Catalog (algunos objetos protegibles están atenuados para resaltar la jerarquía de objetos administrados en catálogos).

Los objetos de esa jerarquía incluyen lo siguiente:

• Metastore: Un metastore es el contenedor de nivel superior de los objetos de Unity Catalog. Los metastores residen en el nivel de cuenta y funcionan como la parte superior de la pirámide en el modelo de gobernanza de datos de Azure Databricks.

  Los metastores almacenan recursos de datos (tablas, vistas y volúmenes) y los permisos que rigen el acceso a los mismos. Los administradores de cuentas de Azure Databricks pueden crear un metastore para cada región en la que operen y asignarlos a varias áreas de trabajo de Azure Databricks en la misma región. Los administradores de metastore pueden administrar todos los objetos en el metastore. No tienen acceso directo para leer y escribir en tablas registradas en el metastore, pero tienen acceso indirecto a través de su capacidad para transferir la propiedad del objeto de datos.

  El almacenamiento físico de cualquier metastore determinado está, de forma predeterminada, aislado del almacenamiento de cualquier otro metastore de la cuenta.

  Los metastores proporcionan aislamiento regional, pero no están diseñados como unidades de aislamiento de datos. El aislamiento de datos debe comenzar en el nivel de catálogo.

• Catálogo: Los catálogos son el nivel más alto de la jerarquía de datos (tabla, vista o volumen de >esquema> de catálogo) administrada por el metastore de Unity Catalog. Están diseñados como la unidad principal de aislamiento de datos en un modelo típico de gobernanza de datos de Azure Databricks.

  Los catálogos representan una agrupación lógica de esquemas, normalmente limitados por los requisitos de acceso a datos. Los catálogos suelen reflejar las unidades organizativas o los ámbitos del ciclo de vida de desarrollo de software. Puede elegir, por ejemplo, tener un catálogo para datos de producción y un catálogo para datos de desarrollo, o un catálogo para datos que no sean de cliente y otro para datos confidenciales del cliente.

  Los catálogos se pueden almacenar en el nivel de metastore o puede configurar un catálogo para que se almacene por separado del resto del metastore primario. Si el área de trabajo se ha habilitado automáticamente para el catálogo de Unity, no hay ningún almacenamiento de nivel de metastore y debe especificar una ubicación de almacenamiento al crear un catálogo.

  Si el catálogo es la unidad principal de aislamiento de datos en el modelo de gobernanza de datos de Azure Databricks, el área de trabajo es el entorno principal para trabajar con recursos de datos. Los administradores de metastore y los propietarios del catálogo pueden administrar el acceso a catálogos independientemente de las áreas de trabajo, o pueden enlazar catálogos a áreas de trabajo específicas para asegurarse de que determinados tipos de datos solo se procesan en esas áreas de trabajo. Es posible que desee separar áreas de trabajo de producción y desarrollo, por ejemplo, o un área de trabajo independiente para procesar datos personales.

  De forma predeterminada, los elementos secundarios de ese objeto heredan los permisos de acceso para un objeto protegible, con catálogos en la parte superior de la jerarquía. Esto facilita la configuración de reglas de acceso predeterminadas para los datos y especificar reglas diferentes en cada nivel de la jerarquía solo donde las necesite.

• Esquema (base de datos): Los esquemas, también conocidos como bases de datos, son agrupaciones lógicas de datos tabulares (tablas y vistas), datos no tabulares (volúmenes), funciones y modelos de Machine Learning. Proporcionan una manera de organizar y controlar el acceso a los datos que son más granulares que los catálogos. Normalmente representan un único caso de uso, un proyecto o un espacio aislado de equipo.

  Los esquemas se pueden almacenar en el mismo almacenamiento físico que el catálogo primario, o puede configurar un esquema que se almacenará por separado del resto del catálogo primario.

  Los administradores de metastore, los propietarios de catálogos primarios y los propietarios de esquemas pueden administrar el acceso a esquemas.

• Tablas: Las tablas residen en la tercera capa del espacio de nombres de tres niveles de Unity Catalog. Contienen filas de datos.

  Unity Catalog le permite crear tablas administradas y tablas externas.

  En el caso de las tablas administradas, Unity Catalog administra completamente el ciclo de vida y el diseño de archivos. De manera predeterminada, las tablas administradas se almacenan en la ubicación de almacenamiento raíz que se configura al crear un metastore. En su lugar, puede elegir aislar el almacenamiento de las tablas administradas en los niveles de catálogo o esquema.

  Las tablas externas son tablas cuyo ciclo de vida de datos y diseño de archivos se administran mediante el proveedor de nube y otras plataformas de datos, no con Unity Catalog. Generalmente utiliza tablas externas para registrar grandes cantidades de datos existentes, o si también necesita acceso de escritura a los datos mediante herramientas fuera de los clústeres de Azure Databricks o los almacenes SQL de Databricks. Una vez que se registra una tabla externa en un metastore de Unity Catalog, puede administrar y auditar el acceso de Azure Databricks a ella de la misma manera que puede hacerlo con tablas administradas.

  Los propietarios de catálogos primarios y los propietarios de esquemas pueden administrar el acceso a las tablas, como los administradores de metastore (indirectamente).

• Vistas: Una vista es un objeto de solo lectura derivado de una o varias tablas y vistas de un metastore.

• Filas y columnas: el acceso a nivel de filas y columnas, junto con el enmascaramiento de datos, se concede mediante vistas dinámicas o filtros de fila y máscaras de columna. Las vistas dinámicas son de solo lectura.

• Volúmenes: Los volúmenes residen en la tercera capa del espacio de nombres de tres niveles de Unity Catalog. Administran datos no tabulares. Puede usar volúmenes para almacenar y organizar archivos en cualquier formato, incluidos datos estructurados, semiestructurados y no estructurados, así como acceder a ellos. Los archivos de volúmenes no se pueden registrar como tablas.

• Modelos y funciones: Aunque no son, estrictamente hablando, los recursos de datos, los modelos registrados y las funciones definidas por el usuario también se pueden administrar en Unity Catalog y residir en el nivel más bajo de la jerarquía de objetos. Consulte Administrar el ciclo de vida del modelo en Unity Catalog y Funciones definidas por el usuario (UDF) en Unity Catalog.

Planificar el modelo de aislamiento de datos

Cuando una organización usa una plataforma de datos como Azure Databricks, a menudo es necesario tener límites de aislamiento de datos entre entornos (como desarrollo y producción) o entre unidades operativas organizativas.

Los estándares de aislamiento pueden variar para su organización, pero normalmente incluyen las siguientes expectativas:

• Los usuarios solo pueden obtener acceso a los datos en función de las reglas de acceso especificadas.
• Los datos solo se pueden administrar mediante personas o equipos designados.
• Los datos están separados físicamente en el almacenamiento.
• Solo se puede acceder a los datos en entornos designados.

La necesidad de aislamiento de datos puede dar lugar a entornos aislados que pueden dificultar innecesariamente tanto la gobernanza de datos como la colaboración. Azure Databricks resuelve este problema mediante Unity Catalog, que proporciona una serie de opciones de aislamiento de datos al tiempo que mantiene una plataforma unificada de gobernanza de datos. En esta sección se describen las opciones de aislamiento de datos disponibles en Azure Databricks y cómo usarlas, tanto si prefiere un modelo de gobernanza de datos centralizado como uno distribuido.

Los usuarios solo pueden obtener acceso a los datos en función de las reglas de acceso especificadas

La mayoría de las organizaciones tienen requisitos estrictos sobre el acceso a los datos en función de los requisitos internos o normativos. Entre los ejemplos típicos de datos que se deben mantener seguros se incluyen información de salario de empleado o información de pago con tarjeta de crédito. El acceso a este tipo de información normalmente se controla y audita periódicamente. Unity Catalog proporciona un control pormenorizado sobre los recursos de datos dentro del catálogo para cumplir estos estándares del sector. Con los controles que proporciona Unity Catalog, los usuarios pueden ver y consultar solo los datos que tienen derecho a ver y consultar.

Los datos solo se pueden administrar mediante personas o equipos designados

Unity Catalog ofrece la posibilidad de elegir entre modelos de gobernanza centralizados y distribuidos.

En el modelo de gobernanza centralizado, los administradores de gobernanza son propietarios del metastore y pueden tomar posesión de cualquier objeto y conceder y revocar permisos.

En un modelo de gobernanza distribuida, el dominio de datos es un catálogo o un conjunto de catálogos. El propietario de ese catálogo puede crear y poseer todos los recursos y administrar la gobernanza dentro de ese dominio. Los propietarios de cualquier dominio determinado pueden funcionar independientemente de los propietarios de otros dominios.

Independientemente de si elige el metastore o los catálogos como dominio de datos, Databricks recomienda encarecidamente establecer un grupo como administrador de metastore o propietario del catálogo.

Los datos están físicamente separados en el almacenamiento

Una organización puede requerir que los datos de determinados tipos se almacenen dentro de cuentas o cubos específicos en su inquilino en la nube.

Unity Catalog ofrece la capacidad de configurar ubicaciones de almacenamiento en el nivel de metastore, catálogo o esquema para satisfacer estos requisitos.

Por ejemplo, supongamos que su organización tiene una directiva de cumplimiento de la empresa que requiere que los datos de producción relacionados con recursos humanos residan en el contenedor abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. En Unity Catalog, puede lograr este requisito estableciendo una ubicación en un nivel de catálogo, creando un catálogo denominado, por ejemplo hr_prod, y asignando la ubicación abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog a él. Esto significa que las tablas o volúmenes administrados creados en el catálogo hr_prod (por ejemplo, mediante CREATE TABLE hr_prod.default.table …) almacenan sus datos en abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Opcionalmente, puede optar por proporcionar ubicaciones de nivel de esquema para organizar los datos en hr_prod catalog en un nivel más granular.

Si no se requiere este aislamiento de almacenamiento, puede establecer una ubicación de almacenamiento en el nivel del metastore. El resultado es que esta ubicación actúa como ubicación predeterminada para almacenar las tablas y los volúmenes administrados tanto en catálogos como en esquemas en el metastore.

El sistema evalúa la jerarquía de las ubicaciones de almacenamiento del esquema al catálogo en el metastore.

Por ejemplo, si se crea una tabla myCatalog.mySchema.myTable en my-region-metastore, la ubicación de almacenamiento de tablas se determina según la siguiente regla:

1. Si se ha proporcionado una ubicación para mySchema, se almacenará allí.
2. Si no es así, y se ha proporcionado una ubicación en myCatalog, se almacenará allí.
3. Por último, si no se ha proporcionado ninguna ubicación en myCatalog, se almacenará en la ubicación asociada a my-region-metastore.

Solo se puede acceder a los datos en entornos designados

Los requisitos de cumplimiento y organizativos suelen especificar que se mantengan determinados datos, como los datos personales, accesibles solo en determinados entornos. También puede que desee mantener los datos de producción aislados de los entornos de desarrollo o asegurarse de que ciertos conjuntos de datos y dominios nunca se unen.

En Databricks, el área de trabajo es el entorno de procesamiento de datos principal y los catálogos son el dominio de datos principal. Unity Catalog permite que los administradores de metastore y los propietarios del catálogo asignen o "enlacen" catálogos a áreas de trabajo. Estos enlaces compatibles con el entorno permiten asegurarse de que solo determinados catálogos están disponibles en un área de trabajo, independientemente de los privilegios específicos de los objetos de datos concedidos a un usuario.

Ahora echemos un vistazo más profundo al proceso de configuración de Unity Catalog para satisfacer sus necesidades.

Configuración del metastore de Unity Catalog

Un metastore es el contenedor de nivel superior de los objetos de Unity Catalog. Los metastores administran recursos de datos (tablas, vistas y volúmenes), así como otros objetos protegibles administrados por Unity Catalog. Para obtener la lista completa de objetos protegibles, consulte Objetos protegibles en Unity Catalog.

En esta sección se proporcionan sugerencias para crear y configurar metastores. Si el área de trabajo se ha habilitado automáticamente para el catálogo de Unity, no es necesario crear un metastore, pero la información presentada en esta sección podría ser útil. Consulte Habilitación automática de Unity Catalog.

Sugerencias para configurar metastores:

• Debe configurar un metastore para cada región en la que tenga áreas de trabajo de Azure Databricks.

  Cada área de trabajo asociada a un único metastore regional tiene acceso a los datos administrados por el metastore. Si desea compartir datos entre metastores, use Delta Sharing.

• Cada metastore se configura con una ubicación de almacenamiento administrada (también denominada almacenamiento raíz) en el inquilino en la nube que se puede usar para almacenar tablas administradas y volúmenes administrados.

  Si decide crear una ubicación administrada de nivel de metastore, debe asegurarse de que ningún usuario tenga acceso directo a ella (es decir, a través de la cuenta en la nube que la contiene). Dar acceso a esta ubicación de almacenamiento puede permitir que un usuario omita los controles de acceso en un metastore de Unity Catalog e interrumpa la auditoría. Por estas razones, tu almacenamiento gestionado por metastore debe ser un contenedor dedicado. No debe volver a usar un contenedor que sea también su sistema de archivos raíz de DBFS o que lo haya sido anteriormente.

  También tiene la opción de definir el almacenamiento administrado en los niveles de catálogo y esquema, reemplazando la ubicación de almacenamiento raíz del metastore. En la mayoría de los escenarios, Databricks recomienda almacenar los datos administrados en el nivel de catálogo.

• Debe comprender los privilegios de los administradores de áreas de trabajo en las áreas de trabajo habilitadas para Unity Catalog y revisar sus asignaciones de administrador de áreas de trabajo existentes.

  Los administradores del área de trabajo pueden administrar las operaciones de su área de trabajo, incluida la adición de usuarios y entidades de servicio, la creación de clústeres y la delegación de otros usuarios para que sean administradores del área de trabajo. Si el área de trabajo se ha habilitado automáticamente para el catálogo de Unity, los administradores del área de trabajo pueden crear catálogos y muchos otros objetos de Catálogo de Unity de forma predeterminada. Consulte Privilegios de administrador del área de trabajo cuando las áreas de trabajo están habilitadas para el catálogo de Unity automáticamente

  Los administradores del área de trabajo también tienen la capacidad de realizar tareas de administración del área de trabajo, como administrar la propiedad del trabajo y ver cuadernos, lo que puede dar acceso indirecto a los datos registrados en el Catálogo de Unity. El administrador del área de trabajo es un rol con privilegios que debe distribuir con cuidado.

• Si usa áreas de trabajo para aislar el acceso a datos de usuario, es posible que desee usar enlaces de catálogo de áreas de trabajo. Los enlaces de catálogo de áreas de trabajo permiten limitar el acceso al catálogo por límites del área de trabajo. Por ejemplo, puede asegurarse de que los administradores del área de trabajo y los usuarios solo pueden acceder a los datos de producción desde un prod_catalog entorno de área de trabajo de producción, prod_workspace. El valor predeterminado es compartir el catálogo con todas las áreas de trabajo asociadas al metastore actual. Consulte Limitación del acceso del catálogo a áreas de trabajo específicas.

  Si el área de trabajo se ha habilitado automáticamente para el catálogo de Unity, el catálogo del área de trabajo aprovisionado previamente se enlaza al área de trabajo de forma predeterminada.

Consulte Creación de un metastore de Unity Catalog.

Configuración de las ubicaciones externas y credenciales de almacenamiento

Las ubicaciones externas permiten a Unity Catalog leer y escribir datos en su inquilino en la nube en nombre de los usuarios. Las ubicaciones externas se definen como una ruta de acceso al almacenamiento en la nube, combinada con una credencial de almacenamiento que se puede usar para acceder a esa ubicación.

Puede usar ubicaciones externas para registrar tablas externas y volúmenes externos en Unity Catalog. El contenido de estas entidades se encuentra físicamente en una subruta en una ubicación externa a la que se hace referencia cuando un usuario crea el volumen o la tabla.

Una credencial de almacenamiento encapsula una credencial en la nube a largo plazo, que proporciona acceso al almacenamiento en la nube. Puede ser una identidad administrada de Azure (muy recomendable) o una entidad de servicio. El uso de una identidad administrada de Azure presenta las siguientes ventajas en comparación con el uso de una entidad de servicio:

• Las identidades administradas no requieren que mantenga credenciales ni rotar secretos.
• Si el área de trabajo de Azure Databricks se implementa en su propia red virtual (también conocida como inyección de red virtual), puede conectarse a una cuenta de Azure Data Lake Storage Gen2 protegida por un firewall de almacenamiento.

Para aumentar el aislamiento de datos, puede enlazar credenciales de almacenamiento y ubicaciones externas a áreas de trabajo específicas. Consulte (opcional) Asignar un catálogo a áreas de trabajo específicas y (opcional) Asignar una ubicación externa a áreas de trabajo específicas.

Sugerencia

Las ubicaciones externas, mediante la combinación de credenciales de almacenamiento y rutas de acceso de almacenamiento, proporcionan un control seguro y una auditoría del acceso al almacenamiento. Para evitar que los usuarios omitan el control de acceso proporcionado por Unity Catalog, debe asegurarse de limitar el número de usuarios con acceso directo a cualquier contenedor que se use como ubicación externa. Por la misma razón, no debe montar cuentas de almacenamiento en DBFS si también se están usando 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.

Para obtener una lista de los procedimientos recomendados para administrar ubicaciones externas, consulte Administración de ubicaciones externas, tablas externas y volúmenes externos. Consulte también Creación de una ubicación externa para conectar el almacenamiento en la nube a Azure Databricks.

Organización de los datos

Databricks recomienda el uso de catálogos para proporcionar segregación en la arquitectura de información de la organización. A menudo, esto significa que los catálogos corresponden al ámbito del entorno de desarrollo de software, al equipo o a la unidad de negocio. Si usa áreas de trabajo como herramienta de aislamiento de datos (por ejemplo, mediante áreas de trabajo diferentes para entornos de producción y desarrollo o un área de trabajo específica para trabajar con datos altamente confidenciales, también puede enlazar un catálogo a áreas de trabajo específicas. Esto garantiza que todo el procesamiento de los datos especificados se controle en el área de trabajo adecuada. Consulte Limitación del acceso del catálogo a áreas de trabajo específicas.

Un esquema (también denominado base de datos) es la segunda capa del espacio de nombres de tres niveles de Unity Catalog y organiza tablas, vistas y volúmenes. Puede usar esquemas para organizar y definir permisos para los recursos.

Los objetos regulados por Unity Catalog pueden ser administrados o externos:

• Los objetos administrados son la manera predeterminada de crear objetos de datos en Unity Catalog.

  Unity Catalog administra el ciclo de vida y el diseño de archivos para estos protegibles. No debe utilizar herramientas fuera de Azure Databricks para manipular archivos en tablas o volúmenes administrados directamente.

  Las tablas y volúmenes administrados se almacenan en el almacenamiento administrado, que puede existir en el nivel del metastore, catálogo o esquema de cualquier tabla o volumen determinado. Consulte Los datos están físicamente separados en el almacenamiento.

  Las tablas y volúmenes administrados son una solución cómoda cuando desea aprovisionar una ubicación regulada para el contenido sin la sobrecarga de crear y administrar ubicaciones externas y credenciales de almacenamiento.

  Las tablas administradas siempre utilizan el formato de tabla Delta.

• Los objetos externos son protegibles cuyo ciclo de vida de datos y disposición de archivos no son administrados por Unity Catalog.

  Los volúmenes y tablas externos se registran en una ubicación externa para proporcionar acceso a un gran número de archivos que ya existen en el almacenamiento en la nube sin necesidad de actividad de copia de datos. Use objetos externos cuando tenga archivos generados por otros sistemas y desee almacenarlos provisionalmente para acceder desde Azure Databricks o cuando las herramientas fuera de Azure Databricks requieran acceso directo a estos archivos.

  Las tablas externas admiten Delta Lake y muchos otros formatos de datos, como Parquet, JSON y CSV. Tanto los volúmenes administrados como externos se pueden usar para acceder a los archivos de formatos arbitrarios y almacenarlos: los datos pueden ser estructurados, semiestructurados o no estructurados.

Para obtener más información sobre cómo crear tablas y volúmenes, consulte ¿Qué son las tablas y vistas? y ¿Qué son los volúmenes del catálogo de Unity?.

Administración de ubicaciones externas, tablas externas y volúmenes externos

El diagrama siguiente representa la jerarquía del sistema de archivos de un único contenedor de almacenamiento en la nube, con cuatro ubicaciones externas que comparten una credencial de almacenamiento.

Una vez que tenga ubicaciones externas configuradas en Unity Catalog, puede crear tablas y volúmenes externos en directorios dentro de las ubicaciones externas. A continuación, puede usar Unity Catalog para administrar el acceso de usuarios y grupos a estas tablas y volúmenes. Esto le permite proporcionar a usuarios o grupos específicos acceso a directorios y archivos específicos en el contenedor de almacenamiento en la nube.

Nota:

Al definir un volumen, el acceso URI de nube a los datos de la ruta de acceso del volumen se rige por los permisos del volumen.

Recomendaciones para usar ubicaciones externas

Recomendaciones para conceder permisos en ubicaciones externas:

• Conceda la capacidad de crear ubicaciones externas 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.

  Las ubicaciones externas proporcionan acceso desde Unity Catalog a una ubicación ampliamente abarcada en el almacenamiento en la nube, por ejemplo, un cubo o contenedor completo (abfss://my-container@storage-account.dfs.core.windows.net) o una subruta amplia (abfss://my-container@storage-account.dfs.core.windows.net/path/to/subdirectory). 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 o WRITE FILES en ubicaciones externas a los usuarios finales.

  Con la disponibilidad de volúmenes, los usuarios no deben usar ubicaciones externas para nada, excepto 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.

  Los volúmenes proporcionan compatibilidad para trabajar con archivos mediante comandos SQL, dbutils, API de Spark, API de REST, Terraform y una interfaz de usuario para explorar, 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.

Debe usar ubicaciones externas para hacer lo siguiente:

• Registre tablas y volúmenes externos mediante los comandos CREATE EXTERNAL VOLUME o CREATE TABLE.
• 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.
• Registre una ubicación como almacenamiento administrado para catálogos y esquemas en lugar del cubo raíz de metastore. El privilegio CREATE MANAGED STORAGE es una condición previa.

Más recomendaciones para usar ubicaciones externas:

• 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 una 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.

Recomendaciones para usar volúmenes externos

Debe usar volúmenes externos para hacer lo siguiente:

• Registre áreas de aterrizaje para datos sin procesar generados por sistemas externos para admitir su procesamiento en las primeras fases de las canalizaciones ETL y otras actividades de ingeniería de datos.
• Registre ubicaciones de almacenamiento provisional para la ingesta, por ejemplo, mediante instrucciones de Auto Loader, COPY INTO, o CTAS (CREATE TABLE AS).
• 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.
• Proporcione a los usuarios de Azure Databricks acceso a archivos arbitrarios generados y depositados en el almacenamiento en la nube por otros sistemas, por ejemplo, grandes recopilaciones de datos no estructurados (como archivos de imagen, audio, vídeo y PDF) capturados por sistemas de vigilancia o dispositivos IoT, o archivos de biblioteca (JAR y archivos wheel de Python) exportados desde sistemas de administración de dependencias locales o canalizaciones de CI/CD.
• Almacene datos operativos, como el registro o los archivos de punto de comprobació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.

Recomendaciones para usar tablas externas

Debe usar tablas externas para admitir patrones de consulta normales sobre los datos almacenados en el almacenamiento en la nube. Al crear tablas administradas no es una opción.

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 de datos de forma segura mediante Delta Sharing.

Configuración del control de acceso

Cada objeto protegible de Unity Catalog tiene un propietario. La entidad de seguridad que crea un objeto se convierte en su propietario inicial. El propietario del objeto tiene todos los privilegios sobre el objeto, como SELECT y MODIFY, en una tabla, así como el permiso para conceder privilegios sobre el objeto protegible a otras entidades de seguridad. Solo los propietarios de un objeto protegible tienen permiso para conceder privilegios sobre ese objeto a otras entidades de seguridad. Por tanto, se recomienda configurar la propiedad de todos los objetos para el grupo responsable de la administración de las concesiones en el objeto. Tanto el propietario como los administradores de metastore pueden transferir la propiedad de un objeto protegible a un grupo. Además, si el objeto está incluido en un catálogo (como una tabla o vista), el propietario del catálogo y del esquema podrá cambiar la propiedad del objeto.

Los objetos protegibles en el catálogo de Unity son jerárquicos y los privilegios se heredan hacia abajo. Esto significa que, al conceder un privilegio en un catálogo o esquema, se concede automáticamente dicho privilegio a todos los objetos actuales y futuros del catálogo o esquema. Para obtener más información, vea Modelo de la herencia.

Para leer datos de una tabla o vista, el usuario debe tener los siguientes privilegios:

• SELECT en la tabla o vista
• USE SCHEMA en el esquema que posee la tabla
• USE CATALOG en el catálogo que posee el esquema

USE CATALOG permite al receptor recorrer el catálogo para acceder a sus objetos secundarios y USE SCHEMA permite al receptor atravesar el esquema para acceder a sus objetos secundarios. Por ejemplo, para seleccionar datos de una tabla, los usuarios deben tener el privilegio SELECT en esa tabla y el privilegio USE CATALOG en su catálogo primario, así como el privilegio USE SCHEMA en su esquema primario. Por lo tanto, puede usar este privilegio para restringir el acceso a secciones del espacio de nombres de datos a grupos específicos. Un escenario común consiste en configurar un esquema por equipo en el que solo dicho equipo tenga USE SCHEMA y CREATE en el esquema. Esto significa que cualquier tabla que hayan generado los miembros del equipo solo se puede compartir dentro de dicho equipo.

Puede proteger el acceso a una tabla mediante la siguiente sintaxis de SQL:

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

Puede proteger el acceso a las columnas mediante una vista dinámica en un esquema secundario, tal y como se muestra en la siguiente sintaxis de SQL:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

Puede proteger el acceso a las filas mediante una vista dinámica en un esquema secundario, tal y como se muestra en la siguiente sintaxis de SQL:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

También puede conceder a los usuarios acceso seguro a las tablas mediante filtros de fila y máscaras de columna. Para obtener más información, consulte Filtrado de datos de tabla confidenciales con filtros de fila y máscaras de columna.

Para obtener más información sobre todos los privilegios de Unity Catalog, consulte Administrar privilegios en Unity Catalog.

Administración de las configuraciones de clúster

Databricks recomienda el uso de políticas de clúster para limitar la capacidad de configurar clústeres en función de un conjunto de reglas. Las directivas de clúster permiten restringir el acceso solo para crear clústeres que estén habilitados para Unity Catalog. El uso de directivas de clúster reduce las opciones disponibles, lo que simplificará en gran medida el proceso de creación de clústeres para los usuarios y garantizará que puedan acceder a los datos sin problemas. Las directivas de clúster también permiten controlar los costos mediante la limitación del costo máximo por clúster.

Para garantizar la integridad de los controles de acceso y aplicar garantías de aislamiento sólidas, Unity Catalog impone requisitos de seguridad en los recursos de proceso. Por este motivo, Unity Catalog incorpora el concepto de modo de acceso de un clúster. Unity Catalog es seguro de manera predeterminada; si un clúster no está configurado con un modo de seguridad adecuado, este no podrá acceder a los datos de Unity Catalog. Consulte Requisitos de proceso.

Databricks recomienda el uso del modo de acceso compartido cuando se comparte un clúster y el modo de acceso de Usuario único para trabajos automatizados y cargas de trabajo de aprendizaje automático.

El siguiente código JSON proporciona una definición de directiva para un clúster compartido con el modo de acceso compartido:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

El siguiente código JSON proporciona una definición de directiva para un clúster de trabajos automatizado con el modo de acceso de Usuario único:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

Auditoría del acceso

Sin embargo, una solución de gobernanza de datos completa requiere auditar el acceso a los datos y proporcionar funcionalidades de supervisión y alertas. Unity Catalog captura un registro de auditoría de las acciones que se realizan en el metastore y dichos registros se entregan como parte de los registros de auditoría de Azure Databricks.

Puede acceder a los registros de auditoría de su cuenta mediante tablas del sistema. Para obtener más información sobre la tabla del sistema de registros de auditoría, consulte Análisis de la tabla del sistema de registros de auditoría.

Consulte Supervisión de la plataforma de inteligencia de datos de Databricks con registros de auditoría para más información sobre cómo obtener visibilidad completa de los eventos críticos relacionados con la plataforma de inteligencia de datos de Databricks.

Compartir datos de forma segura mediante Delta Sharing

Delta Sharing es un protocolo abierto que desarrolla Databricks para el uso compartido de datos seguro con otras organizaciones u otros departamentos de la organización, independientemente de las plataformas informáticas que usen. Cuando Delta Sharing está habilitado en un metastore, Unity Catalog ejecuta un servidor de Delta Sharing.

Para compartir datos entre metastores, puede sacar provecho de Databricks-to-Databricks Delta Sharing. Esto le permite registrar tablas de metastores en diferentes regiones. Estas tablas aparecerán como objetos de solo lectura en el metastore de consumo. A estas tablas se les puede conceder acceso como a cualquier otro objeto de Unity Catalog.

Cuando se usa Databricks-to-Databricks Delta Sharing para compartir entre metastores, tenga en cuenta que el control de acceso está limitado a un metastore. Si a un objeto protegible, como una tabla, se le han otorgado concesiones y ese recurso se comparte en un metastore dentro de la cuenta, las concesiones del origen no se aplicarán en el recurso compartido de destino. El recurso compartido de destino tendrá que establecer sus propias concesiones.

Saber más

• Configuración y administración de Unity Catalog
• ¿Qué es Delta Sharing?
• Actualizar tablas y vistas de Hive al Unity Catalog