Melhores práticas do Unity Catalog

Este documento fornece recomendações para o uso do Unity Catalog e do Delta Sharing para atender às suas necessidades de governança de dados.

O Unity Catalog é uma solução de governança refinada para dados e IA na plataforma Databricks. Ele ajuda a simplificar a segurança e a governança de seus dados, fornecendo um local central para administrar e auditar o acesso aos dados. O Delta Sharing é uma plataforma de compartilhamento de dados segura que permite compartilhar dados no Databricks com usuários fora da sua organização. Ele usa o Unity Catalog para gerenciar e auditar o comportamento de compartilhamento.

Elementos de governança de dados e isolamento de dados

Para desenvolver um modelo de governança de dados e um plano de isolamento de dados que funcionem para sua organização, é útil compreender os principais elementos que estão disponíveis quando você cria sua solução de governança de dados no Databricks.

O diagrama a seguir ilustra a hierarquia de dados primária no Unity Catalog (alguns objetos protegíveis estão desativados para enfatizar a hierarquia de objetos gerenciados em catálogos).

Diagrama de modelo de objeto do Unity Catalog

Os objetos nessa hierarquia incluem os seguintes:

  • Metastore: um metastore é o contêiner de nível superior de objetos no Unity Catalog. Os metastores residem no nível da conta e funcionam como o topo da pirâmide no modelo de governança de dados do Databricks.

    Os metastores gerenciam ativos de dados (tabelas, visualizações e volumes) e as permissões que regem o acesso a eles. Os administradores de conta do Databricks podem criar um metastore para cada região em que operam e atribuí-los a vários workspaces do Databricks na mesma região. Os administradores do metastore podem gerenciar todos os objetos no metastore. Eles não possuem acesso direto para ler e gravar em tabelas registradas no metastore, mas têm acesso indireto por meio de sua capacidade de transferir a propriedade de objetos de dados.

    O armazenamento físico de qualquer metastore é, por padrão, isolado do armazenamento de qualquer outro metastore na sua conta.

    Os metastores fornecem isolamento regional, mas não se destinam a unidades de isolamento de dados. O isolamento de dados deve começar no nível do catálogo.

  • Catálogo: catálogos são o nível mais alto na hierarquia de dados (catálogo > esquema > tabela/view/volume) gerenciados pelo metastore do Unity Catalog. Eles são concebidos como a unidade primária de isolamento de dados em um modelo típico de governança de dados do Databricks.

    Os catálogos representam um agrupamento lógico de esquemas, geralmente delimitados por requisitos de acesso a dados. Os catálogos geralmente espelham unidades organizacionais ou escopos do ciclo de vida de desenvolvimento de software. É possível escolher, por exemplo, ter um catálogo para dados de produção e outro para dados de desenvolvimento, ou um catálogo para dados não relacionados a clientes e outro para dados sensíveis de clientes.

    Os catálogos podem ser armazenados no nível do metastore ou você pode configurar um catálogo para que ele seja armazenado separadamente do restante do metastore principal. Se o seu workspace foi ativado automaticamente para Unity Catalog, não há armazenamento no nível do metastore e você tem que especificar um local de armazenamento quando criar um catálogo.

    Se o catálogo for a unidade primária de isolamento de dados no modelo de governança de dados do Databricks, o workspace será o ambiente principal para trabalhar com ativos de dados. Os administradores do metastore e proprietários de catálogos podem gerenciar o acesso aos catálogos independentemente dos workspaces, ou podem vincular catálogos a workspaces específicos para garantir que certos tipos de dados sejam processados apenas nesses workspaces. Você pode querer workspaces de produção e desenvolvimento separados, por exemplo, ou um workspace separado para processar dados pessoais.

    Por padrão, as permissões de acesso de um objeto seguro são herdadas pelos elementos secundários desse objeto, com os catálogos no topo da hierarquia. Isso facilita a configuração de regras de acesso padrão para seus dados e a especificação de regras diferentes em cada nível da hierarquia apenas quando necessário.

  • Esquema (banco de dados): esquemas, também conhecidos como bancos de dados, são agrupamentos lógicos de dados tabulares (tabelas e views), dados não tabulares (volumes), funções e modelos de machine learning. Eles oferecem uma maneira de organizar e controlar o acesso aos dados que é mais granular do que os catálogos. Normalmente, eles representam um único caso de uso, projeto ou sandbox de equipe.

    Os esquemas podem ser armazenados no mesmo armazenamento físico que o catálogo principal ou você pode configurar um esquema para ser armazenado separadamente do restante do catálogo principal.

    Os administradores do metastore, os proprietários do catálogo principal e os proprietários do esquema podem gerenciar o acesso aos esquemas.

  • Tabelas: as tabelas residem na terceira camada do namespace de três níveis do Unity Catalog. Elas contêm linhas de dados.

    O Unity Catalog permite criar tabelas gerenciadas e tabelas externas.

    Para tabelas gerenciadas, o Unity Catalog gerencia totalmente o ciclo de vida e o layout dos arquivos. Por padrão, as tabelas gerenciadas são armazenadas no local de armazenamento raiz que você configura ao criar um metastore. Você pode optar por isolar o armazenamento para tabelas gerenciadas nos níveis de catálogo ou esquema.

    Tabelas externas são aquelas cujo ciclo de vida dos dados e o layout dos arquivos são gerenciados usando seu provedor de cloud e outras plataformas de dados, não o Unity Catalog. Normalmente, você usa tabelas externas para registrar grandes volumes dos seus dados existentes, ou se também precisar de acesso de gravação aos dados usando ferramentas fora dos clusters do Databricks e dos SQL warehouses do Databricks. Depois que uma tabela externa é registrada em um metastore do Unity Catalog, você pode gerenciar e auditar o acesso do Databricks a ela da mesma forma que faz com as tabelas gerenciadas.

    Os proprietários do catálogo principal e proprietários de esquemas podem gerenciar o acesso às tabelas, assim como os administradores do metastore (indiretamente).

  • Views: um view é um objeto somente para leitura derivado de uma ou mais tabelas e views em um metastore.

  • Linhas e colunas: o acesso em nível de linha e coluna, juntamente com o mascaramento de dados, é concedido usando visualizações dinâmicas ou filtros de linhas e máscaras de colunas. As visualizações dinâmicas são somente de leitura.

  • Volumes: os volumes residem na terceira camada do namespace de três níveis do Unity Catalog. Eles gerenciam dados não tabulares. Você pode usar volumes para armazenar, organizar e acessar arquivos em qualquer formato, incluindo dados estruturados, semiestruturados e não estruturados. Arquivos em volumes não podem ser registrados como tabelas.

  • Modelos e funções: embora não sejam, estritamente falando, ativos de dados, modelos registrados e funções definidas pelo usuário também podem ser gerenciados no Unity Catalog e residem no nível mais baixo na hierarquia de objetos. Consulte Gerenciar ciclo de vida de modelos no Unity Catalog e Funções definidas pelo usuário (UDFs) no Unity Catalog.

