Fala dataholics, vamos para um post um pouco mais técnico hoje, esse tema estava no meu backlog tem mais de 6 meses, no passado já fiz uma apresentação sobre DBFS e Mounts, agora preciso mostrar a evolução, dar Adeus aos Mounts (sei que muitos gostavam) e dar Oi para os Volumes.
O que veremos hoje:
DBFS e Mount
Volumes e comparação com Mount
Resumo
DBFS e Mount
O termo DBFS se refere a Databricks File System, ou seja, sistema de arquivo do Databricks, falarei especificamente de Azure a seguir, sempre que é criado um Workspace Databricks um novo Storage Account é atribuído para esse Workspace, esse Storage Account é exclusivo do Databricks e é bloqueado para qualquer alteração manual, esse Storage Acccount é utilizado como o DBFS Roots.
Ressalto que com o lançamento do Unity Catalog, não é recomendado mais o uso do DBFS Root nem Mounts, falaremos mais a frente sobre isso.
Abaixo uma representação dos containers criados dentro desse storage, dentro dele já vem algumas informações como Datasets de exemplos e estrutura de pastas utilizadas pelo databricks.
Como podemos ver nessa imagem abaixo, o Storage Account onde ficam as estruturas do DBFS estão em um Resource group da Databricks.
Esse é um dos motivos para você não utilizar o DBFS para salvar suas tabelas ou informações importantes, pois, é um Storage gerenciado pela Databricks, caso seu Workspace seja excluído, o storage será excluído e você perdera seus dados, também tem a questão de governança, gestão de acessos, evite ao máximo salvar informações no DBFS.
O DBFS era muito utilizado para subir arquivos Ad hoc, Excel, CSV, etc., Ou seja, usado para fins de testes, como uma area temporária.
Na prática, temos essa visão do storage account usado como DBFS, não podemos acessar nenhuma dessas pastas, pois, estão bloqueadas.
Vale reforçar que estou mostrando algo ao nível de conhecimento, na prática, não utilize mais o DBFS Root ou Mount, foque em usar as features do Unity Catalog (External Location e Volumes), o DBFS ainda será mantido e inclusive você poderá acessar seus Volumes usando o padrão dbfs:/Volumes/, como se estivesse usando um Mount.
Recomendações sobre DBFS:
Como vimos na imagem anterior, o DBFS além de algumas estruturas de pastas padrão, ele também possui o famoso Mount.
Quando usamos o Mount, estamos criando uma montagem de um disco nas máquinas do nosso cluster, como montar uma unidade de disco em nosso Windows, o disco aparece como se fosse local, mas, referenciando um local remoto, se você não está familiarizado com o termo de montagem de disco, seria como ter um atalho na sua máquina apontando para outro servidor, assim como um atalho do OneDrive/Sharepoint que temos em nossas máquinas, ele dá impressão que tudo esta local, facilitando a navegação.
O Mount foi amplamente utilizado por alguns motivos, mas destaco 2 principais:
Facilidade de referenciar as pastas (Não precisar referenciar o caminho completo do Cloud Object Storage)
Não precisava gerenciar acesso de logins (baita problema)
Basicamente o Mount dava a possibilidade de apontar para diversos locais externos como se eles estivessem dentro do nosso cluster, veja essa imagem abaixo, é como se eu criasse um disco dentro do meu cluster que no final das contas era um apontamento para um Object Store como um AWS S3 ou Azure Blob Storage.
Claro que você já deveria saber que o cluster de máquinas virtuais do Databricks utiliza Linux né? Mais especificamente Ubuntu, então internamente ele utiliza o FUSE que é um gerenciador do File System do Linux.
Como criar e usar um Mount?
Primeiro, listaremos os Mounts existentes utilizando o dbutils.fs.ls(), que nada mais é que um comando LS no File system, quando ver esse comando leia:
dbutils = Databricks Utilities
fs = File System Utility
ls = List
No comando abaixo estou criando um Mount apontando para uma Azure Storage Account em um container e pasta especifico, para isso estou usando uma App Registration, essa app será utilizada para autenticar no Storager account, os acessos para essa pasta deve ser liberada para essa App.
Obs: Preste bem atenção aqui, explicarei mais abaixo, aqui mora o risco de usar o Mount.
Pronto, Mount criado, já podemos acessar o nosso storage sem especificar o caminho completo.
Ao invés de acessar assim:
abfss://datalake@sahierarchicaldatalake.core.windows.net/landing/Agora você acessa assim: "/mnt/landing", muito melhor não?
Bom, se é lindo, qual o problema disso? Por que foi descontinuado?
O principal problema é a gestão de acessos, uma vez que você cria um Mount, todos os usuários podem visualizar os dados dentro dele, ou seja, não tem controle nenhum de acesso.
Como o acesso ao Storage é feito com um login fixo (nesse caso uma AppRegistration), mesmo o usuário com menos privilégio dentro do Databricks, herdará todo o acesso nesse Mount.
Esse é o principal motivo para o Mount ser descontinuado.
O Unity Catalog é conhecido como "Seguro por padrão", ou seja, ninguém pode ter acesso a dados se não for liberado, o Mount fere essa lei.
Estamos juntos até aqui? Toma um cafe e bora falar sobre Volumes.
Volumes
Estamos comparando os Volumes com o Mounts por algumas similaridades em funções específicas, embora sejam features totalmente distintas, os Volumes nasceram nativamente como objetos do Unity Catalog, eles representam um volume lógico no Storage account, da mesma forma que um Mount, mas com um porém, com segurança.
Os Volumes podem ser Managed ou External assim como tabelas Delta, quer entender mais o que isso significa, veja esse post:
Uma analogia sobre os Volumes Managed e External:
Mount = External Volume
DBFS Root = Managed Volume
É apenas uma maneira para refletir, obviamente não é exatamente assim.
Como podemos ver na imagem abaixo, os Volumes estão no mesmo nível de tabelas, ou seja, eles aparecem com 3 níveis, exemplo: catalogo.schema.volume, e dentro dele tem a referência para o Storage.
Apesar de aparecerem no mesmo nível de tabelas, um volume não é uma tabela e nem um Mount, parece confuso né?
Quando usávamos os Mounts antes do Unity Catalog, eles eram usados para referenciar não somente camadas de chegada de arquivos (landing, transient, etc) mas também as camadas mais refinadas como silver e bronze, ou seja, todas as tabelas ficavam dentro do Mount para facilitar o acesso.
Com a entrada do Unity Catalog e a introdução de External Location (papo para outro post), agora ao invés de utilizar Mount para as tabelas, você utilizará um External Location (para tabelas gerenciadas ou external).
O uso de Volumes fica para ETL (simplificando), podemos usar o Volumes para uma camada landing apontando para um local no storage onde os arquivos são despejados, ler esses dados e gravar em nossas tabelas.
Veja que não faz sentido eu criar uma tabela dentro de um Volume assim como era feito no Mount, pois, agora temos os External Location, mas como não temos mais o Mount, o Volume pode ser uma opção boa para substituir essa necessidade, podendo simplificar o acesso no storage e também criar uma area onde você pode fazer upload de arquivos de forma ad hoc para explorar ou testar.
A grosso modo podemos pensar assim:
Mount - Usávamos para referenciar tudo dentro do nosso Storage, camadas temporárias e tabelas de produção.
External Location (Ou Metastore Root): Agora todas as suas tabelas de produção você ira colocá-las em uma External Location
Volumes - As camadas temporárias, arquivos Ad hocs, testes, pode usar um Volume
Sei que pode parecer um pouco confuso, é mudança de paradigma, então pode levar um tempo pra voce virar a chave.
Vejamos na prática.
Listando os Volumes existentes e criando um novo Volume.
Obs: Você precisa criar seus Volumes usando um local dentro de uma External Location.
Novo Volume criado com sucesso apontando para uma pasta especifica no Storage.
Listando arquivos em um Volume (Podemos fazer via comando LIST em sql):
Note o path do volume começando com DBFS, ou seja, o DBFs continua existindo, mas não utilize o Root path nem Mounts mais, veja as recomendações que deixei no link la em cima.
Fazendo SELECT num Volume como se fosse um sistema de arquivos:
Da pra criar uma tabela usando Volume?
Aparentemente não, como disse, nem faria sentido, o ideal é utilizar External Location para as tabelas.
Reginaldo, isso parece muito com um Mount, o que diferencia um do outro?
Diferente de um Mount que é apenas um "atalho" para o Storage ao nível de sistema operacional, onde não temos controle de acesso, os Volumes estão dentro do nosso Unity Catalog, muito similar a uma tabela, posso gerenciar seu acesso como uma tabela.
Liberando acesso aos meus Volumes (Podemos fazer viam SQL com comando grant):
Por ele ser um objeto, posso aplicar comentários e Tags:
Por fim, posso fazer upload de arquivos da minha máquina para dentro do meu Volume e utilizar para algum experimento ou ingestão, como se fosse o DBFS, lembra?
Resumo
Podemos dizer que o Mount reinou por muito tempo, em ambientes menores, onde não havia a necessidade de gerenciar os acessos, Mount cai como uma luva, porém, devido ao seu problema de gerir acessos, ambientes maiores já não podiam utilizar Mount mesmo antes do Unity Catalog, se você utiliza e não sabia desse problema de segurança corra agora.
O Volume vem não só para substituir os Mounts, ele traz aspectos de segurança e, ao mesmo tempo, facilidade de uso para quem quer manipular arquivos Ad hoc, arquivos soltos, testes, fazer upload de arquivos para ingestão ou para experimentos, tudo isso com governança de dados, gestão de acessos e features como compartilhar dados via Delta Sharing e suporte a tags.
Como tudo nasce para unity catalog, obviamente não faz mais sentido o uso de Mounts, embora, sabemos que temos muitos pipelines legados e que precisam ainda serem migrados para Unity Catalog.
Por fim:
Não utilize mais DBFS Root ou Mount
Volumes não são para armazenar suas tabelas
Volumes são objetos como tabelas, com governança de dados
Use Volumes para facilitar a manipulação de arquivos
Espero que ajude, qualquer dúvida me envie uma mensagem.
Fique bem e até a próxima.
Referências:
Show de bola Regis! Me ajudou a entender melhor a diferença entre Volumes e External Location.