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. Ajuda a simplificar a segurança e a governança dos seus dados, fornecendo um local central para administrar e auditar o acesso aos dados. Delta Sharing é uma plataforma segura de compartilhamento de dados 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.

Blocos de construção 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 Catálogo do Unity (alguns objetos protegíveis estão esmaecidos para enfatizar a hierarquia de objetos gerenciados nos catálogos).

Diagrama de modelo de objeto do Unity Catalog

Os objetos nessa hierarquia incluem o seguinte:

Modelos e funções: Embora não sejam, estritamente falando, dados ativos, os modelos registrados e as funções definidas pelo usuário também podem ser gerenciados no Unity Catalog e residem no nível mais baixo da 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 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 obter 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 em silos que podem dificultar desnecessariamente a governança e a colaboração dos dados. A 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 obter 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 de salário de funcionários ou informações de pagamento com cartão de crédito. O acesso a esse tipo de informação é normalmente rigidamente controlado e auditado periodicamente. O Unity Catalog fornece controle granular sobre ativos de dados dentro do catálogo para atender a esses padrões dinâmicos. Com os controles que o Unity Catalog fornece, os usuários podem ver e query apenas os dados que têm direito de ver e query.

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 centralizada, seus administradores de governança são proprietários do metastore e podem assumir a propriedade de qualquer objeto, 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 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.

Os dados são fisicamente separados no armazenamento

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

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

Por exemplo, digamos que sua organização tenha uma política compliance empresarial que exija que os dados de produção relacionados aos recursos humanos residam no bucket s3://mycompany-hr-prod. No Unity Catalog, você pode atender a esse requisito definindo um local no nível do catálogo, criando um catálogo chamado, por exemplo, hr_prod e atribuindo o local s3://mycompany-hr-prod/unity-catalog a ele. Isso significa que gerenciar tabelas ou volumes criados no catálogo hr_prod (por exemplo, usando CREATE TABLE hr_prod.default.table …) armazena seus dados em s3://mycompany-hr-prod/unity-catalog. Opcionalmente, você pode optar por fornecer locais no nível do esquema para organizar os dados no 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 local default para armazenar tabelas e volumes de gerenciamento em catálogos e esquemas no metastore.

O sistema avalia a hierarquia de locais de armazenamento do esquema ao catálogo e ao 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:

Se um local tiver sido fornecido para mySchema, ele será armazenado lá.
Caso contrário, e um local tiver sido fornecido em myCatalog, ele será armazenado lá.
Finalmente, 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.

Em Databricks, o workspace é o principal ambiente de processamento de dados, e os catálogos são o principal domínio de dados. Unity Catalog permite que os administradores do metastore e os proprietários de catálogos atribuam ou "vinculem" catálogos a um espaço de trabalho específico. Essas associações com reconhecimento de ambiente permitem que o senhor garanta que apenas determinados catálogos estejam disponíveis em um site 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

Um metastore é o contêiner de objetos de nível superior no Unity Catalog. Metastores gerenciando dados ativos (tabelas, view 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 o seu workspace foi habilitado automaticamente para Unity Catalog, você não precisa criar um metastore, mas as informações apresentadas nesta seção ainda podem ser úteis. Consulte Ativação automática do Unity Catalog.

Dicas para configurar metastores:

Consulte Criar uma metastore do Unity Catalog.

Configurar locais externos e credenciais de armazenamento

Localizações externas permitem que o Unity Catalog leia e escreva 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á 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, na AWS, você pode configurar uma função IAM para acessar os buckets S3.

Dica

Locais externos, ao combinar credenciais e caminhos de armazenamento, fornecem 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 bucket que esteja sendo usado como local externo. Pelo mesmo motivo, você não deve montar account de armazenamento no DBFS se ela também estiver sendo usada como locais externos. A Databricks recomenda que você migre montagens em locais de armazenamento clouds para locais externos no Unity Catalog usando o Catalog Explorer.

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

Organize seus dados

Databricks recomenda o uso de catálogos para fornecer segregação na arquitetura de informação da sua organização. Geralmente, 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 workspace como uma ferramenta de isolamento de dados, por exemplo, usando workspace diferente para ambientes de produção e desenvolvimento ou um workspace específico para trabalhar com dados altamente confidenciais, também poderá vincular um catálogo a um workspace específico. Isso garante que todo o processamento de dados especificados seja feito no workspace apropriado. Consulte (Opcional) Atribuir um catálogo a um workspaceespecífico.

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, view e volumes. Você pode usar esquemas para organizar e definir permissões para seu ativo.

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

Gerenciar objetos é a maneira default de criar objetos de dados no Unity Catalog.

O Unity Catalog gerencia o ciclo de vida e a disposição do arquivo para esses protegíveis. Você não deve usar ferramentas fora do Databricks para manipular arquivos em tabelas gerenciadas ou volumes diretamente.

Gerenciar tabelas e volumes são armazenados em Gerenciar armazenamento, que pode existir no nível de metastore, catálogo ou esquema para qualquer tabela ou volume. 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 seguros cujo ciclo de vida de 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 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 quiser que eles sejam preparados para acesso a partir do Databricks, ou quando ferramentas fora do Databricks exigirem acesso direto a esses arquivos.

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 a criação de tabelas e volumes, consulte Criar tabelas no Unity Catalog 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.

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 bucket de armazenamento em nuvem.

Observação

Quando o senhor define um volume, o acesso do URI de nuvens aos dados no 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 cloud ou a um engenheiro de dados confiável.

Locais externos fornecem acesso do Unity Catalog a um local amplamente abrangente no armazenamento clouds , por exemplo, um bucket ou contêiner inteiro (s3://mybucket) ou um subcaminho amplo (s3://mybucket/alotofdata). A intenção é que um administrador clouds possa estar envolvido na configuração de alguns locais externos e depois delegar a responsabilidade de gerenciar esses locais a um administrador do 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, a 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 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.
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 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 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 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:

Registrar áreas de aterrissagem 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 aprendizado de máquina 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.
Conceder aos usuários do Databricks acesso a arquivos arbitrários produzidos e depositados no cloud armazenamento por outros sistemas, por exemplo, grandes coleções de dados não estruturados (como arquivos de imagem, áudio, vídeo e PDF) capturados por sistemas de vigilância ou dispositivos IoT ou arquivos de biblioteca (arquivos JARs e Python wheel ) exportados de sistemas locais de gerenciamento de dependências ou CI/CD pipeline.
Armazene dados operacionais, como registro ou verificação de arquivos, quando volumes gerenciados não são uma opção.

Mais recomendações para usar 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 Auto Loader ou — use volumes externos. COPY INTO 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 de consulta normais no topo dos dados armazenados no armazenamento em nuvem, ao criar tabelas gerenciadas não é uma opção.

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

A Databricks recomenda que o senhor crie tabelas externas usando um local externo por esquema.
Databricks recomenda fortemente contra o registro de uma tabela como uma tabela externa em mais de um metastore devido ao risco de problemas de consistência. Por exemplo, uma alteração no esquema em um metastore não será registrada no segundo metastore. Use o compartilhamento Delta para compartilhar dados entre metastores. Consulte Compartilhe dados com segurança usando o compartilhamento Delta.

Configurar o controle de acesso

Cada objeto seguro no Unity Catalog tem um proprietário. O principal que cria um objeto se torna 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 seguro a outros princípios. 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 em todos os objetos para o grupo responsável pela administração de concessões no objeto. Tanto o proprietário quanto os administradores de metástoro podem transferir a propriedade de um objeto seguro para um grupo. Além disso, se o objeto estiver contido dentro de um catálogo (como uma tabela ou visualização), o proprietário do catálogo e do esquema poderá alterar a propriedade do objeto.

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 no 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 na mesa ou vista
USE SCHEMA no esquema que possui a 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-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 no catálogo pai, juntamente com o privilégio USE SCHEMA no esquema pai. Portanto, você pode usar esse privilégio para restringir o acesso a seções do seu namespace de dados para 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 quaisquer tabelas produzidas por membros da equipe só poderão 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 visualizaçã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 acesso seguro às tabelas usando filtros de linhas e máscaras de colunas. Para obter mais informações, consulte Filtrar tabela sensível uso de filtros de linha e máscaras de coluna de dados.

Para obter mais informações sobre todos os privilégios no Catálogo do Unity, consulte gerenciar privilégios no Catálogo do Unity.

Gerenciar configurações de cluster

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

Para garantir a integridade dos controles de acesso e impor fortes garantias de isolamento, o Unity Catalog impõe requisitos de segurança ao recurso compute . Por esse motivo, o Unity Catalog introduz o conceito de modo de acesso de clusters . O Unity Catalog é seguro por default; se um clusters não estiver configurado com um modo de acesso apropriado, os clusters não poderão acessar dados no Unity Catalog. Consulte Modos de acesso compute e clusters compatíveis para o Unity Catalog.

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 acesso de auditoria aos dados e fornece recursos de alerta e monitoramento. O catálogo do Unity captura um registro de auditoria de ações executadas em relação ao metastore e esses logs são entregues como parte dos logs de auditoria do Databricks.

Você pode accountacessar de auditoria da logs sua 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 monitoramento da 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.