Planeje seu modelo de isolamento de dados

Quando uma organização utiliza uma plataforma de dados como o Databricks, muitas vezes há a necessidade de ter limites de isolamento de dados entre ambientes (como desenvolvimento e produção) ou entre unidades operacionais da organização.

Os padrões de isolamento podem variar para sua organização, mas normalmente incluem as seguintes expectativas:

  • Os usuários só podem ter acesso aos dados com base em regras de acesso especificadas.

  • Os dados podem ser gerenciados apenas por pessoas ou equipes designadas.

  • Os dados são separados fisicamente no armazenamento.

  • Os dados podem ser acessados somente em ambientes designados.

A necessidade de isolamento dos dados pode levar a ambientes isolados que podem dificultar desnecessariamente a governança de dados e a colaboração. O Databricks resolve esse problema usando o Unity Catalog, que oferece várias opções de isolamento de dados e, ao mesmo tempo, mantém uma plataforma unificada de governança de dados. Esta seção aborda as opções de isolamento de dados disponíveis no Databricks e como utilizá-las, independentemente de você preferir um modelo de governança de dados centralizado ou distribuído.

Os usuários só podem ter acesso aos dados com base em regras de acesso especificadas

A maioria das organizações tem requisitos rígidos em relação ao acesso a dados com base em requisitos internos ou regulamentares. Exemplos típicos de dados que devem ser mantidos em segurança incluem informações sobre o salário de funcionários ou informações de pagamentos com cartão de crédito. O acesso a esse tipo de informação normalmente fica sob controle rígido e é auditado periodicamente. O Unity Catalog fornece controle granular sobre ativos de dados dentro do catálogo para atender a esses padrões do setor. Com os controles que o Unity Catalog fornece, os usuários podem ver e consultar apenas os dados que têm direito de ver e consultar.

