Compartir vía

¿Qué es Unity Catalog?

Unity Catalog es una solución unificada de gobernanza de datos e inteligencia artificial integrada directamente en la plataforma de Azure Databricks. Se trata de una introducción a los conceptos clave del catálogo de Unity y cómo usar el catálogo de Unity para controlar los datos.

Entre los pilares clave del catálogo de Unity se incluyen los siguientes:

  • Control de acceso unificado: Unity Catalog ofrece un único lugar para administrar permisos para tablas, archivos, modelos y otros objetos desde una sola interfaz.
  • Detección de datos: El Catálogo de Unity permite a los usuarios buscar y comprender los recursos de datos a través de una interfaz que se puede buscar enriquecida con etiquetas, descripciones y metadatos.
  • Seguimiento automatizado del linaje de datos: Vea automáticamente el flujo de datos y cómo se transforma desde el origen hasta las vistas finales y los paneles.
  • Auditoría: Mantenga un registro completo de todo el acceso a datos y la actividad del sistema para satisfacer los requisitos de seguridad y el cumplimiento normativo.
  • Supervisión de la calidad de los datos: Realice un seguimiento proactivo del estado de los recursos de datos con generación de perfiles integrada y alertas que detecten anomalías antes de llegar a los consumidores de nivel inferior.
  • Protección del uso compartido de datos: Intercambie datos activos de forma segura entre organizaciones y nubes mediante el protocolo delta sharing abierto, lo que elimina la necesidad de copiar datos o ETL complejos.

El Unity Catalog también está disponible como una implementación de código abierto. Consulte el blog de anuncios y el repositorio de GitHub público de Unity Catalog.

El modelo de objetos de Catálogo de Unity

En el Catálogo de Unity, todos los recursos que rige se modelan como un objeto. Más concretamente, estos objetos se denominan objetos protegibles en el catálogo de Unity. Puede usar directivas de control de acceso y metadatos como etiquetas para controlar estos objetos protegibles.

Los objetos protegibles residen en la jerarquía del modelo de objetos del catálogo de Unity, que se basa en un objeto especial denominado metastore. En él, los recursos de datos, como tablas, vistas, volúmenes, funciones y modelos, siguen un espacio de nombres de tres niveles (catalog.schema.object). Otros objetos, como las credenciales de almacenamiento, las ubicaciones externas, las conexiones y los recursos compartidos, se encuentran directamente bajo el metastore.

Diagrama del modelo de objetos de Catálogo de Unity

Esta jerarquía es la base de cómo Unity Catalog organiza los recursos y aplica la gobernanza. Para comprender el modelo de objetos de Catálogo de Unity y cada objeto protegible con más detalle, consulte Referencia de objetos protegibles del catálogo de Unity. Para comprender cómo funciona el modelo de permisos en el contexto del modelo de objetos del catálogo de Unity, consulte Conceptos del modelo de permisos del catálogo de Unity.

Roles de administración

Los administradores son responsables de supervisar la gobernanza en el catálogo de Unity. A continuación se muestran los distintos niveles de roles de administrador y sus privilegios predeterminados:

  • Los administradores de cuentas pueden crear metastores, vincular áreas de trabajo a metastores, agregar usuarios y asignar privilegios en metastores.
  • Los administradores del área de trabajo pueden agregar usuarios a un área de trabajo y administrar muchos objetos específicos del área de trabajo, como trabajos y cuadernos. En función del área de trabajo, los administradores del área de trabajo también pueden tener muchos privilegios en el metastore que está asociado al área de trabajo.
  • Los administradores de metastore son roles opcionales que pueden administrar el almacenamiento de tablas y volúmenes en el nivel de metastore. También es conveniente si desea administrar datos de forma centralizada en varias áreas de trabajo de una región.

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

Conceder y revocar el acceso a objetos protegibles

Los usuarios con privilegios pueden conceder y revocar el acceso a objetos protegibles en cualquier nivel de la jerarquía, incluido el propio metastore. El acceso a un objeto concede implícitamente el mismo acceso a todos los elementos secundarios de ese objeto, a menos que se revoque el acceso.

Puede usar comandos de ANSI SQL típicos para conceder y revocar el acceso a objetos en Unity Catalog. Por ejemplo:

GRANT CREATE TABLE ON SCHEMA mycatalog.myschema TO `finance-team`;

También puede usar el Explorador de catálogos, la CLI de Databricks y las API de REST para administrar los permisos de objetos.

Concesión de privilegios mediante el Explorador de catálogos

Los administradores del metastore, los propietarios de un objeto y los usuarios con MANAGE privilege en un objeto pueden conceder y revocar el acceso. Para obtener información sobre cómo administrar privilegios en el catálogo de Unity, consulte Administración de privilegios en el catálogo de Unity.

Acceso predeterminado a objetos de base de datos en Unity Catalog

Unity Catalog funciona en el principio de privilegios mínimos, donde los usuarios tienen el acceso mínimo que necesitan para realizar sus tareas necesarias. Cuando se crea un área de trabajo, los usuarios que no son administradores solo tienen acceso al catálogo de áreas de trabajo aprovisionadas automáticamente, lo que hace que este catálogo sea un lugar cómodo para que los usuarios prueben el proceso de creación y acceso a objetos de base de datos en el catálogo de Unity. Consulte Privilegios del catálogo del área de trabajo.

Administrado frente a tablas y volúmenes externos

Las tablas y volúmenes pueden ser administrados o ser externos.

  • 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. Las tablas administradas se almacenan en una ubicación administrada por Unity Catalog en el almacenamiento en la nube. Las tablas administradas siempre usan el formato Delta Lake. Puede almacenar tablas administradas en los niveles de metastore, catálogo o esquema.
  • 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. Normalmente, se usan tablas externas para registrar grandes cantidades de datos existentes en Azure Databricks, o si también necesita acceso de escritura a los datos mediante herramientas fuera de Azure Databricks. Las tablas externas se admiten en varios formatos de datos. Una vez registrada una tabla externa en un metastore de Catálogo de Unity, puede administrar y auditar el acceso de Azure Databricks a ella--- y trabajar con ella---juste como puede con las tablas administradas.
  • 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. Al crear un volumen administrado, se almacena automáticamente en la ubicación de almacenamiento administrada asignada al esquema contenedor.
  • 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.

Databricks recomienda tablas y volúmenes administrados para la mayoría de los casos de uso, ya que permiten aprovechar al máximo las funcionalidades de gobernanza del catálogo de Unity y las optimizaciones de rendimiento. Para obtener información sobre los casos de uso típicos de tablas y volúmenes externos, consulte Tablas administradas y externas y volúmenes administrados y externos.

Consulte también:

Almacenamiento en la nube y aislamiento de datos

El catálogo de Unity usa el almacenamiento en la nube de dos maneras principales:

  • Almacenamiento administrado: ubicaciones predeterminadas para tablas administradas y volúmenes administrados (datos no estructurados y no tabulares) que se crean en Azure Databricks. Estas ubicaciones de almacenamiento administradas se pueden definir en el nivel de metastore, catálogo o esquema. Creas localizaciones de almacenamiento gestionadas en tu proveedor de nube, pero su ciclo de vida es totalmente administrado por Unity Catalog.
  • Ubicaciones de almacenamiento donde se almacenan tablas y volúmenes externos. Se trata de tablas y volúmenes 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. Normalmente, se usan tablas o volúmenes externos para registrar grandes cantidades de datos existentes en Azure Databricks, o si también necesita acceso de escritura a los datos mediante herramientas fuera de Azure Databricks.

Gobernanza del acceso al almacenamiento en la nube mediante ubicaciones externas

Tanto las ubicaciones de almacenamiento administradas como las ubicaciones de almacenamiento donde se almacenan tablas y volúmenes externos usan objetos protegibles de ubicación externa para administrar el acceso desde Azure Databricks. Los objetos de ubicación externa hacen referencia a una ruta de acceso de almacenamiento en la nube y a la credencial de almacenamiento necesaria para acceder a él. Las credenciales de almacenamiento son objetos protegibles del catálogo de Unity que registran las credenciales necesarias para acceder a una ruta de acceso de almacenamiento determinada. Juntos, estos elementos protegibles garantizan que el acceso al almacenamiento se controla y se realiza su seguimiento mediante el catálogo de Unity.

En el diagrama siguiente se muestra cómo las ubicaciones externas hacen referencia a las credenciales de almacenamiento y a las ubicaciones de almacenamiento en la nube.

Relación entre las credenciales de almacenamiento, las ubicaciones externas y el almacenamiento en la nube

En este diagrama:

  • Cada ubicación externa hace referencia a una credencial de almacenamiento y una ubicación de almacenamiento en la nube.
  • Varias ubicaciones externas pueden hacer referencia a la misma credencial de almacenamiento. La credencial de almacenamiento 1 concede acceso a todo en la ruta de acceso bucket/tables/*, por lo que tanto la ubicación externa A como la ubicación externa B hacen referencia a él.

Para obtener más información, consulte ¿Cómo controla Unity Catalog el acceso al almacenamiento en la nube?.

Jerarquía de ubicación de almacenamiento administrado

El nivel en el que se define el almacenamiento administrado en el Catálogo de Unity depende del modelo de aislamiento de datos preferido. Es posible que su organización requiera que determinados tipos de datos se almacenen dentro de cuentas o depósitos específicos en el inquilino en la nube.

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

Por ejemplo, supongamos que su organización tiene una política de cumplimiento de la empresa que requiere que los datos de producción relacionados con los recursos humanos residan en el contenedor abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. En el catálogo de Unity, 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 hr_prod catálogo (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 el aislamiento de almacenamiento no es necesario para algunos catálogos, puede establecer opcionalmente una ubicación de almacenamiento en el nivel de metastore. Esta ubicación sirve como ubicación predeterminada para tablas y volúmenes administrados en catálogos y esquemas que no tienen asignado almacenamiento. Sin embargo, normalmente, Databricks recomienda asignar ubicaciones de almacenamiento administradas independientes para cada catálogo.

El sistema evalúa la jerarquía de las ubicaciones de almacenamiento desde el esquema al catálogo y al 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.

Jerarquía de almacenamiento de Unity Catalog

Para obtener más información, consulte Especificar una ubicación de almacenamiento administrada en el catálogo de Unity.

Aislamiento del entorno mediante la vinculación del catálogo del área de trabajo

De forma predeterminada, los propietarios de catálogos (y los administradores de metastore, si están definidos para la cuenta) pueden hacer que un catálogo sea accesible para los usuarios de varias áreas de trabajo asociadas al mismo metastore de Unity Catalog.

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 Azure Databricks, el área de trabajo es el entorno de procesamiento de datos principal y los catálogos son el dominio de datos principal. El catálogo de Unity permite a los administradores de metastore, los propietarios de catálogos y los usuarios con el permiso de MANAGE asignar o "enlazar" catálogos a áreas de trabajo específicas. 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. Sin embargo, si usa áreas de trabajo para aislar el acceso a datos de usuario, es posible que desee limitar el acceso de catálogo a áreas de trabajo específicas de su cuenta, 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. Esto se conoce como enlace de catálogos del área de trabajo. Consulte Limitar el acceso de catálogo a áreas de trabajo específicas.

Catálogos de Unity Catalog

Nota:

Para un mayor aislamiento de datos, también puede enlazar el acceso al almacenamiento en la nube y el acceso al servicio en la nube a áreas de trabajo específicas. Consulte (Opcional) Asignar una credencial de almacenamiento a áreas de trabajo específicas, (opcional) Asignar una ubicación externa a áreas de trabajo específicas y (opcional) Asignar una credencial de servicio a áreas de trabajo específicas.

Cómo configurar el catálogo de Unity para mi organización?

Para usar Unity Catalog, el área de trabajo de Azure Databricks debe estar habilitada para Unity Catalog, lo que significa que el área de trabajo está asociada a un metastore de Unity Catalog.

¿Cómo se vincula un área de trabajo a un metastore? Depende de la cuenta y del área de trabajo:

  • Normalmente, cuando se crea un área de trabajo de Azure Databricks en una región por primera vez, el metastore se crea automáticamente y se adjunta al área de trabajo.
  • Para algunas cuentas antiguas, un administrador de cuenta debe crear el metastore y asignar los espacios de trabajo de esa región al metastore. Para obtener instrucciones, consulte Crear un metastore de Unity Catalog.
  • Si una cuenta ya tiene asignada una metastore para una región, un administrador de cuenta puede decidir si desea adjuntar automáticamente la metastore a todas las áreas de trabajo nuevas de esa región. Consulte Habilitar una metastore para que se asigne automáticamente a nuevas áreas de trabajo.

Ya sea que el área de trabajo se haya habilitado automáticamente para Unity Catalog o no, se requieren los pasos siguientes para comenzar con Unity Catalog:

  • Cree catálogos y esquemas para contener objetos de base de datos como tablas y volúmenes.
  • Cree ubicaciones de almacenamiento administradas para almacenar las tablas y volúmenes administrados en estos catálogos y esquemas.
  • Conceda al usuario acceso a catálogos, esquemas y objetos de base de datos.

Las áreas de trabajo que están habilitadas automáticamente para el catálogo de Unity aprovisionan un catálogo de áreas de trabajo con privilegios amplios concedidos a todos los usuarios del área de trabajo. Este catálogo es un punto de partida conveniente para probar el Unity Catalog.

Para obtener instrucciones detalladas sobre la configuración, consulte Introducción al catálogo de Unity.

Actualización de un área de trabajo existente al catálogo de Unity

Para obtener información sobre cómo actualizar un área de trabajo que no es de Unity Catalog a Unity Catalog, consulte Actualización de un área de trabajo de Azure Databricks al catálogo de Unity.

Requisitos y restricciones de Unity Catalog

Unity Catalog requiere tipos específicos de formatos de proceso y archivo, que se describen a continuación. A continuación también se enumeran algunas características de Azure Databricks que no son totalmente compatibles con el Unity Catalog en todas las versiones de Databricks Runtime.

Soporte de región

Todas las regiones admiten Unity Catalog. Para más información, consulte Regiones de Azure Databricks.

Requisitos de cómputo

Unity Catalog es compatible con clústeres que ejecutan Databricks Runtime 11.3 LTS o posteriores. Unity Catalog es compatible de forma predeterminada en todas las versiones de computación de SQL Warehouse.

Los clústeres que se ejecutan en versiones anteriores de Databricks Runtime no proporcionan compatibilidad con todas las características y funcionalidades de GA del catálogo de Unity.

Para acceder a los datos en el Catálogo de Unity, los clústeres deben configurarse con el modo de acceso correcto. Unity Catalog es seguro de forma predeterminada. Si un clúster no está configurado con el modo de acceso estándar o dedicado, el clúster no puede acceder a los datos en el Catálogo de Unity. Consulte Modos de acceso.

Para obtener información detallada sobre los cambios de funcionalidad del catálogo del Unity en cada versión de Databricks Runtime, consulte las notas de lanzamiento.

Compatibilidad con el formato de archivo

El catálogo de Unity admite los siguientes formatos de tabla:

Limitaciones

El catálogo de Unity tiene las siguientes limitaciones. Algunas de ellas son específicas de las versiones más antiguas de Databricks Runtime y los modos de acceso a la computación.

Las cargas de trabajo de Structured Streaming tienen limitaciones adicionales, en función del entorno de ejecución y el modo de acceso de Databricks. Consulte Requisitos y limitaciones de proceso estándar yRequisitos y limitaciones de proceso dedicados.

Databricks publica nuevas funcionalidades que reducen esta lista periódicamente.

  • Los grupos que se crearon anteriormente en un entorno de trabajo (es decir, grupos a nivel de entorno de trabajo) no se pueden usar en las instrucciones de Unity Catalog GRANT. Esto es para garantizar una visualización uniforme de los grupos que pueden abarcar espacios de trabajo. Para usar grupos en GRANT instrucciones, cree los grupos en el nivel de cuenta y actualice cualquier automatización para la administración de principales o grupos (como los conectores SCIM, Okta y Microsoft Entra ID y Terraform) para hacer referencia a los puntos de conexión de la cuenta en lugar de a los puntos de conexión del espacio de trabajo. Consulte Fuentes de grupo.

  • Las cargas de trabajo en R no admiten el uso de vistas dinámicas para la seguridad a nivel de fila o columna al ejecutarse en Databricks Runtime 15.3 y versiones anteriores.

    • Use un recurso de proceso dedicado que ejecute Databricks Runtime 15.4 LTS o superior para cargas de trabajo en R que consultan vistas dinámicas. Estas cargas de trabajo también requieren un área de trabajo habilitada para el proceso sin servidor. Para más información, consulte Control de acceso detallado en cómputo dedicado.

  • Una tabla administrada se puede clonar superficialmente en otra tabla administrada en Databricks Runtime 13.3 LTS y versiones posteriores. Una tabla externa se puede clonar superficialmente a otra tabla externa en Databricks Runtime 14.2 y versiones posteriores. Una tabla administrada no se puede copiar superficialmente en una tabla externa. Además, una tabla externa no se puede clonar de forma superficial en una tabla administrada. Para obtener más información, consulte Clone superficial para tablas del catálogo de Unity.

  • No se admite la creación de cubos para las tablas Unity Catalog. Si ejecuta comandos que intentan crear una tabla en cubo en Unity Catalog, se producirá una excepción.

  • Escribir en la misma ruta o tabla de Delta Lake desde áreas de trabajo en varias regiones puede resultar en un rendimiento poco fiable si algunos clústeres acceden a Unity Catalog y otros no.

  • La manipulación de particiones para tablas externas mediante comandos como ALTER TABLE ADD PARTITION requiere que se habilite el registro de metadatos de partición. Consulte Detección de particiones para tablas externas.

  • Cuando se usa el modo de sobrescritura para tablas que no están en formato Delta, el usuario debe tener el CREATE TABLE privilegio en el esquema primario y debe ser el propietario del objeto existente O tener el privilegio MODIFY en el objeto.

  • Las UDF de Python no se admiten en Databricks Runtime 12.2 LTS y versiones posteriores. Esto incluye UDAFs, UDTFs y Pandas en Spark (applyInPandas y mapInPandas). Las UDF escalares de Python se admiten en Databricks Runtime 13.3 LTS y versiones posteriores.

  • Las UDFs de Scala no se admiten en Databricks Runtime 14.1 y versiones anteriores en cómputo con modo de acceso estándar. Las UDFs escalares se admiten en Databricks Runtime 14.2 y versiones posteriores en el cálculo con el modo de acceso estándar.

  • No se admiten los grupos estándar de subprocesos de Scala. En su lugar, utilice los grupos de subprocesos especiales en org.apache.spark.util.ThreadUtils, por ejemplo, org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool. Sin embargo, los siguientes grupos de procesos en ThreadUtils no son compatibles: ThreadUtils.newForkJoinPool y cualquier grupo de procesos ScheduledExecutorService.

  • Los registros de diagnóstico de Azure solo registran eventos del catálogo de Unity en el nivel de área de trabajo. Para ver las acciones de nivel de cuenta, debe usar la tabla del sistema de registro de auditoría. Consulte la referencia de la tabla del sistema de registro de auditoría .

Los modelos registrados en Unity Catalog tienen limitaciones adicionales. Consulte limitaciones de .

Cuotas de recursos

Unity Catalog aplica cuotas de recursos en todos los objetos protegibles. Estas cuotas se enumeran en Límites de recursos. Si espera superar estos límites de recursos, póngase en contacto con el equipo de la cuenta de Azure Databricks.

Puede supervisar el uso de la cuota mediante las API de cuotas de recursos de Unity Catalog. Consulte Supervisión del uso de cuotas de recursos del catálogo de Unity.

Recursos adicionales

  • Last updated on