Hive metastore federação: habilita para controlar tabelas registradas em um Unity Catalog Hive metastore

Este artigo apresenta a federação de tabelas ( Hive metastore ), um recurso que permite que o Unity Catalog controle tabelas armazenadas em um Hive metastore. É possível federar um domínio externo Hive metastore ou um domínio interno antigo Databricks Hive metastore.

Hive metastore A federação pode ser utilizada para os seguintes casos de uso:

• Como parte do processo de migração para Unity Catalog, é possível habilitar a migração incremental sem adaptação de código, com algumas de suas cargas de trabalho continuando a utilizar os dados registrados em Hive metastore enquanto outras são migradas.

  Este caso de uso é mais adequado para organizações que utilizam atualmente um repositório interno legado Databricks Hive metastore , pois os repositórios internos federados Hive permitem cargas de trabalho de leitura e gravação.

• Para fornecer um modelo híbrido de longo prazo para organizações que precisam manter alguns dados em um repositório de dados de confiança ( Hive metastore ) juntamente com seus dados registrados em um repositório de identidade ( Unity Catalog).

  Este caso de uso é mais adequado para organizações que utilizam um repositório externo ( Hive metastore), pois os catálogos externos para esses repositórios de metadados ( Hive ) são somente de leitura.

Visão geral da federação Hive metastore

Em uma federação Hive metastore, é possível criar uma conexão do seu Databricks workspace para o seu Hive metastore, e o Unity Catalog rastreia o Hive metastore para preencher um catálogo externo, às vezes chamado de catálogo federado , que permite que sua organização trabalhe com suas tabelas Hive metastore em Unity Catalog, fornecendo controles de acesso centralizados, linhagem, pesquisa e muito mais.

Quando você consulta tabelas externas em um banco de dados federado ( Hive metastore), 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 Hive metastore. Por exemplo, se um usuário consultar uma tabela armazenada no formato Parquet em um catálogo externo, 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 contra o Hive metastore subjacente, utilizando os metadados e as informações de partição mais recentes armazenados nesse local.

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

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

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

• Pode ser utilizado para registrar um local arbitrário no armazenamento em nuvem como uma tabela.
• É possível aplicar permissões de “ Unity Catalog ” e controles de acesso refinados.
• Pode ser visualizado na linhagem para consultas que fazem referência a eles.

As tabelas externas em um banco de dados federado ( Hive metastore ) possuem as seguintes propriedades:

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

Desta forma, é possível considerar as tabelas estrangeiras em um Hive metastore federado como oferecendo compatibilidade retroativa com Hive metastore, permitindo que as cargas de trabalho utilizem a semântica exclusiva de Hive, mas com governança fornecida por Unity Catalog.

No entanto, alguns recursos Unity Catalog não estão disponíveis em tabelas estrangeiras, por exemplo:

• Recurso disponível apenas para tabelas gerenciadas pelo Unity Catalog, como otimização preditiva.
• Pesquisa vetorial, Delta Sharing, monitoramento lakehouse e tabelas online.
• Algumas funcionalidades da loja de recursos, incluindo criação de loja de recursos, criação de modelo de serviço, criação de especificação de recurso, registro de modelo e pontuação de lotes.

O desempenho pode ser ligeiramente inferior ao das cargas de trabalho em Unity Catalog ou Hive metastore, pois tanto Hive metastore quanto Unity Catalog estão no caminho de consulta de uma tabela externa.

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

O que significa escrever para um catálogo estrangeiro em um Hive metastore federado?

As gravações são suportadas apenas para metastores Hive federados internos, não para metastores Hive externos.

As gravações em metástores federados são de dois tipos:

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

  As operações DDL são refletidas de forma síncrona no banco de dados subjacente. Hive metastore Por exemplo, executar uma instrução ` CREATE TABLE ` cria a tabela tanto no catálogo ` Hive metastore ` quanto no catálogo `foreign`.

atenção

Isso também significa que o comando DROP é refletido em Hive metastore. Por exemplo, “ DROP SCHEMA mySchema CASCADE ” exclui todas as tabelas no esquema subjacente “ Hive metastore ”, sem a opção “ UNDROP”, porque “ Hive metastore ” não suporta “ UNDROP”.

• Operações DML, tais como INSERT, UPDATE e DELETE.

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

  O suporte à escrita é um recurso opcional ( key ) que permite uma transição perfeita durante a migração de Hive metastore para Unity Catalog. Consulte Como utilizar a federação Hive metastore durante a migração para Unity Catalog?

