Veja como o Machine Learning pode analisar automaticamente os arquivos de log do Nginx para gerar insights relevantes sobre o status operacional de um site.

ml-and-nginx-website-logs-fullbleed.jpg

Machine Learning for Nginx Logs - Identifying Operational Issues with Your Website

Machine Learning para logs de Nginx: como identificar problemas operacionais com seu site

Se estiver procurando orientações práticas sobre quantos índices e shards ter no cluster, esta postagem de blog vai ajudá-lo a evitar armadilhas comuns.

O Elasticsearch é uma plataforma bastante versátil, que oferece suporte a vários casos de uso, além de proporcionar excelente flexibilidade em torno das estratégias de organização e replicação de dados. Entretanto, essa flexibilidade às vezes dificulta a determinação antecipada de como organizar melhor os dados em índices e shards, principalmente se você for novato no Elastic Stack. Apesar de escolhas inferiores às ideais não necessariamente causarem problemas logo de início, elas têm o potencial de causar falhas de desempenho à medida que aumentam os volumes de dados com o tempo. Quanto mais dados o cluster contiver, mais difícil também ficará a solução do problema, uma vez que por vezes pode ser necessária a reindexação de grandes quantidades de dados.
Quando nos deparamos com usuários que enfrentam problemas de desempenho, não é incomum que isso possa ser rastreado de volta a problemas em torno de como os dados estão indexados e do número de shards no cluster. Isso é particularmente verdadeiro para casos de uso envolvendo multi-tenancy e/ou uso de índices baseados em tempo. Ao discutir essa questão com os usuários, seja pessoalmente, em eventos, encontros ou por meio do nosso <a href="https://discuss.elastic.co">fórum</a>, algumas das dúvidas mais comuns são “Quantos shards devo ter?” e “Qual é o tamanho que os shards devem ter?”.
Esta plotagem de blog tem como objetivo ajudar você a responder essas dúvidas e fornecer orientações práticas para casos de uso que envolvem o uso de índices baseados em tempo, por exemplo, análise de logs ou segurança, em um único local.
<h2 dir="ltr">O que é shard?</h2>Antes de começarmos, precisamos estabelecer alguns fatos e terminologia de que precisaremos em seções mais adiante.
Os dados no Elasticsearch estão organizados em <a href="/guide/en/elasticsearch/guide/2.x/_add_an_index.html">índices</a>. Cada índice consiste em um ou mais shards. Cada shard é uma instância de um índice de Lucene, que pode ser considerado um mecanismo de pesquisa autocontido que indexa e manipula consultas para um subconjunto dos dados em um cluster do Elasticsearch.
À medida que os dados são gravados em um shard, eles são publicados periodicamente em novos segmentos Lucene imutáveis no disco, e é nessa hora que ficam disponíveis para consultas. Isso é denominado atualização. O modo de funcionamento disso é descrito em mais detalhes em <a href="/guide/en/elasticsearch/guide/current/inside-a-shard.html">Elasticsearch: the Definitive Guide</a> (Guia definitivo do Elasticsearch).
À medida que cresce o número de segmentos, estes são consolidados periodicamente em segmentos maiores. Esse processo é denominado <a href="/guide/en/elasticsearch/reference/5.5/index-modules-merge.html">mesclagem</a>. Como todos os segmentos são imutáveis, isso significa que o espaço em disco usado normalmente oscilará durante a indexação, à medida que novos segmentos mesclados precisem ser criados antes que os substituídos possam ser excluídos. A mesclagem pode usar muitos recursos, principalmente com relação a E/S de disco.
O shard é a unidade em que o Elasticsearch distribui dados em torno do cluster. A velocidade em que o Elasticsearch pode mover shards ao rebalancear dados, por exemplo, após uma falha, dependerá do tamanho e número de shards, além do desempenho da rede e do disco.
<table>
<tbody>
<tr>
	<td>DICA&nbsp;Evite ter shards muito grandes porque isso pode prejudicar a capacidade de recuperação do cluster após falha. Não há limite fixo sobre o tamanho máximo dos shards, mas um tamanho de 50 GB em geral é citado como limite que parece funcionar para vários casos de uso.
	</td>