Os dados só podem ser gerenciados por pessoas ou equipes designadas

O Unity Catalog oferece a capacidade de escolher entre modelos de governança centralizada e distribuída.

No modelo de governança centralizada, seus administradores de governança são proprietários do metastore e podem assumir a propriedade de qualquer objeto, além de conceder e revogar permissões.

Em um modelo de governança distribuída, o catálogo ou um conjunto de catálogos é o domínio de dados. O proprietário desse catálogo pode criar e possuir todos os ativos e gerenciar a governança dentro desse domínio. Os proprietários de um determinado domínio podem operar independentemente dos proprietários de outros domínios.

Independentemente de você escolher o metastore ou os catálogos como seu domínio de dados, o Databricks recomenda enfaticamente que você defina um grupo como administrador do metastore ou proprietário do catálogo.

Propriedade e acesso do Unity Catalog

Os dados são fisicamente separados no armazenamento

Uma organização pode exigir que dados de determinados tipos sejam armazenados em contas ou buckets específicos em seu tenant na nuvem.

O Unity Catalog oferece a capacidade de configurar locais de armazenamento no nível do metastore, catálogo ou esquema para atender a tais requisitos.

Por exemplo, digamos que sua organização tenha uma política de conformidade empresarial que exija que os dados de produção relacionados aos recursos humanos residam no bucket gs://mycompany-hr-prod. No Unity Catalog, você pode atingir esse requisito definindo um local em nível de catálogo, criando um catálogo chamado, por exemplo, hr_prod e atribuindo o local gs://mycompany-hr-prod/unity-catalog a ele. Isso significa que tabelas ou volumes gerenciados criados no catálogo hr_prod (por exemplo, usando CREATE TABLE hr_prod.default.table ) armazenam seus dados em gs://mycompany-hr-prod/unity-catalog. Opcionalmente, você pode optar por fornecer locais em nível de esquema para organizar dados dentro do hr_prod catalog em um nível mais granular.

Caso esse isolamento de armazenamento não seja necessário, você pode definir um local de armazenamento no nível do metastore. O resultado é que esse local serve como um local padrão para armazenar tabelas gerenciadas e volumes em catálogos e esquemas no metastore.

O sistema avalia a hierarquia dos locais de armazenamento do esquema para o catálogo e para o metastore.

Por exemplo, se uma tabela myCatalog.mySchema.myTable for criada em my-region-metastore, o local de armazenamento da tabela será determinado de acordo com a seguinte regra:

  1. Se um local tiver sido fornecido para mySchema, ele será armazenado lá.

  2. Caso contrário, se um local tiver sido fornecido em myCatalog, ele será armazenado lá.

  3. Por fim, se nenhum local tiver sido fornecido em myCatalog, ele será armazenado no local associado a my-region-metastore.

Hierarquia de armazenamento do Unity Catalog

Os dados podem ser acessados somente em ambientes designados

Requisitos organizacionais e de conformidade frequentemente especificam que você mantenha determinados dados, como dados pessoais, acessíveis apenas em ambientes específicos. Você também pode manter os dados de produção isolados dos ambientes de desenvolvimento ou garantir que determinados conjuntos de dados e domínios nunca sejam unidos.

No Databricks, o workspace é o principal ambiente de processamento de dados, e os catálogos são o domínio de dados principal. Unity Catalog permite que administradores de metastore e proprietários de catálogos atribuam ou "vinculem" catálogos a workspaces específicos. Essas associações com reconhecimento de ambiente oferecem a capacidade de garantir que apenas determinados catálogos estejam disponíveis em um workspace, independentemente dos privilégios específicos em objetos de dados concedidos a um usuário.

Agora vamos dar uma olhada mais profunda no processo de configuração do Unity Catalog para atender às suas necessidades.

Configurar um metastore do Unity Catalog

Metastore é o contêiner de alto nível de objetos no Unity Catalog. Metastores gerenciam ativos de dados (tabelas, views e volumes), além de outros objetos protegidos gerenciados pelo Unity Catalog. Para ver a lista completa de objetos protegidos, consulte Objetos protegidos no Unity Catalog.

Esta seção traz dicas para criar e configurar metastores. Se o seu workspace foi habilitado automaticamente para Unity Catalog, você não precisa criar um metastore, mas as informações apresentadas nesta seção podem ser úteis mesmo assim. Consulte Ativação automática do Unity Catalog.

Dicas para configurar metastores:

  • Você deve configurar um metastore para cada região na qual você tem workspaces do Databricks.

    Cada workspace anexado a um único metastore regional tem acesso aos dados gerenciados pelo metastore. Se você quiser compartilhar dados entre metastores, use Delta Sharing.

  • Cada metastore pode ser configurado com um local de armazenamento gerenciado (também chamado de armazenamento raiz) em seu tenant na nuvem, que pode ser usado para armazenar tabelas gerenciadas e volumes gerenciados.

    Se você optar por criar um local gerenciado no nível do metastore, você deve garantir que nenhum usuário tenha acesso direto a ele (ou seja, através da account na nuvem que o contém). Conceder acesso a esse local de armazenamento pode permitir que um usuário ignore os controles de acesso em um metastore do Unity Catalog e interrompa a auditabilidade. Por esses motivos, o armazenamento gerenciado do metastore deve ser um bucket dedicado. Você não deve reutilizar um bucket que também seja seu sistema de arquivos raiz DBFS ou que tenha sido anteriormente um sistema de arquivos raiz DBFS.

    Você também tem a opção de definir o armazenamento gerenciado nos níveis de catálogo e esquema, substituindo o local de armazenamento raiz do metastore. Na maioria dos cenários, o Databricks recomenda armazenar dados gerenciados no nível do catálogo.

  • Você deve conhecer os privilégios dos administradores de workspace em workspaces habilitados para o Unity Catalog e revisar suas atribuições de administrador de workspace existentes.

    Os administradores de workspace podem gerenciar operações para seu workspace, inclusive adicionar usuários e entidades de serviço, criar clusters e delegar outros usuários para serem administradores de workspaces. Se o seu workspace foi ativado para Unity Catalog automaticamente, os administradores do workspace podem criar catálogos e muitos outros objetos do Unity Catalog por padrão. Consulte Privilégios de administrador do workspace quando os workspaces são ativados automaticamente para Unity Catalog

    Os administradores do workspace podem também executar tarefas de gerenciamento do workspace, como por exemplo gerenciar a propriedade do job e ver notebooks, o que pode dar acesso indireto aos dados registrados no Unity Catalog. A função de administrador do workspace é uma função privilegiada que você deve distribuir com cautela.

  • Se você utilizar workspaces para isolar o acesso aos dados do usuário, talvez tenha que utilizar ligações entre catálogo e workspace. As ligações de catálogo de workspace possibilitam a limitação do acesso ao catálogo por limites de workspace. Por exemplo, você pode garantir que os administradores e os usuários do workspace possam acessar somente dados de produção em prod_catalog de um ambiente de workspace de produção, prod_workspace. O padrão é compartilhar o catálogo com todos os workspaces anexados ao metastore atual. Consulte Limitar o acesso do catálogo a espaços de trabalho específicos.

    Se o workspace foi habilitado para o Unity Catalog automaticamente, o catálogo de workspaces pré-provisionado será vinculado ao seu workspace por padrão.

Consulte Criar um metastore do Unity Catalog.

Configurar locais externos e credenciais de armazenamento

Locais externos permitem que o Unity Catalog leia e grave dados em seu tenant de nuvem em nome dos usuários. Os locais externos são definidos como um caminho para o armazenamento em nuvem, combinado com uma credencial de armazenamento que pode ser usada para acessar esse local.

Você pode usar locais externos para registrar tabelas externas e volumes externos no Unity Catalog. O conteúdo dessas entidades está localizado fisicamente em um subcaminho em um local externo que é referenciado quando um usuário cria o volume ou a tabela.

Uma credencial de armazenamento encapsula uma credencial de nuvem de longo prazo que oferece acesso ao armazenamento em nuvem. Por exemplo, no GCP, você pode configurar uma account serviço e conceder a ela acesso baseado em função a um bucket do GCS.

Para maior isolamento de dados, você pode vincular credenciais de armazenamento e locais externos a áreas de trabalho específicas. Consulte (Opcional) Atribuir um local externo a workspaces específicos e (Opcional) Atribuir uma credencial de armazenamento a workspaces específicos.

Dica

Os locais externos, combinando credenciais de armazenamento e caminhos de armazenamento, oferecem forte controle e auditabilidade do acesso ao armazenamento. Para evitar que os usuários contornem o controle de acesso fornecido pelo Unity Catalog, limite o número de usuários com acesso direto a qualquer bucket que esteja em uso como local externo. Pelo mesmo motivo, você não deve montar accounts de armazenamento no DBFS se elas também estiverem sendo usadas como locais externos. A Databricks recomenda que você migre montagens em locais de armazenamento em cloud para locais externos no Unity Catalog usando o Explorador de Catálogos.

Para obter uma lista de práticas recomendadas para gerenciar external locations , consulte Gerenciar external locations, external tables e volumes externos. Confira também Criar uma external location para conectar o armazenamento em nuvem ao Databricks.

Organizar seus dados

A Databricks recomenda o uso de catálogos para oferecer segregação em toda a arquitetura de informações da organização. Muitas vezes isso significa que os catálogos correspondem a um escopo, uma equipe ou uma unidade de negócios do ambiente de desenvolvimento de software. Se você utilizar workspaces como uma ferramenta de isolamento de dados, por exemplo, utilizar diferentes workspaces para ambientes de produção e desenvolvimento ou um workspace específico para trabalhar com dados altamente sensíveis, também poderá vincular um catálogo a workspaces específicos. Isso garante que todo o processamento de dados especificados seja tratado no workspace apropriado. Consulte Limitar o acesso ao catálogo a áreas de trabalho específicas.

Catálogos do Unity Catalog

Um esquema (também chamado de base de dados) é a segunda camada do namespace de três níveis do Unity Catalog e organiza tabelas, visualizações e volumes. Você pode usar esquemas para organizar e definir permissões para seus ativos.

Os objetos regidos pelo Unity Catalog podem ser gerenciados ou externos:

  • Objetos gerenciados são a maneira padrão de criar objetos de dados no Unity Catalog.

    O Unity Catalog gerencia o ciclo de vida e a disposição do arquivo para esses itens protegidos. Não utilize ferramentas fora do Databricks para manipular arquivos em tabelas gerenciadas ou volumes diretamente.

    As tabelas e os volumes gerenciados são armazenados no armazenamento gerenciado, que pode existir no nível do metastore, do catálogo ou do esquema para qualquer tabela ou volume específico. Consulte Os dados são fisicamente separados no armazenamento.

    Tabelas e volumes gerenciados são uma solução conveniente quando você deseja provisionar um local controlado para seu conteúdo sem a sobrecarga de criar e gerenciar locais externos e credenciais de armazenamento.

    As tabelas gerenciadas sempre usam o formato de tabela Delta.

  • Os objetos externos são objetos protegidos cujo ciclo de vida dos dados e layout de arquivo não são gerenciados pelo Unity Catalog.

    Os volumes e tabelas externos são registrados em um local externo para disponibilizar acesso a um grande número de arquivos que já existem no armazenamento na nuvem sem necessidade de copiar os dados. Utilize objetos externos caso tenha arquivos produzidos por outros sistemas e queira que eles sejam preparados para acesso dentro do Databricks, ou quando ferramentas fora do Databricks exigirem acesso direto a esses arquivos.

    As tabelas externas são compatíveis com Delta Lake e muitos outros formatos de dados, incluindo Parquet, JSON e CSV. Os volumes gerenciados e externos podem ser usados para acessar e armazenar arquivos de formatos arbitrários: os dados podem ser estruturados, semiestruturados ou não estruturados.

Para obter mais informações sobre a criação de tabelas e volumes, consulte O que são tabelas e visualizações? e What are Unity Catalog volumes (O que são volumes do Unity Catalog?).

Gerenciar locais externos, tabelas externas e volumes externos

O diagrama abaixo representa a hierarquia do sistema de arquivos de um único bucket de armazenamento em nuvem, com quatro locais externos que compartilham uma credencial de armazenamento.

Locais externos

Depois de ter locais externos configurados no Unity Catalog, você pode criar tabelas e volumes externos em diretórios dentro dos locais externos. Em seguida, pode usar o Unity Catalog para gerenciar o acesso de usuários e grupos a essas tabelas e volumes. Isso permite que você forneça a usuários ou grupos específicos acesso a diretórios e arquivos específicos no bucket de armazenamento em nuvem.

Observação

Ao definir um volume, o acesso via URI da nuvem aos dados sob o caminho do volume é regido pelas permissões do volume.

Recomendações para o uso de locais externos

Recomendações para conceder permissões em locais externos:

  • Conceda a capacidade de criar locais externos 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.

    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 (gs://mybucket) ou um subcaminho amplo (gs://mybucket/alotofdata). 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 para um administrador de 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 sob o 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.

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

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

    Com a disponibilidade de volumes, 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.

    Os volumes oferecem suporte para trabalhar com arquivos usando comandos SQL, dbutils, APIs Spark, APIs REST, Terraform e uma interface de usuário para navegar, carregar e baixar arquivos. Além disso, os volumes oferecem um suporte FUSE acessível no sistema de arquivos local em /Volumes/<catalog_name>/<schema_name>/<volume_name>/. O suporte 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 machine learning ou 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.

Você deve usar locais externos para fazer o seguinte:

  • Registre tabelas e volumes externos utilizando os comandos CREATE EXTERNAL VOLUME ou CREATE TABLE.

  • Explore os arquivos existentes no armazenamento em nuvem antes de criar uma tabela ou volume externo com um prefixo específico. O privilégio de READ FILES é uma pré-condição.

  • Registre um local como armazenamento gerenciado para catálogos e esquemas em vez do bucket raiz do metastore. O privilégio de CREATE MANAGED STORAGE é uma pré-condição.

Mais recomendações para usar locais externos:

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

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

Recomendações para usar volumes externos

Você deve usar volumes externos para fazer o seguinte:

  • Registre áreas de destino para dados brutos produzidos por sistemas externos para apoiar seu processamento nos estágios iniciais de pipelines de ETL e outras atividades de engenharia de dados.

  • Registre locais de preparação para ingestão, por exemplo, usando instruções de Auto Loader, COPY INTO ou CTAS (CREATE TABLE AS).

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

  • Conceda aos usuários do 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 Python wheel) exportados de sistemas locais de gerenciamento de dependências ou pipelines de CI/CD.

  • Armazene dados operacionais, como arquivos de registro ou de pontos de verificação, quando volumes gerenciados não forem 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— utilize volumes externos. Use tabelas externas quando quiser consultar dados no local como uma tabela, sem nenhuma cópia envolvida.

Recomendações para o uso de tabelas externas

Você deve usar tabelas externas para permitir padrões de consulta normais sobre os dados no armazenamento em nuvem, quando criar tabelas gerenciadas não for uma opção.

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

  • Databricks recomenda que você crie tabelas externas usando um local externo por esquema.

  • O Databricks não recomenda 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 Delta Sharing para compartilhar dados entre metastores. Veja Compartilhar dados com segurança usando o Delta Sharing.

Configurar o controle de acesso

Cada objeto protegível no Unity Catalog tem um proprietário. A entidade que cria um objeto se torna seu proprietário inicial. O proprietário de um objeto tem todos os privilégios sobre ele, como SELECIONAR e MODIFICAR em uma tabela, bem como a permissão para conceder privilégios sobre o objeto protegível a outras entidades. Somente os proprietários de um objeto protegível têm permissão para conceder privilégios sobre esse objeto a outras entidades. Portanto, é uma prática recomendada configurar a propriedade de todos os objetos para o grupo responsável pela administração de concessões no objeto. Tanto o proprietário quanto os administradores de metastore podem transferir a propriedade de um objeto protegível para um grupo. Além disso, se o objeto estiver contido em um catálogo (como uma tabela ou view), o proprietário do catálogo e do esquema poderá alterar a propriedade do objeto.

Os objetos protegíveis no Unity Catalog são hierárquicos, e os privilégios são herdados para baixo. Isso significa que conceder um privilégio em um catálogo ou esquema concede automaticamente o privilégio a todos os objetos atuais e futuros dentro do catálogo ou esquema. Para obter mais informações, consulte Modelo de herança.

Para ler dados de uma tabela ou view, um usuário deve ter os seguintes privilégios:

  • SELECT na tabela ou view

  • USE SCHEMA no esquema que detém a tabela

  • USE CATALOG no catálogo que detém o esquema

USE CATALOG permite que o beneficiário percorra o catálogo para acessar seus objetos filhos e USE SCHEMA permite que o beneficiário percorra o esquema para acessar seus objetos filhos. Por exemplo, para selecionar dados de uma tabela, os usuários precisam ter o privilégio SELECT nessa tabela e o privilégio USE CATALOG em seu catálogo pai, juntamente com o privilégio USE SCHEMA em seu esquema pai. Portanto, você pode usar esse privilégio para restringir o acesso a seções do seu namespace de dados a grupos específicos. Um cenário comum é configurar um esquema por equipe em que somente essa equipe tem USE SCHEMA e CREATE no esquema. Isso significa que todas as tabelas produzidas pelos membros da equipe só podem ser compartilhadas dentro da equipe.

Você pode proteger o acesso a uma tabela utilizando a seguinte sintaxe SQL:

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

Você pode proteger o acesso a colunas usando uma exibição dinâmica em um esquema secundário, como mostrado na seguinte sintaxe SQL:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

Você pode proteger o acesso às linhas usando uma exibição dinâmica em um esquema secundário, conforme mostrado na seguinte sintaxe SQL:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

Você também pode conceder aos usuários o acesso seguro às tabelas com filtros de linha e máscaras de coluna. Para mais informações, consulte Filtrar dados de tabela confidenciais com filtros de linha e máscaras de coluna.

Para obter mais informações sobre todos os privilégios no Unity Catalog, consulte Gerenciar privilégios no Unity Catalog.

Gerenciar configurações de cluster

O Databricks recomenda usar políticas de clusters para limitar a capacidade de configurar clusters com base em um conjunto de regras. As políticas de clusters permitem restringir o acesso para criar apenas clusters habilitados para o Unity Catalog. O uso de políticas de clusters reduz as opções disponíveis, o que simplifica muito o processo de criação de clusters para os usuários e garante que eles possam acessar os dados sem problemas. As políticas de clusters também permitem controlar o custo limitando o custo máximo por cluster.

Para garantir a integridade dos controles de acesso e impor fortes garantias de isolamento, o Unity Catalog impõe requisitos de segurança aos recursos computacionais. Por isso o Unity Catalog introduz o conceito do modo de acesso de um cluster. O Unity Catalog é seguro por padrão. Se um cluster não estiver configurado com um modo de acesso apropriado, o cluster não poderá acessar os dados no Unity Catalog. Consulte Requisitos de computação.

A Databricks recomenda utilizar o modo de acesso compartilhado para compartilhar um cluster e o modo de acesso de usuário único para trabalhos automatizados e cargas de trabalho de aprendizado de máquina.

O JSON abaixo fornece uma definição de política para um cluster com o modo de acesso compartilhado:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

O JSON abaixo apresenta uma definição de política para um cluster de trabalho automatizado com o modo de acesso Single User:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

Acesso para auditoria

Uma solução completa de governança de dados exige a auditoria do acesso aos dados e a disponibilização de recursos de alerta e monitoramento. O Unity Catalog captura um log de auditoria das ações executadas no metastore, que é entregue como parte dos logs de auditoria do Databricks.

Você pode acessar os logs de auditoria da sua account usando system tables. Para mais informações sobre a system table de logs de auditoria, consulte Referência da system table de logs de auditoria.

Consulte Monitorando sua plataforma de inteligência de dados do Databricks com logs de auditoria para obter detalhes sobre como obter visibilidade completa de eventos críticos relacionados à sua plataforma de inteligência de dados do Databricks.

Compartilhar dados em segurança com Delta Sharing

O Delta Sharing é um protocolo aberto desenvolvido pela Databricks para compartilhamento seguro de dados com outras organizações ou outros departamentos da sua organização, independentemente das plataformas de computação usadas. Quando o Delta Sharing está habilitado em um metastore, o Unity Catalog executa um servidor do Delta Sharing.

Para compartilhar dados entre metastores, você pode aproveitar o Delta Sharing Databricks-to-Databricks. Isso permite que você registre tabelas de metastores em diferentes regiões. Essas tabelas aparecerão como objetos somente leitura no metastore de consumo. Essas tabelas podem receber acesso como qualquer outro objeto dentro do Unity Catalog.

Quando você usar o Delta Sharing Databricks-to-Databricks para compartilhamento entre metastores, lembre-se de que o controle de acesso é limitado a um metastore. Se um objeto protegível, como uma tabela, tiver concessões e esse recurso for compartilhado com um metastore dentro da conta, as concessões da origem não serão aplicadas ao compartilhamento de destino. O compartilhamento de destino terá que definir suas próprias concessões.