Melhores práticas do Catálogo do Unity

Este documento fornece recomendações para usar o Catálogo do Unity para atender às suas necessidades de governança de dados com mais eficiência. 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 Catálogo do Unity, consulte o que é o Catálogo do Unity?.

Identidades

Principais (usuários, grupos e principais de serviço) devem ser definidos no nível da conta do Azure Databricks para receber privilégios em objetos protegidos do Unity Catalog. O Databricks recomenda que você use o SCIM para provisionar entidades de segurança na sua conta do Azure Databricks a partir do seu IdP.

Práticas recomendadas:

• Evite (e desative, se já estiver ativado) o provisionamento SCIM no nível de espaço de trabalho. O provisionamento de entidades de segurança diretamente para um espaço de trabalho deve ser reservado para espaços de trabalho legados que não estão habilitados para o Catálogo do Unity. Você deve gerenciar o provisionamento inteiramente no nível da conta.

• Defina e gerencie grupos em seu IdP. Elas devem ser consistentes com suas definições de grupo organizacional.

  Os grupos se comportam de forma diferente dos usuários e entidades de serviço. Embora os usuários e as 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 do espaço de trabalho, será necessário 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 você possa usá-los com eficácia para conceder acesso a dados e outros itens de segurança do Catálogo do Unity. 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 à conta ou ao workspace. Evite modificar grupos no Azure Databricks: use seu IdP.

• Use entidades de serviço para executar trabalhos. As entidades de serviço permitem a automação do trabalho. Se você usar usuários para executar trabalhos que gravam em produção, correrá o risco de substituir dados de produção por acidente.

Para obter mais informações, consulte Gerenciar usuários, entidades de serviço e grupos e Sincronizar usuários e grupos da ID do Microsoft Entra 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 de administradores de conta, administradores de workspace e administradores de metastore antes de atribuí-los. Confira Privilégios de administrador no Unity Catalog.
• Atribua essas funções a grupos sempre que possível.
• Os administradores do Metastore são opcionais. Atribua-os somente se você precisar deles. Para obter diretrizes, consulte (Opcional) Atribuir a função de administrador metastore.
• Atribua a propriedade do objeto a grupos, especialmente se os objetos forem usados na produção. O criador de qualquer objeto é seu primeiro proprietário. Os criadores devem reatribuir a propriedade a grupos apropriados.
• Somente administradores de metastore, proprietários e usuários com o MANAGE privilégio em um objeto podem conceder privilégios nesse objeto. Os proprietários de catálogos e esquemas pais também têm a capacidade de conceder privilégios em todos os objetos no catálogo ou esquema. Seja comedido ao atribuir propriedade e privilégio MANAGE.
• Use com parcimônia na atribuição de ALL PRIVILEGES, que inclui todos os privilégios, exceto MANAGE e 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 efetivo.

Práticas recomendadas:

• Entenda a diferença entre USE CATALOG (ou USE SCHEMA) e BROWSE:

  • USE CATALOG | SCHEMA concede a capacidade de visualizar dados no catálogo ou esquema. Sozinhos, esses privilégios não concedem SELECT nem READ nos objetos dentro do catálogo ou esquema, mas são um pré-requisito para conceder acesso aos usuários. Conceda esses privilégios somente aos usuários que devem ser capazes de exibir dados no catálogo ou esquema.
  • USE CATALOG | SCHEMA, restringindo 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. É comum criar um esquema por equipe e conceder USE SCHEMA e CREATE TABLE somente para essa equipe (juntamente com USE CATALOG no catálogo pai).
  • BROWSE pode ser concedido amplamente no nível do catálogo para permitir que os usuários exibam os metadados associados aos objetos no catálogo.

• 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 no objeto, como SELECT e MODIFY em uma tabela, bem como permissão para conceder privilégios no objeto protegível para outras entidades de segurança e transferir a propriedade para outras entidades de segurança.
  • Os proprietários podem conceder o privilégio MANAGE para delegar capacidades de propriedade em um objeto a outras entidades de segurança.
  • Os proprietários de catálogo e esquema podem transferir a propriedade de qualquer objeto no catálogo ou esquema.
  • É melhor configurar a propriedade ou conceder o MANAGE privilégio em todos os objetos a um grupo responsável pelo gerenciamento de concessões nos objetos.

• Reserve acesso MODIFY direto às tabelas de produção para entidades de serviço.

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

Metastores

Veja a seguir as regras e as práticas recomendadas para criar e gerenciar metastores:

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

• Os metastores fornecem isolamento regional, mas não se destinam como unidades padrão de isolamento de dados. Normalmente, o isolamento de dados começa no nível do catálogo. No entanto, se você preferir um modelo de governança mais centralizado, poderá criar um armazenamento gerenciado no nível do 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.

Importante

Não registre tabelas acessadas com frequência como tabelas externas em mais de um metastore. Se você fizer isso, as alterações no esquema, nas propriedades da tabela, nos comentários e em outros metadados que ocorrem como resultado de gravações no metastore A não serão registradas no metastore B. Você também pode causar problemas de consistência com o serviço de confirmação do Azure Databricks.

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 Catálogo do Unity. 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 refletem divisões organizacionais e projetos. Geralmente, isso significa que os catálogos correspondem a um escopo de ambiente, equipe, unidade de negócios ou alguma combinação deles. Isso facilita o uso da hierarquia de privilégios para gerenciar o acesso com eficiência.
• Quando os ambientes de trabalho e os dados têm os mesmos requisitos de isolamento, você pode associar um catálogo a um workspace específico. Quando isso for necessário, crie catálogos que tenham escopo para um conjunto limitado de espaços de trabalho.
• Sempre atribua a propriedade de catálogos de produção e esquemas a grupos, não a usuários individuais.
• Conceda 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 Catálogo do Unity, 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 especifique um local de armazenamento gerenciado no Catálogo do Unity.

Práticas recomendadas para locais de armazenamento gerenciado:

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

  O armazenamento no nível do Metastore era necessário nos primeiros ambientes do Catálogo do Unity, mas não é mais necessário.

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

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

  Se um serviço externo ou entidade de segurança acessar dados no local de armazenamento gerenciado, ignorando o Catálogo do Unity, o controle de acesso e a auditabilidade em tabelas e volumes gerenciados serão comprometidos.

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

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

  contas re:[ADLS] suportam 20.000 solicitações por segundo por padrão. Isso poderá causar limitação e desaceleraçã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, distribua o armazenamento em várias contas de armazenamento.

  Essa distribuição seria invisível para os usuários finais do Catálogo do Unity.

Tabelas gerenciadas e externas

Tabelas gerenciadas são totalmente gerenciadas pelo Catálogo do Unity, o que significa que o Catálogo do Unity gerencia a governança e os arquivos de dados subjacentes para cada tabela gerenciada. Eles estão sempre no formato Delta ou Apache Iceberg.

Tabelas externas são tabelas cujo acesso do Azure Databricks é gerenciado pelo Catálogo do Unity, 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, especifique sua localização, que deve estar em um caminho definido em um local externo do Catálogo do Unity.

Use tabelas gerenciadas:

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

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

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

• Para todas as tabelas novas.

Use tabelas externas:

• Quando você já estiver usando-os e estiver atualizando do metastore do Hive para o Catálogo do Unity.

  • O uso de tabelas externas pode fornecer uma atualização rápida e perfeita de "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 desastre para esses dados que não podem ser atendidos por tabelas gerenciadas.

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

• Se for necessário que leitores ou gravadores externos interajam com os dados a partir de fora do Databricks.

  Normalmente, você deve evitar permitir acesso externo até mesmo às tabelas externas registradas no Catálogo do Unity. Ao fazer isso, são ignorados o controle de acesso, a auditoria e a rastreabilidade do Catálogo Unity. É uma prática melhor usar tabelas gerenciadas e compartilhar dados entre regiões ou provedores de nuvem usando o Compartilhamento Delta. Se você precisar permitir o acesso externo a tabelas externas, limite-o a leituras, com todas as escritas acontecendo por meio do Azure Databricks e Unity Catalog.

• Você deve dar suporte a tabelas que não sejam Delta ou Iceberg, como Parquet, Avro, ORC e assim por diante.

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

• O Databricks recomenda que você crie tabelas externas usando um local externo por esquema.
• A 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 em outro. Use o Compartilhamento Delta para compartilhar dados entre metastores. Consulte o compartilhamento entre regiões e entre plataformas.

Consulte também Introdução às tabelas do Azure Databricks.

Volumes gerenciados e externos

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

Use volumes gerenciados:

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

Use volumes externos:

• Para registrar áreas de destino para dados brutos produzidos por sistemas externos a fim de viabilizar o processamento nos estágios iniciais de pipelines de ETL e outras atividades de engenharia de dados.
• Para registrar locais de preparo para ingestão, por exemplo, usando o Carregador Automático, COPY INTO, ou instruções CTAS.
• Forneça locais de armazenamento de arquivos para cientistas de dados, analistas de dados e engenheiros de aprendizado de máquina usarem como parte de sua análise exploratória 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, tais como 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 (arquivos JARs e wheel do Python) exportados de sistemas de gerenciamento de dependência local ou pipelines de CI/CD.
• Para armazenar dados operacionais, por exemplo, arquivos de registro em log ou de ponto de verificação, quando volumes gerenciados não são uma opção.

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

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

Dica

Para casos de uso de ingestão em que os dados são copiados para outro local, por exemplo, usando o Carregador Automático ou COPY INTO, use volumes externos. Use tabelas externas quando quiser consultar dados no local como uma tabela, sem nenhuma cópia envolvida.

Consulte também Volumes gerenciados versus externos e locais externos.

Locais externos

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 impedir que os usuários acessem os contêineres registrados como locais externos diretamente, ignorando o controle de acesso fornecido pelo Catálogo do Unity.

Para usar locais externos de forma eficaz:

• Verifique se você limita 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 no DBFS se elas também estiverem sendo usadas como locais externos. O Databricks recomenda a migração de montagens em locais de armazenamento em nuvem para locais externos no Catálogo do Unity usando o Explorador do Catálogo.

• Conceda a capacidade de criar locais externos apenas para administradores que têm a tarefa de configurar conexões entre o Catálogo do Unity e o armazenamento em nuvem ou para 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 se envolver 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 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 muito abrangentes, o Databricks recomenda conceder a permissão CREATE EXTERNAL LOCATION somente a um administrador encarregado de configurar as conexões entre o Catálogo do Unity e o armazenamento em nuvem, ou a engenheiros de dados confiáveis. Para fornecer a outros usuários um acesso mais granular, o Databricks recomenda registrar tabelas ou volumes externos em cima de locais externos e conceder aos usuários acesso a dados usando volumes ou tabelas. Como as tabelas e os volumes são filhos de um catálogo e de um esquema, os administradores do catálogo ou do esquema têm o controle final sobre as permissões de acesso.

  Também é possível controlar o acesso a um local externo associando-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 caminhos para ciência de dados ou outros casos de uso de dados não tabulares.

  Para acesso baseado em caminho a dados não tabulares, use volumes. O acesso de URI de nuvem aos dados no caminho do volume é regido pelos privilégios concedidos no volume, não pelos privilégios concedidos no local externo em que o volume é armazenado.

  Os volumes permitem que você trabalhe com arquivos usando comandos SQL, dbutils, APIs do Spark, APIs REST, Terraform e uma interface do usuário para navegar, carregar e baixar arquivos. Além disso, os volumes oferecem uma montagem FUSE que pode ser acessada no sistema de arquivos local em /Volumes/<catalog_name>/<schema_name>/<volume_name>/. A montagem do 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 aprendizado de máquina ou do sistema operacional.

  Se você deve 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), você pode conceder READ FILES. Casos de uso para concessão de WRITE FILES são raros.

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

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

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

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

Locais externos versus volumes externos

Antes de os volumes serem lançados, algumas implementações do Catálogo do Unity atribuíram 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á nenhum motivo real para usar locais externos para qualquer coisa além de criar 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.

Compartilhamento entre regiões e entre plataformas

Você pode ter apenas um metastore por região. Se quiser compartilhar dados entre espaços de trabalho em diferentes regiões, use o recurso Compartilhamento Delta do Databricks para Databricks.

Práticas recomendadas:

• Use seu metastore de região única para todos os escopos de ciclo de vida de desenvolvimento de software e unidades de negócios, por exemplo, desenvolvimento, teste, produção, vendas e marketing. Verifique se os workspaces que exigem acesso frequente a dados compartilhados estão localizados na mesma região.
• Use o Compartilhamento Delta do Databricks para Databricks entre diferentes regiões de nuvem ou provedores de nuvem.
• Use o Compartilhamento Delta para tabelas acessadas com pouca frequência, pois você é responsável pelas taxas de saída entre regiões 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 de compartilhamento Delta (para provedores).

Lembre-se das seguintes limitações ao usar o compartilhamento Databricks-to-Databricks:

• Os grafos de linhagem são criados no nível do metastore e não cruzam os limites de região ou plataforma. Isso se aplica mesmo se um recurso for compartilhado entre metastores na mesma conta do Databricks: as informações de linhagem da origem não estarão visíveis no destino e vice-versa.
• O controle de acesso é definido no nível do metastore e não cruza os limites de região ou 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 a criar clusters habilitados para o Catálogo do Unity, especificamente clusters que usam o modo de acesso padrão (antigo modo de acesso compartilhado) ou o modo de acesso dedicado (antigo modo de acesso atribuído ou de usuário único).

Somente os clusters que usam um desses modos de acesso podem acessar dados no Catálogo do Unity. Toda a computação sem servidor e a computação DBSQL dão suporte ao Catálogo do Unity.

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 tiver suporte no modo de acesso padrão. Consulte Modos de acesso.