Compartilhar via

Objetos de banco de dados no metastore herdado do Hive

  • Artigo

A documentação do Azure Databricks se concentra em trabalhar com objetos de dados usando o Unity Catalog, mas a maioria das instruções também se aplica ao trabalho com objetos registrados no metastore herdado do Hive.

Este artigo se concentra em como trabalhar com objetos de banco de dados registrados no metastore herdado do Hive. Especificamente, este artigo chama a atenção para onde trabalhar com objetos metastore do Hive difere do trabalho com objetos do Unity Catalog. Também descreve outros comportamentos que podem ser inesperados.

O Databricks recomenda que você migre todos os dados do metastore herdado do Hive para o Unity Catalog. Consulte Atualizar tabelas e exibições do Hive para o Catálogo Unity.

Como funciona a governança de dados do metastore do Hive?

Embora os espaços de trabalho do Azure Databricks continuem a incluir o metastore interno do Hive, a governança de dados usando o metastore do Hive foi preterida. O Databricks recomenda que você use o Unity Catalog para toda a governança de dados. Consulte Trabalhar com o Unity Catalog e o metastore herdado do Hive.

Habilitar um espaço de trabalho para o Unity Catalog não reduz sua capacidade de trabalhar com dados já registrados no metastore do Hive. Todos os objetos de dados registrados no metastore herdado do Hive são exibidos nas interfaces do hive_metastore Unity Catalog no catálogo. Um metastore híbrido do Hive e um espaço de trabalho do Unity Catalog podem ser um modelo útil para a transição de um espaço de trabalho de metastore do Hive de longa data. No entanto, as vantagens de governança de dados e desempenho do Unity Catalog são altas, e você deve fazer a transição completa de seus espaços de trabalho assim que puder.

O metastore do Hive usa o controle de acesso à tabela (ACLs de tabela) para gerenciar o acesso a objetos de banco de dados. Algum suporte permanece para controle de acesso à tabela quando você usa computação no modo de acesso compartilhado. Consulte Controle de acesso à tabela de metastore do Hive (legado).

A passagem de credenciais é um padrão preterido para governança de dados em objetos de banco de dados de metastore do Hive. Este artigo não aborda a passagem de credenciais. Consulte Passagem de credenciais (legado).

Nota

Quando este artigo se refere ao controle de acesso a dados no metastore do Hive, ele está se referindo ao controle de acesso à tabela herdada.

O que é o hive_metastore catálogo?

Em um espaço de trabalho habilitado para o Unity Catalog, todos os esquemas no metastore do Hive aparecem como filhos do hive_metastore catálogo no namespace de três níveis do Unity Catalog. Na verdade, o metastore do Hive não usa catálogos, e essa construção fornece um ponto de entrada para tabelas no metastore herdado do Hive para usuários do Unity Catalog. Use a sintaxe a seguir para consultar tabelas no metastore herdado do Hive:

SELECT * FROM hive_metastore.schema_name.table_name

Nota

Opcionalmente, você pode definir o hive_metastore catálogo como o espaço de trabalho padrão nos espaços de trabalho habilitados para Unity Catalog. Consulte Gerenciar o catálogo padrão.

Esquemas no metastore do Hive

No metastore herdado do Hive, um esquema é o nível mais alto na hierarquia de objetos de dados.

Existem algumas diferenças importantes entre o Unity Catalog e o metastore do Hive, incluindo o seguinte:

  • Não é possível criar esquemas no metastore do Hive usando o Catalog Explorer. Você pode exibir e editar permissões para esquemas.
  • Os esquemas criados no metastore do Hive podem usar apenas caracteres ASCII alfanuméricos e sublinhados em seus nomes.
  • O metastore do Hive permite que você declare um LOCATION para um esquema durante a criação. Isso funciona de forma semelhante aos locais de armazenamento gerenciado do Unity Catalog, com as seguintes diferenças comportamentais:
    • Se você não fornecer um local, o local /user/hive/warehouse/<schema-name> padrão será usado. Esse local está na raiz DBFS, que não é recomendada para armazenar dados de produção.
    • O caminho fornecido pode ser qualquer local de armazenamento em nuvem disponível para o usuário que cria o esquema, incluindo URIs de nuvem, raiz DBFS e montagens DBFS.
    • O acesso ao local não é gerenciado pelo metastore do Hive.
    • A exclusão de um esquema no metastore do Hive faz com que todos os arquivos nesse local do esquema sejam excluídos recursivamente, independentemente do tipo de tabela (gerenciada ou externa).

Para evitar a perda acidental de dados, o Databricks recomenda o seguinte quando você trabalha com locais de esquema de metastore do Hive:

  • Não atribua um local de esquema que já contenha dados.
  • Não crie uma tabela externa em um local de esquema.
  • Não compartilhe um local entre vários esquemas.
  • Não atribua um local de esquema que se sobreponha a outro local de esquema. Em outras palavras, não use um caminho que seja filho de outro local do esquema.
  • Não atribua um local de esquema que se sobreponha ao local de uma tabela externa.

