Melhores práticas do Unity Catalog

Este documento fornece recomendações para usar o Unity Catalog e o 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. A Partilha Delta é uma plataforma segura de partilha de dados que lhe permite partilhar dados no Azure Databricks com utilizadores fora da sua organização. Ele usa o Unity Catalog para gerenciar e auditar o comportamento de compartilhamento.

Blocos de construção de governança e isolamento de dados

Para desenvolver um modelo de governança de dados e um plano de isolamento de dados que funcione para sua organização, ele ajuda a entender os principais blocos de construção que estão disponíveis para você quando você cria sua solução de governança de dados no Azure Databricks.

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

Os objetos nessa hierarquia incluem o seguinte:

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

  Os metastores gerenciam ativos de dados (tabelas, exibições e volumes) e as permissões que controlam o acesso a eles. Os administradores de conta do Azure Databricks podem criar um metastore para cada região em que operam e atribuí-los a vários espaços de trabalho do Azure Databricks na mesma região. Os administradores do Metastore podem gerenciar todos os objetos no metastore. Eles não têm 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 do objeto de dados.

  O armazenamento físico de qualquer metastore é, por padrão, isolado do armazenamento de qualquer outro metastore em 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: Os catálogos são o nível mais alto na hierarquia de dados (tabela/visualização/volume do esquema > de catálogo>) gerenciada pelo metastore do Catálogo Unity. Eles são destinados como a unidade primária de isolamento de dados em um modelo típico de governança de dados do Azure Databricks.

  Os catálogos representam um agrupamento lógico de esquemas, geralmente limitados por requisitos de acesso a dados. Os catálogos geralmente espelham unidades organizacionais ou escopos do ciclo de vida de desenvolvimento de software. Você pode escolher, por exemplo, ter um catálogo para dados de produção e um catálogo para dados de desenvolvimento, ou um catálogo para dados de não clientes e um para dados confidenciais de clientes.

  Os catálogos podem ser armazenados no nível do metastore ou você pode configurar um catálogo para ser armazenado separadamente do restante do metastore pai. Se seu espaço de trabalho foi habilitado para o Unity Catalog automaticamente, não há armazenamento no nível de metastore e você deve especificar um local de armazenamento ao 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 Azure Databricks, o espaço de trabalho será o ambiente principal para trabalhar com ativos de dados. Os administradores de metastore e os proprietários de catálogos podem gerenciar o acesso a catálogos independentemente dos espaços de trabalho ou podem vincular catálogos a espaços de trabalho específicos para garantir que certos tipos de dados sejam processados somente nesses espaços de trabalho. Você pode querer espaços de trabalho de produção e desenvolvimento separados, por exemplo, ou um espaço de trabalho separado para processar dados pessoais.

  Por padrão, as permissões de acesso para um objeto protegível são herdadas pelos filhos desse objeto, com catálogos na parte superior 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 onde você precisar delas.

• Esquema (Banco de Dados): Os esquemas, também conhecidos como bancos de dados, são agrupamentos lógicos de dados tabulares (tabelas e exibições), dados não tabulares (volumes), funções e modelos de aprendizado de máquina. Eles oferecem uma maneira de organizar e controlar o acesso a dados que é mais granular do que catálogos. Normalmente, eles representam um único caso de uso, projeto ou área restrita de equipe.

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

  Administradores de metastore, proprietários de catálogos pai e proprietários de esquemas podem gerenciar o acesso a esquemas.

• Tabelas: as tabelas residem na terceira camada do namespace de três níveis do Unity Catalog. Eles 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 do arquivo. Por padrão, as tabelas gerenciadas são armazenadas no local de armazenamento raiz que você configura ao criar um metastore. Em vez disso, você pode optar por isolar o armazenamento para tabelas gerenciadas nos níveis de catálogo ou esquema.

  As tabelas externas são tabelas cujo ciclo de vida de dados e layout de arquivo são gerenciados usando seu provedor de nuvem e outras plataformas de dados, não o Catálogo Unity. Normalmente, você usa tabelas externas para registrar grandes quantidades de seus dados existentes ou se também precisar de acesso de gravação aos dados usando ferramentas fora dos clusters do Azure Databricks e dos armazéns SQL do Databricks. Depois que uma tabela externa é registrada em um metastore do Catálogo Unity, você pode gerenciar e auditar o acesso do Azure Databricks a ela da mesma forma que pode fazer com tabelas gerenciadas.

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

• Modos de exibição: um modo de exibição é um objeto somente leitura derivado de uma ou mais tabelas e exibições em um metastore.

• Linhas e colunas: o acesso em nível de linha e coluna, juntamente com o mascaramento de dados, é concedido usando modos de exibição dinâmicos ou filtros de linha e máscaras de coluna. As vistas dinâmicas são só 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 residir no nível mais baixo na hierarquia de objetos. Consulte Gerenciar o ciclo de vida do modelo 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 usa uma plataforma de dados como o Azure Databricks, muitas vezes há a necessidade de ter limites de isolamento de dados entre ambientes (como desenvolvimento e produção) ou entre unidades operacionais organizacionais.

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

• Os usuários só podem obter acesso aos dados com base em regras de acesso especificadas.
• Os dados só podem ser geridos por pessoas ou equipas designadas.
• Os dados são fisicamente separados no armazenamento.
• Os dados podem ser acessados apenas em ambientes designados.

A necessidade de isolamento de dados pode levar a ambientes em silos que podem dificultar desnecessariamente a governança e a colaboração de dados. O Azure Databricks resolve esse problema usando o Unity Catalog, que fornece várias opções de isolamento de dados enquanto mantém uma plataforma unificada de governança de dados. Esta seção discute as opções de isolamento de dados disponíveis no Azure Databricks e como usá-las, quer você prefira um modelo de governança de dados centralizado ou distribuído.

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

A maioria das organizações tem requisitos rigorosos em relação ao acesso a dados com base em requisitos internos ou regulamentares. Exemplos típicos de dados que devem ser mantidos seguros incluem informações salariais de funcionários ou informações de pagamento de cartão de crédito. O acesso a este tipo de informação é normalmente rigorosamente controlado e auditado periodicamente. O Unity Catalog fornece controle granular sobre os 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 a ver e consultar.

Os dados só podem ser geridos por pessoas ou equipas designadas

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

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 e 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 qualquer domínio podem operar independentemente dos proprietários de outros domínios.

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

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 locatário de nuvem.

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

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

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

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

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

1. Se um local tiver sido fornecido mySchema, ele será armazenado lá.
2. Se não, e um local foi fornecido no myCatalog, ele será armazenado lá.
3. Finalmente, se nenhum local tiver sido fornecido no myCatalog, ele será armazenado no local associado my-region-metastoreao .

Os dados só podem ser acedidos em ambientes designados

Os requisitos organizacionais e de conformidade geralmente especificam que você mantenha determinados dados, como dados pessoais, acessíveis apenas em determinados ambientes. Você também pode querer 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 espaço de trabalho é o ambiente de processamento de dados primário e os catálogos são o domínio de dados primário. O Unity Catalog permite que administradores de metalojas e proprietários de catálogos atribuam ou "vinculem" catálogos a espaços de trabalho específicos. Essas associações com reconhecimento de ambiente oferecem a capacidade de garantir que apenas determinados catálogos estejam disponíveis em um espaço de trabalho, 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

Um metastore é o contêiner de nível superior de objetos no Unity Catalog. Os metastores gerenciam ativos de dados (tabelas, exibições e volumes), bem como outros objetos protegíveis gerenciados pelo Unity Catalog. Para obter a lista completa de objetos protegíveis, consulte Objetos protegíveis no Unity Catalog.

Esta seção fornece dicas para criar e configurar metastores. Se seu espaço de trabalho foi habilitado automaticamente para o Unity Catalog, você não precisa criar um metastore, mas as informações apresentadas nesta seção ainda podem ser úteis. Veja Ativação automática do Unity Catalog.

Dicas para configurar metastores:

• Você deve configurar um metastore para cada região na qual você tem espaços de trabalho do Azure Databricks.

  Cada espaço de trabalho anexado a um único metastore regional tem acesso aos dados gerenciados pelo metastore. Se você quiser compartilhar dados entre metastores, use o Compartilhamento Delta.

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

  Se você optar por criar um local gerenciado no nível de metastore, deverá garantir que nenhum usuário tenha acesso direto a ele (ou seja, por meio da conta de nuvem que o contém). Dar 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 contêiner dedicado. Você não deve reutilizar um contêiner 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 o armazenamento de dados gerenciados no nível do catálogo.

• Você deve entender os privilégios dos administradores de espaço de trabalho em espaços de trabalho habilitados para o Catálogo Unity e revisar suas atribuições de administrador de espaço de trabalho existentes.

  Os administradores de espaço de trabalho podem gerenciar operações para seu espaço de trabalho, incluindo a adição de usuários e entidades de serviço, a criação de clusters e a delegação de outros usuários para serem administradores de espaço de trabalho. Se seu espaço de trabalho foi habilitado para o Unity Catalog automaticamente, os administradores do espaço de trabalho têm a capacidade de criar catálogos e muitos outros objetos do Unity Catalog por padrão. Consulte Privilégios de administrador do espaço de trabalho quando os espaços de trabalho são habilitados para o Unity Catalog automaticamente

  Os administradores de espaço de trabalho também têm a capacidade de executar tarefas de gerenciamento de espaço de trabalho, como gerenciar a propriedade do trabalho e visualizar blocos de anotações, o que pode dar acesso indireto aos dados registrados no Catálogo Unity. O administrador do espaço de trabalho é uma função privilegiada que você deve distribuir com cuidado.

• Se você usar espaços de trabalho para isolar o acesso aos dados do usuário, convém usar associações de catálogo de espaço de trabalho. As associações de catálogo de espaço de trabalho permitem limitar o acesso ao catálogo por limites de espaço de trabalho. Por exemplo, você pode garantir que os administradores e usuários do espaço de trabalho só possam acessar dados de produção em prod_catalog um ambiente de espaço de trabalho de produção, prod_workspace. O padrão é compartilhar o catálogo com todos os espaços de trabalho anexados ao metastore atual. Consulte Limitar o acesso do catálogo a espaços de trabalho específicos.

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

Consulte Criar um metastore do Catálogo Unity.

Configurar locais externos e credenciais de armazenamento

Os locais externos permitem que o Unity Catalog leia e grave dados em seu locatário 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á fisicamente localizado 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 fornece acesso ao armazenamento em nuvem. Pode ser uma identidade gerenciada do Azure (altamente recomendada) ou uma entidade de serviço. Usar uma identidade gerenciada do Azure tem os seguintes benefícios em relação ao uso de uma entidade de serviço:

• As identidades gerenciadas não exigem que você mantenha credenciais ou alterne segredos.
• Se seu espaço de trabalho do Azure Databricks for implantado em sua própria VNet (também conhecida como injeção de VNet), você poderá se conectar a uma conta do Azure Data Lake Storage Gen2 protegida por um firewall de armazenamento.

Para aumentar o isolamento de dados, você pode vincular credenciais de serviço, credenciais de armazenamento e locais externos a espaços de trabalho específicos. Consulte (Opcional) Atribuir uma credencial de serviço a espaços de trabalho específicos, (Opcional) Atribuir um local externo a espaços de trabalho específicos e (Opcional) Atribuir uma credencial de armazenamento a espaços de trabalho específicos.

Gorjeta

Os locais externos, combinando credenciais de armazenamento e caminhos de armazenamento, fornecem um forte controle e auditabilidade do acesso ao armazenamento. Para evitar que os usuários ignorem o controle de acesso fornecido pelo Unity Catalog, você deve limitar o número de usuários com acesso direto a qualquer contêiner que esteja sendo usado como um local externo. Pelo mesmo motivo, você não deve montar contas de armazenamento no 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.

Para obter uma lista de práticas recomendadas para gerenciar locais externos, consulte Gerenciar locais externos, tabelas externas e volumes externos. Consulte também Criar um local externo para conectar o armazenamento em nuvem ao Azure Databricks.

Organize os seus dados

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

Um esquema (também chamado de banco de dados) é a segunda camada do namespace de três níveis do Unity Catalog e organiza tabelas, exibiçõ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:

• Os 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 o layout de arquivos para esses protegíveis. Você não deve usar ferramentas fora do Azure Databricks para manipular arquivos em tabelas ou volumes gerenciados diretamente.

  As tabelas e volumes gerenciados são armazenados em armazenamento gerenciado, que pode existir no nível de metastore, catálogo ou esquema para qualquer tabela ou volume. Consulte Os dados estã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 protegíveis cujo ciclo de vida de dados e layout de arquivo não são gerenciados pelo Unity Catalog.

  Volumes e tabelas externos são registrados em um local externo para fornecer acesso a um grande número de arquivos que já existem no armazenamento em nuvem sem exigir atividade de cópia de dados. Use objetos externos quando tiver arquivos produzidos por outros sistemas e quiser que eles sejam preparados para acesso de dentro do Azure Databricks ou quando ferramentas fora do Azure Databricks exigirem acesso direto a esses arquivos.

  As tabelas externas suportam 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 como criar tabelas e volumes, consulte O que são tabelas e exibições? e O que são volumes do Catálogo Unity?.

Gerenciar locais externos, tabelas externas e volumes externos

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

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, você 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 contêiner de armazenamento em nuvem.

Nota

Quando você define um volume externo, o acesso 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.

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.

  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 (abfss://my-container@storage-account.dfs.core.windows.net) inteiro ou um subcaminho amplo (abfss://my-container@storage-account.dfs.core.windows.net/path/to/subdirectory). 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.

  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 fornecem suporte para trabalhar com arquivos usando comandos SQL, dbutils, APIs Spark, APIs REST, Terraform e uma interface de usuário para navegação, upload e download de 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 WRITE FILES são raros.

Você deve usar locais externos para fazer o seguinte:

• Registre tabelas e volumes externos usando os CREATE EXTERNAL VOLUME comandos or CREATE TABLE .
• 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.
• Registre um local como armazenamento gerenciado para catálogos e esquemas em vez do bucket raiz do metastore. O CREATE MANAGED STORAGE privilégio é uma condição prévia.

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

Recomendações para o uso de volumes externos

Você deve usar volumes externos para fazer o seguinte:

• Registrar áreas de aterrissagem para dados brutos produzidos por sistemas externos para apoiar seu processamento nos estágios iniciais de pipelines ETL e outras atividades de engenharia de dados.
• Registre locais de preparo para ingestão, por exemplo, usando instruções Auto Loader COPY INTOou CTAS (CREATE TABLE AS).
• 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.
• Dê 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.
• Armazene dados operacionais, como arquivos de registro em log ou de ponto de verificação, quando os volumes gerenciados não forem 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.

Gorjeta

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.

Recomendações para o uso de tabelas externas

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

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 Compartilhar dados com segurança usando o Delta Sharing.

Configurar o controlo de acesso

Cada objeto protegível no Unity Catalog tem um proprietário. A entidade que cria um objeto torna-se seu proprietário inicial. O proprietário de um objeto tem todos os privilégios no objeto, como SELECT e MODIFY em uma tabela, bem como a permissão para conceder privilégios no objeto protegível a outras entidades de segurança. Somente os proprietários de um objeto protegível têm permissão para conceder privilégios sobre esse objeto a outras entidades de segurança. Portanto, é uma prática recomendada configurar a propriedade em todos os objetos para o grupo responsável pela administração de concessões no objeto. Tanto o proprietário quanto os administradores do 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 exibição), o proprietário do catálogo e do esquema poderá alterar a propriedade do objeto.

Os objetos com capacidade de segurança no Catálogo Unity são hierárquicos e os privilégios são herdados para baixo. Isto significa que a concessão de um privilégio num 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 exibição, um usuário deve ter os seguintes privilégios:

• SELECT sobre a mesa ou vista
• USE SCHEMA no esquema proprietário da tabela
• USE CATALOG no catálogo que possui o esquema

USE CATALOG permite que o beneficiário percorra o catálogo para acessar seus objetos filho e permite que o beneficiário percorra USE SCHEMA o esquema para acessar seus objetos filho. Por exemplo, para selecionar dados de uma tabela, os usuários precisam ter o SELECT privilégio nessa tabela e o USE CATALOG privilégio em seu catálogo pai, juntamente com o USE SCHEMA privilégio 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 onde apenas 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 usando 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, conforme 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 a 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 acesso seguro a tabelas usando filtros de linha e máscaras de coluna. Para obter mais informações, consulte Filtrar dados confidenciais da tabela usando filtros de linha e máscaras de coluna.

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

Gerenciar configurações de cluster

O Databricks recomenda o uso de políticas de cluster para limitar a capacidade de configurar clusters com base em um conjunto de regras. As políticas de cluster permitem restringir o acesso apenas para criar clusters habilitados para Unity Catalog. O uso de políticas de cluster reduz as opções disponíveis, o que simplificará muito o processo de criação de cluster para os usuários e garantirá que eles possam acessar os dados sem problemas. As políticas de cluster 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 de computação. Por esse motivo, o Unity Catalog introduz o conceito de 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 dados no Unity Catalog. Consulte Requisitos de computação.

O Databricks recomenda o uso do modo de acesso compartilhado ao 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 fornece uma definição de política para um cluster de tarefas automatizado com o modo de acesso de usuário único:

{
"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 à auditoria

Uma solução completa de governança de dados requer auditar o acesso aos dados e fornecer recursos de alerta e monitoramento. O Unity Catalog captura um log de auditoria de ações executadas no metastore e esses logs são entregues como parte dos logs de auditoria do Azure Databricks.

Você pode acessar os logs de auditoria da sua conta usando tabelas do sistema. Para obter mais informações sobre a tabela do sistema de log de auditoria, consulte Referência da tabela do sistema de log de auditoria.

Consulte Monitorando sua plataforma de inteligência de dados 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 Databricks.

Compartilhe dados com segurança usando o Delta Sharing

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

Para compartilhar dados entre metastores, você pode aproveitar o Databricks-to-Databricks Delta Sharing. 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 ter acesso como qualquer outro objeto dentro do Unity Catalog.

Ao usar o Compartilhamento Delta de Databricks para Databricks para compartilhar 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 se aplicarão ao compartilhamento de destino. A quota de destino terá de definir as suas próprias subvenções.

Mais informações

• Configurar e gerir o Catálogo Unity
• O que é o Delta Sharing?
• Atualizar tabelas e exibições do Hive para o Catálogo Unity