Como configurar uma federação d Hive metastore?

Para configurar uma federação d Hive metastore, proceda da seguinte forma:

1. Crie uma conexão no Unity Catalog que especifique o caminho e as credenciais para acessar o Hive metastore.

2. Crie uma credencial de armazenamento e um local externo em Unity Catalog para os caminhos das tabelas registradas em Hive metastore.

3. Crie um catálogo externo no Unity Catalog, utilizando a conexão criada na etapa 1.

   Este é o catálogo que os usuários do workspace e fluxo de trabalho utilizam para trabalhar com tabelas do Hive metastore utilizando Unity Catalog. Após criar o catálogo externo, o Unity Catalog o preenche com as tabelas registradas no Hive metastore.

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

   Também é possível utilizar filtros de linha e coluna do Unity Catalog para um controle de acesso mais detalhado.

5. Iniciar a consulta de dados.

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

   Para metastores internos Hive e metastores externos Hive, o Unity Catalog atualiza continuamente os metadados da tabela à medida que eles são alterados no Hive metastore. Para metastores internos Hive, novas tabelas e atualizações de tabelas confirmadas a partir do catálogo externo são gravadas de volta no Hive metastore, mantendo a interoperabilidade total entre os catálogos Unity Catalog e Hive metastore.

Para obter instruções detalhadas, consulte:

Como utilizar uma federação d Hive metastore durante a migração para Unity Catalog?

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

• As cargas de trabalho executadas em catálogos externos são executadas em um modo de compatibilidade d Hive metastore, 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 em Hive metastore e Unity Catalog, aliviando a necessidade de coordenação entre cargas de trabalho que têm dependências entre si.

Passo 1: Federar o interno Hive metastore

Nesta etapa, você cria um catálogo externo que espelha o seu Hive metastore em Unity Catalog. Vamos chamá-lo de hms_in_uc.

nota

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 nos quais algumas cargas de trabalho estão consultando os mecanismos de acesso legados uso de dados e outras cargas de trabalho estão consultando os mesmos dados em Unity Catalog, os controles de acesso Unity Catalog-gerenciar em locais externos podem impedir que as cargas de trabalho legadas acessem os caminhos para o armazenamento a partir de Unity Cataloghabilitado para compute. É possível ativar o “modofallback ” nesses locais externos para recorrer a qualquer credencial de clustering ou do escopo do Notebook que tenha sido definida para a carga de trabalho legada. Em seguida, quando a migração estiver concluída, desative o modo de fallback. Consulte O que é o modo de fallback?

Para obter detalhes, consulte Habilitar a federação de Hive metastore para um workspace legado Hive metastore.

Passo 2. Execute novas cargas de trabalho no catálogo externo em Unity Catalog

Quando você possui um catálogo externo, é possível conceder aos usuários de analista e ciência de dados do SQL acesso a ele e começar a desenvolver novas cargas de trabalho que apontam para ele. As novas cargas de trabalho se beneficiam do recurso adicional definido em Unity Catalog, incluindo controles de acesso, pesquisa e linhagem.

Nessa etapa, você normalmente faz o seguinte:

• Selecione um serviço compatível com o Unity Catalog ( compute , ou seja, modos de acesso padrão ou dedicado compute, armazenamento SQL ou serverless compute). Consulte Requisitos e suporte a recursos.
• Defina o catálogo externo como o catálogodefault no recurso compute ou adicione USE CATALOG hms_in_uc no início do seu código. Como os esquemas e nomes de tabelas no catálogo externo são espelhos exatos dos que estão no Hive metastore, seu código começará a se referir ao catálogo externo.

Passo 3. Migrar o trabalho existente para execução em relação ao catálogo externo

Para migrar o trabalho existente para consultar o catálogo externo:

1. Altere o catálogo default no agrupamento de tarefas para hms_in_uc, definindo uma propriedade no próprio agrupamento ou adicionando USE CATALOG hms_in_uc no início do seu código.
2. Altere o trabalho para o modo de acesso padrão ou dedicado compute e atualize para uma das versões Databricks Runtime que suportam a federação Hive metastore. Consulte Requisitos e suporte a recursos.
3. Solicite a um administrador do Databricks que conceda os privilégios corretos de Unity Catalog aos objetos de dados em hms_in_uc e a quaisquer caminhos de armazenamento em nuvem (incluídos em Unity Catalog external locations) aos quais o trabalho acessa. Consulte gerenciar privilégios em Unity Catalog.

