Get best of the week

Como é organizado o sistema de conteúdo das páginas Turbo: esquemas, fatos e um pouco de história



Segundo o TelecomDaily , quase 30% dos usuários de Internet móvel na Rússia diariamente têm problemas para baixar sites. No entanto, o motivo pode estar não apenas na cobertura desigual, mas também no excesso de "peso" da página.

Não podemos influenciar a qualidade da conexão, mas para ajudar os webmasters a simplificar o conteúdo do site, facilite - por que não? Assim, a tecnologia das páginas Turbo apareceu no Yandex: tudo o que é necessário para a colocação é transferido para o nosso sistema de conteúdo e converte esses dados em materiais fáceis e rápidos.

Como essa mágica funciona? Qual é o caminho dos dados antes de se tornar uma página Turbo completa? Meu nome é Stas Makeev, lidero o desenvolvimento de páginas de tecnologia Turbo. Agora vou tentar explicar tudo.

Mas, primeiro, é um resumo para que você não se perca quando eu começar a me aprofundar nos detalhes.

Uma vantagem importante do sistema de páginas Turbo é a rápida conversão de dados da forma original para a final: os materiais dos sites de notícias são mais procurados nos primeiros minutos após a publicação, e os cartões de mercadorias das lojas online devem ser atualizados rapidamente e sempre corresponder ao status atual de disponibilidade. O segundo parâmetro importante é a confiabilidade: o sistema de conteúdo deve ser o mais estável possível, capaz de sobreviver à quebra de servidores individuais ou mesmo de datacenters inteiros. E, é claro, era importante evitar carga excessiva nos hosts de nossos parceiros conectados às páginas do Turbo. Ou seja, ao projetar o serviço, era necessário encontrar um equilíbrio entre a velocidade do processamento de dados e o aumento no número de solicitações.

Os proprietários do site têm várias maneiras de se conectar ao sistema:

  • . : YML — -, RSS – ;
  • API: ( );
  • : - .

O sistema de conteúdo armazena os resultados de seu trabalho em um armazenamento especial do tipo "valor-chave" (armazenamento de valor-chave ou armazenamento KV), em que a chave é a URL do site original e o valor armazena o conteúdo da página Turbo. Assim que os dados entram nesse armazenamento KV, a próxima página Turbo fica imediatamente disponível para procurar usuários, e nos serviços Yandex o documento correspondente tem um ícone especial com um foguete. Além disso, para acelerar o trabalho, armazenamos em cache fotos e vídeos em nossas CDNs.

Um esquema geral de trabalho muito simplificado se parece com isso:



Como tudo começou


A primeira versão do sistema de conteúdo foi organizada de maneira simples: a cada poucos minutos, de acordo com o cronograma, o mesmo programa era lançado no servidor em nuvem interno do Yandex. Consistia em várias etapas, cada execução seguinte após os dados anteriores estarem prontos para todos os feeds que conhecemos:

  • A lista de feeds RSS foi baixada, o analisador de documentos foi lançado;
  • uma lista de imagens foi extraída dos resultados do analisador;
  • ainda não foram carregadas imagens em cache na CDN;
  • documentos processados ​​foram despejados no repositório KV.

Esse esquema funcionou perfeitamente quando o sistema lidou com milhares de feeds RSS bastante leves de agências de notícias (no total - informações sobre pouco menos de 100.000 documentos). Porém, com o aumento do número de feeds, um problema foi rapidamente descoberto: cada etapa demorava cada vez mais, havia um atraso entre a aparência de um novo documento na fonte original e a exibição no modo Turbo.

Conseguimos manter a situação sob controle com a ajuda de vários truques: a primeira coisa que fizemos foi selecionar o primeiro passo (baixar feeds RSS + um analisador de documentos) em um processo separado. Ou seja, enquanto um processava imagens para a iteração anterior, o outro processo já estava baixando feeds para a próxima. Depois de algum tempo, ficou claro: dessa forma, o sistema é muito difícil de escalar. Precisamos de algo fundamentalmente novo.

Processando RSS, API e YML no novo sistema de conteúdo


O principal problema do antigo sistema de conteúdo era que todos os dados foram processados ​​em uma única peça: não houve transição para a próxima etapa até que cada documento passasse pela anterior. Para se livrar disso, foi decidido construir um determinado pipeline: permita que os feeds e documentos individuais sejam processados ​​da maneira mais independente possível. Todas as etapas foram separadas em cubos de serviço separados - no nível superior, o esquema ficou assim:



  • o primeiro cubo baixa feeds RSS e passa adiante;
  • o segundo - pega feeds um por um, analisa o conteúdo. Na saída - documentos separados;
  • o terceiro - pega documentos um de cada vez, processa fotos e vídeos, grava tudo no armazenamento KV.

