lakehouse¶
o lakehouse é o armazenamento de dados próprio da datablixt: um repositório organizado onde os workflows gravam os dados processados, e de onde o catálogo e outros workflows leem esses dados de volta.
por que um lakehouse próprio, e não "vários bancos soltos"¶
um problema comum em empresas que crescem organicamente com dados é acabar com informação espalhada: uma cópia em um banco relacional, outra em uma planilha, outra em um bucket de armazenamento sem nenhuma organização. cada pipeline decide sozinho onde e como gravar seu resultado, e não existe um lugar único para consultar "o que a empresa já processou".
o lakehouse resolve isso oferecendo:
- um único lugar organizado por workspace, onde qualquer workflow pode gravar e qualquer outro workflow (ou o catálogo) pode ler;
- formato aberto: os dados são gravados em Parquet, um formato de arquivo colunar aberto e amplamente adotado no mercado — não é um formato proprietário que prende seus dados à datablixt. isso significa que, se um dia sua empresa quiser processar esses dados fora da plataforma, os arquivos continuam legíveis por qualquer ferramenta compatível;
- compatibilidade com S3: o armazenamento segue o padrão de object storage compatível com S3, o mesmo modelo usado por praticamente todo provedor de nuvem;
- organização em camadas: é uma prática comum (e recomendada) organizar os dados em camadas de maturidade — cru, tratado e pronto para consumo, o clássico padrão bronze / silver / gold — criando um lakehouse para cada camada dentro do workspace.
argumento de negócio
sem lakehouse próprio, cada novo pipeline tende a inventar seu próprio destino de dados — um banco aqui, uma planilha ali — e depois de alguns meses ninguém mais sabe onde está o dado "oficial" de determinado processo. com um lakehouse centralizado por workspace, existe sempre um único lugar de consulta, o que reduz retrabalho, evita divergência entre times, e facilita auditoria (veja governança).
como um lakehouse se relaciona com o workspace¶
cada workspace pode ter múltiplos lakehouses — normalmente um por camada de maturidade dos dados, ou um por domínio de negócio. os workflows leem e escrevem nesses lakehouses através dos nós de camada e de leitura/escrita do construtor visual; o cliente, nesta seção da documentação, gerencia os lakehouses em si — criação, tabelas, arquivos — não a lógica interna dos nós de workflow.
seções desta documentação¶
| página | descrição |
|---|---|
| criando um lakehouse | tutorial de criação e primeiros passos |
| tabelas | como as tabelas são organizadas dentro de um lakehouse |
| armazenamento | formato aberto, compatibilidade S3 e organização dos arquivos |
acesso e permissões
quem pode criar, renomear ou apagar lakehouses depende do papel do usuário no workspace. veja RBAC.