Passo 4. Desative o acesso direto ao Hive metastore

Após migrar todas as suas cargas de trabalho para consultar o catálogo externo, não será mais necessário o Hive metastore.

1. Desative o acesso direto ao Hive metastore.

   Consulte Desativar acesso ao Hive metastore utilizado pelo seu Databricks workspace .

2. Impedir que os usuários criem e utilizem agrupamentos que contornem o controle de acesso da tabela (agrupamentos que não utilizam o modo de acesso compartilhado isolado ou um tipo de agrupamento personalizado legado) utilizando políticas de isolamento de usuários ( compute ) e a configuração “Enforce user isolation” ( workspace ).

   Consulte as configurações de computação e os tipos de agrupamento de isolamento de usuário em um workspace.

3. Defina o catálogo federado como o catálogo workspace default .

   Consulte gerenciar o catálogo default.

Perguntas frequentes

As seções a seguir fornecem informações mais detalhadas sobre a federação Hive metastore.

O que é o modo de fallback?

O modo de fallback é uma configuração em locais externos que pode ser utilizada para ignorar as verificações de permissão do Unity Catalog durante a migração para o Unity Catalog. A configuração garante que as cargas de trabalho que ainda não foram migradas não sejam afetadas durante a fase de configuração.

Unity Catalog obtém acesso ao armazenamento em nuvem utilizando locais externos, que são objetos protegidos que definem um caminho e uma credencial para acessar seu armazenamento em nuvem account. Você pode emitir permissões para eles, como READ FILES, para determinar quem pode usar o caminho. Um desafio durante o processo de migração é que talvez você não queira que Unity Catalog comece a controlar todo o acesso ao caminho imediatamente, por exemplo, quando você tem cargas de trabalho existentes e não migradas que fazem referência ao caminho.

O modo de fallback permite adiar a aplicação rigorosa do controle de acesso Unity Catalog em locais externos. Quando o modo de autenticação de credenciais de instância ( fallback ) está ativado, as cargas de trabalho que acessam um caminho são primeiro verificadas em relação às permissões de autenticação de credenciais de instância ( Unity Catalog ), e se falharem, recorrem ao uso de credenciais de cluster ou credenciais no escopo do Notebook, como o perfil da instância ou as propriedades de configuração de autenticação de credenciais de instância ( Apache Spark ). Isso permite que as cargas de trabalho existentes continuem usando suas credenciais atuais.

O modo de fallback destina-se apenas para uso durante a migração. Recomenda-se desativá-lo quando todas as cargas de trabalho tiverem sido migradas e você estiver pronto para aplicar os controles de acesso do Unity Catalog.

Verificar o log de auditoria para uso de fallback

Utilize a consulta a seguir para verificar se algum acesso ao local externo utilizou o modo de fallback nos últimos 30 dias. Se não houver acesso ao modo “ fallback ” em seu account, Databricks recomenda desativar o modo “ fallback ”.

SQL

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 externo que é suportado por uma federação d Hive metastore, é solicitado que forneça caminhos autorizados para o armazenamento em nuvem onde as tabelas Hive metastore estão armazenadas. Qualquer tabela que você deseja acessar usando uma federaçã Hive metastore, deve estar coberta por esses caminhos. A Databricks recomenda que os caminhos autorizados sejam subcaminhos comuns a um grande número de tabelas. Por exemplo, se você tiver tabelas em gs://bucket/table1, gs://bucket/table2 e gs://bucket/table3, deverá fornecer gs://bucket/ como um caminho autorizado.

Os caminhos autorizados adicionam uma camada extra de segurança aos catálogos externos que são suportados por uma federação Hive metastore. Eles permitem que o proprietário do catálogo aplique barreiras aos dados que os usuários podem acessar usando a federação. Isso é útil se o seu Hive metastore permite 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 elas apontem para novos locais aos quais, de outra forma, não teriam acesso.

Requisitos e suporte a recursos

A tabela a seguir lista os serviços e recursos compatíveis com uma federação de Hive metastore. 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
Metastores	Legado workspace Hive metastores (interno a Databricks) Metastores externos no Apache Hive versão 0.13, 2.3 e 3.1 MySQL, SQL Server ou Postgres
Operações	Databricks HMS interno: lê e grava OPTIMIZE, VACUUM e ANALYZE TABLE são suportados. HMS externo: apenas leitura OPTIMIZE e VACUUM são suportados. ANALYZE TABLE não é suportado.
Hive metastore dados ativos	gerenciar e tabelas externas em Hive metastore Isso inclui tabelas em todos os formatos de dados listados em Formatos de arquivo para tabelas externas, com a adição de tabelas Iceberg (apenas em metastores Hive externos federados). O suporte para Iceberg está em pré-visualização pública. Consulte as limitações da tabela Iceberg. Esquemas Exibições Tabelas SerDe do Hive Acessando clones superficiais registrados no Hive metastore por meio de um catálogo externo (Pré-visualização pública). Consulte Trabalho com clones superficiais. Definindo novos clones superficiais no catálogo estrangeiro (visualização pública)	Funções do Hive e UDFs Tabelas com suporte JDBC Mesas compartilhadas Delta Sharing
Armazenar	Google Cloud Storage Tabelas que fazem referência a locais de montagem d DBFS, incluindo DBFS root Tabelas cujos caminhos se sobrepõem a outros caminhos de tabelas HMS definidos em locais externos	Tabelas HMS cujos caminhos se sobrepõem aos caminhos de objetos nativos do Unity Catalog Acesso a tabelas em DBFS root ou locais de montagem registrados em um arquivo externo. HMS Acesso a tabelas em DBFS root ou locais de montagem a partir de qualquer workspace diferente daquele em que o HMS interno está definido.
tipos de computação	Modo de acesso padrão compute (anteriormente modo de acesso compartilhado) Modo de acesso dedicado compute (anteriormente modo de acesso de usuário único) sem servidor (todos) SQL armazém (todos) Databricks Container Services (DCS): Requer a configuração de spark.databricks.unityCatalog.hms.federation.enabled true em Spark config	Sem agrupamento de isolamento
versões computacionais	Todos os canais d Databricks SQL Todos os canais declarativos do pipeline " LakeFlow " Databricks Runtime 13.3 LTS Databricks Runtime 14.3 LTS Databricks Runtime 15,1 e acima Databricks Runtime 16.2 e acima para suporte ao Iceberg (Pré-visualização pública)
Unity Catalog recurso	Unity Catalog modelo de privilégios Filtros de linha e máscaras de coluna Auditoria Linhagem a jusante Pesquisa de tabela Acesso cross-workspace (exceto DBFS root e mounts) Acesso aos dados limitado a locais externos definidos	Delta Sharing Monitoramento do lakehouse Vector Search Tabelas online Algumas funcionalidades da loja de recursos, incluindo criação de loja de recursos, criação de modelo de serviço, criação de especificação de recurso, registro de modelo e pontuação de lotes. Não é possível gravar tabelas de visualização materializada e transmissão do pipeline declarativo LakeFlow em um catálogo externo, mas é possível utilizar tabelas e visualizações externas como fonte para tabelas de visualização materializada e transmissão do pipeline declarativo LakeFlow. Migração automática de ACLs de tabelas legadas para privilégios do Unity Catalog para o catálogo externo.

Trabalhando com clones superficiais

info

Visualização

O suporte para clones superficiais está na versão prévia pública.

Hive metastore A federação suporta a criação de clones superficiais a partir de tabelas registradas em Hive metastore, com as seguintes ressalvas:

• Ao ler o clone superficial de um catálogo federado do Hive metastore, o clone apresenta um estado de provisionamento " DEGRADED ". Isso indica que o clone superficial utiliza o modelo de permissão Hive, que exige que o usuário que lê da tabela do clone superficial tenha o privilégio SELECT tanto no clone superficial quanto na tabela base.

  Para atualizar a clonagem superficial para que seja consistente com o modelo de permissão “ Unity Catalog ”, o proprietário da tabela deve executar REPAIR TABLE <table> SYNC METADATA. Após a execução do comando, o estado de provisionamento da tabela muda para “ ACTIVE ” e as permissões passam a ser controladas pelo Unity Catalog. As leituras subsequentes no clone superficial requerem apenas um comando ` SELECT ` no próprio clone superficial, desde que o comando seja executado em um ` compute ` que suporte ` Unity Catalog`.

• Clones superficiais criados no DBFS ou com base em tabelas montadas no DBFS não são suportados.

Limitações

• Você não pode consultar tabelas federadas em que os arquivos da tabela estã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, em que o esquema é referenciado usando a propriedade de tabela avro.schema.url. Ao consultar essas tabelas, uma exceção UNAUTHORIZED_ACCESS ou AccessDeniedException pode ser lançada.