Os mesmos feeds podem ser registrados não apenas no Turbo, mas também em nossos outros serviços - no News ou no Market, por exemplo. Se cada um deles baixar dados por conta própria, a carga no servidor de webmasters será várias vezes maior que a permitida. Quão certo? Faça o download do feed uma vez e depois distribua o conteúdo a todos os serviços ao consumidor - o Yandex.Robot faz isso. Utilizamos seus serviços para baixar conteúdo: pegamos no Yandex.Webmaster uma lista de feeds RSS e YML registrados no Turbo, transferimos para o Robot e assinamos os resultados do download.

Nos dados recebidos, inicie o analisador. Só para lembrar, um feed RSS é apenas um arquivo no formato ".XML", acessível por um URL estático no host do parceiro. Este arquivo contém informações sobre todas as atualizações no site - quais documentos são novos, quais são alterados. Somente as informações mais atualizadas nas últimas horas estariam nos feeds ideais: não mais que 100 documentos por centenas de kilobytes.

Mordidas da realidade: às vezes os arquivos ficam dentro do feed por um período muito longo e nunca mudam. Como evitar o reprocessamento nesses casos? Calculamos o hash de cada documento, armazenamos no banco de dados e não fazemos nada até que o hash seja alterado.

O processamento de feeds e APIs YML do ponto de vista do sistema de conteúdo é praticamente diferente de interagir com o RSS: para YML, iniciamos outro analisador, e os dados transmitidos pela API são obtidos diretamente no Yandex.Webmaster.



Processamento de imagem e vídeo


O documento recebido na saída do analisador está quase pronto para gravação no armazenamento KV. A única coisa que resta a fazer antes do envio é processar as imagens e vídeos: armazenar em cache na CDN e substituir os links no documento. Aqui, novamente, procuramos o robô para obter ajuda.

Antes de tudo, verificamos cada foto e vídeo: eles estão na CDN? Se tudo já estiver em cache, substitua os links e envie o documento atualizado para o repositório KV. De outra forma:

  • enviamos a lista de URLs ausentes ao robô para planejamento e download;
  • o documento em si está em armazenamento temporário; portanto, depois de um tempo, tente verificar novamente.

Outro cubo no momento recebe os resultados do download, carrega os dados na CDN e atualiza o banco de dados.

Nesse esquema, outro problema importante relacionado ao planejamento pode ser resolvido: o robô entende a rapidez com que é possível baixar dados de diferentes hosts e não permite sobrecargas.



Caminho típico que um novo documento segue:

  • O documento aparece no feed.
  • O robô faz o download do feed;
  • o analisador descobre um novo documento e o envia mais;
  • verificamos que as imagens do documento não são mencionadas no banco de dados, solicitamos o download, o documento é enviado para armazenamento temporário (Atraso). Enquanto o documento estiver lá, o Robot fará o download das imagens, elas serão armazenadas em cache na CDN e os links aparecerão no banco de dados;
  • , CDN, KV-.
  • : , Delay.


Há outra maneira de conectar-se às páginas Turbo, para as quais o webmaster não precisa fazer nada - o Autoparser. Ele cria páginas Turbo com base nos dados de origem do site de conteúdo. Você pode se conectar, ver exemplos de páginas concluídas, configurar anúncios e análises no Yandex.Webmaster.

A principal dificuldade que o AutoParser enfrenta é reconhecer pela marcação HTML quais informações básicas devem ser usadas ao criar uma página Turbo. Para fazer isso, temos vários processos offline que estão tentando entender exatamente como analisar um host específico. Vou me concentrar em dois principais:

  • O primeiro RSS- HTML- . — , RSS- ( ), . , . CatBoost , , . , , , . , . , , , HTML . ? : . – , .
  • : .. , , , , — . — .

A propósito, mais um obstáculo frequente - muitos sites bloqueiam a capacidade de baixar imagens de robôs no robots.txt. Infelizmente, é impossível contornar esse problema, e o Autoparser não está disponível para essas páginas.

Como resultado, o esquema completo do sistema de conteúdo fica assim:



O sistema acabou sendo escalonável: agora uma quantidade significativa de recursos é usada para atender o banco de dados, o autoparser e outros componentes do sistema (apenas o cubo responsável pela análise de RSS, YML e API usa mais de 300 processadores núcleos) e, em caso de aumento de carga, não será muito difícil conectar capacidades adicionais.

Obrigado por ler até o fim! Espero que, após este material, no trabalho das páginas Turbo você tenha mais lógica e menos magia (a propósito, aqui- ainda mais detalhes sobre as páginas Turbo). Se algo ainda for incompreensível, escreva nos comentários - estamos em contato.

More articles:


All Articles