</tr>
</tbody>
</table><h2 dir="ltr">Índice por período de retenção</h2>Como os segmentos são imutáveis, <a href="/guide/en/elasticsearch/guide/2.x/update-doc.html">atualizar um documento</a> exige que o Elasticsearch primeiro encontre o documento existente, marque-o como excluído e adicione a versão atualizada. <a href="/guide/en/elasticsearch/guide/2.x/delete-doc.html">Excluir um documento</a> também exige que o documento seja encontrado e marcado como excluído. Por isso, os documentos excluídos <a href="/pt/blog/lucenes-handling-of-deleted-documents">continuarão ocupando espaço em disco e alguns recursos de sistema até que sejam mesclados</a>, o que pode consumir mais recursos do sistema.
O Elasticsearch permite que índices completos sejam excluídos com muito eficiência diretamente do sistema de arquivos, sem explicitamente obrigar a exclusão de todos os registros individualmente. Isso é de longe o jeito mais eficiente de excluir do Elasticsearch.
<hr>DICA: Tente usar <a href="/guide/en/elasticsearch/guide/2.x/time-based.html">índices baseados em tempo</a> para gerenciar a retenção de dados sempre que possível. Agrupe os dados em índices com base no período de retenção. Os índices baseados em tempo também tornam fácil variar o número de réplicas e shards primários com o tempo, uma vez que isso pode ser alterado para o próximo índice a ser gerado. Isso simplifica a adaptação a eventuais alterações feitas em volumes de dados e requisitos.
<hr><h2 dir="ltr">Os índices e shards não são gratuitos?</h2>Para cada índice do Elasticsearch, as informações sobre mapeamentos e estado são armazenadas no estado do cluster. Elas são mantidas na memória para agilizar o acesso. Assim, ter um grande número de índices e shards em um cluster pode resultar em um estado de cluster grande, principalmente se os mapeamentos forem grandes. Isso pode tornar lento o processo de atualização, porque todas as atualizações precisam ser feitas através de um único thread para garantir consistência antes que as alterações sejam distribuídas no cluster.
<hr>DICA: Para reduzir o número de índices e evitar mapeamentos grandes e dispersos, avalie armazenar dados com estrutura semelhante no mesmo índice em vez de dividi-los em índices separados com base no local de origem dos dados. É importante encontrar um bom equilíbrio entre o número de índices e shards, e o tamanho do mapeamento para cada índice individual. Como o <a href="/guide/en/elasticsearch/guide/2.x/finite-scale.html#finite-scale" target="_blank">estado do cluster</a> está carregado no mapa em cada nó (incluindo os mestres), e a quantidade de heap é diretamente proporcional ao número de índices, campos por índice e shards, é importante também monitorar a utilização de heap nos nós mestres e garantir que tenham tamanho apropriado. &nbsp;
<hr>Cada shard tem dados que precisam ser mantidos na memória e usam espaço de heap. Isso inclui estruturas de dados que contêm informações no nível de shard, mas também no nível de segmento para definir onde os dados residem no disco. O tamanho dessas estruturas de dados não é fixo e vai variar dependendo do caso de uso.
Uma característica importante do overhead relacionado ao segmento, entretanto, é que ele não é estritamente proporcional ao tamanho do segmento. Isso significa que segmentos maiores têm menos overhead por volume de dados em comparação com segmentos menores. A diferença pode ser substancial.
Para poder armazenar tantos dados quanto possíveis por nó, torna-se importante gerenciar a utilização de heap e reduzir a quantidade de overhead ao máximo possível. Quanto mais espaço de heap um nó tiver, mais dados e shards ele poderá manipular.
Assim, os índices e shards não são gratuitos do ponto de vista de um cluster, porque há algum nível de overhead de recurso para cada índice e shard.
<hr>DICA: Pequenos shards resultam em pequenos segmentos, o que aumenta o overhead. Tenha como objetivo manter o tamanho médio de shard entre pelo menos alguns GB e algumas dezenas de GB. Para casos de uso com dados baseados em tempo, é comum ver shards entre 20 GB e 40 GB de tamanho.
DICA: Como o overhead por shard depende da contagem e tamanho do segmento, obrigar segmentos menores a mesclar para maiores através de uma operação <a href="/guide/en/elasticsearch/reference/5.5/indices-forcemerge.html">forcemerge</a> pode reduzir o overhead e melhorar o desempenho das consultas. O ideal é que isso seja feito depois que nenhum dado seja gravado no índice. Esteja ciente de que essa é uma operação cara que deve ser executada durante horários fora de pico.
DICA: O número de shards que você pode manter em um nó será proporcional à quantidade de heap disponível, mas não há limite fixo imposto pelo Elasticsearch. Uma ótima regra prática é garantir que você mantenha o número de shards por nó abaixo de 20 GB por heap que ele configurou. Um nó com heap de 30 GB portanto deve ter no máximo 600&nbsp;shards, mas quanto mais abaixo desse limite você conseguir mantê-lo, melhor será. Isso geralmente ajudará o cluster a ficar com boa integridade.
<hr><h2 dir="ltr">De que maneira o tamanho do shard influencia no desempenho?</h2>No Elasticsearch, cada consulta é executada em um único thread por shard. Entretanto, vários shards podem ser processados paralelamente, assim como várias consultas e agregações com base no mesmo shard.
Isso significa que a mínima latência de consulta, quando não há cache envolvido, dependerá dos dados, do tipo de consulta e do tamanho do shard. A consulta de muitos pequenos shards tornará o processamento por shard mais rápido, mas como muito mais tarefas precisam ser enfileiradas e processadas em sequência, isso não necessariamente será mais rápido do que consultar um número menor de shards maiores. Ter muitos pequenos shards também pode reduzir o throughput de consulta se houver várias consultas simultâneas.
<hr>DICA: A melhor maneira de determinar o tamanho máximo de shard do ponto de vista do desempenho das consultas é <a href="/pt/elasticon/conf/2016/sf/quantitative-cluster-sizing">adotar um parâmetro de comparação usando dados e consultas realistas</a>. Sempre adote um parâmetro de comparação com uma consulta e um representante de carga de indexação daquilo que o nó precisaria manipular em produção, uma vez que otimizar para uma única consulta pode gerar resultados enganosos.
<hr><h2 dir="ltr">Como gerencio o tamanho do shard?</h2>Ao usar índices baseados no tempo, cada índice tradicionalmente é associado a um período de tempo fixo. Os índices diários são muito comuns e em geral são usados para manter dados com curto período de retenção ou grandes volumes diários. Isso permite que o período de retenção seja gerenciado com boa granularidade e facilita o ajuste para alterações feitas em volumes diariamente. Dados com um período de retenção mais longo, principalmente se os volumes diários não garantirem o uso de índices diários, em geral usam índices semanais ou mensais para manter grande o tamanho do shard. Isso reduz o tamanho dos índices e shards que precisam ser armazenados no cluster com o tempo.
<hr>DICA: Se estiver usando índices baseados no tempo abrangendo um período fixo, ajuste o período que cada índice abrange com base no período de retenção e nos volumes de dados esperados para atingir o tamanho do shard de destino.
<hr>Índices baseados no tempo com intervalo de tempo fixo funcionam bem quando os volumes de dados são razoavelmente previsíveis e se alteram lentamente. Se a taxa de indexação puder variar rapidamente, ficará muito difícil manter um tamanho de shard de destino uniforme.
Para poder manipular melhor esse tipo de cenário, as <a href="/pt/blog/managing-time-based-indices-efficiently">APIs de Rollover e Encolhimento</a> foram introduzidas. Elas adicionam bastante flexibilidade à maneira como os índices e shards são gerenciados, especificamente para índices baseados no tempo.
A <a href="/guide/en/elasticsearch/reference/5.5/indices-rollover-index.html">API de índice de rollover</a> possibilita especificar o número de documentos que um índice deve conter e/ou o período máximo em que os documentos devem ser gravados nele. Depois que um desses critérios tiver sido excedido, o Elasticsearch poderá disparar um novo índice a ser criado para gravar sem inatividade. Em vez de precisar que cada índice abranja um período de tempo específico, agora é possível trocar para um novo índice com tamanho específico, o que possibilita atingir mais facilmente um tamanho de shard uniforme para todos os índices.
Nos casos em que os dados podem ser atualizados, não há mais um link distinto entre o carimbo de tempo do evento e o índice no qual ele reside ao usar essa API, o que pode tornar as atualizações significativamente menos eficientes porque cada atualização pode precisar ser precedida por uma pesquisa.
<hr>DICA: Se você tiver dados imutáveis baseados em tempo em que os volumes podem variar significativamente com o tempo, avalie o uso da API de índice de rollover para atingir um tamanho de shard de destino ideal variando dinamicamente o período de tempo que cada índice abrange. Isso oferece ótima flexibilidade e pode ajudar a evitar a necessidade de ter shards muito grandes ou muito pequenos quando os volumes são imprevisíveis. 
<hr>A <a href="/guide/en/elasticsearch/reference/5.5/indices-shrink-index.html">API de encolhimento de índices</a> permite encolher um índice existente para um novo índice com menos shards primários. Se uma dispersão uniforme de shards entre os nós for desejada durante a indexação, mas isso resultará em shards muito pequenos, essa API poderá ser usada para reduzir o número de shards primários depois que houver a indexação. Isso resultará em shards maiores, mais adaptados para armazenamento de dados em períodos mais longos. 
<hr>DICA: Se você precisar que cada índice abranja um período de tempo específico, mas ainda assim quiser poder dispersar a indexação entre um grande número de nós, avalie o uso da API de encolhimento para reduzir o número de shards primários depois que não houver mais indexação. Essa API também pode ser usada para reduzir o número de shards caso você tenha inicialmente configurado muitos shards. 
<hr><h2 dir="ltr">Conclusões</h2>Esta postagem de blog forneceu dicas e orientações práticas sobre como gerenciar melhor os dados no Elasticsearch. Se tiver interesse em saber mais, a publicação "Elasticsearch: the definitive guide" contém uma seção sobre <a href="/guide/en/elasticsearch/guide/2.x/scale.html">como projetar para escala</a>, que vale a pena ler apesar de ser um pouco antiga.
Muitas decisões em torno de como distribuir melhor os dados entre índices e shards, entretanto, dependerão de especificidades dos casos de uso, e às vezes poderá ser difícil determinar como aplicar melhor o aviso disponível. Para saber de mais avisos aprofundados e pessoais, participe conosco <a href="/pt/subscriptions">comercialmente através de uma assinatura</a> e deixe que as equipes de Suporte e Consultoria ajudem a acelerar o projeto. Se estiver satisfeito em discutir seu caso de uso abertamente, você também poderá obter ajuda da <a href="/pt/community">nossa comunidade</a> e através do nosso <a href="https://discuss.elastic.co">fórum</a> público.

elasticsearch-sharding-fullbleed.jpg

elasticsearch-sharding-thumbnail.jpg

How many shards should I have in my Elasticsearch cluster?

Quantos shards eu devo ter em meu cluster do Elasticsearch?

Articles By

Register to Attend

Sign In to Attend

Register to Watch

You'll also receive an email with related content

Mais, enviaremos conteúdo relevante para você.

Watch now

Learn more

Contact Info

See All Posts

What to explore next...

Load more news

Load more press releases

Load More

See when this webinar starts in my time zone

Consultar a hora de início do webinar no meu fuso horário

Hosted by

Highlights

Featured webinar

On-demand webinar

Upcoming webinar

View next

Register now

Video for

Small image for

View more posts

Continue reading

Share

Translate Content

Veja um detalhamento de como o X-Pack Machine Learning pontua anomalias e as classifica automaticamente em uma escala de 0 a 100.

anomaly_scoring_full_bleed.jpg

anomaly_scoring_thumb.jpg

Machine Learning Anomaly Scoring and Elasticsearch - How it Works

Pontuação de anomalia no Machine Learning e o Elasticsearch - Como funciona

Elliot usa o Kibana para visualizar os esforços do Dark Army para roubar dados em eps3.4_runtime-error.r00 do seriado Mr. Robot.

Elliot usa o Kibana para visualizar os esforços do Dark Army para roubar dados em "eps3.4_runtime-error.r00".&nbsp;Os usuários da Elastic no mundo inteiro ficam bastante surpresos. Nós tentamos redigir tranquilamente uma postagem de blog.
Mr. Robot é uma atração favorita em toda a empresa por motivos um tanto evidentes. O seriado é famoso por descrever as situações de ciberssegurança com estratégias, ferramentas e respostas de detecção realistas. Assim, quando a equipe de Mr. Robot chegou até nós, ficamos empolgados em saber que eles queriam apresentar o Kibana em um episódio futuro. É claro que prontamente dissemos “sim”! Não podíamos esperar para ver nosso software em ação no mundo de Elliot. Aliás, você perceberá que não se trata da versão mais recente do Kibana, mas do <a href="/pt/blog/kibana-4-literally" target="_blank">Kibana 4</a> para se adequar ao cronograma do seriado.
<img src="https://api.contentstack.io/v2/uploads/5a05c452e5cca3277d6e93b4/download?uid=bltcca1f717f1bd3743" data-sys-asset-uid="bltcca1f717f1bd3743" alt="Elliot-Kibana-MrRobot.png">&nbsp;
Como era de se esperar, os técnicos em Mr. Robot queriam criar um genuíno painel Kibana populado com dados, criado usando as ferramentas reais. Você entende por que somos fãs?
<a href="https://medium.com/@ryankazanciyan" target="_blank">Ryan Kazanciyan</a>, Consultor Técnico para o Mr. Robot, rasga elogios a nós nos bastidores da ciberssegurança de cada episódio. Em sua postagem mais recente, ele descreve como criou um painel Kibana&nbsp;que ilustra atividades maliciosas executadas pelo Dark Army. Para começar, Ryan criou uma máquina virtual ELK (conhecida hoje como Elastic Stack) composta por Elasticsearch, Logstash e Kibana. Depois populou-a com dados dos sistemas Windows e Linux. Para saber mais comentários de bastidores sobre como ele criou cada seção do painel, acesse <a href="https://medium.com/@ryankazanciyan/mr-robot-disassembled-3-4-runtime-error-r00-9319c70c30f2" target="_blank">sua postagem de blog</a>.
<img src="https://api.contentstack.io/v2/uploads/5a05c285b11e02074c49718b/download?uid=blt7ed0d8f1cabe5fdb" data-sys-asset-uid="blt7ed0d8f1cabe5fdb" alt="Kibana-MrRobot.png">
Adoramos conhecer todas as maneiras pelas quais os usuários colocam o Elastic Stack para trabalhar. Assistir ao Elliot usar o Kibana para visualizar os ataques do Dark Army foi no mínimo surreal. 
Aqui está um gostinho das reações dos fãs de nossa equipe:
<blockquote>“Os redatores e consultores de Mr. Robot criaram um programa estimulante e tecnicamente honesto. Eles não economizam nos detalhes, mas tudo é acessível. Soa familiar. Sinto-me lisonjeado por eles terem escolhido o Elastic Stack.” — Nick Waringa, Analista de Segurança Sênior
</blockquote><blockquote>“Nossa família inteira quebrou o recorde de maratonar Mr. Robot no fim de semana ao se preparar para o episódio do Kibana.” - Beth McAnerney, Administrador da Netsuite
</blockquote><blockquote>“A última vez em que fiquei tão empolgado em ser nerd foi quando li Snow Crash!” - Mark Walkom, Arquiteto de Soluções / Apoiador de Desenvolvedores
</blockquote><blockquote>“Finalmente eu trabalho em um lugar legal o suficiente para detonar em Mr. Robot!” - Grant Murphy, Engenheiro de Nuvem
</blockquote>

kibana-dashboard-fullbleed.jpg

Elliot-Kibana-MrRobot-image.jpg

Monitoring the Dark Army with Kibana on Mr. Robot

Monitoramento dos hackers chineses Dark Army com o Kibana no seriado televisivo Mr. Robot

O <a href="/pt/elasticsearch">Elasticsearch</a> é bastante usado como um mecanismo de busca e análise. Seus recursos como API de mineração de texto também não são conhecidos.

No artigo a seguir, eu gostaria de mostrar como é possível fazer classificação de texto com o Elasticsearch. Com conhecimento em linguística computacional e vários anos de experiência em negócios como autônomo na área de mineração de texto, tive a oportunidade de implementar e testar as seguintes técnicas em diferentes cenários.

Quando me deparei com o Elasticsearch pela primeira vez, fiquei fascinado com sua facilidade de uso, sua velocidade e suas opções de configuração. Toda vez que usava ele, eu descobria um jeito ainda mais simples de fazer o que já fazia com ferramentas e técnicas tradicionais de NLP (Processamento de Linguagem Natural).

Em algum momento percebi que ele pode resolver de imediato <a href="http://dataconomy.com/2016/12/use-elasticsearch-text-mining%E2%80%8A-%E2%80%8Apart-1/">um monte de coisas</a> que eu fui treinado para implementar do zero.

A maioria das tarefas de NLP começa com um pipeline de pré-processamento padrão:

<ol>
	<li>
	Coleta de dados
	</li>
	<li>
	Extração de texto bruto
	</li>
	<li>
	<a href="https://en.wikipedia.org/wiki/Sentence_boundary_disambiguation">Divisão de frases</a>
	</li>
	<li>
	Tokenização
	</li>
	<li>
	Normalização (stemização, <a href="https://github.com/jprante/elasticsearch-analysis-baseform">lematização</a>)
	</li>
	<li>
	Remoção de palavras vazias
	</li>
	<li>
	<a href="https://en.wikipedia.org/wiki/Part-of-speech_tagging">Marcação de parte do discurso</a>
	</li>
</ol>
Algumas tarefas de NLP, como análise sintática, exigem profunda análise linguística.

Para esse tipo de tarefa, o Elasticsearch não oferece imediatamente a arquitetura e o formato de dados ideais. Isso significa que, para tarefas que vão além do nível de token, é necessário escrever ou usar plugins personalizados que acessam o texto completo.

Só que tarefas como classificação, armazenamento em cluster, extração de palavras-chave, mensuração de similaridade etc. só exigem uma representação de saco-de-palavras normalizada e possivelmente ponderada de um determinado documento.

As etapas 1 e 2 podem ser resolvidas com o <a href="/guide/en/elasticsearch/plugins/current/ingest-attachment.html">Plugin Ingest Attachment Processor</a> (antes da versão 5.0: <a href="/guide/en/elasticsearch/plugins/5.0/mapper-attachments.html">Plugin Mapper Attachments</a>) no Elasticsearch.

