Na parte 1 da série, compartilhamos a arquitetura customizada do Avance Network, que carrega mais de 150 TB / dia para o BigQuery.

Lição 1: as consultas podem ser (extremamente) caras

Fazemos upload continuamente de visualizações de página para o BigQuery e as mantemos por seis meses. Isso se traduz em mais de 13 PB de visualizações de página no BigQuery. Consultar o conjunto de dados inteiro seria extremamente caro, cerca de $ 65K / consulta (assumindo $ 5 / TB). 

Aplicamos alguns métodos e diretrizes para reduzir substancialmente esse custo:

Nunca use SELECT *: o custo da consulta do BigQuery é baseado no tamanho dos dados verificados. Na verdade, a maioria das consultas precisa de apenas alguns campos. Portanto, selecionar apenas os campos relevantes reduzirá drasticamente o custo da consulta.

Tabelas de cluster: o clustering é um recurso bacana do BigQuery que reduz a contagem de linhas verificadas. Com o clustering, o BigQuery otimiza o layout dos dados para reduzir o tamanho dos dados verificados ao filtrar em um campo clusterizado. Por exemplo, com o clustering no campo 'siteName', uma consulta contendo 'WHERE siteName = example.com' verificará apenas as linhas que correspondem a esse filtro, em vez de toda a tabela, reduzindo o custo significativamente.

Tabelas de partição / shard por dia : a maioria das consultas usa um intervalo de tempo de uma semana ou um mês. O particionamento diário de tabelas permite a verificação apenas dos dias relevantes, eliminando o custo de verificação de dados redundantes.

Tabelas de amostra : muitas consultas calculam informações estatísticas sobre as visualizações de página (por exemplo, taxa de cliques). Esses dados estatísticos também podem ser determinados consultando uma amostra das visualizações de página. Isso é muito mais econômico. Portanto, além das tabelas de page views completas, também temos 0,5% de tabelas de page views com amostra. Usar as tabelas de amostra reduz o custo por um fator de 1: 200.

Lição 2: novas tentativas multicamadas são essenciais

Idealmente, a arquitetura funciona sem intervenção humana. Por outro lado, o serviço é complicado e depende de outros serviços internos e externos. Esses serviços podem falhar temporariamente ou estar indisponíveis. Fazemos o possível para conter e nos recuperar automaticamente desses problemas.

Os operadores do Airflow executam suas tarefas enviando tarefas ao mecanismo. Problemas temporários de Internet ou interrupções de serviço podem fazer com que esses trabalhos falhem. Para atenuar isso, aproveitamos o recurso de nova tentativa do operador do Airflow. O Airflow tentará novamente os operadores que falharam algumas vezes antes de desistir.

A aposentadoria do operador do Airflow é uma solução simples que funciona bem. No entanto, é uma solução cara porque a execução do operador pode ser longa. Na maioria dos casos, apenas uma pequena parte do trabalho do operador falha e pode ser recuperada tentando novamente apenas a parte que falhou. Novas tentativas em camadas inferiores resolvem o problema: 

Nova tentativa de tarefa: um trabalho do servidor cria e carrega as visualizações de página para o Cloud Storage usando milhares de tarefas do que criam milhares de arquivos. É provável que algumas dessas tarefas falharão devido a falhas na Internet. Para evitar a falha de todo o trabalho junto com o operador Airflow, usamos o recurso de novas tentativas de tarefa. Cada tarefa pode ser repetida algumas vezes. Na maioria dos casos, isso salvará o trabalho. Se o problema for persistente, a função desistirá e todo o trabalho falhará.

Nova tentativa da API REST : o Airflow e o mecanismo se comunicam pela API REST. A API é vulnerável a problemas internos de rede. Portanto, novas tentativas de API são importantes. Para tentar novamente na camada da API REST, estendemos o gancho HTTP do Airflow com uma máquina de estado para se recuperar facilmente de tais problemas. Por exemplo, tente novamente no tempo limite, mas falhe (sem tentar novamente) nas respostas 4XX. Essas novas tentativas são transparentes para o operador do Airflow.

Lição 3: anexos podem corromper seus dados

Em alguns fluxos de trabalho do servidor, acrescentamos uma tabela de estágio por hora a uma tabela de produção diária. Anexar a mesma tabela de estágio duas vezes levará a dados duplicados. Por exemplo, o Airflow pode tentar novamente o operador append (copiar), o que pode levar ao acréscimo duplo. Obviamente, isso deve ser evitado!

O trabalho não existe: este é o caso típico (primeiro anexo), quando definitivamente não anexamos os dados antes. Portanto, podemos executar com segurança o trabalho de acréscimo.

Trabalho bem - sucedido : já anexamos os dados. Não há mais nada a fazer.

Job faile: Algo ruim aconteceu na última tentativa. Os dados definitivamente não foram anexados, porque o trabalho é atômico e falhou. Portanto, apresentamos o trabalho novamente.

Trabalho em execução : “adotamos” o trabalho em execução e esperamos sua conclusão.

Como sabemos qual ID de tarefa do BigQuery procurar? O truque é calcular nós mesmos um ID de trabalho exclusivo, em vez de permitir que o BigQuery o gere aleatoriamente. Antes de enviar o trabalho, anexamos o ID do trabalho à tabela de destino em uma etiqueta para garantir que sempre possamos recuperá-lo.

O khaos pode está nos detalhes

A arquitetura certa é importante, mas não o suficiente, o khaos está nos detalhes. Prestar atenção às lições descritas acima torna o servidor escalonável, confiável e econômico.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.