Tabelas gerenciadas no metastore do Hive

As tabelas gerenciadas no metastore do Hive não têm nenhum dos benefícios de desempenho das tabelas gerenciadas no Unity Catalog. Como as tabelas gerenciadas do Unity Catalog, as tabelas gerenciadas pelo metastore do Hive usam o Delta Lake por padrão. No entanto, no metastore do Hive, ao contrário do Unity Catalog, você também pode criar uma tabela gerenciada usando a maioria dos outros formatos de dados suportados pelo Azure Databricks.

As tabelas gerenciadas no metastore do Hive são sempre criadas no local de armazenamento do esquema que as contém. A computação usada para consultar uma tabela gerenciada deve ter acesso ao local de armazenamento.

O metastore do Hive não gerencia o layout de dados de tabelas gerenciadas da mesma forma que o Unity Catalog. Quando você solta uma tabela gerenciada no metastore do Hive, todos os arquivos de dados subjacentes são excluídos imediatamente. No Unity Catalog, por outro lado, você pode UNDROP gerenciar uma tabela por 7 dias e os dados são excluídos permanentemente dentro de 30 dias.

Você pode usar o acesso baseado em caminho para ler ou gravar dados em tabelas gerenciadas pelo metastore do Hive, enquanto no Unity Catalog você não pode e não precisa.

Tabelas externas no metastore do Hive

A maioria das tabelas criadas no Azure Databricks antes da introdução do Unity Catalog foram configuradas como tabelas externas no metastore do Hive. As recomendações legadas que favoreciam as tabelas externas geralmente se concentravam em alguns aspetos principais:

  • Você pode registrar uma tabela externa sobre os dados existentes no armazenamento de objetos na nuvem.
  • Você pode acessar diretamente arquivos de dados em tabelas externas de sistemas externos para leituras ou gravações.
  • Os arquivos de dados não foram excluídos se a tabela foi descartada acidentalmente.
  • Como as tabelas externas exigem um LOCATION, era menos provável que os dados de produção acabassem acidentalmente na raiz do DBFS.

O Azure Databricks agora recomenda tabelas gerenciadas do Unity Catalog para a maioria do armazenamento de dados tabulares. Consulte Trabalhar com tabelas gerenciadas.

Visualizações no metastore do Hive

Você pode declarar um modo de exibição no metastore do Hive apoiado por qualquer fonte de dados suportada pelo Azure Databricks. No Unity Catalog, você só pode declarar exibições em tabelas e exibições do Unity Catalog, incluindo tabelas estrangeiras, exibições materializadas e tabelas de Compartilhamento Delta.

Devido à capacidade de declarar exibições em fontes de dados não tabulares, as exibições no metastore do Hive podem conceder acesso inesperado ou não intencional aos dados em combinação com outras configurações de acesso no ambiente do usuário.

Por exemplo, considere o seguinte:

  • Uma tabela my_table é definida usando o caminho /mnt/my_tablede montagem do DBFS .
    • As credenciais de montagem do DBFS são armazenadas no espaço de trabalho, para que todos os usuários tenham acesso a esse caminho por padrão.
  • As ACLs de tabela são usadas para restringir o acesso a my_table um grupo de usuários.
    • As ACLs de tabela herdadas só se aplicam à computação configurada com modo de acesso compartilhado ou armazéns SQL.
  • Uma exibição my_view é definida diretamente em relação ao URI da nuvem que suporta os mesmos arquivos de 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'dados.
    • As credenciais de URI dependem de políticas de acesso definidas na sessão do Spark ou na configuração de computação.

O modo de exibição my_view tem as seguintes propriedades:

  • Ele não usa as credenciais de montagem do DBFS usadas para montar o armazenamento de objetos na nuvem no /mnt/my_table.
  • Ele não respeita as ACLs de tabela definidas em my_table, independentemente das configurações de computação.
  • Requer uma política de acesso a dados configurada para computação que forneça acesso de leitura ao 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.

Nota

Este é um exemplo de comportamento inesperado que você pode encontrar, e não compreenda todas as armadilhas potenciais apresentadas pelas visualizações no metastore herdado do Hive. A Databricks recomenda o uso do Unity Catalog para todas as definições de exibição.

Tabelas Hive herdadas e suporte a HiveQL

O Azure Databricks inclui algum suporte herdado para tabelas Hive e funcionalidade HiveQL. Essa funcionalidade é um remanescente das versões anteriores do Azure Databricks e do ecossistema de ferramentas do Apache Hadoop. O Databricks não recomenda o uso de tabelas do Hive ou outra funcionalidade do Hive, pois essa funcionalidade não é otimizada e carece de suporte em algumas configurações de computação.

Os seguintes artigos descrevem a funcionalidade herdada do Hive: