Como construir uma plataforma de dados lakehouse escalável e económica

Na última década, passámos de armazéns de dados rígidos para data lakes flexíveis e, mais recentemente, para arquiteturas lakehouse que prometem combinar o melhor de ambos os mundos.

No entanto, a transição de uma geração de plataformas de dados para a seguinte está a revelar-se mais difícil do que o esperado. Aqueles que já estão nesta jornada estão a descobrir desafios e a repetir erros ao transportar antigos padrões de design para novos sistemas.

Tendo ajudado várias organizações a projetar e escalar plataformas de dados modernas, vi que o sucesso não depende de ferramentas, mas de disciplina. Este artigo é um guia prático sobre como fazer a transição de forma eficaz, o que evitar e como traduzir escolhas técnicas em valor de negócio mensurável.

Por que a Pura História do Big Data já não é Útil

Se olharmos para trás, o movimento de big data começou com o sonho de armazenamento ilimitado e experimentação infinita. Por volta de meados da década de 2010, as empresas começaram a recolher todos os logs, cliques e transações possíveis, convencidas de que apenas o Volume traria insights. Na prática, esta crença apenas criou mais complexidade. Os data lakes surgiram como o sucessor da moda aos armazéns, mas a maioria deles tornou-se rapidamente pântanos de dados, lugares onde a informação entrava facilmente mas raramente voltava numa forma utilizável.

Em 2022, a indústria tinha amadurecido e as questões começaram a mudar. As equipas já não perguntam quanto dados podem armazenar, mas como podem confiar e usar o que já têm. O verdadeiro desafio hoje não é a capacidade, mas a governação, não é a ingestão, mas a interpretação.

A lição chave aqui é simples. Recolher mais dados não torna uma empresa orientada por dados. O que realmente importa é compreender os dados, manter uma governação adequada e usá-los de forma eficiente.

Recomendo definir propriedade para cada conjunto de dados, estabelecer políticas claras de retenção e qualidade, e concentrar os esforços de engenharia nos dados que apoiam diretamente as decisões de negócio. Sem esta base, até o lakehouse mais avançado acaba por se tornar num pântano moderno.

O Lakehouse como Ponto de Viragem

A ascensão do lakehouse reflete exatamente esta mudança. Em vez de escolher entre desempenho e flexibilidade, o modelo lakehouse combina ambos. No seu núcleo, utiliza armazenamento em nuvem económico em formatos como Delta ou Iceberg, enriquecido com metadados e garantias transacionais. O resultado é um sistema que custa tão pouco como um lake e comporta-se como um armazém quando consultado.

Isto é importante para os líderes empresariais porque remove a constante troca entre armazenamento barato para dados históricos e sistemas dispendiosos para análises em tempo real. Sugiro sempre posicionar o vosso lakehouse não como uma substituição para tudo o resto, mas como uma base partilhada que permite tanto análises tradicionais como machine learning num só ambiente.

Num lakehouse, o mesmo ambiente pode suportar um Painel para o Diretor de tecnologia (CTO), um modelo de machine learning que prevê o comportamento do cliente e uma consulta ad hoc de um Analista de produto. Os dados já não são duplicados entre sistemas, o que torna a governação mais simples e permite que a Otimização de custos aconteça naturalmente.

Desafios Estruturais e de Governação na Adoção de Data Lakehouse

Quando as empresas passam de armazéns de dados clássicos ou data lakes para uma arquitetura lakehouse mais flexível, a transição raramente é suave. Muitas equipas copiam estruturas existentes do antigo armazém para o novo ambiente sem repensar o seu propósito. O resultado é o surgimento de silos de dados, ou seja, fragmentação. Uma versão dos dados vive no armazém, outra no lake e uma terceira algures no meio. Evite isto redesenhando esquemas para o lakehouse desde o início. Modele dados com base em padrões de acesso e necessidades do consumidor, em vez de lógica de armazém legada.

Outro problema recorrente é a normalização. O que quero dizer com isto? Os armazéns são construídos sobre estruturas estritas e profundamente normalizadas com dezenas de tabelas interconectadas. Quando estas são copiadas diretamente para um lake, cada consulta requer uma floresta de joins. O desempenho colapsa, os engenheiros culpam a infraestrutura e o projeto perde credibilidade. Em vez disso, desnormalize onde ajuda o desempenho e coloque entidades relacionadas mais próximas para minimizar shuffle. Trate o design de desempenho como parte da modelagem de dados, não como uma Otimização posterior.

A governação e o controlo são críticos. Num data lake, há frequentemente pouca supervisão porque as equipas trabalham diretamente com ficheiros. Num armazém, aplicam-se regras estritas como segurança ao Nível de linha, acesso baseado em funções e trilhas de auditoria detalhadas. Um lakehouse deve encontrar um equilíbrio garantindo abertura sem perder responsabilidade. Deve implementar acesso baseado em funções e rastreamento de linhagem desde o início. A governação funciona melhor quando cresce juntamente com a plataforma e se torna a base da confiança.

O desempenho também depende de design inteligente. Os armazéns tradicionais dependem de Indexação automática, mas nos lakehouses a eficiência vem de particionamento ou liquid clustering, caching e escolha dos formatos de ficheiro certos para análises. Recomendo tratar a estratégia de particionamento e o layout de ficheiros como cidadãos de primeira classe na vossa arquitetura.

A Otimização de custos é outra promessa chave do lakehouse, mas não acontece automaticamente. Embora o armazenamento em nuvem seja económico e a análise possa escalar para cima ou para baixo conforme necessário, estas vantagens são frequentemente compensadas por design de dados deficiente e crescimento descontrolado. Deve gerir ativamente os ciclos de vida dos conjuntos de dados e remover cópias não utilizadas. Se este processo for ignorado, os custos da nuvem aumentarão silenciosamente ao longo do tempo.

