External Storages com Unity Catalog
Geralmente eu dou um intervalo considerável entre meus posts, mas ontem numa reunião com a Databricks quinzenal que temos, o Arquiteto deles elogiou o meu post anterior e soltou a braba “você vai ficar chocado em ver a facilidade de fazer o mesmo processo usando o Unity Catalog”. Acabou a reunião falei “a é?” (Curiosão, rs)
Primeiramente vou explicar de forma Reduzida 2 coisas, Data Mesh e onde o Unity Catalog entra nisso.
Data Mesh
A “buzzword” do momento no mundo dos dados. O mundo dos dados sempre foi centralizado desde quando não existia a cloud, os servidores eram adquiridos pelo time de TI, administrados por TI e o custo deles ficando a maioria das vezes em TI, sem passar os gastos para as áreas que realmente lucram com o uso deles. A migração do mundo on premisses pra cloud na maioria das empresas foi quase um CTRL+C e CTRL+V disso, deixando uma administração de serviços centralizada e por sua vez os dados de forma centralizada, tanto em armazenamento como no acesso a eles também.
O Data Mesh propõe uma descentralização desses dados trabalhando com o dados por domínio, mas ainda assim propondo uma governança centralizada (A parte lógica da coisa). Por exemplo, numa instituição financeira, o time de cartões ser um domínio, o time de marketing outro domínio, conta corrente outro e assim por diante. Porém com cada um responsável por esse dado, o controle fica mais fino, o custo fica mais visível, o uso de tecnologias e serviços mais enxuto, pois cada uma das áreas pode ter um data stack de ferramentas somente dele, uns usando mais coisas e outros não.
Existe um site que é a bíblia desse assunto caso tenha interesse.
É uma metodologia um pouco extensa, o objetivo é entregar o dado como um produto que pode ser consumido e gerado por domínios em curtas palavras.
Tá, mas onde o Unity Catalog da Databricks entra nisso?
Lembra que falei que hoje é tudo centralizado? Então considere um único workspace de Databricks (seja DEV/QA/PROD) pra empresa inteira? É exatamente isso que a maioria das empresas tem hoje e com a vinda do DataMesh onde cada domínio será responsável pelo seu dado, também será responsável pela ferramenta que gera os dados, no caso o Databricks, tendo um Workspace para cada Dominio se ele for necessário para esse Stack.
Ai você fala: “Mas vai ficar uma loucura isso, quem vai gerenciar todos esses Workspaces, usuários, acessos a recursos, clusters, dados?”
Entendo sua preocupação pois foi o mesmo pensamento que eu tive no início, mas o que o Unity Catalog sugere é um gerenciamento centralizado dos Workspace usados nos N domínios de sua empresa.
Unity Catalog
A idéia aqui é um overview rápido sobre Unity Catalog até pra você entenda o assunto central do artigo que é a entrega do External Storage (ADLS) para o Databricks feito por ele. Acho que esse desenho explica mais ou menos o funcionamento, é relativamente simples.
O desenho acima explica o gerenciamento centralizado do Unity Catalog sobre os Workspaces 1 e 2 controlando acesso, gerenciando usuários e a parte que interessa pra esse post, OS EXTERNAL STORAGES.
Se liga que louco, eu crio um service principal na minha cloud, com acesso completo a um Storage Account (Azure), entrego ele pro Unity Catalog e ele fala, OK, deixa que eu distribuo os acessos pros usuários e ambientes que eu tenho aqui. Por exemplo posso criar um grupo que só lê os arquivos e outro que pode ter privilégio total, não pela Azure e sim pelo Unity Catalog, sem precisar abrir chamado pro seu time de Cloud por exemplo, seu Databricks admin ou seu próprio sistema de chamados pode fazer isso via API do Databricks. Foda né?
Outro ponto que estou querendo ver se funciona, se posso ter meu Databricks principal da Azure que é o meu caso e colocar metastores ou external locations da AWS (S3) e do Google (GCS) no mesmo Unity (ainda estou vendo se funciona).
Seria um lance incrível por exemplo que tenho dados gerenciados no Google Analitycs e processados pelo BigQuery do Google, esses dados ficam num GCS deles e trazidos pra Azure diariamente, eu poderia ou ter uma metastore ou external storages entre clouds como poderia ter uma parte do domínio de dados no Google com um Databricks lá e gerenciado pelo mesmo Unity catalog, usando features como o Delta Sharing para compartilhar esses dados entre workspaces das 2 clouds.
Irado né? Eu dou umas brisadas mesmo, rs.
Se quiser ver mais como funciona segue um material de introdução ao Unity Catalog.
Tem também um vídeo bem explicativo pra você ver que não tem nenhum bicho de 7 cabeças.
Agora que te dei um banho de loja de Data Mesh e Unity Catalog, vamos ver como consigo entregar esse ADLS pro Databricks.
Vamos à prática
Nesse exemplo abaixo eu tenho um Unity Catalog e 2 Workspaces Databricks chamados ADB001 e ADB002 conforme a imagem abaixo.
O primeiro ponto aqui é criar um MetaStore, mas…
O que seria um Metastore?
Quando eu não tenho um MetaStore linkado a um Workspace pelo Unity Catalog, no seu Workspace a aba “Data” aparece mais ou menos assim:
O Unity catalog usa um Metastore, um local que você define no seu Storage Account Azure que vai centralizar as informações dos seus catálogos, schemas (databases se você preferir chamar assim) e tabelas desses schemas. Onde você pode (ou não) compartilhar com um ou mais schemas, assim esses dados ficam compartilhados entre um ou mais Workspaces. Vamos fazer na prática isso de brinde.
Voltando pro Azure
Vou criar um novo storage account no Azure chamado “testeunity”, criar um container chamado “teste” e criar uma pastinha lá chamada “pasta2” (só pra efeitos didáticos, nem precisaria).
Criando um Azure Databricks Access Connector
Esse cara é novo e bem diferente do que foi o post de ontem, esse é um app registration que é criado pra fazer a integração entre o Databricks e os Serviços da Azure mais especificamente o Storage Account. Ele funciona mais ou menos conforme imagem abaixo:
Vamos criar esse cara e dar privilégio de Storage Blob Contributor pra ele no IAM (eu ja tinha criado um mas vou excluir e criar de novo pra mostrar como e feito).
Agora vou dar privilegio no Storage account pra esse cara.
Agora que concluímos a parte do Azure vamos pro Databricks, mas antes vou mostrar pra vocês que ainda não funciona, pra você não dizer que foi bruxaria.
Vamos lá no Unity Catalog cadastrar esse cara agora para entrar no Unity catalog você loga nesse link abaixo com sua conta admin Azure Databricks (A conta que você usou pra criar seu Workspace Databricks)
Logado na console, você vai lá em DATA > Create MetaStore e um Wizard será exibido igual o gif abaixo.
A primeira vez que fiz eu falei: “car****, então ele já aparece esse storage pro Workspace?” não se emocione como eu, ainda não é isso, estamos falando de Metastore ainda.
Atribuindo o Metastore a um Workspace
Eu vou atribuir o Metastore ao meu Workspace “ADB001” e se liga como vai ser exibido meu campo Data, no fim do GIF vou lá no “ADB002” e te provar que lá continua igual era antes.
Deu pra entender né? Agora vou mostrar como colocar finalmente o External Location ADLS pra usar. Eu tenho um outro Storage account chamado “sarescue001” e dentro dele um container chamado “dados”, criei uma pastinha lá chamada pasta1, só pra dizer que coloquei algo lá.
Tenho uma service principal (app registration) chamada “srv_rescue” e dei privilégios de storage blob contributor pra ela, conforme GIF abaixo:
O que vou fazer? Dentro do Workspace “ADB001" vou criar uma service principal com o app registration “srv_rescue” (você vai ver que eu poderia usar o “adbcrescue” que usamos para o Metastore, mas pra deixar os acessos bem segmentados, criei um só pra esse External Metastore).
O ponto aqui é que deixo de ter aqueles spark configs chumbados no notebook (igual o post anterior), não preciso colocar mais no spark config (o que seria o próximo post que traria uma versão mais otimizada da autorização OAUTH2 durante a subida do cluster). É tudo cadastrado no Metastore e boas, seguro, gerenciável de forma visual e com administração centralizada.
Agora vamos adicionar finalmente o External Storage com essa service principal que cadastramos.
Com nosso carinha criado vou fazer alguns testes:
- Tentar listar o conteúdo do External Storage com dbutils.fs.ls.
- Criando uma temporary view (biritas_temp) apontando para um csv do External Storage.
- Criando um catalogo chamado catalogo01 apontando pro External Storage.
- Criar um database chamado anselmo apontando o location pra esse External Storage.
- Criar uma tabela delta (biritas) lendo a temp view biritas_temp como origem nesse database anselmo.
Viu que criei os caras apontando para esse external storage, note também que quando crio catalogo e database tenho a opção de adicionar a location apontando para um external storage ou posso não colocar nada, assim em vez dele usar o sarescue001 que eu teria, ele usa o testeunity.
Vamos validar lá no Storage account se tudo foi criado.
Se precisar desse notebook pra adaptar pro seu cenário, segue abaixo.
Considerações finais
O que quis mostrar com esse post, são as facilidades que o Unity catalog traz para o gerenciamento do meu lake, principalmente com essa idéia de Data Mesh chegando, sinceramente eu não vi ainda como colocar External Storages de outras clouds, o desenho da documentação vendia isso ou entendi errado, rs. Descobrindo faço um post aqui.
Eu não precisei criar notebooks, Azure Key Vault e outras peripércias do post anterior, foi bem mais simples e visual fazendo por aqui, nem precisei setar spark configs nem no notebook nem na inicialização do cluster, o Unity catalog se vira com isso.
De brinde
Se liga esse ultimo GIF Bonus, você vai ver que no workspace ADB002 o catalogo01 nem o database anselmo aparecem, mas vou linkar o metastore com ele e você verá a mágica.
Te fez entender? Ajuda ae, dá a palminha ae, compartilha o o artigo, o post do Linkedin pra chegar em mais pessoas que precisam desse material, perdi 7 horas de um sábado fazendo isso que nem tem nada em português a respeito.
Dá essa moral ae?
Abraço e até o próximo!
Anselmo Borges
