Pular para o conteúdo principal

Hive metastore federação: permite que governe tabelas registradas em uma Unity Catalog Hive metastore

Este artigo apresenta a federação Hive metastore, um recurso que permite que o Unity Catalog governe tabelas armazenadas em um Hive metastore. O senhor pode federar um Hive metastore externo ou um Databricks interno legado Hive metastore.

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

  • Como uma etapa no caminho de migração para 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 Hive metastore enquanto outras são migradas.

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

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

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

Diagrama que apresenta a federação Hive

Visão geral da federação Hive metastore

Na federação Hive metastore, o senhor cria 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 as tabelas Hive metastore no Unity Catalog, fornecendo controles de acesso centralizados, linhagem, pesquisa e muito mais.

Quando o senhor consulta tabelas estrangeiras em um Hive metastore federado, o Unity Catalog fornece a camada de governança, realizando 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 própria consulta é executada no site subjacente Hive metastore, aproveitando os metadados mais recentes e as informações de partição armazenadas nele.

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

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

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

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 Unity Catalog e controles de acesso refinados.
  • Podem ser visualizados na linhagem para consultas que os referenciam.

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

  • São descobertos automaticamente com base no rastreamento de um site 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 a semântica do Hive, como Hive SerDes e partições.
  • Permita que as tabelas tenham caminhos sobrepostos com outras tabelas em catálogos estrangeiros.
  • Permitir que as mesas sejam colocadas em DBFS root locais.
  • Inclua a visualização que está definida em Hive metastore.

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

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

  • recurso disponível somente para Unity Catalog gerenciar tabelas, como otimização preditiva.
  • Pesquisa vetorial, Delta Sharing, monitoramento de lagos e tabelas on-line.
  • Algumas funcionalidades da loja de recursos, incluindo a criação de lojas de recursos, criação de modelos de serviço, criação de especificações de recursos, registro de modelos e pontuação de lotes.

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

Para obter mais informações sobre a funcionalidade suportada, consulte Requisitos, recurso suportado e limitações.

O que significa escrever em um catálogo externo em um Hive metastore federado em Databricks?

As gravações são compatíveis apenas com os metastores internos federados do Hive, não com os metastores externos do Hive.

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 site subjacente Hive metastore. Por exemplo, a execução de uma instrução CREATE TABLE cria a tabela tanto no catálogo Hive metastore quanto no catálogo externo.

atenção

Isso também significa que DROP comandos são refletidos no site Hive metastore. Por exemplo, DROP SCHEMA mySchema CASCADE elimina todas as tabelas do esquema subjacente Hive metastore, sem a opção UNDROP, porque o site Hive metastore não oferece suporte a UNDROP.

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

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

    O suporte à gravação é um key para permitir uma transição perfeita durante a migração de Hive metastore para Unity Catalog. Consulte Como o senhor usa a federação Hive metastore durante a migração para Unity Catalog?

Como o senhor configura a federação Hive metastore?

Para configurar a federação Hive metastore, o senhor deve fazer o seguinte:

  1. Crie uma conexão em Unity Catalog que especifique o caminho e as credenciais para acessar o site 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, usando a conexão que o senhor criou na etapa 1.

    Esse é o catálogo que os usuários do workspace e do fluxo de trabalho usam para trabalhar com as tabelas do Hive metastore usando o Unity Catalog. Depois de criar o catálogo externo, o site Unity Catalog o preenche com as tabelas registradas no site Hive metastore.

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

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

  5. começar a consultar dados.

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

    Para os metastores internos do Hive e externos do Hive, o Unity Catalog atualiza continuamente os metadados da tabela à medida que eles são alterados no Hive metastore. Para os metastores internos do Hive, as novas tabelas e atualizações de tabelas confirmadas 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 o senhor usa a federação Hive metastore durante a migração para Unity Catalog?

Hive metastore A federação permite que o senhor migre para Unity Catalog de forma incremental, reduzindo a necessidade de coordenação entre equipes e cargas de trabalho. Em particular, se estiver migrando do Databricks workspace 's internal Hive metastore, a capacidade de ler e gravar no Hive metastore e no Unity Catalog metastore significa que é possível manter metastores "espelhados" durante a migração, proporcionando os seguintes benefícios:

  • As cargas de trabalho que são executadas em catálogos estrangeiros são executadas no modo de compatibilidade 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 tanto em Hive metastore quanto em Unity Catalog, aliviando a necessidade de coordenação entre cargas de trabalho que dependem umas das outras.

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

