Partilhar 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 destaca where trabalhar com objetos metastore do Hive difere de trabalhar com objetos 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. Veja Atualizar o Hive tables e views para Unity Catalog.

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. A 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 registados no metastore herdado do Hive são exibidos nas interfaces do Unity Catalog no hive_metastorecatalog. Um metastore híbrido do Hive e um espaço de trabalho do Unity Catalog pode ser um modelo útil para a transição de um espaço de trabalho de metastore do Hive que existe há muito tempo. 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 table controle de acesso (ACLstable) para gerenciar o acesso a objetos de banco de dados. Algum suporte existe para table controlo de acesso quando se utiliza computação no modo de acesso partilhado. Consulte metastore do Hive table controle de acesso (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

Where este artigo se refere ao controle de acesso a dados no metastore do Hive, ele está se referindo ao controle de acesso table herdado.

Qual é o hive_metastorecatalog?

Em um espaço de trabalho habilitado para o Unity Catalog, todos os esquemas no metastore do Hive aparecem como filhos do hive_metastorecatalog no namespace de três níveis do Unity Catalog. Na verdade, o metastore do Hive não usa catalogs, e essa construção fornece um ponto de entrada para tables no metastore herdado do Hive para usuários do Unity Catalog. Utilize a seguinte sintaxe para consultar tables no repositório legado do Hive:

SELECT * FROM hive_metastore.schema_name.table_name

Nota

Opcionalmente, você pode set o hive_metastorecatalog como o espaço de trabalho padrão nos espaços de trabalho habilitados para Unity Catalog. Consulte Gerenciar o catalogpadrão .

Esquemas no metastore do Hive

No metastore herdado do Hive, um schema é 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 declarar um LOCATION para um schema durante a sua criação. Isto funciona de forma semelhante aos locais de armazenamento geridos 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 schema, incluindo URIs na nuvem, raiz DBFS e montagens DBFS.
    • O acesso ao local não é gerenciado pelo metastore do Hive.
    • A exclusão de um schema no metastore do Hive faz com que todos os arquivos nesse local schema sejam excluídos recursivamente, independentemente do tipo de table (gerenciado ou externo).

Para evitar a perda acidental de dados, a Databricks recomenda o seguinte ao trabalhar com locais de metastore do Hive schema:

  • Não atribua um local schema que já contenha dados.
  • Não crie um table externo em um local schema.
  • Não compartilhe um local entre vários esquemas.
  • Não atribua um local schema que se sobreponha a outro local schema. Em outras palavras, não use um caminho que seja subordinado a outro local schema.
  • Não atribua uma posição schema que se sobreponha à posição de um tableexterno.

Gerenciado tables no metastore do Hive

Os tables gerenciados no metastore do Hive não têm nenhum dos benefícios de desempenho do tables gerenciado no Unity Catalog. Como o Unity Catalog gerenciado tables, o metastore do Hive gerenciado tables usa o Delta Lake por padrão. No entanto, no metastore do Hive, ao contrário do Unity Catalog, você também pode criar um table gerenciado usando a maioria dos outros formatos de dados suportados pelo Azure Databricks.

Os tables geridos no metastore do Hive são sempre criados no local de armazenamento do schemaque os contém. A computação que você usa para consultar um table gerenciado deve ter acesso ao local de armazenamento.

O metastore do Hive não gere o layout de dados do tables da mesma forma que o Unity Catalog. Quando você solta um table gerenciado no metastore do Hive, todos os arquivos de dados subjacentes são excluídos imediatamente. No Unity Catalog, por outro lado, você pode UNDROP um table gerenciado 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 no metastore Hive gerenciado tables, enquanto no Unity Catalog você não pode e não precisa.

tables externo no metastore do Hive

A maioria dos tables criados no Azure Databricks antes da introdução do Unity Catalog foram configurados como tables externos no metastore do Hive. As recomendações legadas que favoreceram tables externas geralmente se concentraram em alguns aspectos-chave:

  • Você pode registrar um table externo sobre os dados existentes no armazenamento de objetos na nuvem.
  • Você pode aceder diretamente a ficheiros de dados no tables externo a partir de sistemas externos para leitura ou escrita.
  • Os arquivos de dados não eram eliminados caso o table tivesse sido descartado acidentalmente.
  • Como os tables externos exigem um LOCATION, era menos provável que os dados de produção acabassem acidentalmente na raiz do DBFS.

O Azure Databricks agora recomenda o Unity Catalogtables gerenciado para a maioria do armazenamento de dados tabulares. Consulte Trabalhar com tablesgerenciado .

Views 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 views contra o Unity Catalogtables e views, incluindo tablesestrangeiros, viewsmaterializados e Delta Sharing tables.

Devido à capacidade de declarar views em relação a fontes de dados que não são tabulares, views no metastore do Hive pode conceder acesso aos dados de maneira inesperada ou não intencional em conjunto com outras configurações de acesso no ambiente do utilizador.

Por exemplo, considere o seguinte:

  • Um tablemy_table é definido usando o caminho de montagem DBFS /mnt/my_table.
    • As montagens DBFS credentials são armazenadas no espaço de trabalho, e todos os utilizadores têm acesso a esse caminho por padrão.
  • Table ACLs são usadas para restringir o acesso a my_table a um grupo de utilizadores.
    • As ACLs table herdadas só se aplicam à computação configurada com o 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 URIs credentials dependem de políticas de acesso definidas na sessão do Spark ou na configuração de cálculo.

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

  • Não utiliza o ponto de montagem DBFS credentials, usado para montar o armazenamento de objetos em nuvem no /mnt/my_table.
  • Isso não respeita as table ACLs set no 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 por views no metastore herdado do Hive. O Databricks recomenda o uso do Unity Catalog para todas as definições de exibição.

Suporte ao Hive tables herdado e ao HiveQL

O Azure Databricks inclui algum suporte herdado para a funcionalidade Hive tables e 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 do Hive tables 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: