Como fazer buscas em mais de um bilhão de notícias



Imagine o desafio de encontrar apenas notícias do seu interesse analisando mais de um bilhão delas? Adicione, então, mais um milhão a cada novo dia. E, para completar, você precisa encontra-las e menos de um segundo. Esse é o cenário que temos na Knewin hoje.

Quando decidimos trabalhar com coleta de notícias nós já sabíamos que precisávamos captura-las e disponibiliza-las para nossos clientes tão logo fossem publicadas. Afinal, notícia é algo que precisa ser lida agora. Mesmo assim, nossos clientes ainda precisam ter acesso às notícias antigas para construir certos tipos de relatórios ou gerar análises históricas. Saber o que foi publicado no passado sobre uma marca ou produto, por exemplo, pode ajudar a definir ações para o presente e futuro.

Montar essa base de notícias levou anos. Além de ter sido trabalhoso, também é complexo. A maioria dos sistemas que criamos vieram de ideias lidas em artigos científicos. Com o tempo e a prática, evoluímos nossos sistemas para ter maior eficiência. Hoje, cinco etapas são executadas para ter uma notícia disponível para os clientes em nossos sistemas: coleta, estruturação, enriquecimento, armazenamento e indexação.

A etapa de coleta das notícias ocorre por meio de um crawler (ou robô) que navega nas páginas dos sites. O crawler analisa cada página e verifica se o principal conteúdo dela é de uma notícia. Se a página não contém uma notícia, o crawler apenas extrai os links da página e a descarta na sequência. Já, se há uma notícia, ele envia a página para a próxima etapa (mais detalhes sobre nosso crawler em Como coletar milhões de notícias online).

A segunda etapa, de estruturação, analisa o código da página e extrai os dados que fazem parte da notícia. Os principais dados são: o título, a data, o autor, o texto completo e as imagens. Extrai-se, ainda, para alguns veículos, outros dados como, por exemplo, a seção do veículo, a categoria da notícia, e assim por diante.

Há muitos desafios para extrair os dados de uma notícia. Em nosso caso, esse desafio é maior por que temos que lidar com milhares de sites diferentes. As páginas desses veículos contêm vários tipos de conteúdo, além dos dados da própria notícia, como links para outras notícias, assuntos e categorias, botões para compartilhar em redes sociais; também apresentam anúncios (i.e., publicidade) ao redor ou, até mesmo, no meio do texto da notícia.

Nós criamos diversos códigos específicos para extrair cada tipo de dado de uma notícia. No entanto, nem sempre é possível extrair esses dados com precisão, pois há sites que misturam outros conteúdos aos dados da notícia. Tivemos, então, que criar regras para remover esses ruídos, como palavras que não fazem parte da notícia e caracteres inválidos. Por exemplo, se no título de uma notícia também há o nome do veículo — isso é comum em sites menores — nós temos que removê-lo do título. O principal objetivo é ter os dados exatos da notícia.

Na sequência, inicia-se a terceira etapa: o enriquecimento. Essa etapa agrega dados de outras fontes de informação à notícia. Esses dados extras tornam uma notícia mais valiosa e, também, permitem que ela seja encontrada com mais facilidade. Um exemplo é o local do veículo, que permitirá a notícia ser achada quando se busca por notícias de uma região.

A quarta etapa é simples e direta: a notícia é armazenada. O maior desafio é usar uma tecnologia que seja rápida e consiga gerir muitos dados. No início, usamos um banco de dados tradicional principalmente por que não havia outra opção que nos desse garantia que as notícias ficariam armazenadas corretamente. Com o tempo, o banco de dados foi ficando lento por causa do volume de notícias capturadas todos os dias. Tivemos que buscar outra tecnologia.

Escolhemos uma tecnologia No-SQL disponível na cloud onde pudemos armazenar notícias com espaço ilimitado. Ela é rápida tanto para guardar as notícias quanto para acessa-las; e não fica lenta com o tempo. Além disso, o seu custo é proporcional ao uso, ou seja, paga-se pelo que se consome.

Entretanto, essa tecnologia não consegue fazer buscas dentro dos dados de uma notícia por meio de palavras-chaves (ex., buscar notícias da Petrobras). A busca por palavras-chaves é o jeito mais simples de pesquisar assuntos em documentos com texto — é assim que pesquisamos no Google. É por isso que as notícias precisam ser indexadas. A indexação, quinta etapa, organiza os dados (i.e., título, autor, etc.) das notícias em índices, que são, simplesmente, listas ordenadas de palavras — mesma ideia do índice de um livro. É, portanto, mais fácil e rápido achar um assunto em uma lista ordenada de palavras, também para o computador.

Quando se deseja ter uma função de busca textual, o maior desafio é definir como os os dados dos índices são organizados. As mesmas regras usadas nas palavras de um índice também precisam ser usadas nas palavras-chaves das consultas. Por exemplo, se utilizar as regras de que as palavras no índice estejam em minúscula e sem acentuação, essas mesmas regras têm que ser usadas nas palavras-chaves das consultas — senão, as notícias não serão achadas. Por isso, o índice tem que ter regras claras e já deve prever como os documentos serão buscados.

