Partilhar via


Federação de metastore do Hive: habilitar o Unity Catalog para controlar tabelas registradas em um metastore do Hive

Este artigo apresenta a federação de metastore do Hive, um recurso que permite que o Unity Catalog controle tabelas armazenadas em um metastore do Hive. Você pode federar um metastore externo do Hive ou um metastore interno herdado do Azure Databricks Hive.

A federação de metastore do Hive pode ser utilizada nos seguintes casos de uso:

  • Como uma etapa no caminho de migração para o Unity Catalog, permitindo a migração incremental sem adaptação de código, com algumas de suas cargas de trabalho continuando a usar dados registrados em seu metastore do Hive enquanto outras são migradas.

    Este caso de uso é mais adequado para organizações que usam um metastore interno herdado do Azure Databricks Hive atualmente, porque os metastores internos federados do Hive permitem cargas de trabalho de leitura e gravação.

  • Para fornecer um modelo híbrido de longo prazo para organizações que devem manter alguns dados em um metastore do Hive juntamente com seus dados registrados no Unity Catalog.

    Este caso de uso é mais adequado para organizações que usam um metastore externo do Hive, porque os catálogos estrangeiros para esses metastores do Hive são somente leitura.

Diagrama que introduz a federação do Hive

Visão geral da federação de metastore do Hive

Na federação de metastore Hive, estabelece-se uma conexão do espaço de trabalho do Azure Databricks com o metastore do Hive, e o Unity Catalog rastreia o metastore do Hive para preencher um catálogo externo, às vezes chamado de catálogo federado. Este processo permite que a sua organização trabalhe com as tabelas de metastore do Hive no Unity Catalog, fornecendo controles de acesso centralizados, linhagem, pesquisa e muito mais.

Os metastores federados do Hive externos ao seu espaço de trabalho do Azure Databricks permitem leituras usando o Catálogo Unity. Os metastores internos do Hive permitem leituras e gravações, atualizando os metadados do Hive, bem como os metadados do Unity Catalog quando você escreve.

Quando você consulta tabelas estrangeiras em um metastore federado do Hive, o Unity Catalog fornece a camada de governança, executando funções como verificações de controle de acesso e auditoria, enquanto as consultas são executadas usando a semântica do metastore do Hive. Por exemplo, se um usuário consultar uma tabela armazenada no formato Parquet em um catálogo estrangeiro, então:

  • O Unity Catalog verifica se o usuário tem acesso à tabela e infere a linhagem para a consulta.
  • A consulta em si é executada no metastore subjacente do Hive, aproveitando os metadados mais recentes e as informações de partição armazenadas lá.

Diagrama que mostra a relação entre as cargas de trabalho HMS, Unity Catalog e Databricks em um cenário de federação do Hive

Como a federação de metastore do Hive se compara ao uso de tabelas externas do Unity Catalog?

Unity Catalog tem a capacidade de criar tabelas externas, pegando dados que já existem em um local de armazenamento em nuvem arbitrário e registrando-os no Unity Catalog como uma tabela. Esta seção explora as diferenças entre tabelas externas e estrangeiras em um metastore federado do Hive.

Ambos os tipos de tabela têm as seguintes propriedades:

  • Pode ser usado para registrar um local arbitrário no armazenamento em nuvem como uma tabela.
  • Pode aplicar permissões do Catálogo Unity e controles de acesso refinados.
  • Pode ser visualizado em linhagem para consultas que fazem referência a eles.

As tabelas externas em um metastore federado do Hive têm as seguintes propriedades:

  • São descobertos automaticamente com base na varredura de um metastore do Hive. Assim que as tabelas são criadas no metastore do Hive, elas são exibidas e ficam disponíveis para consulta no catálogo estrangeiro do Unity Catalog.
  • Permita que tabelas sejam definidas com semântica do Hive, como SerDes do Hive e partições.
  • Permitir que as tabelas tenham rotas sobrepostas com outras tabelas em catálogos estrangeiros.
  • Permitir que as tabelas sejam localizadas em locais de DBFS root.
  • Inclua visualizações definidas no metastore do Hive.

Dessa forma, pode-se pensar em tabelas externas em um metastore federado do Hive como oferecendo compatibilidade retroativa com o metastore do Hive, permitindo que cargas de trabalho usem semântica exclusiva do Hive, mas com governança fornecida pelo Unity Catalog.

No entanto, alguns recursos do Catálogo Unity não estão disponíveis em tabelas estrangeiras, por exemplo:

  • Recursos disponíveis apenas para tabelas gerenciadas do Unity Catalog, como otimização preditiva.
  • Pesquisa vetorial, Delta Sharing, monitorização do Lakehouse e tabelas online.
  • Algumas funcionalidades de armazenamento de características, incluindo criação de armazenamento de características, criação de serviço para modelo, criação de especificações de características, registo em log de modelo e avaliação em lote.

O desempenho pode ser marginalmente pior do que as cargas de trabalho no Unity Catalog ou no metastore do Hive porque tanto o metastore do Hive quanto o Unity Catalog estão no caminho de consulta de uma tabela estrangeira.

Para obter mais informações sobre a funcionalidade suportada, consulte Requisitos e suporte a recursos.

O que significa escrever para um catálogo internacional em um meta-repositório federado do Hive?

Só são suportadas as operações de escrita para os metastores internos federados do Hive, mas não para os metastores externos do Hive.

Podem ser feitas dois tipos de gravações em metastores federados:

  • Operações DDL, como CREATE TABLE, ALTER TABLEe DROP TABLE.

    As operações DDL são refletidas de forma síncrona no metastore subjacente do Hive. Por exemplo, a execução de uma instrução CREATE TABLE cria a tabela no metastore do Hive e no catálogo estrangeiro.

    Advertência

    Isso também significa que os comandos DROP se refletem no metastore do Hive. Por exemplo, o DROP SCHEMA mySchema CASCADE descarta todas as tabelas no esquema de metastore subjacente do Hive, sem a opção de UNDROP, porque o metastore do Hive não suporta UNDROP.

  • Operações DML, como INSERT, UPDATEe DELETE.

    As operações DML também são refletidas de forma síncrona na tabela de metastore subjacente do Hive. Por exemplo, executar INSERT INTO adiciona registros à tabela no metastore do Hive.

    O suporte de gravação é fundamental para permitir uma transição perfeita durante a migração do metastore do Hive para o Unity Catalog. Consulte Como usar a federação de metastore do Hive durante a migração para o Unity Catalog?.

Como você configura a federação de metastore do Hive?

Para configurar a federação de metastore do Hive, faça o seguinte:

  1. Crie uma conexão no Catálogo Unity que especifique o caminho e as credenciais para acessar o metastore do Hive.

    A federação do metastore do Hive usa essa conexão para explorar o metastore do Hive. Para a maioria dos sistemas de banco de dados, você fornece um nome de usuário e senha. Para estabelecer uma conexão com o metastore Hive de um antigo espaço de trabalho interno do Azure Databricks, a federação do metastore Hive é responsável pela autorização.

  2. Crie uma credencial de armazenamento e um local externo no Catálogo Unity para os caminhos para as tabelas registadas no metastore do Hive.

    Os locais externos contêm caminhos e as credenciais de armazenamento necessárias para acessar esses caminhos. As credenciais de armazenamento são objetos protegíveis do Unity Catalog que especificam credenciais, como identidades gerenciadas do Azure, para acesso ao armazenamento em nuvem. Dependendo do fluxo de trabalho escolhido para criar locais externos, talvez seja necessário criar credenciais de armazenamento antes de criar o local externo.

  3. Crie um catálogo estrangeiro no Unity Catalog, usando a conexão que você criou na etapa 1.

    Este é o catálogo que os usuários do espaço de trabalho e os fluxos de trabalho usam para trabalhar com tabelas de metastore do Hive usando o Unity Catalog. Depois de criar o catálogo estrangeiro, o Unity Catalog o preenche com as tabelas registradas no metastore do Hive.

  4. Conceda privilégios às tabelas no catálogo estrangeiro usando o Unity Catalog.

    Você também pode usar filtros de linha e coluna do Unity Catalog para controle de acesso refinado.

  5. Comece a consultar dados.

    O acesso a tabelas estrangeiras usando o Unity Catalog é somente leitura para metastores externos do Hive e leitura e gravação para metastores internos do Hive.

    Para metastores Hive internos e externos, o Unity Catalog atualiza continuamente os metadados da tabela conforme ocorrem alterações no metastore do Hive. Para metastores internos do Hive, novas tabelas e atualizações de tabelas confirmadas pelo catálogo estrangeiro são registadas novamente no metastore do Hive, mantendo a total interoperabilidade entre os catálogos do Unity Catalog e do metastore do Hive.

Para obter instruções detalhadas, consulte:

Como você usa a federação de metastore do Hive durante a migração para o Unity Catalog?

A federação de metastore do Hive permite migrar para o Unity Catalog de forma incremental, reduzindo a necessidade de coordenação entre equipes e cargas de trabalho. Em particular, se você estiver migrando do metastore interno do Hive do seu espaço de trabalho do Azure Databricks, a capacidade de ler e gravar no metastore do Hive e no metastore do Unity Catalog significa que você pode manter metastores "espelhados" durante a migração, fornecendo os seguintes benefícios:

  • As cargas de trabalho executadas em catálogos estrangeiros são executadas no modo de compatibilidade de metastore do Hive, reduzindo o custo de adaptação do código durante a migração.
  • Cada carga de trabalho pode optar por migrar independentemente das outras, sabendo que, durante o período de migração, os dados estarão disponíveis no metastore do Hive e no Unity Catalog, aliviando a necessidade de coordenação entre cargas de trabalho que têm dependências entre si.

Diagrama que fornece uma visão geral da federação HMS no contexto da migração

Esta secção descreve um fluxo de trabalho típico para migrar o metastore interno herdado do Hive de um espaço de trabalho do Azure Databricks para o Unity Catalog, com a federação de metastore do Hive a facilitar a transição. Ele não se aplica à migração de um metastore externo do Hive. Catálogos de origem estrangeira para metastores externos do Hive não permitem gravações.

Etapa 1: Federar o metastore interno do Hive

Nesta etapa, você cria um catálogo estrangeiro que espelha seu metastore do Hive no Unity Catalog. Vamos chamá-lo hms_in_uc.

Diagrama que mostra as cargas de trabalho que estão a ser executadas no metastore do Hive e a existência do catálogo externo espelhado do Unity Catalog, hms_in_uc

Observação

Como parte do processo de federação, você configura locais externos para fornecer acesso aos dados no armazenamento em nuvem. Em cenários de migração em que algumas cargas de trabalho estão consultando os dados usando mecanismos de acesso herdados e outras cargas de trabalho estão consultando os mesmos dados no Unity Catalog, os controles de acesso gerenciados pelo Unity Catalog em locais externos podem impedir que as cargas de trabalho herdadas acessem os caminhos para o armazenamento a partir da computação habilitada para Unity Catalog. Pode ativar o "modo de recuperação" nestes locais externos para recorrer a quaisquer credenciais com âmbito de cluster ou de notebook, que tenham sido estabelecidas para as cargas de trabalho legadas. Em seguida, quando a migração estiver concluída, você desativará o modo de fallback. Consulte O que é o modo de fallback?.

Para obter detalhes, consulte Ativar a federação de metastore do Hive para um espaço de trabalho herdado.

Passo 2. Execute novas tarefas no catálogo externo do Unity Catalog.

Quando você tem um catálogo estrangeiro, pode conceder aos analistas SQL e aos consumidores de ciência de dados acesso a ele e começar a desenvolver novas cargas de trabalho que apontem para ele. As novas cargas de trabalho se beneficiam do conjunto de recursos adicionais no Unity Catalog, incluindo controles de acesso, pesquisa e linhagem.

Diagrama que mostra cargas de trabalho existentes em execução no metastore do Hive e novas cargas de trabalho em execução no catálogo externo espelhado do Unity Catalog, hms_in_uc

Nesta etapa, você normalmente faz o seguinte:

  • Escolha computação compatível com o Unity Catalog (ou seja, modos de acesso de computação padrão ou dedicado, armazéns SQL ou computação sem servidor). Consulte Requisitos e suporte a recursos.
  • Torne o catálogo externo o catálogo padrão no recurso de computação ou adicione USE CATALOG hms_in_uc no topo do seu código. Como os esquemas e nomes de tabela no catálogo estrangeiro são espelhos exatos daqueles no metastore do Hive, seu código começará a se referir ao catálogo estrangeiro.

Passo 3. Migrar trabalhos existentes para serem executados no catálogo externo

Para migrar trabalhos existentes para consultar o catálogo estrangeiro:

  1. Altere o catálogo padrão no cluster de trabalho a ser hms_in_uc, definindo uma propriedade no próprio cluster ou adicionando USE CATALOG hms_in_uc na parte superior do código.
  2. Alterne a tarefa para a computação em modo de acesso padrão ou dedicado e atualize para uma das versões do Databricks Runtime que oferecem suporte à federação do metastore Hive. Consulte Requisitos e suporte a recursos.
  3. Peça a um administrador do Azure Databricks para conceder os privilégios corretos do Catálogo Unity nos objetos de dados no hms_in_uc e em quaisquer caminhos de armazenamento em nuvem (incluídos nos locais externos do Catálogo Unity) acessados pelo trabalho. Consulte Gerenciar privilégios no Catálogo Unity.

Segunda instância do diagrama que fornece uma visão geral da federação HMS no contexto da migração

Passo 4. Desativar o acesso direto ao metastore do Hive

Depois de migrar todas as cargas de trabalho para consultar o catálogo estrangeiro, você não precisará mais do metastore do Hive.

  1. Desative o acesso direto ao metastore do Hive.

    Consulte Desabilitar o acesso ao metastore do Hive usado pelo seu espaço de trabalho do Azure Databricks.

  2. Impeça que os utilizadores criem e usem clusters que bypassam o controlo de acesso à tabela (clusters que não usam o modo de acesso partilhado sem isolamento ou um tipo de cluster personalizado legado) utilizando políticas de computação e a configuração do espaço de trabalho Impor isolamento do utilizador.

    Consulte Configurações de computação e Imposição de tipos de cluster para isolamento do utilizador num espaço de trabalho.

  3. Torne o catálogo federado o catálogo padrão do espaço de trabalho.

    Consulte Gerenciar o catálogo padrão.

Perguntas frequentes

As secções seguintes fornecem informações mais detalhadas sobre a federação do Hive Metastore.

O que é o modo de fallback?

Fallback mode é uma configuração em locais externos que pode ser usada para bypassar as verificações de permissões do Catálogo Unity durante a migração para o Catálogo Unity. Defini-lo garante que as cargas de trabalho que ainda não foram migradas não sejam afetadas durante a fase de configuração.

O Unity Catalog obtém acesso ao armazenamento em nuvem usando locais externos, que são objetos protegíveis que definem um caminho e uma credencial para acessar sua conta de armazenamento em nuvem. Você pode emitir permissões sobre eles, como READ FILES, para governar quem pode usar o caminho. Um desafio durante o processo de migração é que você pode não querer que o Unity Catalog comece a controlar todo o acesso ao caminho imediatamente, por exemplo, quando você tiver cargas de trabalho existentes e não migradas que façam referência ao caminho.

O modo de fallback permite que você atrase a aplicação estrita do controle de acesso do Unity Catalog em locais externos. Quando o modo de fallback está habilitado, as cargas de trabalho que acessam um caminho são primeiro verificadas em relação às permissões do Catálogo Unity e, se falharem, voltam a usar credenciais com escopo de cluster ou notebook, como perfis de instância ou propriedades de configuração do Apache Spark. Isso permite que as cargas de trabalho existentes continuem usando suas credenciais atuais.

O modo de fallback destina-se apenas ao uso durante a migração. Você deve desativá-lo quando todas as cargas de trabalho tiverem sido migradas e estiver pronto para impor os controles de acesso do Catálogo Unity.

Registo de auditoria de consultas para utilização de fallback

Use a consulta a seguir para verificar se algum acesso ao local externo usou o modo de fallback nos últimos 30 dias. Se não houver acesso ao modo de fallback em sua conta, o Databricks recomenda desativar o modo de fallback.

SELECT event_time, user_identity, action_name, request_params, response, identity_metadata
FROM system.access.audit
WHERE
request_params.fallback_enabled = 'true' AND
request_params.path LIKE '%some-path%' AND
event_time >= current_date() - INTERVAL 30 DAYS
LIMIT 10

O que são caminhos autorizados?

Ao criar um catálogo estrangeiro apoiado pela federação de metastore do Hive, você será solicitado a fornecer caminhos autorizados para o armazenamento em nuvem onde as tabelas de metastore do Hive estão armazenadas. Qualquer tabela que você queira acessar usando a federação de metastore do Hive deve ser coberta por esses caminhos. O Databricks recomenda que seus caminhos autorizados sejam subcaminhos comuns em um grande número de tabelas. Por exemplo, se você tiver tabelas em abfss://container@storageaccount.dfs.core.windows.net/bucket/table1, ./bucket/table2e ./bucket/table3, deverá fornecer abfss://container@storageaccount.dfs.core.windows.net/bucket/ como um caminho autorizado.

Você pode usar UCX para ajudá-lo a identificar os caminhos que estão presentes no metastore do Hive.

Os caminhos autorizados adicionam uma camada extra de segurança em catálogos estrangeiros que são apoiados pela federação de metastore do Hive. Eles permitem que o proprietário do catálogo aplique guarda-corpos aos dados que os usuários podem acessar usando a federação. Isso é útil se o metastore do Hive permitir que os usuários atualizem metadados e alterem arbitrariamente os locais das tabelas — atualizações que, de outra forma, seriam sincronizadas no catálogo externo. Nesse cenário, os usuários poderiam potencialmente redefinir tabelas às quais já têm acesso para que apontem para novos locais aos quais de outra forma não teriam acesso.

Posso federar metastores do Hive usando UCX?

UCX, o projeto Databricks Labs para migrar espaços de trabalho do Azure Databricks para o Unity Catalog, inclui utilitários para habilitar a federação de metastore do Hive:

  • enable-hms-federation
  • create-federated-catalog

Veja o README do projeto no GitHub. Para obter uma introdução ao UCX, consulte Usar os utilitários UCX para atualizar seu espaço de trabalho para o Unity Catalog.

Requisitos e suporte a funcionalidades

A tabela a seguir lista os serviços e recursos suportados pela federação de metastore do Hive. Em alguns casos, serviços ou recursos não suportados também são listados. Nestas tabelas, "HMS" significa Hive Metastore.

Categoria Suportado Não suportado
Metastore
  • Metastores Hive do espaço de trabalho antigo (interno ao Databricks)
  • Metastores externos no Apache Hive versão 0.13, 2.3 e 3.1
  • MySQL, SQL Server ou Postgres
Operações
  • Internal Databricks HMS: lê e escreve
    OPTIMIZE, VACUUMe ANALYZE TABLE são suportados.
  • HMS externo: somente leitura
    OPTIMIZE e VACUUM são suportados. ANALYZE TABLE não é suportado.
Ativos de dados do Hive metastore
  • Tabelas gerenciadas e externas no metastore do Hive
    Isso inclui tabelas em todos os formatos de dados listados em Formatos de arquivo para tabelas externas, com a adição de tabelas Iceberg (somente em metastores externos federados do Hive). O suporte do Iceberg é o Public Preview. Veja as limitações da tabela Iceberg.
  • Esquemas
  • Visualizações
  • Tabelas Hive SerDe
  • Acesso a clones superficiais registrados no metastore do Hive por meio de um catálogo estrangeiro (Visualização pública). Veja Trabalhando com clones superficiais.
  • Definição de novos clones rasos no catálogo estrangeiro (Prévia Pública)
  • Funções Hive e Funções Definidas pelo Usuário (UDFs)
  • Tabelas com suporte JDBC
  • Tabelas compartilhadas Delta Sharing
Armazenamento
  • Tabelas HMS cujos caminhos se sobrepõem aos caminhos de objeto nativos do Unity Catalog
  • Acesso a tabelas na raiz do DBFS ou em locais de montagem registados num HMS externo
  • Acesso a tabelas localizadas na raiz ou nos locais de montagem do DBFS a partir de qualquer espaço de trabalho diferente daquele onde o HMS interno está definido.
Tipos de computação
  • Computação do modo de acesso padrão (anteriormente modo de acesso compartilhado)
  • Computação em modo de acesso dedicado (anteriormente modo de acesso de usuário único)
  • Sem servidor (todos)
  • Armazéns SQL (todos)
  • Databricks Container Services (DCS): Requer definir spark.databricks.unityCatalog.hms.federation.enabled true na configuração do Spark
Sem agrupamentos de isolamento
Versões de computação
  • Todos os canais Databricks SQL
  • Todos os canais Lakeflow Declarative Pipelines
  • Databricks Tempo de execução 13.3 LTS
  • Tempo de execução do Databricks 14.3 LTS
  • Databricks Runtime 15.1 e versões posteriores
  • Databricks Runtime 16.2 e versões superiores para suporte ao Iceberg (Versão preliminar pública)
Recursos do Catálogo Unity
  • Modelo de privilégio do Catálogo Unity
  • Filtros de linha e máscaras de coluna
  • Auditoria
  • Linhagem descendente
  • Pesquisa de tabelas
  • Acesso entre espaços de trabalho (exceto pasta raiz e pontos de montagem do DBFS)
  • Acesso aos dados limitado a locais externos definidos
  • Compartilhamento Delta
  • Monitorização de Lakehouse
  • Pesquisa vetorial
  • Tabelas online
  • Algumas funcionalidades de armazenamento de funcionalidades, incluindo criação de armazenamento de funcionalidades, criação de serviço de disponibilização de modelos, criação de especificações de funcionalidades, registo de modelos e avaliação em lote.
  • Não é possível escrever visualizações materializadas e tabelas de streaming do Lakeflow Declarative Pipelines em um catálogo estrangeiro, mas você pode usar tabelas e exibições estrangeiras como fonte para exibições materializadas e tabelas de streaming do Lakeflow Declarative Pipelines.
  • Migração automática de listas de controlo de acesso de tabelas legadas para privilégios do Unity Catalog para o catálogo federado. UCX pode ajudar com isso.

Trabalhando com clones superficiais

Importante

O suporte a clones superficiais está em visualização pública .

A federação de metastore do Hive suporta a criação de clones superficiais a partir de tabelas registradas no metastore do Hive, com as seguintes advertências:

  • Quando você lê o clone superficial de um catálogo federado de metastore do Hive, o clone tem um estado de provisionamento DEGRADED. Isso indica que o clone superficial usa o modelo de permissão do Hive, que exige que o usuário que lê a partir da tabela de clone superficial tenha o privilégio de SELECT no clone superficial e na tabela base.

    Para atualizar o clone superficial para ser consistente com o modelo de permissão do Catálogo Unity, o proprietário da tabela deve executar REPAIR TABLE <table> SYNC METADATA. Depois que o comando é executado, o estado de provisionamento da tabela muda para ACTIVE e as permissões são controladas pelo Unity Catalog posteriormente. As leituras subsequentes no clone superficial exigem SELECT apenas no clone superficial em si, desde que o comando seja executado em computação que suporte o Unity Catalog.

  • Não há suporte para clones superficiais criados no DBFS ou baseados em tabelas montadas no DBFS.

Limitações

  • Não é possível consultar tabelas federadas onde os arquivos de tabela são armazenados fora do local da tabela federada. Isso pode incluir tabelas em que as partições são armazenadas fora do local da tabela ou, no caso das tabelas Avro, onde o esquema é referenciado usando essa propriedade da tabela. Ao consultar essas tabelas, uma exceção UNAUTHORIZED_ACCESS ou AccessDeniedException pode ser lançada.