Conectando o Unity Catalog ao GCP Data Catalog

Introdução 

 

Nota: Este Blog foi escrito pela CERC, cliente Databricks.

No dia-a-dia, utilizamos diversos recursos tecnológicos, onde é um grande desafio integrá-los e manter a catalogação sempre unificada. Assim, iremos falar sobre como conectar o Unity Catalog ao Data Catalog.

A situação específica que originou essa necessidade é: a maior parte de nossos conjuntos de data assets do ambiente informacional estarem no recurso Databricks e atualmente termos o catálogo de dados corporativo utilizando o GCP-Data Catalog, que para as tabelas dentro da GCP, já as mapeia imediatamente.

Com isso, realizamos a primeira conexão entre estes recursos com um repositório de códigos que captura metadados definidos a partir do Hive Metastore do Databricks, integrando no conjunto GCP.

Com esse primeiro desafio de conexão superado, a companhia entendeu por melhor estratégia utilizar o produto Databricks-Unity Catalog, onde tivemos que repensar nossa integração, de forma que ela fosse capaz de manter os ativos de dados migrados para o novo produto e também manter os data assets existentes com origem no Hive Metastore. 

Entretanto nos deparamos com a falta de solução para integrar o Databricks Unity Catalog e o Google Data Catalog, assim surgindo a solução que iremos apresentar aqui.

O Unity Catalog possui a capacidade de utilizar APIs para acesso aos metadados do Databricks, sendo que na versão com Hive Metastore esta técnica não era possível.  

O GCP- Data Catalog já fornecia o uso de APIs, então com isso, foi possível criar uma conexão funcional entre os catálogos de forma simplificada em comparação às propostas de conexões anteriores.

Com isso podemos chegar em uma solução mais fácil de ser implementada com base nas documentações de cada recurso com algumas bibliotecas para as conexões com o GCP-Data Catalog. O diagrama abaixo mostra o direcionamento de nossa estratégia onde,  os metadados e catalogação se concentram no GCP-Data Catalog, adicionando os metadados do Databricks extraídos do Unity Catalog através do conector.

Neste blog iremos explorar como:

• Criar os requests dos metadados do Databricks;
• Construir o processo de conexão entre Unit Catalog e Data Catalog;
• Postar as alterações com a API do Data Catalog.

Obs.: Deve ser executado em um máquina de Databricks Runtime 10.4, ou até que a google faça uma atualização em sua biblioteca datacatalog_connectors.commons

 

Criar os requests dos metadados do Databricks

 

Com a ajuda do time da Databricks e as documentações do Unity Catalog, foi possível criar a classe responsável por extrair as informações da API do Unity Catalog, e organizá-los em uma lista de assets.

Estes assets são compostos por alguns elementos principais como nome da tabela, seu schema, nome do catálogo, colunas, os tipos das colunas, data de criação e data de atualização (completar infos e colar exemplos) 

 A classe, após fazer os requests no Unity Catalog, organiza as informações na disposição citada anteriormente (list(dict{asset}).

 

Construir o processo de conexão entre Unit Catalog e Google Data Catalog

 

O processo da conexão utiliza principalmente a biblioteca disponibilizada pela google (google-datacatalog-connectors-common) onde são aplicadas abstrações das APIs do Data Catalog com este objetivo. Assim, estando em mente o resultado da classe RetriveMetadataFromUC, é criada uma nova classe que prepara os objetos Entry para serem exportados posteriormente para o sistema GCP, ou seja, para cada asset (tabela do Databrick) é criado um objeto Entry. Podemos observar também que a classe PrepareDatabricksMetadata está herdando as propriedades da classe BaseEntryFactory, que advém da biblioteca google mencionada anteriormente, assim podemos utilizar alguns métodos que facilitam formatações.

Aqui é importante mencionar um detalhe: fazer uma atualização de uma Entry já catalogada com informações vazias pelo conector, irá remover as informações que estão no Data Catalog, assim a função da variável persisted_entry é justamente escrever a entry com as informações que estão no catálogo.

Além disso, uma característica da entry que está sendo criada é o link que vai ser redirecionado ao Databricks quando acessado no Data Catalog, assim, quando criada a entry terá todo seu conteúdo de metadados exportado ao Data Catalog.

Dado que a classe PrepareDatabricksMetadata faz as preparações a partir de cada asset, foi necessário criar uma classe que itere sob a lista de assets (resultado final da API do UC):

Antes da classe final, que irá mandar as entries criadas para o Data Catalog, é preciso criar um processo para manutenção das tabelas deletadas no Databricks, ou seja, quando haver ainda uma entrie no entryGroups designado para o Databricks, mas ela já não mais existir como tabela no Databricks, será deletada, assim primeiro será buscado as entries, depois será criada a comparação e criará a classe de deleção.

Assim a lista deverá ser iterada sob o processo de deleção:

 

Postar as alterações com a API do Data Catalog

 

Finalmente é possível a criação da classe final, que irá condensar as classes anteriores em uma utilização única, onde seus inputs serão o projeto, local e entryGroup do GCP em que os metadados do Databricks serão enviados:

Com isto para a execução do notebook e manter um catálogo atualizado, é preciso então executar a função run, com os inputs da classe preenchido:

Onde __PROJECT_ID é o projeto e o __LOCATION é o local do GCP que serão armazenados os metadados do Unity Catalog, sempre no caminho: projects/__PROJECT_ID/locations/__LOCATION/entryGroups/uc/entries/entry_id dentro do Data Catalog.

Assim, um exemplo de uma entry criada no Data Catalog seria:

Resumo

 

Nós demonstramos que hoje é simples criar uma conexão entre Unity Catalog e Data Catalog, a ideia principal é que se construa diretamente no sistema GCP uma Entry (Metadado da tabela) customizada do catálogo partindo do Databricks. Além disso, toda a construção do conector foi feita de forma modular, partindo de cada classe que o compõem e com isso permite em si customizações, tanto da arquitetura para que ele foi construído quanto para como ele modifica cada metadado. Para referência o código .dbc completo encontra-se nesse link.