Primeiros passos para adoção do Unity Catalog

July 28, 2023 em Produto

Compartilhe este post

Parte I - Conceitos gerais

Este artigo irá explorar os principais conceitos do catálogo de dados Databricks conhecido como Unity Catalog (UC) e trazer uma checklist de implantação mostrando os envolvidos, papéis e responsabilidades bem como cada atividade envolvida no processo de adoção. É composto de duas partes: Conceitos gerais e Guia prático. Boa leitura!

Introdução

Uma grande preocupação de qualquer plataforma de dados é com relação ao gerenciamento de dados e usuários, equilibrando a necessidade de colaboração sem comprometer a segurança.

Unity catalog é a solução de governança de dados do Databricks para o Lakehouse que permite:

Gestão de metadados e usuários de forma centralizada
Controle de acesso aos dados centralizado
Data lineage (rastreabilidade e interdependências)
Auditoria de acesso aos Dados
Pesquisa de Dados (Data search) Public Preview
Compartilhamento seguro de dados com Delta Sharing

Ele é o elemento de ligação entre o Workspace e o lakehouse.

Figura 1 - Arquitetura Unity Catalog

Databricks pode ser usado sem Unity Catalog mas quando ativado, acrescenta a capadiade gestão de usuários e metadados centralizada reduzindo esforços dos administradores.

Figura 2 - Comparação da gestão tradicional sem UC versus centralizada com UC

Um workspace combina colaboração e isolamento e pode ser criado para atender uma linha de negócios (LOB) ou unidade de negócios (BU), caso de uso ou até mesmo times de dados (engenheiros, cientistas e analistas). Unity Catalog vai gerenciar os acessos e permissões através de um metastore (repositório de metadados) de cada um dos workspaces criados, ou seja, de maneira centralizada. Graças à automação, a criação de um workspace foi simplificada para poucos minutos!

Um usuário pode fazer parte de um ou mais workspaces, dependendo dos vários casos de uso para os quais contribuem. Mais importante, seus privilégios, independentemente do workspace ao qual pertencem, permanecem os mesmos.

Isso permite que as organizações adotem um modelo de governança centralizado que permite que o acesso aos dados seja definido em um repositório central e os usuários ficam livres para serem adicionados aos workspaces. Workspaces podem ser adicionados ou removidos de igual forma.

Temos a oportunidade de gerenciar essa complexidade, reduzindo a proliferação de workspaces/clusters como um mecanismo para segregar dados. Adicionalmente o UC acrescenta um elemento chamado Data Lineage (Azure, Geral) que permite visualizar em um gráfico todas as interdependências de uma tabela até o nível de coluna.

Figura 3 - Gráfico de linhagem de dados da funcionalidade UC Data Lineage

Neste artigo, queremos mostrar de uma maneira simples a jornada do cliente para adotar o Unity Catalog (UC) e Federação de Identidade para atender a essa necessidade de gerenciamento centralizado de usuários e privilégios. .
Ponto de acesso para os usuários da plataforma, sejam analistas, cientistas e engenheiros. Com o UC, todo workspace está associado a um Unity metastore e pode ser usado como primeiro nível de isolamento combinado com catálogos. Todo o controle de acesso é feito por permissões dentro do Unity Catalog.

Databricks permite automação através de API, CLI ou Terraform para criação e dimensionamento economizando ainda mais tempo e esforço dos administradores.

Apresentando os elementos

Vamos primeiro apresentar todos os elementos. Qualquer produto baseado em SaaS não pode viver isolado e precisa se integrar bem às ferramentas e funções existentes em sua organização.

Administrador de nuvem e administrador de identidade são funções que existem fora do Databricks e precisam trabalhar em estreita colaboração com a função de administrador de conta (Account Admin - uma função que existe dentro do Databricks) para atingir metas específicas que fazem parte da configuração inicial. Falaremos mais tarde sobre como esses papéis funcionam juntos.

Personas fora da Databricks

Cloud Admin	Administradores de nuvem podem administrar e controlar recursos de nuvem que o Unity Catalog utiliza: contas/buckets de armazenamento, IAM/service principals/identidades gerenciadas.
Identity Admin	Os administradores de identidade podem administrar usuários e grupos no IdP (identity provider), que fornece as identidades para o nível da conta. Conectores SCIM e SSO requerem configuração pelo Administrador de Identidade no Provedor de Identidade.

Agora vamos nos concentrar nas personas que gerenciam recursos no Databricks. Além das principais funções administrativas apresentadas no artigo de administração de workspaces, existe a possibilidade de funções adicionais como Catalog Admin, Schema Admin e Compute Admin. Algumas organizações podem optar por ir ainda mais granular e criar Administradores de Schemas mas em alguns casos todas essas responsabilidades se concentram em uma única pessoa. A beleza do modelo de Herança de Privilégios é que você pode ir tão amplo ou profundo quanto necessário para atender às necessidades da sua organização.

Chapéu Databricks - personas de administração

Persona	Função integrada do Databricks?	Grupo personalizado recomendado?
Account Admin	Y	Y
Metastore Admin	Y	Y
Catalog Admin	N	Y
Schema Admin	N	Y
Workspace Admin	Y	Y
Compute Admin	N	Y

Você vai perceber que recomendamos a criação de um grupo personalizado mesmo quando houver uma função incorporada. Essa é uma prática recomendada geral para incentivar o uso de grupos, o que torna muito mais fácil dimensionar quando se trata de gerenciar permissões nas unidades de negócios, ambientes e workspaces. Você também pode reutilizar alguns desses grupos que já existem em seu IdP e sincronizá-los com o Databricks, permitindo a organização centralizada do grupo, mantendo a capacidade de criar grupos no nível da conta do Databricks para acesso mais granular.

Outro conceito importante a ser entendido é que o Principal que cria um objeto protegível torna-se seu proprietário (owner) inicial, e a transferência de propriedade para o grupo apropriado para um objeto protegível, em qualquer nível, é possível e recomendado.

Componentes do Unity Catalog

Nesta seção, vamos listar os componentes e funcionalidades disponíveis no UC.

Figura 4: Organização dos componentes do Unity Catalo

Termos	Definição
Unity Catalog	O Unity Catalog (UC) é uma solução de governança centralizada de arquivos, tabelas, painéis e modelos de ML em qualquer nuvem no seu lakehouse
Metastore	Um metastore é o contêiner de nível superior de objetos para metadados. Ele armazena dados (tabelas e views) e as permissões que controlam o acesso. Cada metastore expõe um namespace de três níveis (catalog.schema.table) que organiza seus dados.
Catalog	A primeira camada da hierarquia de objetos que é usada para organizar seus ativos de dados. (Pode ser nome da BU,
Schema	Os esquemas (também conhecidos como bancos de dados) são a segunda camada da hierarquia de objetos e contêm tabelas e views.
Table	Nível mais baixo na hierarquia de objetos, as tabelas podem ser externas (Tabelas externas são aquelas cujos dados são armazenados fora do local de armazenamento raiz) ou tabelas gerenciadas (Essas tabelas são armazenadas no local de armazenamento raiz que você configurou ao criar um metastore).
View	Uma view é um objeto somente leitura criado a partir de uma ou mais tabelas e views em um metastore. Ela reside na terceira camada do namespace de três níveis do UC (catalog.schema.view). Pode ser criada a partir de tabelas e outras views em vários esquemas e catálogos.
Materialized view	Uma view atualizada automaticamente que ajuda a melhorar a latência da consulta pré-computando consultas e/ou cálculos usados com frequência. (Private preview)
Function	Uma função definida pelo usuário contida em um esquema.
External function	Um objeto que combina um caminho de armazenamento em nuvem com uma credencial de armazenamento para autorizar acesso ao caminho de armazenamento em nuvem.
Storage Credential	Encapsula uma credencial de nuvem de longo prazo que fornece acesso ao armazenamento em nuvem.
Provider	Uma entidade que disponibilizou dados para compartilhamento.
Share	Um agrupamento lógico para as tabelas que você pretende compartilhar.
Recipient	Identifica uma organização com a qual você deseja compartilhar qualquer objeto definido para compartilhamento.

A relação de cada componente com o Unity Catalog pode ser melhor compreendida através da imagem a seguir.

Figura 5: Relação dos objetos com Unity Catalog (UC)

Agora que apresentamos os principais conceitos e fundação do Unity Catalog como solução de gestão centralizada, vamos para a segunda parte onde apresentamos os principais envolvidos, a divisão de trabalho entre eles e um exemplo com guia para te ajudar na implementação.

Parte II - Guia prático

Como vimos na parte I do artigo sobre UC <<link>>, a solução de governança centralizada nos ajuda administrar melhor e habilitar casos de uso para as diferentes áreas de negócios (LOB, BU, Departamento, Times) e ampliar o controle e segurança de cada uma das áreas e usuários.

Agora que já temos claro os principais conceitos, vamos trazer alguns controles e exemplos para ajudar no entendimento dos papéis, responsabilidades, atividades e referencias.

O primeiro passo é entender por onde começar, as tabelas abaixo mostram qual as primeiras atividades e quem deve ser envolvido na organização.

Colabore com o Identity Admin; Identificar Personas Admin
Tarefa	Persona
Configurar o SCIM do IDP	Account Admin (+ Identity Admin)
Configurar SSO
Identifique principais personas de administrador (Account, Metastore, Workspace)
Identificar personas de administrador recomendadas (Catalog, Compute, Schema)

Colabore com Cloud Admin; Criar recursos de nuvem
Tarefa	Persona
Criar Root bucket	Account Admin (+ Cloud Admin)
Criar IAM role (AWS) ou Criar Access Connector Id (Azure)

Divisão do trabalho

UC requer estreita colaboração e transferências entre vários administradores. Uma vez que entendemos os componentes, as etapas de configuração podem ser simplificadas utilizando a automação. Vamos entender quem desempenha qual papel na Administração da Plataforma como parte do modelo de responsabilidade compartilhada.

Responsabilidade	Account Admin	Metastore Admin	Catalog Admin	Schema Admin	Workspace Admin	Compute Admin
Obter acesso ao Principals	Y
Criar Metastore	Y
Gerenciar Principals	Y
Configurar SSO	Y
Criar Catalogo		Y	Y
Criar Storage Credential	Y
Criar External Location		Y
Delegar acesso aos dados		Y	Y	Y
Gerenciar acesso Access					Y	Y
Atribuir Principals ao workspace					Y

	Pode fazer
	Deveria fazer

Abaixo trazemos uma tabela simples com as principais atividades no formato de um checklist.

Tarefa	Status
Criar Metastore	Pendente
Gerenciar Principals	Pendente
Configurar SSO	Pendente
Criar Catálogo	Pendente
Criar Storage Credential	Pendente
Criar External Location	Pendente
Delegar acessos aos Dados	Pendente
Gerenciar acessos aos Clusters	Pendente
Atribuir Principals ao Workspace	Pendente

Etapas de preparação

As etapas principais a seguir exigem a colaboração de várias pessoas administrativas com diferentes funções e responsabilidades e precisam ser executadas na seguinte ordem prescrita.

Lista de verificação principal - etapas de preparação
	Tarefa	Notas
1	Criar Metastore	Crie 1 metastore por região por conta do Databricks (assegurar de ter acesso como Cloud admin na nuvem)
2a	Criar Storage Credentials	(opcional) Necessário se você deseja acessar locais de armazenamento na nuvem existentes com uma função de IAM / identidade gerenciada para criar tabelas externas.
2b	Criar External Locations	(opcional) Necessário se você tiver locais de armazenamento em nuvem existentes que deseja registrar com UC para armazenar tabelas externas.
3a	Criar Workspace	(opcional) Necessário se você não tiver um workspace existente.
3b	Associar Metatore ao Workspace	Esta etapa ativa a Federação de Identidade como um recurso.
3c	Associar Principals ao Workspace	Esta etapa é como a Federação de Identidade é executada. Os Principals existem centralmente e são "atribuídos" aos workspaces.
4	Criar Catálogo	Crie catálogos por SDLC e/ou necessidades de BU para separação de dados.
5	Associar privilégios ao Catálogo	Use o Modelo de Herança de Privilégios para gerenciar GRANTS facilmente do Catálogo para níveis inferiores.
6	Associar Share Privileges no Metastore	(opcional) Isso faz parte do Delta Sharing gerenciado, que usa UC para gerenciar privilégios para Compartilhamento de Dados.

A tabela abaixo foi criada para servir como um ponto de partida, como uma lista de verificação de cada etapa, com a identificação da pessoa responsável por cada atividade (persona) bem como o status de acompanhamento que pode ir sendo atualizado e compartilhado com o time.

Tarefa	Persona	Detalhe	Status
Atuação do Identity admin
Configurar SCIM do IdP	Account Admin (+ Identity Admin)	AWS, Azure	Pendente
Configurar SSO		AWS, Azure	Pendente
Identificar Administradores (Account, Metastore, Workspace)		AWS, Azure	Pendente

Atuação do Cloud Admin; Criar recursos Cloud
Criar repositório ou bucket	Account Admin (+ Cloud admin)	AWS, Azure	Pendente
Criar IAM roles (AWS) Criar Access connector Id (Azure)	Account Admin (+ Cloud admin)	AWS, Azure	Pendente

Criar um Metastore
Criar Metastore	Account Admin	AWS, Azure	Pendente
Transferir a propriedade do metastore para o grupo metastore_admin	Account Admin	AWS, Azure	Pendente

Criar credenciais de storage & External Locations (p/ tabelas externas)
Criar Storage Credentials	Account Admin	AWS, Azure	Pendente
Criar External Locations	Metastore Admin	AWS, Azure	Pendente

Habilitar o UC no Workspace
Criar Workspace (se não existe ainda)	Account Admin (AWS) Cloud Admin (Azure)	AWS, Azure	Pendente
Associar o Metastore ao Workspace	Account Admin	AWS, Azure	Pendente
Atribuir permissões dos principals ao Workspace	Workspace Admin	AWS, Azure	Pendente

Criar Catálago
Criar catálago	Metastore Admin (ou Catalog Admin)	AWS, Azure	Pendente

Atribuir privilégios ao Catálogo
Transferir propriedade	Metastore Admin	AWS, Azure	Pendente
Criar objetos seguros	Catalog Admin	AWS, Azure	Pendente

Associar privilégios ao Catálogo
Criar compartilhamento	Metastore Admin	AWS, Azure	Pendente
Atribuir privilégios de compartilhamento	Metastore Admin	AWS, Azure	Pendente

A planilha com os cenários pode ser acessada através desse link.

Cenários de exemplo

Analisaremos alguns cenários de exemplo para demonstrar como os usuários em vários workspaces colaboram e como o mesmo usuário tem acesso contínuo aos dados aos quais tem direito, de diferentes workspaces. Alguns usuários criam workspaces por Linha de negócios (LOB) / Unidade de negócios (BU) como um limite de isolamento. Outra demarcação comumente usada é por ambientes para desenvolvimento/sandbox, homologação e produção.

Figura 6: Arquitetura de exemplo de organização de workspaces

Cenário	Descrição
Depto1	Hospeda workspaces separados para desenvolvimento, produção e um ambiente de sandbox compartilhado. Cada um tem um catálogo separado. Os dados subjacentes podem usar o armazenamento gerenciado ou locais de armazenamento externo. Os workloads de desenvolvimento são promovidos para prod, permitindo que os clusters façam referência automaticamente ao catálogo relevante como um parâmetro de configuração de cluster que pode ser aplicado por meio da política de cluster. Estes tem mecanismos de proteção no metastore e podem ter privilégios diferentes no escopo dev/prod.
Depto2	Hospeda um ambiente de sandbox que pode acessar alguns objetos da sandbox Depto1. Isso envolve alguns usuários que também existem no Depto1 e alguns novos.
Depto3	Hospeda um ambiente de produção que usa alguns recursos do Depto1 prod para criar produtos derivados.
Depto4	Está hospedado em uma região/nuvem diferente e deseja acessar alguns dados produzidos pela Depto1. Nesse caso o desenho mostra o uso do Delta Sharing.

Cenário 1: Depto1

-- Workspace Dev: Group1(Table1), Group2(Table2), Group3(Table3)

-- Assumir que Metastore Admin criou CATALOG catalog_dev e schema1

GRANT USE CATALOG ON CATALOG catalog_dev to Group1; -- repetir p/ Group2, Group3

GRANT USE SCHEMA ON SCHEMA catalog_dev.schema1 to Group1; -- repetir p/ Group2, Group3

GRANT CREATE TABLE on SCHEMA catalog_dev.schema1 to Group1; -- repetir p/ Group2, Group3

-- Assumindo que Group1 cria Table1, Group2 cria Table2

-- Por padrão, a pessoa que cria se torna o proprietário

CREATE TABLE catalog_dev.schema1.Table1; -- Membro do Group1 executa

CREATE TABLE catalog_dev.schema1.Table2; -- Membro do Group2 executa

-- Owner (dono) da tabela ou alguém com uma função mais privilegiada, por exemplo, owner do esquema/catálogo/metastore

-- pode executar GRANTS em seu nome ou mudar o owner

GRANT SELECT on catalog_dev.schema1.Table1 to Group3; --Owner Table1 executa

GRANT SELECT on catalog_dev.schema1.Table2 to Group3; --Owner Table2 executa

-- Workspace Sandbox: Group1(Table1), Group2(Table2), Group3(Table3)

-- Cenario: Como é uma sandbox, podemos conceder todos os privilégios do esquema a todos os grupos

GRANT USE CATALOG ON CATALOG catalog_sandbox to Group1; -- repetir p/ Group2, Group3

GRANT ALL PRIVILEGES ON SCHEMA catalog_sandbox to Group1; -- repetir p/ Group2, Group3

-- Suponha que uma nova Table2 seja criada

CREATE TABLE catalog_sandbox.schema1.Table2; -- Membro Group2 executa

-- Voltaremos à tabela acima no cenário Depto2

-- Workspace Prod: ServicePrincipal

-- Cenario: Um job de produção roda por um Service Principal lendo da Table1 e escreve para a Table2

GRANT USE CATALOG ON CATALOG catalog_prod to SP;

GRANT SELECT on catalog_prod.schema_1.table1 to SP;

GRANT MODIFY on catalog_prod.schema_1.table2 to SP;

Cenário 2: Depto2

-- Cenario: Group2 e Group4 no workspace Sandbox Depto2 quer acessar os mesmos dados como foi preparado no catalog_sandbox do Depto1

-- Não precisa de grants adicionaos no Group2 (ja foram concedidos)

-- Membros do Group2 podem acessar os mesmos dados do Workspace sandbox Depto1

-- Precisamos apenas fornecer o novo acesso ao Group4

GRANT USE CATALOG ON CATALOG catalog_sandbox to Group4;

GRANT USE SCHEMA on SCHEMA catalog_sandbox.schema1 to Group4;

GRANT SELECT, MODIFY on catalog_sandbox.schema1.Table2 to Group4;

-- Agora o Group4 pode trabalhar nesta tabela a partir deste workspace (e qualquer outro workspace que você pode se conectar no mesmo metastore)

Cenário 3: Depto3

-- Cenario: Workspace Prod has a new Group5 and they need access to LOB1's catalog_prod to create a derived data product

GRANT USE SCHEMA on SCHEMA catalog_prod.schema1 to Group5;

GRANT SELECT on catalog_prod.schema1.Table2 to Group5;

-- Agora Group5 pode ler desta tabela a partir deste workspace (e qualquer outro workspace que você possa conectar ao mesmo metastore)

-- Um próximo recurso de vínculos de catálogo de espaço de trabalho pode ser usado para restringir os workspaces dos quais catálogos específicos podem ser acessados.

-- garantindo que os dados do Prod só possam ser acessados nos workspaces de Prod, como exemplo

Cenário 4: Depto4

-- Cenario: Compartilha dados com o Metastore em uma região ou cloud diferente

CREATE SHARE IF NOT EXISTS ShareToLob4;

ALTER SHARE ShareToLob4 ADD TABLE catalog_sandbox.schema1.Table2;

CREATE RECIPIENT IF NOT EXISTS RecipientLob4;

GRANT SELECT ON SHARE ShareToLob4 TO RECIPIENT RecipientLob4;

-- Agora, o Destinatário Depto4, que é um metastore em uma nuvem/região diferente, pode ler a partir deste compartilhamento, que possui 1 tabela.

-- O compartilhamento pode ser alterado a qualquer momento para adicionar ou remover tabelas

-- O acesso ao compartilhamento no destinatário pode ser controlado de forma semelhante por meio de ACLs no metastore do destinatário

Servindo os dados

O Unity Catalog simplifica o trabalho de um administrador (tanto no nível da conta quanto do workspace), centralizando as definições, monitoramento e descoberta de dados no metastore e facilitando o compartilhamento seguro de dados, independentemente do número de workspaces anexados a ele. Nosso modelo pode ser definido como "Defina uma vez, proteja em todos os lugares" tem a vantagem adicional de evitar a exposição acidental de dados no cenário de privilégios de um usuário inadvertidamente em um workspace, o que pode dar a eles uma porta dos fundos para obter dados que não deveriam ser consumidos. Isso pode ser feito facilmente utilizando identidades em nível de conta e gerenciamento de privilégios. O UC Audit Log permite visibilidade total de todas as ações de todos os Principals em todos os níveis e em todos os objetos protegidos.

Figura 7: Modelo de Governança do Catálogo Unity

adicionais

Estas são as nossas recomendações para uma experiência melhorada:

Organize os responsáveis:
- Configurar SCIM & SSO no nível de conta (Account Level)
- Criar catalogos por algum dos seguintes métodos: SDLC (dev/prod/…), unidade de negócios ou ambos
- Crie grupos por unidades de negócios/equipes de dados e atribua-os aos workspaces apropriados (workspaces são conceitualmente efêmeros)
- Avalie o número de membros necessários em cada um dos grupos de administradores

Delegue responsabilidades para os responsáveis:
- Certifique-se de que o administrador da conta, o administrador do metastore, o administrador do catálogo e o administrador do esquema entendam as responsabilidades apropriadas para suas funções. Em alguns casos, essa figura é centralizada em apenas uma pessoa.
- Sempre use grupos, não indivíduos, como proprietário de objetos (tabela, view, ...), especialmente se for Metastore, Catalogos e schemas.
- Combine o poder do modelo de herança de privilégios com a capacidade de 'transferir ownership' para democratizar a propriedade de dados.
- Uma plataforma bem governada envolve uma carga administrativa compartilhada entre essas várias funções e a automação é a chave para construir um padrão repetível enquanto oferece controle.

Automatize para facilitar a manutenção
- Fornecemos a receita para um processo de integração simples, mas à medida que você escala para mais usuários, grupos, espaços de trabalho e catálogos, a automação se torna imperativa. A infinidade de opções inclui API, CLI ou o guia completo fornecido por nosso Provedor Terraform (AWS, Azure)

Migre para ampliar o uso
- Use Tabelas Externas para migrar de Hive metastore (HMS) para UC, permitindo que você adote o modelo de governança centralizado sem se preocupar com a movimentação de dados.
- Use SYNC para manter seus objetos sincronizados de HMS para UC.

Audite para manter a organização
- Definitivamente, configure o Audit Log
- Crie um painel sobre os dados do log de auditoria, analise regularmente e crie alertas para ações importantes por meio de um painel SQL do Databricks

Adicionalmente, deixamos uma lista de referências valiosas:

Introdução ao Unity Catalog - (Azure)

Instalação do Unity Catalog - (Azure)

Configurando os Controles de Acesso - (Azure)

Criando um METASTORE - (Azure)

Criando CATÁLOGOS - (Azure)

Criando um Schema (DATABASE) - (Azure)

Criando uma Tabela (DELTA) - (Azure)

Práticas recomendadas UC (Azure, AWS)

Práticas recomendadas para gestão de Identidades (Databricks)

Experimente o Databricks gratuitamente

Introdução

Ver tudo Produto posts