Se um índice tiver dados parciais ou incorretos significa ter que refazê-lo. O mesmo ocorre se qualquer regra de montagem do índice for alterada. Ao construir um índice precisa-se pensar, também, no seu uso futuro. Imagine um índice com dez milhões de notícias. De repente os clientes querem buscar apenas por notícias em inglês. Se o idioma de cada notícia não estiver no índice, será preciso re-definir a sua estrutura e montar um novo índice — pegar os dados de cada uma das dez milho˜es de notícias, mais o idioma, e inserir cada uma no novo índice. É uma tarefa trabalhosa, lenta e cara. Nós enfrentamos algumas situações como esta à medida que evoluímos nossos sistemas.

A velocidade para localizar palavras no índice também é impactada pela variedade de conteúdo. O índice nada mais é do que uma lista de palavras não repetidas que estão ordenadas. Quanto maior é o número de palavras diferentes maior é o tamanho dessa lista e, naturalmente, maior será o tempo para localizar uma palavra — é mais rápido encontrar uma palavra em uma lista com 1.000 itens do que em uma lista com 1.000.000 de itens.

A variedade das palavras em notícias é enorme por que elas descrevem muitos assuntos diferentes. Além disso, sempre há novas palavras, novos nomes, gírias, termos de outros idiomas e assim por diante. A lista de palavras do índice cresce todos os dias. Com o tempo, essa lista se torna tão longa que até mesmo grandes computadores podem não conseguir responder com rapidez.

Foi o cenário que enfrentamos.

Nessa época, as soluções tecnológicas que permitiam distribuir um índice em vários computadores — para dividir o trabalho entre eles — ainda não eram confiáveis. Por isso, tivemos que ser criativos e criar uma solução própria. Observamos como os clientes estavam consumindo as notícias no dia a dia e também a dinâmica dos sites ao publicar as suas notícias. 

A conclusão foi muito simples: as notícias mais usadas pelos clientes eram as mais novas. Criamos, então, índices menores, em mais de um computador, com regras claras sobre onde indexar uma notícia. As notícias novas ficam em índices menores que são usados para responder a maior parte das consultas. Ficou mais rápido localizar as palavras-chaves nesses índices e os computadores não precisam ser tão grandes — custo reduzido e ganho de tempo para o cliente.

Com o fim da etapa de indexação, as notícias estão prontas para serem buscadas. Assim, os clientes já podem localizar as notícias. Eles acessam o nosso sistema de busca e digitam as palavras que descrevem os seus interesses (ex., aquecimento global). O sistema de busca, então, acessa os índices, e aplica as mesmas regras usadas na indexação nas palavras-chaves pesquisadas pelos clientes. Dessa forma, o sistema de busca consegue localizar as notícias com as respectivas palavras-chaves.

As consultas dos clientes, em sua maioria, contêm poucas palavras — a média é em torno três. Para muitos assuntos, algumas palavras-chaves são suficientes para achar notícias corretas. Há, no entanto, outros interesses onde é preciso usar várias palavras-chaves tanto para restringir quanto para ampliar o que se deseja buscar. Para esses casos mais complexos o uso simples de palavras não é suficiente.

Os sistemas de buscas, normalmente, permitem que se combine palavras com conectores que ligam uma palavra a outra. Esses conectores são chamados de operadores lógicos. O nosso sistema de busca também tem essa opção e permite o uso dos mesmos operadores que o Google disponibiliza para seus usuários (i.e., AND, OR e NOT).

Esses operadores permitem montar consultas com maior precisão, para restringir ou ampliar uma pesquisa. Por exemplo, com o operador AND pode-se buscar notícias sobre aquecimento global e que também tratem de agricultura (ex., “aquecimento global” AND agricultura). Já com o operador OR, pode-se buscar as notícias do Banco do Brasil e também as notícias do Bradesco em uma mesma consulta (ex., “Banco do Brasil" OR Bradesco). Com o operador NOT, se busca notícias da Amazônia, mas que não tratem de queimadas (ex., Amazônia NOT queimadas). E é possível combinar todos os três operadores em uma única consulta.

Ter a função de busca com o volume de notícias que lidamos todos os dias requer bastante criatividade. Se adicionar uma nova regra, por exemplo, que use mais um segundo antes de indexar uma notícia, isso significa mais 1.000.000 de segundos a serem processados em um dia, pois capturamos esse número de notícias. Ademais, os computadores onde ficam os índices precisam ser usados ao máximo. Nossos sistemas são configurados para usar toda a capacidade do servidor, mas sem sobrecarregá-los.

Desde o início da Knewin usamos um software open source que é específico para indexar e buscar as notícias. O software se chama Lucene e é usado por várias empresas mundo afora. Nós usamos esse software apenas para prover a opção de busca por palavras-chaves no conteúdo das notícias.

Há algum tempo também usamos a tecnologia ElasticSearch. Essa tecnologia faz o mesmo papel do Lucene (i.e., indexar e buscar documentos textuais), mas permite distribuir um índice em vários computadores. A opção de usa-la é que conseguimos responder algumas consultas com mais rapidez e adicionar novos computadores caso aumente a demanda de consultas. A desvantagem é que seu custo pode inviabilizar o seu uso, principalmente quando se tem muitos dados.

Ainda hoje temos as duas tecnologias em nossos sistemas. Com isso, a nossa solução ficou economicamente viável, os sistemas têm mais garantia que estão ativos e as consultas são respondidas com mais rapidez. 

Manipular um bilhão de notícias, responder consultas em menos de um segundo e com um custo adequado exige muita criatividade e conhecimento. Nós sabemos que a solução atual terá que ser evoluída continuamente. O desafio aumenta a cada dia. Afinal, capturamos mais de um milhão de notícias a cada novo dia.

Novas postagens no endereço fbeppler.com.