- Ao processar cerca de 1,75 GB de dados de partidas de xadrez com ferramentas de linha de comando em vez de Hadoop, a tarefa foi concluída em apenas 12 segundos, mostrando desempenho mais de 235 vezes superior aos 26 minutos do Hadoop
- Combinando comandos básicos de shell como grep, sort, uniq, awk, xargs e mawk, foi montado um pipeline de processamento em streaming, mantendo o uso de memória praticamente em zero
- Com processamento paralelo com xargs e otimização com mawk, o aproveitamento dos núcleos de CPU aumentou e os gargalos de IO foram minimizados
- Em comparação com o processamento do mesmo conjunto de dados em um cluster Hadoop (7 instâncias c1.medium), o custo e a carga de manutenção são significativamente menores
- O caso mostra que é possível fazer análise de dados eficiente até mesmo em uma única máquina e chama atenção para o uso desnecessário de ferramentas de Big Data
Introdução: processamento em linha de comando mais rápido que Hadoop
- Após ver um caso de análise de cerca de 2 milhões de partidas de xadrez com Amazon EMR e mrjob, o mesmo conjunto de dados foi reproduzido com processamento em streaming baseado em linha de comando
- No cluster Hadoop (7 máquinas c1.medium), foram necessários 26 minutos, com taxa de processamento de 1,14 MB/sec
- Em um notebook local, a tarefa terminou em 12 segundos, com taxa de processamento de 270 MB/sec
- Fica demonstrado que tarefas simples de agregação de resultados são muito mais eficientes com pipelines de shell do que com Hadoop
- Ao combinar comandos de shell, é possível implementar em uma única máquina uma estrutura de processamento paralelo em fluxo semelhante ao Storm
Estrutura e preparação dos dados
- Os dados estão no formato PGN (Portable Game Notation), que registra partidas de xadrez, e o resultado de cada partida aparece na linha
"Result"
"1-0" significa vitória das brancas, "0-1" vitória das pretas e "1/2-1/2" empate
- Foi obtido um conjunto de dados de cerca de 3,46 GB no repositório rozim/ChessData no GitHub
- Aproximadamente o dobro do conjunto usado no experimento de Tom Hayden (1,75 GB)
Construção do pipeline básico
Paralelização e otimização
Conclusão: a eficiência da simplicidade
- Exceto quando é realmente necessário processamento distribuído em larga escala, a combinação de ferramentas de shell em uma única máquina é mais rápida e mais econômica
- O Hadoop muitas vezes vem sendo usado em excesso até para tarefas que um banco de dados relacional ou um script simples resolveriam
- A análise em streaming baseada em linha de comando é uma excelente alternativa em termos de desempenho, custo de implementação e manutenibilidade
2 comentários
Antigamente existia a expressão programação Taco Bell, então parece uma filosofia parecida.
Comentários do Hacker News
A parte mais triste é que este texto é de 2014
Hoje existem ainda mais camadas de abstração, como Airflow, dbt e Snowflake, e elas acabam sendo colocadas por cima até de datasets que cabem inteiros na RAM
Startups torram US$ 5 mil por mês em clusters distribuídos para processar menos de 10 GB de logs por dia. O motivo é que usar o ‘Modern Data Stack’ rende promoção, mas resolver com scripts bash é descartado como ‘não escalável’. Eficiência e incentivos estão completamente desalinhados
Houve até um caso de ingestão de 1 GB de JSON por dia, e quando expliquei que uma máquina só bastava, responderam: “tecnicamente está certo, mas não é a resposta que queremos” — e me rejeitaram
As máquinas de hoje têm RAM na casa dos TBs e centenas de núcleos. Uma única máquina já é enorme
Ao contratar gente de DevOps, enfatizam experiência com frameworks chamativos, então essas pessoas chegam à empresa e repetem exatamente a mesma coisa
Como ninguém contesta, acabam complicando trabalhos que um desktop sozinho daria conta
Estou há mais de um ano procurando emprego com um currículo quase sem frameworks da moda, e começo a me sentir um idiota
Em 2014, 4 GB era algo normal, mas agora a velocidade de streaming via SSD também aumentou, então às vezes ler de um SSD local é melhor do que usar um cluster
Sou o autor do texto!
Fico feliz que um texto antigo ainda seja útil
Concordo com a opinião de que a situação piorou, mas por outro lado também vejo um movimento de afastamento da adoração cega por microservices, o que é um alívio
Mando meu apoio a todos que estão trabalhando para melhorar desempenho. Ainda há esperança
Reli o texto várias vezes e, inspirado por ele, portei a Waters-Series para JavaScript para implementar pipeline de streams
Hoje o setor tem uma noção forte demais de que Spark ou ferramentas distribuídas são a resposta certa para engenharia de dados
É parecido com o uso excessivo de frameworks SPA no desenvolvimento web
Meu conselho é o seguinte:
O que o gestor quer ouvir não é ‘tudo escala infinitamente’, mas a confiança de que ‘isso roda com estabilidade’
O tamanho dos dados segue uma lei de potência, então engenheiros que realmente trabalham com dados em escala de petabytes são uma minoria minúscula
Mas, como muita gente quer colocar esse tipo de experiência no currículo para ganhar mais, acaba surgindo engenharia excessiva
Quando perguntei por quê, a resposta foi: “porque temos que usar”. Provavelmente era por causa de currículo ou de algum motivo político de alguém
Uma história histórica relacionada ao texto
A ferramenta mrjob também podia rodar em modo local, sem Hadoop
Em datasets pequenos, era muito mais rápida que um cluster. Especialmente mais rápida do que clusters temporários como AWS EMR
Mesmo assim, a abordagem do autor provavelmente era ainda mais eficiente que isso
O MapReduce facilitava escalar para volumes grandes, mas para dados pequenos vinha com muitas restrições ineficientes
No começo dos anos 2010, processei dados em escala de petabytes com mrjob, mas hoje quase ninguém usa mais
Quando trabalhei como engenheiro de dados, reescrevi scripts Bash/Python em C# e levei a velocidade de processamento de JSON a 1 GB/s
Só com otimizações simples, como parsing em streaming, já deu uma diferença enorme
Então fico curioso — a partir de que volume de dados um cluster realmente passa a fazer sentido?
Para mim, se a tarefa leva mais de um dia, já vale considerar processamento distribuído
Quando os dados eram grandes, ele fazia amostragem e analisava no Excel. Hoje, com LLMs, até scripts simples em Python/Bash ficaram fáceis de escrever
Já dá para ler e gravar direto em armazenamento de objetos como S3, e hoje dá para chegar a 100 GB/s
Cabe em disco, mas é grande demais para um notebook comum
O ‘tamanho’ dos dados depende do que você quer fazer com eles
Por exemplo, para estatísticas simples em dados cirúrgicos, bash basta; mas se quiser calcular a correlação entre experiência do médico e taxa de sucesso, a complexidade sobe drasticamente
Então, do ponto de vista da empresa, é muito mais fácil dizer “usamos Spark” do que dizer “criamos um motor sob medida para cada pergunta”
Todos os problemas mencionados podem ser resolvidos em um único servidor com ferramentas simples
Este texto já apareceu várias vezes no HN
A versão de 2018, a versão de 2022 e a versão de 2024 foram enviadas pela mesma pessoa
Isso me lembra a frase de apresentação do antigo site da Shakti
“1K rows: Excel / 1M rows: Pandas / 1B rows: Shakti / 1T rows: Only Shakti”
Fonte
Muitos desenvolvedores aprenderam em ambiente Windows e não estão acostumados com ferramentas de CLI
Mas a CLI oferece recursos poderosos, como loops implícitos, separação automática de campos e aplicação paralela de expressões regulares
Isso ajuda a criar rapidamente soluções ad-hoc e serve como um ótimo ponto de partida antes de partir para sistemas grandes
Fico pensando como seria refazer o benchmark escalando bem mais os dados de xadrez
Hoje o dataset do Lichess tem cerca de 7B partidas, 2,34 TB compactado (14 TB sem compactação)
Será que nessa escala o Hadoop venceria?
Mas isso também exige administrar um servidor dedicado
O EMR é um modelo pensado para processamento paralelo quando a frequência de acesso aos dados é baixa (de 1 a 10 vezes por dia)