Construir um Arquivo Web à Escala de Petabyte

No mundo ideal de um engenheiro, a arquitetura é sempre bonita. No mundo real dos sistemas de grande escala, é preciso fazer compromissos. Um dos problemas fundamentais que um engenheiro deve considerar desde o início é o vicioso compromisso entre Velocidade de Escrita e Velocidade de Leitura.

Normalmente, sacrifica-se um pelo outro. Mas no nosso caso, trabalhando com petabytes de dados na AWS, este compromisso não afetou a nossa velocidade–afetou a carteira.

Construímos um sistema que escrevia dados perfeitamente, mas cada vez que lia do arquivo, queimava o orçamento da maneira mais dolorosa imaginável. Afinal, ler petabytes da AWS custa dinheiro para transferência de dados, contagem de solicitações e recuperações de classe de armazenamento... Muito dinheiro!

Esta é a história de como o otimizámos para torná-lo mais eficiente e económico!

Parte 0: Como Acabámos por Gastar $100.000 em Taxas da AWS!

História verdadeira: há alguns meses, um dos nossos arquitetos de soluções quis extrair uma amostra de exportação de um site raro, de baixo tráfego, para demonstrar o produto a um potencial cliente. Devido a um bug na API, o limite de segurança na contagem de arquivos não foi aplicado.

Como os dados deste site "raro" estavam espalhados por milhões de arquivos junto com sites de alto tráfego, o sistema tentou restaurar quase metade de todo o nosso armazenamento histórico para encontrar essas poucas páginas.

Esse erro honesto acabou por nos custar quase $100.000 em taxas da AWS!

Corrigi imediatamente o bug da API (e adicionei limites rigorosos), mas a vulnerabilidade arquitetónica permaneceu. Era uma bomba-relógio...

Deixe-me contar a história da arquitetura do Web Archive da Bright Data: como levei o sistema à armadilha do armazenamento "barato" e como saí usando um Pipeline de Reorganização.

Parte 1: O Legado "Escrever Primeiro"

Quando comecei a trabalhar no Web Archive, o sistema já estava a ingerir um fluxo de dados massivo: milhões de solicitações por minuto, dezenas de terabytes por dia. A arquitetura fundamental foi construída com um objetivo principal: capturar tudo sem perda de dados.

Baseava-se na estratégia mais durável para sistemas de alta taxa de transferência: Log de Apenas Anexar.

1. Os dados (HTML, JSON) são armazenados em buffer.
2. Quando o buffer atinge ~300 MB, é "selado" num arquivo TAR.
3. O arquivo voa para o S3.
4. Após 3 dias, os arquivos movem-se para o S3 Glacier Deep Archive.

Para a fase de ingestão, este design era impecável. Armazenar dados no Deep Archive custa centavos, e a taxa de transferência de escrita é praticamente ilimitada.

O Problema: Aquela Nuance de Preço

A arquitetura funcionava perfeitamente para escrita... até que os clientes começaram a pedir dados históricos. Foi quando enfrentei uma contradição fundamental:

• O Sistema Escreve por Tempo: Um arquivo das 12:00 contém uma mistura de cnn.com, google.com e shop.xyz.
• O Sistema Lê por Domínio: O cliente pergunta: "Dê-me todas as páginas de cnn.com do último ano."

Aqui está o erro que inspirou este artigo. Como muitos engenheiros, estou habituado a pensar em latência, IOPS e taxa de transferência. Mas negligenciei o modelo de faturação do AWS Glacier.

Pensei: "Bem, recuperar alguns milhares de arquivos é lento (48 horas), mas não é tão caro."

A Realidade: A AWS cobra não apenas pela chamada da API, mas pelo volume de dados restaurados ($ por GB recuperado).

O Efeito "Byte de Ouro"

Imagine que um cliente solicita 1.000 páginas de um único domínio. Como a lógica de escrita era cronológica, estas páginas podem estar espalhadas por 1.000 arquivos TAR diferentes.

Para dar ao cliente estes 50 MB de dados úteis, ocorre um desastre:

