Melhores práticas do Catálogo do Unity

Este documento fornece recomendações para usar o Catálogo do Unity e Compartilhamento Delta para atender às suas necessidades de governança de dados.

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

Blocos de criação da governança e do 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 disponíveis 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 Catálogo do Unity (alguns objetos protegíveis são esmaecidos para enfatizar a hierarquia dos objetos gerenciados em catálogos).

Unity Catalog object model diagram

Os objetos nessa hierarquia incluem o seguinte:

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

    Os metastores gerenciam os ativos de dados (tabelas, exibições e volumes) e as permissões que regem 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 workspaces 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 para qualquer metastore especificado é, por padrão, isolado do armazenamento para qualquer outro metastore em sua conta.

    Os metastores fornecem isolamento regional, mas não se destinam como 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 (catálogo > esquema > tabela/exibição/volume) gerenciado pelo metastore do Catálogo do Unity. Elas são destinadas 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 espelho 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 não cliente e um para dados confidenciais do cliente.

    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 Catálogo do Unity automaticamente, não haverá armazenamento no nível do metastore e você deve especificar um local de armazenamento quando criar um catálogo.

    Se o catálogo for a principal unidade de isolamento de dados no modelo de governança de dados do Azure Databricks, o espaço de trabalho será o principal ambiente para trabalhar com ativos de dados. Os administradores do Metastore e os proprietários de catálogo podem gerenciar o acesso a catálogos independentemente de workspaces ou associar catálogos a workspaces específicos para garantir que determinados tipos de dados sejam processados somente nesses workspaces. Talvez você queira espaços de trabalho separados para produção e desenvolvimento, por exemplo, ou um espaço de trabalho separado para o processamento de 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 somente onde você precisa delas.

  • Esquema (Banco de Dados): 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 mais granulares do que catálogos. Normalmente, eles representam um único caso de uso, projeto ou área restrita da equipe.

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

    Administradores do Metastore, proprietários de catálogo pai e proprietários de esquema podem gerenciar o acesso a esquemas.

  • Tabelas: Tabelas residem na terceira camada do namespace de três níveis do Catálogo do Unity. Elas contêm linhas de dados.

    O Catálogo do Unity permite criar tabelas gerenciadas e tabelas externas.

    Para tabelas gerenciadas, o Catálogo do Unity 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ê configurou quando criou o metastore. Em vez disso, você pode optar por isolar o armazenamento para tabelas gerenciadas nos níveis de catálogo ou esquema.

    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 do Unity. Normalmente, você usa tabelas externas para registrar grandes quantidades de dados existentes ou se também precisar de acesso de gravação aos dados usando ferramentas fora dos clusters do Azure Databricks e warehouses SQL do Databricks. Depois que uma tabela externa é registrada em um metastore do Catálogo do Unity, você pode gerenciar e auditar o acesso do Azure Databricks a ela da mesma forma que você pode com tabelas gerenciadas.

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

  • Exibições: Uma 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 a máscara de dados, é concedido usando exibições dinâmicas ou filtros de linha e máscaras de coluna. Exibições dinâmicas são somente leitura.

  • Volumes: os volumes residem na terceira camada do namespace de três níveis do Catálogo do Unity. 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. Os arquivos em volumes não podem ser registrados como tabelas.

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

Planeje seu modelo de isolamento de dados

Quando uma organização usa uma plataforma de dados como o Azure Databricks, geralmente é necessário 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 de acordo com sua organização, mas normalmente incluem as seguintes expectativas:

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

A necessidade de isolamento de dados pode levar a ambientes isolados que podem dificultar a governança de dados e a colaboração desnecessariamente. O Azure Databricks resolve esse problema usando o Catálogo do Unity, que fornece várias opções de isolamento de dados, mantendo 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 nas regras de acesso especificadas

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

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

O Catálogo do Unity oferece a capacidade de escolher entre modelos de governança centralizados e distribuídos.

No modelo de governança centralizado, os administradores de governança são proprietários do metastore e podem se apropriar de qualquer objeto e conceder e revogar permissões.

Em um modelo de governança distribuído, 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 determinado 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 fortemente que você defina um grupo como o administrador do metastore ou o proprietário do catálogo.

Unity Catalog ownership and access

Os dados são fisicamente separados no armazenamento

Uma organização pode exigir que dados de determinados tipos sejam armazenados em contas específicas ou buckets em seu locatário de nuvem.