Etapa 1: Federar o sistema interno Hive metastore

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

Diagrama que mostra as cargas de trabalho em execução no Hive metastore e a existência do catálogo externo espelhado do Unity Catalog, 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 de uso de dados legados e outras cargas de trabalho estão consultando os mesmos dados em,Unity Catalog Unity Catalogos controles de acesso de -gerenciar em locais externos podem impedir que as cargas de trabalho legadas acessem os caminhos para o armazenamento a partir de Unity Cataloghabilitado compute para. O senhor pode ativar o "modofallback " nesses locais externos para recorrer a qualquer credencial de clustering ou de escopo de Notebook que tenha sido definida para a carga de trabalho herdada. Então, quando a migração estiver concluída, o senhor desativa o modo de fallback. Consulte O que é o modo fallback?

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

Etapa 2. execução de novas cargas de trabalho no catálogo externo em Unity Catalog

Quando o senhor tiver um catálogo externo implementado, poderá conceder acesso a ele aos consumidores de SQL analista e ciência de dados 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 em Unity Catalog, incluindo controles de acesso, pesquisa e linhagem.

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

Nessa etapa, você normalmente faz o seguinte:

  • Escolha compute compatível com o Unity Catalog (ou seja, modos de acesso compute padrão ou dedicado, SQL warehouse ou serverless compute). Consulte Requisitos, recursos compatíveis e limitações.
  • Faça com que o catálogo estrangeiro seja o catálogodefault no recurso compute ou adicione USE CATALOG hms_in_uc à parte superior do seu código. Como os esquemas e nomes de tabelas no catálogo externo são espelhos exatos daqueles no Hive metastore, seu código começará a fazer referência ao catálogo externo.

Etapa 3. Migrar o trabalho existente para execução no catálogo externo

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

  1. Altere o catálogo default no clustering do Job para hms_in_uc, definindo uma propriedade no próprio clustering ou adicionando USE CATALOG hms_in_uc na parte superior do código.
  2. Mude o Job para o modo de acesso padrão ou dedicado compute e atualize para uma das versões do Databricks Runtime que ofereça suporte à federação Hive metastore. Consulte Requisitos, recursos compatíveis e limitações.
  3. Solicite a um administrador do Databricks que conceda os privilégios corretos do Unity Catalog nos objetos de dados em hms_in_uc e em quaisquer caminhos de armazenamento em nuvem (incluídos em Unity Catalog locais externos) que o Job acesse. Consulte gerenciar privilégios em Unity Catalog.

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

Etapa 4. Negar acesso ao Hive metastore

Depois que o senhor migrar todas as suas cargas de trabalho para consultar o catálogo externo, não precisará mais do Hive metastore. O senhor pode usar as permissões de controle de acesso legado da tabela e compute para bloquear o acesso direto do seu Databricks workspace ao Hive metastore. Por exemplo, você pode:

  1. Revogar todos os privilégios dos objetos no catálogo Hive metastore.

    O comando MSCK REPAIR PRIVILEGES é conveniente para essa finalidade. Veja Msck REPAIR PRIVILEGES e Hive metastore privileges and securable objects (legado).

  2. Impeça que os usuários criem e usem clusters que ignorem o controle de acesso da tabela (clusters que não usam o modo de acesso compartilhado de isolamento ou um tipo de cluster personalizado legado) usando as políticas do site compute.

    Consulte gerenciar compute configurações.

  3. Tornar o catálogo federado 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 fallback?

O modo de fallback é uma configuração em locais externos que o senhor pode usar 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 usando locais externos, que são objetos seguros 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 o senhor não queira que o Unity Catalog comece a governar todo o acesso ao caminho imediatamente, por exemplo, quando houver cargas de trabalho existentes e não migradas que façam referência ao caminho.

O modo fallback permite que o senhor adie a aplicação rigorosa do controle de acesso Unity Catalog em locais externos. Quando o modo fallback está ativado, as cargas de trabalho que acessam um caminho são primeiro verificadas em relação às permissões do Unity Catalog e, se falharem, voltam a usar credenciais de clustering ou de escopo de Notebook, como perfil 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 fallback destina-se apenas ao uso durante a migração. O senhor deve desativá-lo quando todas as cargas de trabalho tiverem sido migradas e estiver pronto para aplicar os controles de acesso do Unity Catalog.

Consultar a auditoria log para o uso do fallback

Use a seguinte consulta para verificar se algum acesso ao local externo usou o modo de fallback nos últimos 30 dias. Se não houver acesso ao modo fallbackno seu account, o 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?

Quando o senhor cria um catálogo externo que é apoiado pela federação Hive metastore, é solicitado que forneça caminhos autorizados para o armazenamento em nuvem onde as tabelas Hive metastore estão armazenadas. Qualquer tabela que o senhor queira acessar usando a federação Hive metastore deve ser coberta por esses caminhos. A Databricks recomenda que seus caminhos autorizados sejam subcaminhos comuns em 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 em catálogos estrangeiros que são apoiados pela 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 site Hive metastore 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 elas apontem para novos locais aos quais, de outra forma, não teriam acesso.

Requisitos, recursos suportados e limitações

A tabela a seguir lista o serviço e o recurso que são suportados pela federação Hive metastore. Em alguns casos, o serviço ou recurso sem suporte também é listado. Nessas tabelas, "HMS" significa Hive metastore.

Categoria

Suportado

Não suportado

Metastores

  • Legado workspace Hive metastores (internos a Databricks)
  • Metastores externos no Apache Hive versão 0.13, 2.3 e 3.1
  • MySQL, SQL Server ou Postgres

Operações

  • HMS interno do Databricks: leituras e gravações
  • HMS externo: somente leitura

Hive metastore dados ativos

  • gerenciar e tabelas externas em Hive metastore
  • Esquemas
  • Exibições
  • Tabelas do Hive SerDe
  • Acesso a clones rasos registrados no site Hive metastore por meio de um catálogo externo (Public Preview). Consulte Trabalho com clones superficiais.
  • Definindo novos clones superficiais no catálogo estrangeiro (visualização pública)
  • Funções Hive e UDFs
  • Tabelas apoiadas em JDBC
  • Delta Sharing mesas compartilhadas

Armazenar

  • Google Cloud Storage
  • Tabelas que fazem referência aos locais de montagem do DBFS, incluindo DBFS root
  • Tabelas cujos caminhos se sobrepõem a outros caminhos de tabela do 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 HMS
  • Acesso a tabelas em DBFS root ou locais de montagem de qualquer workspace que não seja aquele no qual o HMS interno está definido

tipos de cálculo

  • 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)

Sem clustering de isolamento

versões de cálculo

  • Todos Databricks SQL canal
  • Todos os canais DLT
  • Databricks Runtime 13.3 LTS
  • Databricks Runtime 14.3 LTS
  • Databricks Runtime 15.1 e acima

Unity Catalog recurso

  • Modelo de privilégios do Unity Catalog
  • Filtros de linha e máscaras de coluna
  • Auditoria
  • Linhagem a jusante
  • Pesquisa de tabela
  • Acesso cruzado -workspace (exceto DBFS root e montagens)
  • Acesso aos dados limitado a locais externos definidos
  • Delta Sharing
  • Monitoramento do lakehouse
  • Vector Search
  • Tabelas online
  • Algumas funcionalidades do recurso store, incluindo criação de recurso store, criação de modelo de serviço, criação de recurso spec, registro de modelo e pontuação de lotes
  • O senhor não pode gravar tabelas de visualização e transmissão materializadas DLT em um catálogo externo, mas pode usar tabelas e visualizações externas como fonte para tabelas de visualização e transmissão materializadas DLT.
  • Migração automática de ACLs de tabelas herdadas 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 oferece suporte à criação de clones rasos a partir de tabelas registradas em Hive metastore, com as seguintes ressalvas:

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

    Para atualizar o clone raso e torná-lo consistente com o modelo de permissão Unity Catalog, 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 por Unity Catalog a partir de então. As leituras subsequentes no clone raso exigem SELECT somente no próprio clone raso, desde que o comando seja executado em compute que suporte Unity Catalog.

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