1. O sistema tem que acionar uma Restauração para 1.000 arquivos.
2. Ele levanta 300 GB de dados do "congelador" (1.000 arquivos × 300 MB).
3. A AWS cobra-nos pela restauração de 300 GB.
4. Extraio os 50 MB necessários e descarto os outros 299,95 GB 🤯.

Estávamos a pagar para restaurar terabytes de lixo apenas para extrair grãos de ouro. Era um clássico problema de Localidade de Dados que se transformou num buraco negro financeiro.

Parte 2: Corrigindo o Erro: O Pipeline de Reorganização

Não consegui mudar rapidamente o método de ingestão–o fluxo de entrada é demasiado paralelo e massivo para ser ordenado "em tempo real" (embora esteja a trabalhar nisso), e precisava de uma solução que funcionasse também para dados já arquivados.

Então, projetei o Pipeline de Reorganização, um processo em segundo plano que "desfragmenta" o arquivo.

Este é um processo ETL (Extract, Transform, Load) assíncrono, com vários componentes críticos:

1. Seleção: Não faz sentido ordenar dados que os clientes não estão a pedir. Assim, direciono todos os novos dados para o pipeline, bem como dados que os clientes especificamente pediram para restaurar. Pagamos a mais pela recuperação na primeira vez, mas nunca acontece uma segunda vez.

   \

2. Embaralhamento (Agrupamento): Vários trabalhadores descarregam arquivos não ordenados em paralelo e organizam buffers por domínio. Como o sistema é assíncrono, não me preocupo com o fluxo de entrada sobrecarregando a memória. Os trabalhadores lidam com a carga ao seu próprio ritmo.

   \

3. Reescrita: Escrevo os arquivos ordenados de volta para o S3 sob um novo prefixo (para distinguir arquivos ordenados dos brutos).

• Antes: 2024/05/05/random_id_ts.tar → [cnn, google, zara, cnn]
• Depois: 2024/05/05/cnn/random_id_ts.tar → [cnn, cnn, cnn...]

1. Troca de Metadados: No Snowflake, a tabela de metadados é apenas de anexação. Fazer MERGE INTO ou UPDATE é proibitivamente caro.

• A Solução: Descobri que era muito mais eficiente pegar todos os registos de um dia específico, escrevê-los numa tabela separada usando um JOIN, excluir os registos do dia original e inserir o dia inteiro de volta com os registos modificados. Consegui processar mais de 300 dias e mais de 160 mil milhões de operações UPDATE em apenas algumas horas num armazém Snowflake 4X-Large.

O Resultado

Esta mudança alterou radicalmente a economia do produto:

• Precisão Exata: Agora, quando um cliente pede cnn.com, o sistema restaura apenas os dados onde cnn.com vive.
• Eficiência: Dependendo da granularidade da solicitação (domínio inteiro vs. URLs específicos via regex), alcancei uma redução de 10% a 80% na recuperação de "dados lixo" (o que é diretamente proporcional ao custo).
• Novas Capacidades: Além de apenas economizar dinheiro em dumps, isso desbloqueou casos de uso de negócios totalmente novos. Como recuperar dados históricos já não é agonizantemente caro, agora podemos extrair conjuntos de dados massivos para treinar modelos de IA, realizar pesquisas de mercado de longo prazo e construir bases de conhecimento para sistemas de IA agênticos raciocinarem (pense em motores de busca especializados). O que antes era uma missão suicida financeira agora é uma operação padrão.

Estamos a Contratar

A Bright Data está a escalar o Web Archive ainda mais. Se gosta de:

• Sistemas distribuídos de alta taxa de transferência,
• Engenharia de dados em escala massiva,
• Construir pipelines confiáveis sob carga do mundo real,
• Levar o Node.js aos seus limites absolutos,
• Resolver problemas que não aparecem em livros didáticos...

Então adoraria conversar.

Estamos a contratar engenheiros Node.js fortes para ajudar a construir a próxima geração do Web Archive. Ter experiência em engenharia de dados e ETL é altamente vantajoso. Sinta-se à vontade para enviar o seu CV para [email protected].

Mais atualizações virão à medida que continuo a escalar o arquivo—e à medida que continuo a encontrar formas novas e criativas de o quebrar!

\