O Catálogo do Unity oferece a capacidade de configurar locais de armazenamento no nível do 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 Catálogo do Unity, 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 as tabelas gerenciadas ou os volumes criados no catálogo hr_prod (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 dados dentro do hr_prod catalog 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 de locais de armazenamento de esquema para catálogo para 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. Se não, e 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 ao my-region-metastore.

Unity Catalog storage hierarchy

Os dados só podem ser acessados 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. Talvez você também queira 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 ambiente de processamento de dados primário e os catálogos são o domínio de dados primário. O Catálogo do Unity permite que administradores de metastore e proprietários de catálogo atribuam ou "associem" catálogos a workspaces. 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 nos objetos de dados concedidos a um usuário.

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

Criar um metastore do Catálogo do Unity

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

Esta seção fornece dicas para a criação e configuração de metastores. Se seu espaço de trabalho foi habilitado automaticamente para o Catálogo do Unity, não será necessário criar um metastore, mas as informações apresentadas nesta seção ainda poderão ser úteis. Confira Habilitação automática do Catálogo do Unity.

Dicas para configurar metastores:

  • Você deve configurar um metastore em cada região na qual você tenha workspaces 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 os metastores, use o Compartilhamento Delta.

  • Cado 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 utilizado para armazenar tabelas gerenciadas e volumes gerenciados.

    Se você optar por criar um local gerenciado no nível do metastore, deverá garantir que nenhum usuário tenha acesso direto a ele (ou seja, por meio da conta de 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 Catálogo do Unity 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 do catálogo e do 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 entender os privilégios dos administradores do espaço de trabalho nos espaços de trabalho habilitados para o Catálogo do Unity e revisar suas atribuições de administrador de espaço de trabalho existentes.

    Os administradores do workspace podem gerenciar operações para seu workspace, incluindo adicionar usuários e entidades de serviço, criar clusters e delegar outros usuários para serem administradores do workspace. Se seu espaço de trabalho foi habilitado para o Catálogo do Unity automaticamente, os administradores do espaço de trabalho terão a capacidade de criar catálogos e muitos outros objetos do Catálogo do Unity por padrão. Consulte Privilégios de administrador do espaço de trabalho quando os espaços de trabalho são habilitados automaticamente para o Catálogo do Unity

    Os administradores do espaço de trabalho também têm a capacidade de realizar tarefas de gerenciamento do espaço de trabalho, como gerenciar a propriedade do trabalho e exibir notebooks, o que pode fornecer acesso indireto aos dados registrados no Catálogo do Unity. O administrador do workspace é uma função privilegiada que você deve distribuir cuidadosamente.

  • Se você usar workspaces para isolar o acesso aos dados do usuário, talvez queira usar ligações de catálogo de área de trabalho. As ligações de catálogo de workspace permitem limitar o acesso ao catálogo por limites de workspace. Por exemplo, é possível garantir que os administradores do workspace e os usuários só possam acessar os dados de produção em prod_catalog a partir 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 (Opcional) Atribuir um catálogo a workspaces específicos.

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

Consulte Criar um metastore do Catálogo do Unity.

Configurar locais externos e credenciais de armazenamento

Locais externos permitem que o Catálogo do Unity leia e grave dados no 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 Catálogo do Unity. 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.

As credenciais de armazenamento encapsulam uma credencial de nuvem de longo prazo que fornece acesso ao armazenamento em nuvem. Pode ser tanto uma identidade gerenciada pela Azure (fortemente recomendada) ou entidades de serviço. O uso de uma identidade gerenciada tem os seguintes benefícios em relação às entidades de serviço:

  • As identidades gerenciadas não exigem que você mantenha credenciais ou alterne segredos.
  • Se o workspace 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 dp Azure Data Lake Storage Gen2 protegida por um firewall de armazenamento.

Dica

Locais externos, combinando credenciais de armazenamento e caminhos de armazenamento, fornecem forte controle e auditabilidade do acesso ao armazenamento. Para impedir que os usuários ignorem o controle de acesso fornecido pelo Catálogo do Unity, você deve garantir o limite ao 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 a migração de montagens em locais de armazenamento em nuvem para locais externos no Catálogo do Unity usando o Explorador do Catálogo.

Para obter uma lista de práticas recomendadas de gerenciamento de 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 seus dados

O Databricks recomenda o uso de catálogos para fornecer segregação na 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 do ambiente de desenvolvimento de software. Se você usar workspaces como uma ferramenta de isolamento de dados, por exemplo, usando workspaces diferentes para ambientes de produção e desenvolvimento ou um workspace específico para trabalhar com dados altamente confidenciais, também poderá associar um catálogo a workspaces específicos. Isso garante que todo o processamento de dados especificados seja tratado no workspace apropriado. Consulte (Opcional) Atribuir um catálogo a workspaces específicos.

Unity Catalog catalogs

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

Os objetos controlados pelo Catálogo do Unity podem ser gerenciados ou externos:

  • Objetos gerenciados são a maneira padrão de criar objetos de dados no Catálogo do Unity.

    O Catálogo do Unity gerencia o ciclo de vida e o layout do arquivo para esses protegíveis. Não use ferramentas externas ao Azure Databricks para manipular arquivos em tabelas ou volumes gerenciados diretamente.

    Tabelas e volumes gerenciados são armazenados no armazenamento gerenciado, que podem existir no nível de metastore, catálogo ou esquema para qualquer tabela ou volume especificado. 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.

  • Objetos externos são protegíveis cujo ciclo de vida de dados e layout de arquivo não são gerenciados pelo Catálogo do Unity.

    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 você tiver arquivos produzidos por outros sistemas e desejar que eles sejam preparados para acesso a partir do Azure Databricks ou quando ferramentas fora do Azure Databricks exigirem acesso direto a esses arquivos.

    As tabelas externas dão suporte ao Delta Lake e a muitos outros formatos de dados, incluindo Parquet, JSON e CSV. Tanto os volumes gerenciados quanto os 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 Criar tabelas no Catálogo do Unity e Criar e trabalhar com volumes.

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.

External locations

Depois de configurar os locais externos no Catálogo do Unity, você pode criar tabelas e volumes externos nos diretórios dentro dos locais externos. Em seguida, você pode usar o Catálogo do Unity 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.

Observação

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

Recomendações para o uso de locais externos

Recomendações para concessão de permissões em locais externos:

  • Conceda a capacidade de criar locais externos apenas a um administrador encarregado de configurar conexões entre o Catálogo do Unity e o armazenamento em nuvem ou a engenheiros de dados confiáveis.

    Os locais externos fornecem acesso de dentro do Catálogo do Unity a um local amplamente abrangente no armazenamento em nuvem, por exemplo, um bucket ou contêiner inteiro (abfss://my-container@storage-account.dfs.core.windows.net) 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 se envolver na configuração de alguns locais externos e, em seguida, delegar a responsabilidade de gerenciar esses locais a um administrador do Azure Databricks em sua organização. O administrador do Azure Databricks pode organizar ainda mais o local externo em áreas com permissões mais granulares registrando volumes externos ou tabelas externas em prefixos específicos no local externo.

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

  • 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 caminhos para ciência de dados ou outros casos de uso de dados não tabulares.

    Os volumes dão suporte para trabalhar com arquivos usando comandos SQL, dbutils, APIs Spark, APIs REST, Terraform e uma interface de usuário para navegar, fazer 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 do FUSE permite que cientistas de dados e engenheiros de ML acessem arquivos como se estivessem em um sistema de arquivos local, conforme exigido por muitas bibliotecas de aprendizado de máquina ou do sistema operacional.

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

Você deve usar locais externos para fazer o seguinte:

  • Registre tabelas e volumes externos usando os comandos CREATE EXTERNAL VOLUME ou CREATE TABLE.
  • Explore os arquivos existentes no armazenamento em nuvem antes de criar uma tabela ou volume externo em um prefixo específico. O privilégio READ FILES é uma pré-condição.
  • Registre um local como armazenamento gerenciado para catálogos e esquemas em vez do bucket raiz do metastore. O privilégio CREATE MANAGED STORAGE é uma pré-condição.

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

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

    Se você criar volumes ou tabelas externos na raiz do local externo, não será possível criar nenhum volume ou tabela externo adicional no local externo. Em vez disso, crie volumes ou tabelas externas 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:

  • Registre áreas de aterrissagem para dados brutos produzidos por sistemas externos para dar suporte ao 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 as instruções do Carregador Automático, COPY INTO ou 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 parte de sua análise exploratória de dados e outras tarefas de ciência de dados, quando os volumes gerenciados não forem uma opção.
  • 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 bibliotecas de códigos (JARs e wheels do Python) exportados de sistemas de gerenciamento de dependência local ou pipelines CI/CD.
  • Armazene dados operacionais, como arquivos de log ou 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 a partir de um local externo em um esquema.

Dica

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

Recomendações para o uso de tabelas externas

Você deve usar tabelas externas para dar suporte a 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.
  • A Databricks recomenda fortemente não registrar uma tabela como uma tabela externa em mais de um metastore devido ao risco de problemas de consistência. Por exemplo, uma alteração no esquema em um metastore não será registrada em outro. Use o Compartilhamento Delta para compartilhar dados entre metastores. Confira Compartilhar dados de forma segura usando o Compartilhamento Delta.

Configurar o controle de acesso

Cada objeto protegível no Catálogo do Unity tem um proprietário. A entidade de segurança que cria um objeto passa a ser o proprietário inicial dele. O proprietário de um objeto tem todos os privilégios no objeto, como SELECT e MODIFY em uma tabela, assim como a permissão para conceder privilégios de objetos seguros para outras entidades de segurança. Somente os proprietários de um objeto seguro têm a permissão para conceder privilégios nesse objeto para outras entidades. 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. Os administradores do proprietário e do metastore podem transferir a propriedade de um objeto seguro para um grupo. Além disso, se o objeto estiver contido em um catálogo (como uma tabela ou exibição), o catálogo e o proprietário do esquema poderão alterar a propriedade do objeto.

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

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

  • SELECT na tabela ou visualizar
  • USE SCHEMA no esquema que possui a tabela
  • USE CATALOG no catálogo que possui o esquema

USE CATALOG permite que a entidade autorizada percorra o catálogo para acessar seus objetos filho e USE SCHEMA permite que a entidade autorizada percorra o esquema para acessar seus objetos filho. Por exemplo, para selecionar dados de uma tabela, os usuários precisam ter o privilégio SELECT nessa tabela, 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 apenas essa equipe tenha 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, confira 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, confira Gerenciar privilégios no Unity Catalog.

Gerenciar configurações de cluster

O Databricks recomenda o uso das 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 para criar apenas clusters habilitados para o Catálogo do Unity. O uso de políticas de cluster reduz as opções disponíveis, o que simplificará muito o processo de criação do cluster para os usuários e garantirá que eles sejam capazes de acessar dados perfeitamente. As políticas de cluster também permitem que você controle o custo limitando o custo máximo por cluster.

Para garantir a integridade dos controles de acesso e impor garantias de isolamento forte, o Catálogo do Unity impõe alguns requisitos de segurança aos recursos de computação. Por esse motivo, o Catálogo do Unity apresenta o conceito do modo de acesso de cluster. O Catálogo do Unity é seguro por padrão; se um cluster não estiver configurado com um modo de segurança apropriado, ele não poderá acessar os dados do Catálogo do Unity. Confira Modos de acesso de computação e cluster suportados para o Catálogo do Unity.

A 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 trabalho 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
}
}

Auditar acesso

No entanto, uma solução completa requer a auditoria do acesso aos dados e o fornecimento de recursos de alerta e monitoramento. O Catálogo do Unity 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 as tabelas do sistema. Para obter mais informações sobre a tabela do sistema de log de auditoria, confira Referência de tabela do sistema de log de auditoria.

Consulte Monitoramento da Plataforma Data Intelligence do Databricks com logs de auditoria para obter detalhes sobre como obter visibilidade completa sobre eventos críticos relacionados à sua Plataforma Data Intelligence do Databricks.

Compartilhar dados de forma segura usando o Compartilhamento Delta

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

Para compartilhar dados entre metastores, utilize o Compartilhamento Delta de Databricks para Databricks. Isso permite que você registre tabelas de metastores em regiões diferentes. Essas tabelas serão exibidas como objetos somente leitura no metastore de consumo. Essas tabelas podem ter acesso como qualquer outro objeto no Catálogo do Unity.

Ao usar o Compartilhamento Delta de Databricks para Databricks a fim de realizar o compartilhamento entre metastores, tenha em mente que o controle de acesso está limitado a um metastore. Se um objeto protegível, como uma tabela, tiver concessões e esse recurso for compartilhado com um metastore da conta, as concessões da origem não serão aplicadas ao compartilhamento de destino. O compartilhamento de destino precisará definir as próprias concessões.

Saiba mais