Compartilhar via

Objetos de banco de dados no metastore herdado do Hive

  • Artigo

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

Este artigo foca no trabalho com objetos de banco de dados registrados no metastore herdado do Hive. Especificamente, este artigo destaca como trabalhar com objetos de metastore do Hive se difere de trabalhar com objetos do Catálogo do Unity. Ele também descreve outros comportamentos que podem ser inesperados.

O Databricks recomenda migrar todos os dados do metastore herdado do Hive para o Catálogo do Unity. Confira Atualizar tabelas e visualizações do Hive para o Catálogo do Unity.

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

Embora os workspaces do Azure Databricks continuem incluindo o metastore interno do Hive, a governança de dados usando o metastore do Hive foi preterida. O Databricks recomenda usar o Catálogo do Unity em toda a governança de dados. Consulte Trabalhar com o Catálogo Unity e o metastore herdado do Hive.

Habilitar um espaço de trabalho no Catálogo do Unity 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 Catálogo do Unity no catálogo hive_metastore. Um metastore híbrido do Hive e um espaço de trabalho do Catálogo do Unity podem ser um modelo útil na transição de um espaço de trabalho de longa data do metastore do Hive. No entanto, as vantagens de governança de dados e desempenho do Catálogo do Unity são altas e você deve fazer a transição completa dos espaços de trabalho o mais rápido possível.

O metastore do Hive usa o controle de acesso à tabela (ACLs de tabela) para gerenciar o acesso a objetos de banco de dados. Ainda resta um suporte para controle de acesso à tabela ao usar a computação no modo de acesso compartilhado. Confira Controle de acesso à tabela no metastore do Hive (herdado).

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

Observação

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 catálogo hive_metastore?

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

SELECT * FROM hive_metastore.schema_name.table_name

Observação

Opcionalmente, você pode definir o catálogo hive_metastore como o padrão do espaço de trabalho em espaços de trabalho habilitados para o Catálogo do Unity. Confira 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.

Há algumas diferenças importantes entre o Catálogo do Unity e o metastore do Hive, incluindo as seguintes:

  • Não é possível criar esquemas no metastore do Hive usando o Gerenciador de Catálogos. 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 nos nomes.
  • O metastore do Hive permite declarar um LOCATION para um esquema durante a criação. Isso funciona de forma semelhante às localizações de armazenamento gerenciado do Catálogo do Unity, com as seguintes diferenças comportamentais:
    • Se você não fornecer uma localização, a localização padrão /user/hive/warehouse/<schema-name> será usada. Essa localização está na raiz do DBFS, o que não é recomendado 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 do DBFS e montagens do DBFS.
    • O acesso à localização não é gerenciado pelo metastore do Hive.
    • Excluir um esquema no metastore do Hive fará com que todos os arquivos na localização desse 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 ao trabalhar com localizações de esquema do metastore do Hive:

  • Não atribua uma localização de esquema que já contenha dados.
  • Não crie uma tabela externa em uma localização de esquema.
  • Não compartilhe uma localização entre vários esquemas.
  • Não atribua uma localização de esquema que se sobreponha a outra. Em outras palavras, não use um caminho que seja filho de outra localização de esquema.
  • Não atribua uma localização de esquema que se sobreponha à localização 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 Catálogo do Unity. Assim como as tabelas gerenciadas do Catálogo do Unity, as tabelas gerenciadas do metastore do Hive usam o Delta Lake por padrão. No entanto, no metastore do Hive, ao contrário do Catálogo do Unity, você também pode criar uma tabela gerenciada usando a maioria dos outros formatos de dados compatíveis com o 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 dos dados de tabelas gerenciadas da mesma forma que o Catálogo do Unity. Quando você descarta uma tabela gerenciada no metastore do Hive, todos os arquivos de dados subjacentes são excluídos imediatamente. No Catálogo do Unity, por outro lado, você pode fazer UNDROP de uma tabela gerenciada por 7 dias e os dados são excluídos permanentemente em 30 dias.

Você pode usar o acesso baseado em caminho para ler ou gravar dados em tabelas gerenciadas do metastore do Hive, enquanto no Catálogo do Unity isso não é possível e nem necessário.

Tabelas externas no metastore do Hive

A maioria das tabelas criadas no Azure Databricks antes da introdução do Catálogo do Unity foi configurada como tabelas externas no metastore do Hive. As recomendações herdadas que favoreciam tabelas externas costumavam se concentrar em alguns aspectos 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, os dados de produção tinham menos probabilidade de acabar acidentalmente na raiz do DBFS.

O Azure Databricks agora recomenda tabelas gerenciadas do Catálogo do Unity para a maioria dos armazenamentos de dados tabulares. Veja Trabalhar com tabelas gerenciadas.

Exibições no metastore do Hive

Você pode declarar uma exibição no metastore do Hive com suporte de qualquer fonte de dados compatível com o Azure Databricks. No Catálogo do Unity, você só pode declarar exibições em tabelas e exibições do Catálogo do Unity, incluindo tabelas externas, exibições materializadas e tabelas de compartilhamento do 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.

Considere o seguinte exemplo:

  • Uma tabela my_table é definida usando o caminho de montagem /mnt/my_table 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 ao my_table a um grupo de usuários.
    • As ACLs de tabela herdadas só se aplicam à computação configurada com o modo de acesso compartilhado ou SQL warehouses.
  • Uma exibição my_view é definida diretamente no URI da nuvem que dá suporte aos mesmos arquivos de dados 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.
    • As credenciais de URI dependem de políticas de acesso definidas na sessão do Spark ou na configuração de computação.

A exibição my_view tem as seguintes propriedades:

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

Observação

Este é um exemplo de comportamento inesperado que você pode encontrar e não abrange todas as possíveis armadilhas apresentadas pelas exibições no metastore herdado do Hive. O Databricks recomenda usar o Catálogo do Unity em todas as definições de exibição.

Tabelas herdadas do Hive e suporte ao HiveQL

O Azure Databricks inclui algum suporte herdado para tabelas do Hive e funcionalidade do 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 ou outra funcionalidade do Hive, pois essa funcionalidade não é otimizada e não tem suporte em algumas configurações de computação.

Os seguintes artigos descrevem a funcionalidade herdada do Hive: