Compartir vía

Objetos de base de datos en el metastore de Hive heredado

  • Artículo

La documentación de Azure Databricks se centra en trabajar con objetos de datos mediante el catálogo de Unity, pero la mayoría de las instrucciones también se aplican a trabajar con objetos registrados en el metastore de Hive heredado.

En este artículo se centra en cómo trabajar con objetos de base de datos registrados en el metastore de Hive heredado. En concreto, en este artículo se indica dónde trabajar con objetos de metastore de Hive difieren de trabajar con objetos del catálogo de Unity. También describe otros comportamientos que podrían ser inesperados.

Databricks recomienda migrar todos los datos del metastore de Hive heredado a Unity Catalog. Consulte Actualización de tablas y vistas de Hive al Unity Catalog.

¿Cómo funciona la gobernanza de datos de metastore de Hive?

Aunque las áreas de trabajo de Azure Databricks siguen incluyendo el metastore de Hive integrado, la gobernanza de datos mediante el metastore de Hive está en desuso. Databricks recomienda usar Unity Catalog para toda la gobernanza de datos. Consulte Trabajar con Unity Catalog y el metastore Hive heredado.

La habilitación de un área de trabajo para el catálogo de Unity no reduce la capacidad de trabajar con datos ya registrados en metastore de Hive. Todos los objetos de datos registrados en el metastore de Hive heredado se muestran en las interfaces de Unity Catalog en el catálogo hive_metastore. Una tienda de metadatos de Hive híbrida y un área de trabajo de Unity Catalog pueden ser un modelo útil para realizar la transición de un área de trabajo de metastore de Hive de larga duración. Sin embargo, las ventajas de gobernanza y rendimiento de los datos de Unity Catalog son altas y debe realizar la transición completa de las áreas de trabajo tan pronto como pueda.

El metastore de Hive usa el control de acceso a tablas (ACL de tabla) para administrar el acceso a los objetos de base de datos. Se mantiene cierta compatibilidad con el control de acceso a las tablas cuando se usa el proceso en modo de acceso compartido. Consulte Control de acceso a la tabla de metastore de Hive (heredado).

El paso a través de credenciales es un patrón en desuso para la gobernanza de datos en objetos de base de datos de metastore de Hive. En este artículo no se aborda el paso directo de credenciales. Consulte Acceso directo a credenciales (heredado).

Nota:

Cuando en este artículo se hace referencia al control de acceso a datos en el metastore de Hive, se hace referencia al control de acceso a tablas heredado.

¿Qué es el catálogo hive_metastore?

En un área de trabajo habilitada para el catálogo de Unity, todos los esquemas de la metastore de Hive aparecen como elementos secundarios del catálogo hive_metastore en el espacio de nombres de tres niveles del catálogo de Unity. Hive metastore no usa realmente catálogos y esta construcción proporciona un punto de entrada a las tablas en el metastore de Hive heredado para los usuarios del catálogo de Unity. Use la sintaxis siguiente para consultar tablas en el metastore de Hive heredado:

SELECT * FROM hive_metastore.schema_name.table_name

Nota:

Opcionalmente, puede establecer el catálogo hive_metastore como el valor predeterminado del área de trabajo en áreas de trabajo habilitadas para catálogos de Unity. Consulte Administración del catálogo predeterminado.

Esquemas en metastore de Hive

En el metastore de Hive heredado, un esquema es el nivel más alto de la jerarquía de objetos de datos.

Hay algunas diferencias importantes entre el catálogo de Unity y el metastore de Hive, incluidas las siguientes:

  • No se pueden crear esquemas en la metastore de Hive mediante el Explorador de catálogos. Puede ver y editar permisos para esquemas.
  • Los esquemas creados en el metastore de Hive solo pueden usar caracteres ASCII alfanuméricos y caracteres de subrayado en sus nombres.
  • Metastore de Hive permite declarar un LOCATION para un esquema durante la creación. Esto funciona de forma similar a las ubicaciones de almacenamiento administrados del catálogo de Unity, con las siguientes diferencias de comportamiento:
    • Si no proporciona una ubicación, se usa la ubicación predeterminada /user/hive/warehouse/<schema-name>. Esta ubicación está en la raíz de DBFS, que no se recomienda para almacenar ningún dato de producción.
    • La ruta de acceso proporcionada puede ser cualquier ubicación de almacenamiento en la nube disponible para el usuario que cree el esquema, incluidos los URI en la nube, la raíz de DBFS y los montajes DBFS.
    • El acceso a la ubicación no está gestionado por el metastore de Hive.
    • Eliminar un esquema en la metastore de Hive cause que todos los archivos de esa ubicación de esquema se eliminen de forma recursiva, independientemente del tipo de tabla (administrada o externa).

Para evitar la pérdida accidental de datos, Databricks recomienda lo siguiente al trabajar con ubicaciones de esquema de metastore de Hive:

  • No asigne una ubicación de esquema que ya contenga datos.
  • No cree una tabla externa en una ubicación de esquema.
  • No comparta una ubicación entre varios esquemas.
  • No asigne una ubicación de esquema que se superponga a otra ubicación de esquema. En otras palabras, no use una ruta de acceso que sea un elemento secundario de otra ubicación de esquema.
  • No asigne una ubicación de esquema que superponga la ubicación de una tabla externa.

Tablas administradas en metastore de Hive

Las tablas administradas en metastore de Hive no tienen ninguna de las ventajas de rendimiento de las tablas administradas en el catálogo de Unity. Al igual que las tablas administradas por el catálogo de Unity, las tablas administradas de metastore de Hive usan Delta Lake de forma predeterminada. Sin embargo, en el metastore de Hive, a diferencia de Unity Catalog, también puede crear una tabla administrada con la mayoría de los otros formatos de datos compatibles con Azure Databricks.

Las tablas administradas en metastore de Hive siempre se crean en la ubicación de almacenamiento del esquema contenedor. El proceso que se usa para consultar una tabla administrada debe tener acceso a la ubicación de almacenamiento.

El metastore de Hive no administra el diseño de datos de las tablas administradas de la manera que hace Unity Catalog. Al quitar una tabla administrada en el metastore de Hive, todos los archivos de datos subyacentes se eliminan inmediatamente. En el Catálogo de Unity, por otro lado, puede UNDROP administrar una tabla durante 7 días y los datos se eliminan permanentemente en un plazo de 30 días.

Puede usar el acceso basado en rutas de acceso para leer o escribir datos en tablas administradas de Metastore de Hive, mientras que en el catálogo de Unity no puede y no es necesario.

Tablas externas en metastore de Hive

La mayoría de las tablas creadas en Azure Databricks antes de la introducción del catálogo de Unity se configuraron como tablas externas en el metastore de Hive. Las recomendaciones heredadas que favorecieron las tablas externas suelen centrarse en algunos aspectos clave:

  • Puede registrar una tabla externa sobre los datos existentes en el almacenamiento de objetos en la nube.
  • Puede acceder directamente a archivos de datos en tablas externas desde sistemas externos para lecturas o escrituras.
  • Los archivos de datos no se eliminaron si la tabla se quitó accidentalmente.
  • Dado que las tablas externas requieren un LOCATION, es menos probable que los datos de producción terminen accidentalmente en la raíz de DBFS.

Azure Databricks ahora recomienda tablas administradas de Unity Catalog para la mayoría del almacenamiento de datos tabulares. Consulte Trabajar con tablas administradas.

Vistas en metastore de Hive

Puede declarar una vista en el metastore de Hive respaldada por cualquier origen de datos compatible con Azure Databricks. En el catálogo de Unity, solo puede declarar vistas en las tablas y vistas del catálogo de Unity, incluidas las tablas externas, las vistas materializadas y las tablas de Delta Sharing.

Debido a la capacidad de declarar vistas en orígenes de datos no tabulares, las vistas en el metastore de Hive pueden conceder acceso inesperado o no deseado a los datos en combinación con otras configuraciones de acceso en el entorno de usuario.

Por ejemplo, considere lo siguiente:

  • Una tabla my_table se define mediante la ruta de acceso de montaje de DBFS /mnt/my_table.
    • Las credenciales de montaje de DBFS se almacenan en el área de trabajo, por lo que todos los usuarios tienen acceso a esta ruta de acceso de forma predeterminada.
  • Las ACL de tabla se usan para restringir el acceso a my_table a un grupo de usuarios.
    • Las ACL de tablas heredadas solo se aplican en equipos configurados con el modo de acceso compartido o en almacenes SQL.
  • Una vista my_view se define directamente en el URI de nube que respalda los mismos archivos de datos 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.
    • Las credenciales de URI se basan en las directivas de acceso definidas en la configuración de proceso o sesión de Spark.

La vista my_view tiene las siguientes propiedades:

  • No usa las credenciales de montaje de DBFS usadas para montar el almacenamiento de objetos en la nube en /mnt/my_table.
  • No respeta las ACL de tabla establecidas en my_table, independientemente de las configuraciones de proceso.
  • Requiere una directiva de acceso a datos configurada para el proceso que proporciona acceso de lectura a 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.

Nota:

Este es un ejemplo de comportamiento inesperado que podría encontrar y no se completan todos los posibles problemas presentados por las vistas en el metastore de Hive heredado. Databricks recomienda usar el catálogo de Unity para todas las definiciones de vista.

Compatibilidad con tablas heredadas de Hive y HiveQL

Azure Databricks incluye cierta compatibilidad heredada con las tablas de Hive y la funcionalidad de HiveQL. Esta funcionalidad es un resto de las versiones anteriores de Azure Databricks y el ecosistema de herramientas de Apache Hadoop. Databricks no recomienda usar tablas de Hive u otra funcionalidad de Hive, ya que esta funcionalidad no está optimizada y carece de compatibilidad con algunas configuraciones de proceso.

En los artículos siguientes se describe la funcionalidad heredada de Hive: