Práticas recomendadas do Unity Catalog

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

Identidades

Os principals (usuários, grupos e entidades de serviço) devem ser definidos no nível Databricks account para que sejam atribuídos privilégios aos objetos protegíveis Unity Catalog. Databricks recomenda que o senhor use o site SCIM para provisionar os principais para o seu Databricks account a partir do seu IdP.

Melhores práticas:

• Evite (e desative o existente) workspace-level SCIM provisionamento. Os princípios de provisionamento diretamente para um workspace devem ser reservados para o espaço de trabalho legado que não está habilitado para Unity Catalog. O senhor deve gerenciar o provisionamento inteiramente no nível account.

• 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 das entidades de serviço. Embora os usuários e entidades de serviço que o senhor adiciona a um workspace sejam automaticamente sincronizados com a sua conta do Databricks, os grupos de nível workspacenão são. Se o senhor tiver grupos workspace-local, deverá migrá-los manualmente para o account, de preferência replicando-os em seu IdP (se necessário) e provisionando-os para o account.

• Configure grupos para que o senhor possa usá-los de forma eficaz para conceder acesso a dados e outros itens seguros 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 no site account ou no site workspace. Evite modificar grupos no Databricks: use seu IdP.

• Use a entidade de serviço para executar o trabalho. A entidade de serviço permite a automação do trabalho. Se o senhor usar usuários para executar trabalhos que gravam na produção, corre o risco de sobrescrever os 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 do seu provedor de identidade usando SCIM.

Funções administrativas e privilégios poderosos

A atribuição de funções de administrador e privilégios poderosos, como ALL PRIVILEGES e MANAGE, exige cuidado:

• Entenda os privilégios dos administradores de account, workspace e metastore antes de atribuí-los. Consulte Privilégios de administrador no Unity Catalog.
• Atribua essas funções aos grupos sempre que possível.
• Os administradores do Metastore são opcionais. Atribua-os somente se você precisar deles. Para obter orientação, consulte (Opcional) Atribuir a função de administrador da 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 aos grupos apropriados.
• Somente administradores, proprietários e usuários da metastore com o privilégio MANAGE em um objeto podem conceder privilégios nesse objeto. Os proprietários dos catálogos e esquemas principais também podem conceder privilégios em todos os objetos no catálogo ou esquema. Seja econômico em sua atribuição de propriedade e no privilégio MANAGE.
• Seja moderado na atribuição de ALL PRIVILEGES, que inclui todos os privilégios, exceto MANAGE.

Atribuição de privilégios

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

Melhores práticas:

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

  • USE CATALOG | SCHEMA concede a capacidade de view dados no catálogo ou no esquema. Sozinhos, esses privilégios não concedem SELECT ou READ aos objetos dentro do catálogo ou esquema, mas são um pré-requisito para conceder esse acesso aos usuários. Conceda esses privilégios somente aos usuários que devem ser capazes de view dados no catálogo ou no esquema.
  • USE CATALOG | SCHEMA, ao restringir o acesso a um catálogo ou esquema, impede que 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 (junto com USE CATALOG no catálogo principal).
  • BROWSE pode ser concedida amplamente no nível do catálogo para permitir que os usuários acessem view os metadados associados aos objetos no catálogo.

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

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

• Reservar acesso direto MODIFY às mesas de produção para a entidade de serviço.

Para obter mais informações, consulte gerenciar privilégios em Unity Catalog.

Metástores

A seguir estão as regras e as melhores práticas para criar e gerenciar metástores:

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

• Os metastores oferecem isolamento regional, mas não se destinam a ser default unidades de isolamento de dados. O isolamento de dados geralmente começa no nível do catálogo. No entanto, se o senhor preferir um modelo de governança mais centralizado, poderá criar um armazenamento gerenciado em nível de metastore. Para obter recomendações, consulte gerenciar o armazenamento.

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

important

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

Catálogos e esquemas

Os catálogos são a principal unidade 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álogos e esquemas:

• Organizar dados e objetos AI em catálogos e esquemas que reflitam divisões e projetos organizacionais. Geralmente, isso significa que os catálogos correspondem a um escopo de ambiente, equipe, unidade de negócios ou alguma combinação desses. 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, o senhor pode vincular um catálogo a um site específico workspace. Quando isso for necessário, crie catálogos que possam ter escopo para um conjunto limitado de espaços de trabalho.
• Sempre atribua a propriedade dos catálogos e esquemas de produção a grupos, não a usuários individuais.
• Conceda USE CATALOG e USE SCHEMA somente aos usuários que deveriam poder 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.

gerenciar o armazenamento

As tabelas e volumes gerenciados, objetos cujo ciclo de vida é totalmente gerenciado por Unity Catalog, são armazenados em locais de armazenamento default, conhecidos como armazenamento gerenciado . O senhor pode configurar o armazenamento gerenciar no nível do metastore, do catálogo ou do esquema. Os dados são armazenados no local mais baixo disponível na hierarquia. Para obter detalhes, consulte Hierarquia de locais de armazenamento gerenciar e Especificar um local de armazenamento gerenciar em Unity Catalog.

Práticas recomendadas para gerenciar locais de armazenamento:

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

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

• Se o senhor optar por criar um local de gerenciar no nível do metastore, use um bucket dedicado.

• Não use um bucket que possa ser acessado de fora do Unity Catalog.

  Se um serviço externo ou um diretor acessar os dados no local de armazenamento gerenciado, ignorando Unity Catalog, o controle de acesso e a auditabilidade das tabelas e volumes gerenciados serão comprometidos.

• Não reutilize um bucket que é ou foi usado para seu sistema de arquivosDBFS root.

gerenciar e tabelas externas

As tabelas gerenciar são totalmente gerenciadas por Unity Catalog, o que significa que Unity Catalog gerencia tanto a governança quanto os arquivos de dados subjacentes para cada tabela gerenciar. Eles estão sempre no formato Delta ou Apache Iceberg.

Tabelas externas são tabelas cujo acesso a partir de Databricks é gerenciado por Unity Catalog, mas cujo ciclo de vida de dados e disposição de arquivos são gerenciados usando seu provedor de nuvem e outras plataformas de dados. Ao criar uma tabela externa no Databricks, o usuário especifica seu local, que deve estar em um caminho definido em um local externo do Unity Catalog.

Use tabelas gerenciais:

• Para a maioria dos casos de uso. Databricks recomenda gerenciar tabelas e volumes porque eles permitem que o senhor aproveite ao máximo os recursos de governança e as otimizações de desempenho do Unity Catalog, inclusive:

  • 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 site Databricks dá precedência às tabelas gerenciais.

• Para todas as novas tabelas.

Use tabelas externas:

• Quando o senhor já os estiver usando e estiver fazendo upgrade de Hive metastore para Unity Catalog.

  • O uso de tabelas externas pode fornecer uma atualização rápida e perfeita com “um clique” sem mover dados.
  • Databricks recomenda que o senhor eventualmente migre tabelas externas para tabelas gerenciais.

• Se o senhor tiver requisitos de recuperação de desastres para esses dados que não possam ser atendidos por tabelas gerenciadas.

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

• Se for necessário que leitores ou gravadores externos possam interagir com os dados de fora do Databricks, o senhor pode usar o Databricks para fazer isso.

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

• O senhor deve oferecer suporte a tabelas que não sejam da Delta ou da Iceberg, como Parquet, Avro, ORC e assim por diante.

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

• Databricks recomenda que você crie tabelas externas usando um local externo por esquema.
• A Databricks não recomenda o registro de 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 Delta Sharing para compartilhar dados entre metastores. Consulte Compartilhamento entre regiões e entre plataformas.

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

gerenciar e volumes externos

gerenciar volumes são totalmente gerenciados por Unity Catalog, o que significa que Unity Catalog gerencia o acesso ao local de armazenamento do volume em seu provedor de nuvem account. Os volumes externos representam dados existentes em locais de armazenamento gerenciados fora de Databricks, mas registrados em Unity Catalog para controlar e auditar o acesso de dentro de Databricks. Ao criar um volume externo no Databricks, o usuário especifica sua localização, que deve estar em um caminho definido em uma localização externa do Unity Catalog.

Use gerenciar volumes:

• Para a maioria dos casos de uso, para aproveitar 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 instruções COPY INTO ou 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 do pipeline ETL e outras atividades de engenharia de dados.
• Para registrar locais de preparação para ingestão, por exemplo, usando as declarações Auto Loader, COPY INTO ou CTAS.
• Forneça locais de armazenamento de arquivos para cientistas de dados, analistas de dados e engenheiros de machine learning usarem como parte de sua análise exploratória de dados e outras tarefas de ciência de dados, quando volumes gerenciados não forem uma opção.
• Para dar aos usuários do site 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 (arquivos JARs e Python wheel ) exportados de sistemas locais de gerenciamento de dependências ou do pipeline CI/CD.
• Para armazenar dados operacionais, por exemplo, arquivos de registro ou de ponto de verificação, quando os volumes gerenciais não são uma opção.

Mais recomendações para usar volumes externos:

• A 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 Auto Loader 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 gerenciar vs. volumes externos e Localizações externas.

Localizações externas

Objetos externos que podem ser protegidos em locais externos, combinando credenciais de armazenamento e caminhos de armazenamento, oferecem forte controle e auditabilidade do acesso ao armazenamento. É importante impedir que os usuários acessem diretamente os buckets registrados como locais externos, ignorando o controle de acesso fornecido pelo Unity Catalog.

Para usar locais externos de forma eficaz:

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

• Não monte a conta de armazenamento em DBFS se ela também estiver sendo usada como local externo. A Databricks recomenda que o senhor migre montagens em locais de armazenamento em nuvem para locais externos no Unity Catalog usando o Catalog Explorer.

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

  Os 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 (bucket-path) ou um subcaminho amplo (bucket-subpath). 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 da Databricks em sua organização. O administrador do 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 CREATE EXTERNAL LOCATION apenas a um administrador encarregado de configurar conexões entre o 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 sobre locais externos e conceder aos usuários acesso a dados usando volumes ou tabelas. Como tabelas e volumes são elementos secundários de um catálogo e esquema, os administradores de catálogo ou esquema têm o controle final sobre as permissões de acesso.

  O senhor também pode controlar o acesso a um local externo vinculando-o a um espaço de trabalho específico. Consulte (Opcional) Atribuir um local externo a um espaço de trabalho específico.

• 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 gerenciar locais. 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 caminho a volumes de uso de dados não tabulares. O acesso do Cloud URI 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 está armazenado.

  Os volumes permitem que o senhor trabalhe com arquivos usando SQL comando, dbutils, Spark APIs, REST APIs, Terraform e uma interface de usuário para navegação, upload e download de 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 FUSE permite que os engenheiros do data scientists e do ML acessem arquivos como se estivessem em um sistema de arquivos local, conforme exigido por muitas bibliotecas de aprendizado de máquina ou de sistemas operacionais.

  Se você precisar conceder acesso direto aos 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 caminho: nunca crie volumes ou tabelas externos na raiz de um local externo.

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

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

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

Localizações externas versus volumes externos

Antes de os volumes serem lançados, algumas implementações do Unity Catalog atribuíam o acesso READ FILES 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á motivo real para usar locais externos para nada além de criar tabelas, volumes ou gerenciar locais. Para obter informações detalhadas sobre quando usar locais externos e quando usar volumes, consulte Gerenciar e volumes externos e Locais externos.

Compartilhamento entre regiões e plataformas

Você pode ter apenas um metastore por região. Se o senhor quiser compartilhar dados entre espaços de trabalho em regiões diferentes, use o site Databricks-to-Databricks Delta Sharing.

Melhores práticas:

• Use o metastore de uma única região para todos os escopos do ciclo de vida de desenvolvimento e unidades de negócios do software, por exemplo, desenvolvimento, teste, produção, ventas 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 site Databricks-to-Databricks Delta Sharing entre regiões ou provedores de nuvem.
• Use o Delta Sharing para tabelas que não são acessadas com frequência, pois o senhor é responsável pelas taxas de saída de uma região de nuvem para outra. Se o senhor 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 quando o senhor usar o Databricks-to-Databricks compartilhamento:

• As linhagens gráficas são criadas no nível do metastore e não ultrapassam os limites da região ou da plataforma. Isso se aplica mesmo que um recurso seja compartilhado entre metastores dentro do mesmo Databricks account: 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 ultrapassa 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 no site account, os privilégios desse 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

Databricks recomenda o uso de políticas compute para limitar a capacidade de configurar o clustering com base em um conjunto de regras. As políticas de computação permitem limitar os usuários à criação de clusters habilitados para o Unity Catalog, 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 os dados em Unity Catalog. Todos os sites serverless compute e DBSQL compute suportam Unity Catalog.

A 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.