Otimização de Custos como Regra Número Um

Gostaria de me focar em mais detalhe na Otimização de custos, pois é uma das principais vantagens da arquitetura lakehouse.

Uma das principais formas como a arquitetura lakehouse reduz custos é minimizando o shuffle, ou seja, o movimento de dados entre sistemas ou nós de processamento. Para alcançar isto, projete sempre os seus dados de modo a que entidades relacionadas sejam armazenadas juntas.

Ao manter todos os dados num só lugar e armazenar entidades relacionadas próximas umas das outras, o lakehouse remove a necessidade de joins excessivos e Transferências de dados. Quando realizamos análises, por exemplo ao construir um modelo de machine learning para análise de clientes, podemos usar tanto dados históricos como transacionais reais sem copiar ou movê-los entre sistemas.

Outro princípio chave que permite a Otimização de custos é a separação de armazenamento e computação. O armazenamento de dados e o processamento de dados escalam independentemente com base na procura real. Pagamos apenas pelos recursos que usamos em vez de manter grandes sistemas de capacidade fixa. O armazenamento permanece económico e escalável, e o poder de computação pode ser aumentado ou reduzido quando necessário. Esta flexibilidade leva a custos de infraestrutura mais baixos e operações de dados mais eficientes. Comece sempre pequeno e deixe o autoscaling fazer o seu trabalho. Monitorize o uso e compreenda os seus padrões de carga de trabalho antes de se comprometer com capacidade reservada.

Os clusters de auto-scaling ajudam ainda mais a controlar custos. Uma carga de trabalho de machine learning precisa de recursos de computação nuvem, máquinas virtuais com memória e poder de processamento semelhantes a um computador normal. No passado, as empresas compravam ou alugavam servidores físicos antecipadamente e executavam processos nessa capacidade fixa. Na nuvem, pagamos por computação com base no uso real, por unidade de tempo e por quantidade de recursos. Recomendo fortemente começar com tamanhos mínimos de cluster, observar o comportamento de escalamento e definir limites superiores para prevenir custos descontrolados.

Escolher a Abordagem de Arquitetura Certa

Vamos falar sobre a arquitetura lakehouse. De muitas formas, o seu design depende de como estruturamos o modelo de dados. A abordagem mais comum e eficaz é a arquitetura em camadas, ou medallion, onde cada camada serve um propósito específico e suporta diferentes tipos de utilizadores e cargas de trabalho.

— A primeira camada, frequentemente chamada raw ou bronze, é uma cópia direta dos Dados de mercado de origem. Serve principalmente necessidades técnicas e é mantida apenas por um curto período para permitir reprocessamento rápido quando necessário. Deve ser tratada como armazenamento temporário.

— A segunda camada, ou camada de normalização, contém dados limpos e estruturados, às vezes unidos com outras tabelas como utilizadores e encomendas. É aqui que os modelos de machine learning são frequentemente treinados. É boa prática automatizar a validação de dados e a aplicação de esquemas nesta fase. Manter consistência é mais valioso do que processar grandes volumes de dados.

— A camada final, conhecida como camada gold, é onde vivem os dados agregados. Painéis e ferramentas de BI como Tableau ou Power BI normalmente conectam-se a esta camada para aceder a métricas e visualizações prontas. Ainda assim, nem tudo pode ser pré-calculado.

Cada camada tem um propósito e, juntas, permitem que tanto machine learning como business intelligence prosperem.

Deve alinhar a sua estratégia de camadas com padrões de consumo. Os cientistas de dados normalmente trabalham com a camada silver, e os executivos esperam respostas da camada gold. A flexibilidade é a verdadeira força do lakehouse, a capacidade de servir múltiplas audiências sem construir e manter múltiplos sistemas separados.

Insights do terreno

Se estivesse a projetar desde o início, faria algumas coisas de forma diferente de como a indústria abordou os dados no passado.

Abaixo estão as lições que aprendi com implementações reais e o que agora recomendo.

1. Comece pequeno, entregue rápido

Migrar tudo de uma vez nem sempre é ideal. As empresas frequentemente tentam levantar e mudar terabytes de dados para um novo sistema, apenas para descobrir que ninguém o usa. Um caminho melhor é começar com um único caso de uso que entrega valor de negócio claro, como um motor de recomendação, preços dinâmicos ou um modelo de retenção de clientes. O sucesso nessa Área fornece tanto credibilidade como um modelo para escalar.

1. Traduza Requisitos de negócio cedo

Traduziria Requisitos de negócio em técnicos o mais cedo possível. Se um relatório precisa filtrar por região, esse requisito implica particionamento por região ao Nível de armazenamento. Se os Analistas esperam atualizações quase em tempo real, isso conduz decisões sobre Indexação ou caching. Sem esta tradução, a tecnologia afasta-se dos objetivos de negócio e a confiança corrói-se.

1. Adeque a tecnologia à capacidade organizacional

Adequaria sempre a tecnologia às capacidades da organização. Uma empresa com uma forte cultura de engenharia pode preferir componentes open source e controlo máximo. Um negócio com recursos técnicos limitados pode ser melhor servido por serviços geridos que expõem interfaces SQL aos Analistas. Não há solução universal, o que importa é alinhar ambição com capacidade.

Finalmente, questionaria a suposição de que um lakehouse é simplesmente um lake melhor. Na realidade, é um paradigma diferente. Herda algumas características tanto de lakes como de armazéns, mas não é uma substituição para todos os casos de uso. Cargas de trabalho transacionais de alta frequência, por exemplo, podem ainda requerer sistemas especializados. Reconhecer estas fronteiras previne deceções e garante que o lakehouse é usado onde realmente se destaca.