Construção de um data lakehouse

Um data lakehouse combina o armazenamento aberto e de baixo custo de um data lake com a fiabilidade de um data warehouse. Os dados são guardados em ficheiros num formato aberto, com uma camada adicional que gere as transações, a validação de esquemas e as permissões.

Assim, os relatórios, a análise e o machine learning usam as mesmas tabelas validadas, em vez de cada um depender da sua própria cópia. O lakehouse faz parte da nossa fundação de dados.

Um data warehouse disponibiliza tabelas estruturadas e depuradas para BI e é geralmente desenvolvido em SQL. Um lakehouse também pode guardar dados não estruturados e semiestruturados, como ficheiros de registo e JSON, e foi concebido para Spark e Python, além de SQL.

A distinção está a esbater-se: no Microsoft Fabric, tanto o lakehouse como o warehouse guardam tabelas Delta no OneLake. Segundo a Microsoft, um warehouse é adequado quando precisa de T-SQL e de transações que abrangem várias tabelas. Se trabalha sobretudo com dados estruturados de sistemas ERP e CRM, leia sobre a criação de um data warehouse.

A arquitetura medallion divide um lakehouse em três camadas. A camada bronze contém dados em bruto, não validados, tal como chegaram da origem. A camada prata contém dados validados, depurados e sem duplicados. A camada ouro contém tabelas organizadas por questões de negócio, para dashboards e modelos.

A Databricks apresenta-a como uma prática recomendada, não como uma obrigação, e desaconselha escrever diretamente da ingestão para a camada prata: uma alteração ao esquema na origem poderia interromper a pipeline. A Microsoft recomenda colocar cada camada num workspace próprio no Fabric, para ter mais controlo sobre cada uma.

O Delta Lake guarda os dados em ficheiros Parquet acompanhados de um registo de transações. Isto permite transações ACID, validação do esquema durante a escrita e uma versão por cada alteração, para que possa consultar um estado anterior através de time travel. É o formato predefinido tanto no Databricks como no Microsoft Fabric.

Como o protocolo é aberto, outras ferramentas também conseguem ler as tabelas. Com o UniForm, a Databricks acrescenta metadados Iceberg, permitindo aos leitores Iceberg ler os mesmos ficheiros sem criar uma cópia.

No Databricks, usa-se o Unity Catalog: as tabelas, os volumes e os modelos recebem nomes como catalog.schema.tabela, as permissões são atribuídas através de grupos e a linhagem dos dados mostra que origem alimenta cada dashboard. Para o Koninklijk Concertgebouworkest, trabalhamos com Delta Lake e Unity Catalog.

No Fabric, esse trabalho é feito pelas funções dos workspaces, pela segurança do OneLake até ao nível das linhas e colunas e pelas etiquetas de confidencialidade do Microsoft Purview. Os acordos sobre a responsabilidade pelos dados e as definições fazem parte da governação de dados.

Se alguém pedir a eliminação dos seus dados ao abrigo do RGPD, um DELETE não é suficiente. O Delta Lake conserva versões anteriores das tabelas para time travel, pelo que os dados permanecem nos ficheiros até serem removidos pelo VACUUM. Nas tabelas com deletion vectors, é ainda necessário executar primeiro um passo REORG.

A Databricks recomenda começar pela camada bronze e aplicar depois a eliminação às camadas prata e ouro. Documente esse processo antes de chegar o primeiro pedido. Cabe ao seu jurista ou responsável pela proteção de dados decidir sobre os aspetos jurídicos.

Raramente são problemas técnicos. Normalmente, falta um responsável por cada tabela, cada equipa escreve na sua própria pasta e ninguém sabe que notebook alimenta uma tabela da camada ouro. O lakehouse acaba então por se tornar num pântano de ficheiros.

A manutenção também é esquecida. Muitos ficheiros pequenos tornam as queries mais lentas e, sem VACUUM, as versões antigas fazem crescer o armazenamento. No Databricks, o predictive optimization trata disso para as tabelas geridas. Defina antecipadamente quem vai manter a plataforma após a entrada em produção; pode ser a sua própria equipa ou o nosso serviço de gestão e melhoria contínua.

Se cria relatórios a partir de algumas fontes estruturadas, a sua equipa trabalha em SQL e não prevê usar machine learning nem dados não estruturados. Nesse caso, um data warehouse é mais simples de criar e gerir. Se precisa apenas de alguns relatórios a partir de um único sistema, muitas vezes basta um modelo Power BI ligado à origem.

Um lakehouse também não resolve problemas numa fonte de dados desorganizada; comece por definir regras para a introdução dos dados. Se uma solução mais simples for mais adequada, dizemos-lhe. Se quiser comparar fornecedores primeiro, consulte a nossa visão geral de empresas especializadas em plataformas de dados.