Melhores práticas do Unity Catalog

Este documento fornece recomendações para usar o Unity Catalog para atender às suas necessidades de governança de dados de forma mais eficaz. Para obter uma introdução à governança de dados no Azure Databricks, consulte Governança de dados com o Azure Databricks. Para obter uma introdução ao Unity Catalog, consulte O que é o Unity Catalog?.

Identidades

As entidades principais (usuários, grupos e principals de serviço) devem ser definidas ao nível da conta do Azure Databricks para receberem privilégios em objetos seguros do Unity Catalog. A Databricks recomenda que utilize o SCIM para provisionar principais para a sua conta do Azure Databricks a partir do IdP.

Melhores práticas:

• Evite (e desative o provisionamento SCIM existente) no nível do espaço de trabalho. O aprovisionamento de principais diretamente para um espaço de trabalho deve ser reservado para espaços de trabalho legados que não estão habilitados para o Unity Catalog. Você deve gerenciar o provisionamento inteiramente no nível da conta.

• Defina e gerencie grupos em seu IdP. Eles devem ser consistentes com as definições do seu grupo organizacional.

  Os grupos se comportam de forma diferente dos usuários e entidades de serviço. Embora os usuários e entidades de serviço que você adiciona a um espaço de trabalho sejam sincronizados automaticamente com sua conta do Azure Databricks, os grupos no nível do espaço de trabalho não são. Se você tiver grupos locais de espaço de trabalho, deverá migrá-los manualmente para a conta, de preferência replicando-os em seu IdP (se necessário) e provisionando-os para a conta.

• Configure grupos para que possam ser usados de forma eficaz para conceder acesso a dados e outros objetos protegíveis do Unity Catalog. Evite concessões diretas aos usuários sempre que possível.

• Use grupos para atribuir propriedade à maioria dos objetos protegíveis.

• Evite adicionar usuários manualmente, seja à conta ou ao espaço de trabalho. Evite modificar grupos no Azure Databricks: use o seu IdP.

• Use entidades de serviço para executar trabalhos. As entidades de serviço permitem a automação do trabalho. Se utilizares utilizadores para executar trabalhos que registam dados na produção, corres o risco de sobrescrever acidentalmente os dados de produção.

Para obter mais informações, consulte Gerenciar usuários, entidades de serviço e grupos e Sincronizar usuários e grupos do Microsoft Entra ID usando SCIM.

Funções de administrador e privilégios poderosos

Atribuir funções de administrador e privilégios poderosos como ALL PRIVILEGES e MANAGE requer cuidado:

• Entenda os privilégios dos administradores de conta, administradores de espaço de trabalho e administradores de metastore antes de atribuí-los. Consulte Privilégios de Administrador no Unity Catalog.
• Atribua essas funções a grupos sempre que possível.
• Os administradores da Metastore são opcionais. Atribua-os apenas se precisar deles. Para obter orientações, consulte (Opcional) Atribuir a função de administrador do metastore.
• Atribua a propriedade do objeto a grupos, especialmente se os objetos forem usados na produção. O criador de qualquer objeto é o seu primeiro proprietário. Os criadores devem reatribuir a propriedade aos grupos apropriados.
• Somente administradores, proprietários e usuários do metastore com o MANAGE privilégio em um objeto podem conceder privilégios nesse objeto. Os proprietários de catálogos e esquemas pai também têm a capacidade de conceder privilégios em todos os objetos no catálogo ou esquema. Seja poupado na atribuição de propriedade e do privilégio MANAGE.
• Seja poupador em sua atribuição de ALL PRIVILEGES, que inclui todos os privilégios, exceto MANAGE, EXTERNAL USE LOCATIONe EXTERNAL USE SCHEMA.

Atribuição de privilégios

Os objetos protegíveis no Unity Catalog são hierárquicos e os privilégios são herdados para baixo. Use essa hierarquia de herança para desenvolver um modelo de privilégio eficaz.

Melhores práticas:

• Entenda o papel dos USE CATALOG e USE SCHEMA privilégios:

  • USE CATALOG | SCHEMA Concede a capacidade de exibir dados no catálogo ou esquema. Sozinhos, esses privilégios não concedem SELECT ou READ nos objetos dentro do catálogo ou esquema, mas são um pré-requisito para conceder aos usuários esse acesso. Conceda esses privilégios somente aos usuários que devem ser capazes de exibir dados no catálogo ou esquema.
  • USE CATALOG | SCHEMA, ao restringir o acesso a um catálogo ou esquema, impede que os proprietários de objetos (por exemplo, um criador de tabela) atribuam inadvertidamente acesso a esse objeto (tabela) a usuários que não deveriam ter acesso. É típico criar um esquema por equipe e conceder USE SCHEMA e CREATE TABLE somente para essa equipe (junto com USE CATALOG no catálogo pai).

• Entenda o papel do BROWSE privilégio:

  • BROWSE permite que os usuários visualizem metadados de objetos em um catálogo usando o Gerenciador de Catálogos, o navegador de esquema, a pesquisa, information_schemao gráfico de linhagem e a API REST. Não concede acesso aos dados.
  • BROWSE Permite que os usuários descubram dados e solicitem acesso a eles, mesmo que não tenham os privilégios OR USE CATALOGUSE SCHEMA .
  • O Databricks recomenda a concessão BROWSE de catálogos ao grupo no nível do catálogo para tornar os dados detetáveis e dar suporte a All account users solicitações de acesso.

• Configure os destinos de solicitação de acesso para oferecer suporte ao acesso de autoatendimento:

  • Quando os destinos de solicitação de acesso não estão configurados, os usuários não podem solicitar acesso a objetos, mesmo que possam descobri-los.
  • O Databricks recomenda habilitar destinos de e-mail padrão para que as solicitações sejam enviadas automaticamente ao proprietário do catálogo ou ao proprietário do objeto quando nenhum outro destino estiver configurado.
  • O destino pode ser configurado para endereços de e-mail, Slack, Microsoft Teams, PagerDuty, webhooks ou uma URL de redirecionamento para o sistema de solicitações da sua organização.

• Entenda a diferença entre a propriedade do objeto e o MANAGE privilégio:

  • O proprietário de um objeto tem todos os privilégios sobre o objeto, como SELECT e MODIFY numa tabela, bem como a permissão para conceder privilégios sobre o objeto a outros proprietários e para transferir a propriedade para outros proprietários.
  • Os proprietários podem conceder o MANAGE privilégio de delegar habilidades de propriedade em um objeto a outras entidades.
  • Os proprietários de catálogo e esquema podem transferir a propriedade de qualquer objeto no catálogo ou esquema.
  • O ideal é configurar a propriedade ou conceder o MANAGE privilégio sobre todos os objetos a um grupo responsável pela administração de concessões nos objetos.

• Use a posse de grupo para permitir a edição colaborativa de visualizações e visões métricas.

  • Por defeito, apenas o proprietário de uma vista ou vista métrica pode editar a sua definição. Isto impede a escalada de privilégios, onde um editor pode modificar a vista para aceder a dados não autorizados.
  • Para permitir que vários utilizadores editem em segurança a mesma vista ou vista métrica, transfira a propriedade para um grupo e conceda a esse grupo acesso às tabelas de origem. Todos os membros do grupo podem então editar a definição, e o acesso aos dados fica limitado ao que o grupo tem permissão para ver.
  • Para orientações detalhadas, consulte Permitir a edição colaborativa.

• Reservar o acesso direto MODIFY aos quadros de produção para os responsáveis de serviço.

Para obter mais informações, consulte Gerenciar privilégios no Catálogo Unity.

Metastore

A seguir estão as regras e as práticas recomendadas para criar e gerenciar metastores:

• Você pode ter apenas um metastore por região. Todos os espaços de trabalho nessa região compartilham esse metastore. Para compartilhar dados entre regiões, consulte Compartilhamento entre regiões e entre plataformas.

• Os metastores fornecem isolamento regional, mas não se destinam a unidades padrão de isolamento de dados. O isolamento de dados normalmente começa no nível do catálogo. No entanto, se preferir um modelo de governança mais centralizado, você pode criar armazenamento gerenciado no nível de metastore. Para obter recomendações, consulte Armazenamento gerenciado.