A extração de texto bruto para esses plugins se baseia no <a href="https://tika.apache.org/">Apache Tika</a>, que funciona na maioria dos formatos de dados mais comuns (HTML/PDF/Word etc.).

As etapas de 4 a 6 são resolvidas imediatamente com os <a href="/guide/en/elasticsearch/reference/current/analysis-lang-analyzer.html">analisadores de linguagem</a>.

Mapeamento de amostras:

<pre class="prettyprint"> {
 "properties":{
 "content":{
 "type":"text",
 "analyzer":"german"
 }
 }
 }
</pre>
Se o tipo de mapeamento para um determinado campo for "text" (antes da versão 5.0: "analyzed string") e o analisador for definido como uma das linguagens com suporte nativo do Elasticsearch, a tokenização, a stemização e a remoção de palavras vazias serão executadas automaticamente no momento da indexação.

Por isso não é necessário obter nenhum código personalizado e nenhuma outra ferramenta de qualquer tipo de documento compatível com o Apache Tika para uma representação de saco-de-palavras.

Os analisadores de linguagem também podem ser chamados por meio da API REST, quando o Elasticsearch está em execução.

<pre class="prettyprint">curl -XGET "http://localhost:9200/_analyze?analyzer=english" -d'
 {
 "text" : "This is a test."
 }'
 {
 "tokens":[
 {
 "token":"test",
 "start_offset":10,
 "end_offset":14,
 "type":"&lt;ALPHANUM&gt;",
 "position":3
 }
 ]
 }
</pre>
A abordagem que não seja do Elasticsearch tem aparência semelhante a esta:

Coletar o texto com código personalizado, analisar documentos manualmente ou com a biblioteca Tika, usando uma biblioteca NLP tradicional ou uma API como <a href="http://www.nltk.org/">NLTK</a>, <a href="https://opennlp.apache.org/">OpenNLP</a>, <a href="http://nlp.stanford.edu/">Stanford NLP</a>, <a href="https://spacy.io/">Spacy</a> ou qualquer outra que foi desenvolvida em algum departamento de pesquisa. Entretanto, ferramentas desenvolvidas em departamentos de pesquisa normalmente não são muito úteis para um contexto empresarial. Com muita frequência os formatos de dados são proprietários, as ferramentas precisam ser compiladas e executadas na linha de comando e os resultados são muitas vezes gerados em pipes para fora do padrão. As APIs REST são uma exceção.

Com os analisadores de linguagem do Elasticsearch, em contrapartida, basta configurar o mapeamento e indexar os dados. O pré-processamento ocorre automaticamente no momento da indexação.

<h3>Abordagem tradicional à classificação de texto</h3>
A classificação de texto é uma tarefa tradicionalmente resolvida com machine learning supervisionado. O material inserido para treinar um modelo é um conjunto de documentos identificados. A representação mínima disso seria um documento JSON com 2 campos:

"content" e "category"

Tradicionalmente, a classificação de texto pode ser resolvida com uma ferramenta como <a href="https://scikit-learn.org/0.19/datasets/twenty_newsgroups.html">SciKit Learn</a>, <a href="http://weka.wikispaces.com/Text+categorization+with+WEKA">Weka</a>, <a href="http://www.nltk.org/book/ch06.html">NLTK</a>, <a href="https://mahout.apache.org/users/classification/twenty-newsgroups.html">Apache Mahout</a> etc.

<h3>Criação dos modelos</h3>
A maioria dos algoritmos de machine learning exige uma representação de <a href="https://en.wikipedia.org/wiki/Vector_space_model">modelo de espaço vetorial</a> dos dados. O espaço do recurso normalmente é algo como as 10.000 palavras mais importantes de um determinado conjunto de dados. Como a importância de uma palavra pode ser mensurada?

Normalmente com <a href="https://en.wikipedia.org/wiki/Tf%E2%80%93idf">TF-IDF</a>. Essa é uma fórmula que foi inventada na década de 70 do século passado. TF-IDF é um peso que pontua um termo em um determinado documento em relação ao restante do conjunto de dados. Se um termo em um documento tem uma alta pontuação de TF-IDF, isso significa que ele é uma palavra-chave muito característica e distingue um documento de todos os outros documentos por meio dessa palavra.

As palavras-chave com as mais altas pontuações de TF-IDF em um subconjunto de documentos podem representar um tópico. Para classificação de texto, um espaço de recurso com as n palavras com as mais altas pontuações de TF-IDF gerais é muito comum.

