Duas empresas guardam exatamente os mesmos dados, na mesma plataforma, com o mesmo hardware. Numa, uma consulta corre em segundos; na outra, a mesma consulta demora minutos e custa dez vezes mais. A diferença não está nos dados nem na ferramenta — está numa decisão de design que quase ninguém discute em voz alta mas que decide se um data lake voa ou rasteja: o particionamento. É uma daquelas escolhas invisíveis que não aparecem em nenhuma demonstração, mas que separam uma plataforma de dados rápida e barata de uma lenta e cara.
O particionamento é a arte de organizar fisicamente os dados de forma a que as consultas só precisem de ler o que interessa. É o equivalente, no mundo dos dados, a arrumar um armazém: se os produtos estão organizados por corredor e prateleira, encontras o que procuras num instante; se estão todos amontoados sem critério, tens de revirar tudo de cada vez. A um volume pequeno, a desarrumação passa despercebida; a grande escala, é a diferença entre operar bem e afogar-se.
O problema de ler tudo para responder a pouco
Imagina que guardas anos de transações num data lake e queres analisar as vendas de um único mês. Sem particionamento, o sistema não sabe onde estão as vendas desse mês — estão misturadas com todas as outras. Para responder, tem de ler o conjunto inteiro, filtrar o que interessa e deitar fora o resto. Leste milhares de milhões de linhas para usar uma fração delas. Esse trabalho desperdiçado traduz-se diretamente em tempo de espera e em custo de processamento, porque na cloud pagas pelo que o sistema lê.
É este desperdício que cresce de forma perigosa com a escala. Com poucos dados, ler tudo é rápido e barato, e ninguém liga. Mas à medida que o volume aumenta, cada consulta que lê o conjunto inteiro fica mais lenta e mais cara, de forma linear. Chega um ponto em que a plataforma, que parecia funcionar bem, se torna dolorosamente lenta e a fatura dispara — e a causa raramente é óbvia, porque nada "está partido"; está apenas mal organizado.
A ideia central: dividir por aquilo por que se pesquisa
O particionamento resolve isto dividindo os dados em pedaços — as partições — segundo uma coluna por que se costuma filtrar. O caso mais comum é a data: os dados de cada dia, ou de cada mês, ficam num pedaço próprio e separado. Assim, quando uma consulta pede "as vendas de março", o sistema sabe ir diretamente à partição de março e ignora todas as outras. Em vez de ler o conjunto inteiro, lê uma fatia minúscula. É a mesma consulta, os mesmos dados, mas com uma organização que permite ao sistema saltar o que não interessa.
A escolha da coluna de particionamento é, por isso, a decisão que tudo decide. A regra é dividir pela coluna por que mais se filtra nas consultas reais. Se quase todas as análises são por período, particiona por data. Se muitas são por região, a região pode ser uma boa candidata. Particionar pela coluna errada — uma por que ninguém filtra — não ajuda nada, porque as consultas continuam a ter de ler tudo. Conhecer os padrões de acesso reais é o que separa um bom particionamento de um inútil.
O outro extremo: partições a mais também matam o desempenho
Seria tentador concluir que quanto mais fino o particionamento, melhor — dividir por dia, por hora, por minuto. Mas há um limite, e ultrapassá-lo tem o efeito oposto ao desejado. Cada partição é, tipicamente, um ou mais ficheiros; dividir demais gera uma multidão de ficheiros minúsculos. E ler milhares de ficheiros minúsculos é, paradoxalmente, mais lento do que ler alguns ficheiros de tamanho saudável — o sistema perde-se a abrir e fechar ficheiros em vez de processar dados. É o famoso "problema dos ficheiros pequenos", uma das causas mais comuns de um data lake lento.
O equilíbrio, portanto, não é "quanto mais partições melhor", mas "partições do tamanho certo". Grandes de mais e as consultas leem mais do que precisam; pequenas de mais e o sistema afoga-se em ficheiros. Encontrar o ponto certo — dividir o suficiente para saltar o irrelevante, mas não tanto que se fragmente em migalhas — é a essência de um bom particionamento.
Um caso concreto
Uma empresa tinha um data lake com vários anos de eventos e queixava-se de que as consultas de análise eram lentíssimas e a fatura de processamento não parava de subir. A primeira reação foi pensar em comprar mais capacidade. Antes disso, alguém olhou para como os dados estavam organizados e encontrou a raiz do problema: os eventos estavam todos juntos, sem qualquer particionamento, apesar de praticamente todas as consultas filtrarem por um intervalo de datas. Cada consulta, por mais estreita que fosse, era obrigada a ler os anos todos. Reorganizaram os dados particionados por data. O efeito foi imediato e dramático: as consultas que analisavam um período curto passaram a ler apenas as partições desse período, e o tempo caiu de minutos para segundos, com a fatura de processamento a descer na mesma proporção. Não compraram um único servidor a mais — apenas arrumaram os dados de forma a que o sistema pudesse saltar o que não precisava de ler. A mesma plataforma, uma decisão de design diferente, um problema resolvido pela raiz.
Uma decisão de design, não um acidente
A lição mais importante é que o particionamento não deve ser deixado ao acaso. É uma decisão de design que se toma cedo, com base em como os dados vão ser consultados, e que se revê à medida que os padrões mudam. Uma boa escolha aqui paga dividendos em cada consulta, todos os dias, para sempre; uma má escolha, ou a ausência de escolha, cobra um imposto silencioso em cada consulta, também para sempre. Poucas decisões técnicas têm um retorno tão desproporcionado face ao esforço de as tomar bem.
Na prática
Se o teu data lake está lento e caro à medida que cresce, antes de comprar mais capacidade, olha para como os dados estão organizados fisicamente. Pergunta: por que coluna filtram a maioria das minhas consultas, e os dados estão divididos por essa coluna? Muitas vezes, a resposta a essas duas perguntas é o caminho mais barato e mais eficaz para uma plataforma rápida. Os teus dados estão arrumados de forma a que o sistema salte o que não interessa, ou está a ler tudo, sempre, para responder a pouco?