• A função de administrador do metastore é opcional. Para obter recomendações sobre a atribuição de um administrador de metastore opcional, consulte Funções de administrador e privilégios poderosos.

Catálogos e esquemas

Os catálogos são a unidade primária de isolamento de dados no modelo típico de governança de dados do Unity Catalog. Os esquemas adicionam uma camada adicional de organização.

Práticas recomendadas para uso de catálogo e esquema:

• Organize dados e objetos de IA em catálogos e esquemas que reflitam divisões e projetos organizacionais. Muitas vezes, isso significa que os catálogos correspondem a um escopo de ambiente, equipe, unidade de negócios ou alguma combinação destes. Isso facilita o uso da hierarquia de privilégios para gerenciar o acesso de forma eficaz.
• Quando os ambientes de trabalho e os dados têm os mesmos requisitos de isolamento, você pode vincular um catálogo a um espaço de trabalho específico. Quando isso for necessário, crie catálogos que possam ter como escopo um conjunto limitado de espaços de trabalho.
• Sempre atribua a propriedade de catálogos e esquemas de produção a grupos, não a usuários individuais.
• Conceder USE CATALOG e USE SCHEMA somente aos usuários que devem ser capazes de ver ou consultar os dados contidos neles.

Para obter mais conselhos sobre como conceder privilégios em catálogos e esquemas, consulte Atribuição de privilégios.

Armazenamento gerenciado

Tabelas e volumes gerenciados, objetos cujo ciclo de vida é totalmente gerenciado pelo Unity Catalog, são armazenados em locais de armazenamento padrão, conhecidos como armazenamento gerenciado. Você pode configurar o armazenamento gerenciado no nível de metastore, catálogo ou esquema. Os dados são armazenados no local mais baixo disponível na hierarquia. Para obter detalhes, consulte Hierarquia de local de armazenamento gerenciado e Especificar um local de armazenamento gerenciado no Catálogo Unity.

Práticas recomendadas para locais de armazenamento gerenciado:

• Dê preferência ao armazenamento no nível de catálogo como sua unidade principal de isolamento de dados.

  O armazenamento no nível de metastore era necessário nos primeiros ambientes do Unity Catalog, mas não é mais necessário.

• Se você optar por criar um local gerenciado no nível de metastore, use um contêiner dedicado.

• Não use um contêiner que possa ser acessado de fora do Catálogo Unity.

  Se um serviço externo ou entidade principal aceder a dados no local de armazenamento gerido, sem passar pelo Unity Catalog, o controlo de acesso e a auditabilidade em tabelas e volumes geridos serão comprometidos.

• Não reutilize um contêiner que é ou foi usado para seu sistema de arquivos raiz DBFS.

• Se você tiver cargas de trabalho com uso intensivo de armazenamento, não use uma única conta de armazenamento e contêiner para armazenamento gerenciado e outros locais externos.

  As contas re:[ADLS] suportam 20.000 solicitações por segundo por padrão. Isso pode causar limitação e lentidão da carga de trabalho. O uso de vários contêineres na mesma conta de armazenamento não altera esse limite em toda a conta. Portanto, você deve distribuir o armazenamento por várias contas de armazenamento.

  Esse striping seria invisível para os usuários finais do Unity Catalog.

Tabelas gerenciadas e externas

As tabelas gerenciadas são totalmente gerenciadas pelo Unity Catalog, o que significa que o Unity Catalog gerencia a governança e os arquivos de dados subjacentes para cada tabela gerenciada. Estão sempre no formato Delta ou Apache Iceberg.

As tabelas externas são tabelas cujo acesso a partir do Azure Databricks é gerenciado pelo Unity Catalog, mas cujo ciclo de vida de dados e layout de arquivo são gerenciados usando seu provedor de nuvem e outras plataformas de dados. Ao criar uma tabela externa no Azure Databricks, você especifica seu local, que deve estar em um caminho definido em um local externo do Catálogo Unity.

Use tabelas gerenciadas:

• Para a maioria dos casos de uso. A Databricks recomenda tabelas e volumes gerenciados porque eles permitem que você aproveite ao máximo os recursos de governança e otimizações de desempenho do Unity Catalog, incluindo:

  • Compactação automática
  • Otimização automática
  • Leituras de metadados mais rápidas (cache de metadados)
  • Otimizações inteligentes de tamanho de arquivo

  A nova funcionalidade do Azure Databricks dá precedência às tabelas gerenciadas.

• Para todas as novas tabelas.

Use tabelas externas:

• Quando já os estiveres a usar e estiveres a atualizar do metastore do Hive para o Unity Catalog.

  • O uso de tabelas externas pode fornecer uma atualização rápida e contínua com um clique sem mover dados.
  • O Databricks recomenda que você eventualmente migre tabelas externas para tabelas gerenciadas.

• Se você tiver requisitos de recuperação de desastres para esses dados, isso não pode ser atendido por tabelas gerenciadas.

  As tabelas gerenciadas não podem ser registradas em vários metastores na mesma nuvem.

• Caso leitores ou gravadores externos precisem ser capazes de interagir com os dados a partir de fora do Databricks.

  Normalmente, você deve evitar permitir o acesso externo até mesmo às tabelas externas registradas no Unity Catalog. Isso ignora o controle de acesso, a auditoria e a linhagem do Unity Catalog. É uma prática melhor usar tabelas gerenciadas e compartilhar dados entre regiões ou provedores de nuvem usando o Delta Sharing. Se você precisar permitir o acesso externo a tabelas externas, limite-o a leituras, com todas as gravações acontecendo por meio do Azure Databricks e do Unity Catalog.

• Você deve dar suporte a tabelas não-Delta ou não-Iceberg, como Parquet, Avro, ORC, etc.

Mais recomendações para o uso de tabelas externas:

• O Databricks recomenda que você crie tabelas externas usando um local externo por esquema.
• O Databricks recomenda fortemente não registrar uma tabela como uma tabela externa em mais de um metastore devido ao risco de problemas de consistência. Por exemplo, uma alteração no esquema em um metastore não será registrada no segundo metastore. Use o Compartilhamento Delta para compartilhar dados entre metastores. Consulte Compartilhamento entre regiões e entre plataformas.

Consulte também tabelas do Azure Databricks.

Volumes gerenciados e externos

Os volumes gerenciados são totalmente gerenciados pelo Unity Catalog, o que significa que o Unity Catalog gerencia o acesso ao local de armazenamento do volume em sua conta de provedor de nuvem. Os volumes externos representam dados existentes em locais de armazenamento que são gerenciados fora do Azure Databricks, mas registrados no Unity Catalog para controlar e auditar o acesso de dentro do Azure Databricks. Ao criar um volume externo no Azure Databricks, você especifica seu local, que deve estar em um caminho definido em um local externo do Catálogo Unity.

Use volumes gerenciados:

• Para a maioria dos casos de uso, aproveite ao máximo os recursos de governança do Unity Catalog.
• Se você quiser criar tabelas a partir de arquivos em um volume sem executar COPY INTO ou instruções CTAS (CREATE TABLE AS).

Use volumes externos:

• Registrar áreas de aterrissagem para dados brutos produzidos por sistemas externos para apoiar seu processamento nos estágios iniciais de dutos ETL e outras atividades de engenharia de dados.
• Para registrar locais de preparo para ingestão, por exemplo, usando instruções Auto Loader, COPY INTO, ou CTAS.
• Forneça locais de armazenamento de arquivos para cientistas de dados, analistas de dados e engenheiros de aprendizado de máquina usarem como partes de suas tarefas exploratórias de análise de dados e outras tarefas de ciência de dados, quando os volumes gerenciados não forem uma opção.
• Para dar aos usuários do Azure Databricks acesso a arquivos arbitrários produzidos e depositados no armazenamento em nuvem por outros sistemas, por exemplo, grandes coleções de dados não estruturados (como arquivos de imagem, áudio, vídeo e PDF) capturados por sistemas de vigilância ou dispositivos IoT, ou arquivos de biblioteca (JARs e arquivos de roda Python) exportados de sistemas locais de gerenciamento de dependência ou pipelines de CI/CD.
• Para armazenar dados operacionais, por exemplo, registos ou arquivos de ponto de controlo, quando os volumes geridos não são uma opção.

Mais recomendações para o uso de volumes externos:

• O Databricks recomenda que você crie volumes externos de um local externo dentro de um esquema.

Consulte também Volumes gerenciados versus volumes externos e Locais externos.

Localizações externas

Objetos protegíveis de localização externa, combinando credenciais de armazenamento e caminhos de armazenamento, fornecem forte controle e auditabilidade do acesso ao armazenamento. É importante evitar que os usuários acessem os contêineres registrados como locais externos diretamente, ignorando o controle de acesso fornecido pelo Unity Catalog.

Para utilizar localizações externas de forma eficaz:

• Certifique-se de limitar o número de usuários com acesso direto a qualquer contêiner que esteja sendo usado como um local externo.

• Não monte contas de armazenamento em DBFS se elas também estiverem sendo usadas como locais externos. O Databricks recomenda que você migre montagens em locais de armazenamento em nuvem para locais externos no Catálogo Unity usando o Catalog Explorer.

• Conceda a capacidade de criar locais externos apenas a administradores encarregados de configurar conexões entre o Unity Catalog e o armazenamento em nuvem ou a engenheiros de dados confiáveis.

  Locais externos fornecem acesso de dentro do Unity Catalog a um local amplamente abrangente no armazenamento em nuvem, por exemplo, um bucket ou contêiner inteiro (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net) ou um subcaminho amplo (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog). A intenção é que um administrador de nuvem possa estar envolvido na configuração de alguns locais externos e, em seguida, delegar a responsabilidade de gerenciar esses locais a um administrador do Azure Databricks em sua organização. O administrador do Azure Databricks pode, então, organizar ainda mais o local externo em áreas com permissões mais granulares registrando volumes externos ou tabelas externas em prefixos específicos no local externo.

  Como os locais externos são tão abrangentes, o Databricks recomenda dar a permissão apenas a um administrador encarregado de configurar conexões entre o CREATE EXTERNAL LOCATION Unity Catalog e o armazenamento em nuvem ou a engenheiros de dados confiáveis. Para fornecer a outros usuários acesso mais granular, o Databricks recomenda registrar tabelas ou volumes externos em cima de locais externos e conceder aos usuários acesso aos dados usando volumes ou tabelas. Como tabelas e volumes são filhos de um catálogo e esquema, os administradores de catálogo ou esquema têm o controle final sobre as permissões de acesso.

  Você também pode controlar o acesso a um local externo vinculando-o a espaços de trabalho específicos. Consulte (Opcional) Atribuir um local externo a espaços de trabalho específicos.

• Não conceda permissões gerais READ FILES ou WRITE FILES em locais externos aos usuários finais.

  Os usuários não devem usar locais externos para nada além de criar tabelas, volumes ou locais gerenciados. Eles não devem usar locais externos para acesso baseado em caminho para ciência de dados ou outros casos de uso de dados não tabulares.

  Para acesso baseado em percursos a dados não tabulares, use volumes. O acesso do URI da nuvem aos dados sob o caminho do volume é regido pelos privilégios concedidos no volume, não pelos privilégios concedidos no local externo onde o volume está armazenado.

  Os volumes permitem que você trabalhe com arquivos usando comandos SQL, dbutils, APIs do Spark, APIs REST, Terraform e uma interface de usuário para navegar, carregar e baixar arquivos. Além disso, os volumes oferecem uma montagem FUSE acessível no sistema de arquivos local em /Volumes/<catalog_name>/<schema_name>/<volume_name>/. A montagem FUSE permite que cientistas de dados e engenheiros de ML acessem arquivos como se estivessem em um sistema de arquivos local, conforme exigido por muitas bibliotecas de sistema operacional ou de aprendizado de máquina.

  Se você precisar conceder acesso direto a arquivos em um local externo (para explorar arquivos no armazenamento em nuvem antes que um usuário crie uma tabela ou volume externo, por exemplo), poderá conceder READ FILES. Os casos de uso para concessão de WRITE FILES são raros.

• Evite conflitos de sobreposição de caminho: nunca crie volumes ou tabelas externos na raiz de um local externo.

  Se você criar volumes ou tabelas externos na raiz do local externo, não poderá criar volumes ou tabelas externos adicionais no local externo. Em vez disso, crie volumes ou tabelas externos em um subdiretório dentro do local externo.

Você deve usar locais externos apenas para fazer o seguinte:

• Registe tabelas e volumes externos utilizando o comando CREATE EXTERNAL VOLUME ou CREATE TABLE.
• Registre um local como armazenamento gerenciado. O CREATE MANAGED STORAGE privilégio é uma condição prévia.
• Explore os arquivos existentes no armazenamento em nuvem antes de criar uma tabela ou volume externo em um prefixo específico. O READ FILES privilégio é uma condição prévia. Atribua esse privilégio com moderação. Consulte a recomendação na lista anterior para obter detalhes.

Locais externos vs. volumes externos

Antes do lançamento dos volumes, algumas implementações do Unity Catalog atribuíam READ FILES acesso diretamente a locais externos para exploração de dados. Com a disponibilidade de volumes que registram arquivos em qualquer formato, incluindo dados estruturados, semiestruturados e não estruturados, não há razão real para usar locais externos para nada além da criação de tabelas, volumes ou locais gerenciados. Para obter informações detalhadas sobre quando usar locais externos e quando usar volumes, consulte Volumes gerenciados e externos e Locais externos.

Partilha entre regiões e entre plataformas

Você pode ter apenas um metastore por região. Se quiseres partilhar dados entre espaços de trabalho em diferentes regiões, utiliza o Compartilhamento Delta do Databricks com o Databricks.

Melhores práticas:

• Use o seu metastore de região única para todos os escopos do ciclo de vida de desenvolvimento de software e unidades de negócio, como desenvolvimento, teste, produção, vendas e marketing. Certifique-se de que os espaços de trabalho que exigem acesso frequente a dados compartilhados estejam localizados na mesma região.
• Use o Compartilhamento Delta de Databricks para Databricks entre regiões de nuvem ou provedores de nuvem.
• Use o Compartilhamento Delta para tabelas que são acessadas com pouca frequência, porque você é responsável pelas cobranças de saída da região da nuvem para a região da nuvem. Se você precisar compartilhar dados acessados com frequência entre regiões ou provedores de nuvem, consulte: Monitorar e gerenciar os custos de saída do Delta Sharing (para provedores).

Esteja ciente das seguintes limitações ao usar o compartilhamento de Databricks para Databricks:

• Os gráficos de linhagem são criados no nível do metastore e não cruzam os limites da região ou da plataforma. Isso se aplica mesmo se um recurso for compartilhado entre metastores dentro da mesma conta Databricks: as informações de linhagem da origem não são visíveis no destino e vice-versa.
• O controle de acesso é definido no nível do metastore e não cruza os limites da região ou da plataforma. Se um recurso tiver privilégios atribuídos a ele e esse recurso for compartilhado com outro metastore na conta, os privilégios nesse recurso não se aplicarão ao compartilhamento de destino. Você deve conceder privilégios no compartilhamento de destino no destino.

Configurações de computação

O Databricks recomenda o uso de políticas de computação para limitar a capacidade de configurar clusters com base em um conjunto de regras. As políticas de computação permitem limitar os usuários à criação de clusters habilitados para Unity Catalog, especificamente clusters que usam o modo de acesso padrão (anteriormente modo de acesso compartilhado) ou o modo de acesso dedicado (anteriormente modo de usuário único ou modo de acesso atribuído).

Somente clusters que usam um desses modos de acesso podem acessar dados no Unity Catalog. Todos os recursos de computação sem servidor e de computação DBSQL suportam o Unity Catalog.

O Databricks recomenda o modo de acesso padrão para todas as cargas de trabalho. Use o modo de acesso dedicado somente se a funcionalidade necessária não for suportada pelo modo de acesso padrão. Consulte Modos de Acesso.