Cada documento é convertido em um vetor de recurso, depois com todas as instâncias de treinamento para cada classe/categoria que um modelo é criado. Depois disso, novos documentos podem ser classificados de acordo com esse modelo. Portanto, o documento precisa ser convertido em um vetor de recurso e, a partir daí, todas as similaridades são calculadas. O documento será identificado com a categoria com a mais alta pontuação.

<h3>Classificação de texto com o Elasticsearch</h3>
Todas as questões anteriores podem ser resolvidas de um jeito bem mais simples com o Elasticsearch (ou o <a href="https://lingpipe-blog.com/2014/04/10/lucene4-document-classification/">Lucene</a>).

Basta executar quatro etapas:

<ol>
	<li>
	Configurar o mapeamento ("content" : "<a href="/guide/en/elasticsearch/reference/current/text.html">text</a>", "category" : "<a href="/guide/en/elasticsearch/reference/current/keyword.html">keyword</a>")
	</li>
	<li>
	Indexar os documentos
	</li>
	<li>
	Executar <a href="/guide/en/elasticsearch/reference/current/query-dsl-mlt-query.html">More Like This Query</a> (Consulta MLT)
	</li>
	<li>
	Escrever um pequeno script que agrega as ocorrências dessa consulta por pontuação
	</li>
</ol>
<pre class="prettyprint">PUT sample
 POST sample/document/_mapping
 {
 "properties":{
 "content":{
 "type":"text",
 "analyzer":"english"
 },
 "category":{
 "type":"text",
 "analyzer":"english",
 "fields":{
 "raw":{
 "type":"keyword"
 }
 }
 }
 }
 }
 POST sample/document/1
 {
 "category":"Apple (Fruit)",
 "content":"Granny Smith, Royal Gala, Golden Delicious and Pink Lady are just a few of the thousands of different kinds of apple that are grown around the world! You can make dried apple rings at home - ask an adult to help you take out the core, thinly slice the apple and bake the rings in the oven at a low heat."
 }
 POST sample/document/2
 {
 "category":"Apple (Company)",
 "content":"Apple is an American multinational technology company headquartered in Cupertino, California, that designs, develops, and sells consumer electronics, computer software, and online services. Its hardware products include the iPhone smartphone, the iPad tablet computer, the Mac personal computer, the iPod portable media player, the Apple Watch smartwatch, and the Apple TV digital media player. Apple's consumer software includes the macOS and iOS operating systems, the iTunes media player, the Safari web browser, and the iLife and iWork creativity and productivity suites. Its online services include the iTunes Store, the iOS App Store and Mac App Store, Apple Music, and iCloud."
 }
</pre>
A consulta MLT é uma consulta muito importante para mineração de texto.

Como funciona? Ela pode processar texto arbitrário, extrair as principais n palavras-chave em relação ao "modelo" real e executar uma consulta de correspondência booliana com essas palavras-chave. Essa consulta geralmente é usada para coletar documentos semelhantes.

Se todos os documentos tiverem uma identificação de classe/categoria e um número semelhante de instâncias de treinamento por classe, isso será equivalente à classificação. Basta executar uma consulta MLT com o documento de entrada como campo like e escrever um pequeno script que agrega a pontuação e a categoria das principais n ocorrências.

<pre class="prettyprint">GET sample/document/_search
 {
 "query":{
 "more_like_this":{
 "fields":[
 "content",
 "category"
 ],
 "like":"The apple tree (Malus pumila, commonly and erroneously called Malus domestica) is a deciduous tree in the rose family best known for its sweet, pomaceous fruit, the apple. It is cultivated worldwide as a fruit tree, and is the most widely grown species in the genus Malus. The tree originated in Central Asia, where its wild ancestor, Malus sieversii, is still found today. Apples have been grown for thousands of years in Asia and Europe, and were brought to North America by European colonists. Apples have religious and mythological significance in many cultures, including Norse, Greek and European Christian traditions.",
 "min_term_freq":1,
 "max_query_terms":20
 }
 }
 }
</pre>
Esta amostra só serve para ilustrar o fluxo de trabalho. Para classificação real, você precisará de mais dados. Por isso não se preocupe se com esse exemplo você não obtiver nenhum resultado real. Basta adicionar mais dados para funcionar.

E a seguir está um pequeno script em Python que processa a resposta e retorna a categoria mais provável para o documento de entrada.

<pre class="prettyprint">from operator import itemgetter
 def get_best_category(response):
 categories = {}
 for hit in response['hits']['hits']:
 score = hit['_score']
 for category in hit['_source']['category']: 
 if category not in categories:
 categories[category] = score
 else:
 categories[category] += score
 if len(categories) &gt; 0:
 sortedCategories = sorted(categories.items(), key=itemgetter(1), reverse=True)
 category = sortedCategories[0][0]
 return category
