Fala dataholics, no post de hoje falaremos um pouco sobre tabelas gerenciadas vs tabelas externas, trarei detalhes interessantes do seu funcionamento e novidades como Undrop Table, isso mesmo desfazer um DROP TABLE.
O que veremos nesse post:
Tabela Gerenciada - Managed Table
Tabela Externa - External Table
Mudando o Local da sua tabela Gerenciada
Undrop Managed Tables
Undrop funciona para External?
Features exclusivas das tabelas Managed
Resumo - Usar ou não usar Managed Table?
Tabelas gerenciadas - Managed Tables
Basicamente criar uma gerenciada é o padrão para o Databricks, se você realizar um CREATE TABLE sem especificar o Location automaticamente ela se torna uma Managed Table e os arquivos dessa tabela serão salvos na raiz do Storage do seu Metastore.
O principal comportamento da tabela gerenciada que diferencia ela de uma External é que os arquivos criados por essa tabela são gerenciados pelo Databricks.
Anteriormente, quando você fazia um DROP TABLE em uma Managed Table todos os arquivos eram excluídos do Storage imediatamente, esse comportamento mudou e falaremos sobre ele, embora, a gestão dos arquivos da tabela gerenciada continua sendo do Databricks.
Vamos criar uma tabela gerenciada e ver seu comportamento.
Note, não foi especificado o local dos arquivos, apenas o database e o catalogo, pois, estamos usando Unity Catalog.
Utilizando o DESCRIBE EXTENDED ou SYSTEM TABLES podemos analisar as configurações das nossas tabelas Deltas, abaixo note o tipo da tabela e o Location foi para uma pasta padrão, ele cria um ID para sua tabela, logo se você for direto pelo o Storage terá dificuldade de saber qual é a sua tabela sem saber o seu ID (UUID).
Reginaldo, então quer dizer que não posso escolher o local onde armazenarei minha tabela, pois, se eu informar o Location ela se torna uma tabela External?
Você pode, sim, definir o local das suas tabelas gerenciadas e criar uma organização para o seu Lake, a maneira de fazer isso é definir um caminho padrão para o seu Database\Schema, as tabelas sempre irão respeitar o caminho do schema.
Criarei um novo schema especificando o Location diferente para ele.
Na criação de um novo Schema (database) você especifica o External Location que você pode definir um Storage exclusivo, por exemplo, e também o caminho padrão para todas as tabelas.
Note que agora o Location das nossas tabelas serão salvas na pasta definida na criação do nosso schema, embora ainda sigam o padrão de IDs, o location padrão é o que definimos.
Detalhe no retorno do EXTENDED:
Por padrão as tabelas gerenciadas irão coletar as estatísticas das primeiras 32 colunas, isso é configurável, mas é uma feature que ajuda bastante na otimização e performance.
Outras propriedades exclusiva da Managed:
Predictive Optimizarion (Novo)
Is_managed_location
Tabelas externas - External Tables
As tabelas externas possuem esse nome por conseguirem apontar para qualquer local no Storage, incluindo o nome final da pasta, sem precisar ser um ID complexo como as Managed Tables, porém o que diferencia das tabelas gerenciadas é principalmente o fato de poder apontar para outros tipos de arquivos, ou seja, não são somente tabelas DELTA, elas podem ser tabelas com base em PARQUET, CSV, ORC etc.
Diferente das tabelas gerenciadas, as tabelas Externas gerenciam seu próprio Storage, isso significa que se você rodar um DROP TABLE apenas os metadados são apagados do Unity Catalog (Ou Hive metastore), mantendo os arquivos intactos no storage. Por um lado isso é bom, pois, se você quiser recuperar sua tabela ela estará no Storage ainda, por outro lado, se não tiver uma rotina de limpeza bem definida, seu Storage irá acumular muita sujeira, pois a maioria esquece de apagar o Storage.
Para criar uma External Table basta especificar o LOCATION no storage, se já existir uma tabela naquele local o Databricks faz a leitura do schema nos logs e cria baseado nesse schema, você não precisa nem especificar os detalhes, se não existir nada no local, uma nova tabela será criada, caso o schema seja diferente do especificado, um erro será gerado.
Vamos na prática.
Note que os dados já ficam na raiz do local informado, sem nomenclatura com UUIDs e sem dificuldade para entender que é uma tabela delta.
Olhando nos metadados ela já foi definida como uma tabela EXTERNAL, ou seja, preciso manualmente apagar o seu Storage em caso de precisar excluir ela.
Nesse exemplo abaixo estamos DROPANDO a tabela, ou seja, seus arquivos se mantêm no Storage, posteriormente estamos criando a tabela novamente, mas note, sem especificar nenhum schema de colunas, a engine pegou os metadados do Delta e criou com base neles.
Tentando criar uma tabela externa informando um local de uma tabela existente, mas passando o schema das colunas diferente da tabela no storage:
Nesse caso seria melhor criar sem especificar as colunas e deixar ele puxar automaticamente dos Logs.
Detalhe no EXTENDED:
Não temos coleta de estatísticas mesmo sendo uma tabela DELTA, somente pelo fato de ser uma EXTERNAL.
UNDROP TABLES
Lembra que na parte das tabelas gerenciadas mencionei que quando era executado um DROP TABLE de uma tabela gerenciada imediatamente os arquivos eram excluídos do Storage?
Esse comportamento mudou, agora o Databricks não exclui imediatamente e sim dentro de 30 dias ela poderá ser excluída do seu storage, com isso, você pode se recuperar de um erro humano, alguém acordou cansado numa segunda-feira, não havia tomado café ainda e DROPOU o banco errado, se fosse o comportamento anterior da Managed Table tinha que chorar, mas agora não mais.
Nossa tabela managedtable foi DROPADA 2 vezes, abaixo com o comando SHOW TABLES DROPPED podemos visualizar o histórico de tudo que foi excluído nesse schema.
Abaixo o comando UNDROP em ação, você tem duas opções de execução, informando o nome da tabela e então ele usará a versão mais recente DROPADA, ou especificar pelo ID da versão desejada.
DETALHE IMPORTANTE:
Quando você executa um DROP e UNDROP suas constraints PRIMARY e FOREIGN KEY não são recuperadas. PONTO POSITIVO: Todos os GRANTS são recuperados.
Por final, o comando UNDROP também funciona para EXTERNAL TABLE, embora você pudesse recuperar apenas recriando, pois, seu storage estaria intacto, o lado positivo é a recuperação dos GRANTS de acesso.
Sem dúvidas é mais uma feature bacana para o nosso arsenal de Delta Lake.
RESUMO
Abaixo apresento as principais características entre as tabelas Gerenciadas e Externas.
MANAGED - Modelo padrão do Databricks
MANAGED - Gerencia o próprio Storage e exclui o storage automaticamente
MANAGED - Possibilidade de realizar UNDROP
MANAGED - Nome da pasta na tabela no Storage é um UUID, dificultando a descoberta via Storage
MANAGED - Pode definir apenas a pasta raiz do Schema, as tabelas são gerenciadas por ID
MANAGED - Possui features exclusivas de performance
MANAGED - Apenas Delta Table
---------------------------
EXTERNAL - Possibilita usar outros tipos de arquivos como PARQUET, CSV etc
EXTERNAL - Storage gerenciado manualmente
EXTERNAL - Pode especificar o caminho completo, inclusive o nome da pasta final
EXTERNAL - Se não utilizado DELTA, perde todos os benefícios de um DELTA LAKE
EXTERNAL - Se utilizado DELTA, perde algumas features de performance
---------------------------
UNDROP - Funciona para ambas EXTERNAL e MANAGED
UNDROP - Não recria as Primary e Foreign KEYS
UNDROP - Recupera os GRANTS de acessos
A recomendação principal é sempre trabalhar com tabelas gerenciadas se você estiver usando DELTA, se estiver usando outros formatos ou acessando pastas fora dos seus External Locations utilizar External Table.
Alguns recursos são disponíveis apenas para as tabelas gerenciadas, como o PREDICTIVE OPTIMIZATION e coleta de estatísticas das primeiras 32 colunas (ajustável).
Ou seja, se você utilizará DELTA não há motivos para usar como External, de preferência para usar Managed e tenha alguns benefícios de performance e merlhor gestão do seu storage.
Fiquem bem e até a próxima.