</pre>
E aí está o seu classificador de texto do Elasticsearch!

<h3>Casos de uso</h3>
A classificação de texto é um caso de uso real muito comum para o NLP. Pense em dados de comércio eletrônico (produtos). Muitas pessoas administram lojas de comércio eletrônico com links afiliados. Os dados são fornecidos por várias lojas e geralmente vêm com uma marca de categoria. Só que cada loja tem outra marca de categoria. Então os sistemas de categoria precisam ser unificados e assim todos os dados precisam ser reclassificados de acordo com a árvore da nova categoria. Ou pense em uma aplicação de business intelligence em que os sites da empresa precisam ser classificados de acordo com seu setor (cabeleireiro em comparação com padaria etc).

<h3>Avaliação </h3>
Eu avaliei essa abordagem com um <a href="http://ana.cachopo.org/datasets-for-single-label-text-categorization">conjunto de dados de classificação de texto padrão</a>: O <a href="http://qwone.com/~jason/20Newsgroups/">conjunto de dados 20 Newsgroups</a>. A mais alta precisão (92% de identificações corretas) foi atingida com um limite de pontuação de alta qualidade que incluiu somente 12% dos documentos. Ao identificar todos os documentos (100% de recall), 72% das previsões estavam corretas.

Os melhores algoritmos para classificação de texto no conjunto de dados 20 Newsgroups normalmente são o SVM e o Naive Bayes. Eles têm uma precisão de média mais alta em todo o conjunto de dados.

Então por que você deve avaliar o uso do Elasticsearch para classificação se há algoritmos melhores?

Existem alguns motivos práticos: o treinamento em um modelo SVM leva muito tempo. Principalmente quando você trabalha em uma startup ou precisa se adaptar rapidamente a diferentes clientes ou casos de uso que podem se tornar um problema real. Então talvez você não possa retreinar seu modelo toda vez em que os dados forem alterados. Eu mesmo tive essa experiência ao trabalhar em um projeto para um grande banco alemão. Assim você trabalhará com modelos obsoletos e com certeza eles não pontuarão mais tão bem.

Com a abordagem do Elasticsearch, o treinamento ocorre no momento da indexação e seu modelo pode ser atualizado dinamicamente a qualquer momento com inatividade zero da aplicação. Se os dados forem armazenados no Elasticsearch de qualquer maneira, você não precisará de nenhuma infraestrutura adicional. Com resultados altamente precisos de mais de 10% você normalmente pode preencher a primeira página. Em muitas aplicações, isso é suficiente para causar uma primeira boa impressão.

Então por que usar o Elasticsearch quando existem outras ferramentas?

Porque seus dados já estão disponíveis e de qualquer maneira eles farão um pré-cálculo das estatísticas subjacentes. É quase como obter um pouco de NLP de graça!

<hr>
<img src="https://api.contentstack.io/v2/uploads/58c91685a65c8d5d34e7a9c4/download?uid=blt17cf02e7ec334bcf" data-sys-asset-uid="blt17cf02e7ec334bcf" alt="Saskia Vola" width="148" height="160" style="float:left; width: 148px; height: 160px; margin:0 10px 10px 0;">
	

Saskia Vola estudou Linguística Computacional na Universidade de Heidelberg e começou a trabalhar na área de mineração de texto em 2009. Depois de alguns anos em uma startup de Berlim, ela decidiu se tornar autônoma em tempo integral e aproveitar a vida como uma nômade digital. À medida que recebia cada vez mais ofertas de projetos relevantes, decidiu começar uma plataforma para autônomos de NLP/AI chamada <a href="http://textminers.io/">textminers.io</a>

magnet-letters-pile.jpg

thumb-magnet-letters-pile.jpg

Text Classification made easy with Elasticsearch

Classificação de texto facilitada com o Elasticsearch

Descubra quais navegadores acessam seu site. Saiba de onde seus usuários finais se estão se conectando. Coloque seus endereços IP ou nomes de hosts para funcion

geoip-filtering-elastic-stack-elasticsearc-mount-etna-erupting-full-bleed.jpg

geoip-filtering-elastic-stack-elasticsearc-mount-etna-erupting-thumbnail.jpg

GeoIP in the Elastic Stack

GeoIP no Elastic Stack

Machine Learning para logs de Nginx: como identificar problemas operacionais com seu site

Quantos shards eu devo ter em meu cluster do Elasticsearch?

Produtos

Empresa

Recursos

Soluções

Elastic (ELK) Stack

NOVO

<

2017

<

september

>

Machine Learning para logs de Nginx: como identificar problemas operacionais com seu site

Quantos shards eu devo ter em meu cluster do Elasticsearch?