ELK与搜索引擎

layout: post
title: ELK与搜索引擎
date: 2018-04-05
tags: [“ELK”,”软件服务”]

一、Search Engine的设计架构

1. 数据存储
2. 做切词操作，做同义词替换操作（如大小写，相近单词，bicycle和bike；去除助词如is the 的 得等）、
3. 基于算法构建倒排索引（如果不处理数据当要获取指定数据时只能是遍历整个库）
   

二、倒排索引

1、概念：倒排索引（英语：Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。Wiki百科

2、核心思想：word和frequncy构建成dictionary，当查询时根据切词找到文档（当一个词的频率很低，则它所对应的文档权重很高 wiki百科tf-idf算法）

索引示例：

This is my choice.Coming back,经过切分和构建索引后会形成如下形式。

word：切词
frequncy：出现的频次
documents：文档编号

3、搜索引擎的瓶颈

搜索引擎的分词操作，同义替换、倒排索引，单台服务器根本无法承载如此大的负荷，所以需要分布式计算。而nutch（Nutch 是一个开源Java实现的搜索引擎。）就遇到了以上问题（http://nutch.apache.org/），而这时google公布了三篇论文

1、GFS
2、MapReduce
3、BigTable

nutch工作组如获至宝，根据google的三篇论文原理推出了如下组件

GFS—> HDFS
MapReduce—>MapReduce
BigTable—>HBase

三个组件合在一起就是Hadoop通用搜索引擎（分布式运算和存储平台）

三、Elastic Search 与solr

Elastic Search可以实现站内搜索搜索引擎的功能，但严格意义上来讲，其算不上一个搜索引擎，因其借住了Lucene core 组件来实现切词和索引（nutch的核心组件，纯java开发的类库；lucene.apache.org），Elastic只提供了搜索组件，而索引组件则是由Lucene提供的。

Elastic Search可以实现搜索和索引，但是其构建文档和抓取文档并不是Elastic Search的强项。

solr也是一个站内高性能的搜索引擎服务，借助于Lucene core，借助于http/XML对外服务，Elastic Search 所实现的组件功能和solr基本相同。但当需要分布式的时候，solr在当时并不能实现分布式的功能，虽然solr功能很强大，但是其市场瞬间被Elastic Search所占据，虽然现在solr已经支持分布式了，但是已经无法挽回其霸主地位了。而Elastic Search在最开始设计的方案就是分布式。

四、ELK或者说ELFK的组件

早期称呼 ：ELK,EFK,ELFK
现在称呼：Elastic Stack

1、Elastic Search 在上文中已经说过了。

2、Logstash是jruby语言研发的，可以收集各种应用程序的日志，通过logstash-agent手机日志，传输给logstash-server，并将收集的日志文档化。Logstash-server将文档化后的日志发送给Elastic Search做日志分析。

3、Kibana是Elasticsearch的开源数据可视化插件。它在Elasticsearch集群上索引的内容之上提供可视化功能。用户可以在大量数据的顶部创建条形图，线条和散点图，或饼图和地图。

4、由于Logstash太过于重量级，启动就需要1~2G的内存，所以日志收集如此简单的工作使用logstash就难免显得太过重量级，因此使用服务器端开发的高性能编程语言重写了文件内容收集的工具集，这套工具就叫做beats，而文本收集工具就叫做filebeats。

beats工具集：

Filebeat :日志文件收集
Metricbeat：指标收集（服务器各种指标信息，如cpu、内存用量）
Packetbeat：网络数据报文（抓包）
Winlogbeat：Windows事件日志，logevent
Auditbeat：审计数据
Heartbeat：服务器运行时长。

https://www.elastic.co/cn/products/beats

五、Lucene的核心组件

1、index：es当中相当于数据库，倒排索引就是将文档切分成字典，不但包含了文档切词以后的索引结果，也同时包含了文档的完整的原始数据。（全部存储index中，相当于db）
2、type：index的子容器，将index中的索引分门别类的放在不同的子容器当中，类似关系型数据库的table。（各应用程序的日志所需要切割的字段不同，所以需要分门别类的存放）
3、document：数据组成的整体或者实体就是document，相当于关系型数据库的row

而Elastic Search在调用Lucene的语境当中，去定义数据类型的动作，掌握在key上，叫做mapping（映射）。lucene在接收文档时候，首先需要做的就是分析和切词，将数据标准化（nomallazation），在使用lucene组件搜索时，也会对搜索的关键词做分析和切词，然后与document做交集运算。我们在搜索时可以使用指定的type搜索。

六、Elastic Search的集群原理

1、索引存放的形式

使用集群成员发现方式，使用一致性算法进行分布式存储，以分片（shard）存储方式存储索引，将一个索引切成N片，每个所谓的节点都有所谓的主分片（primary shard）和副本分片（replica shard），没有节点的副本，只有分片的副本，primary shard和replica shard不会存在同一个节点上。

2、配置分片的方案

1）在节点较少的情况下分配大量分片，有好处也有坏处：

好处，当添加新的节点时，进行rebalance显得相当容易，直接使用较为空闲的分片分配给新的节点即可。
坏处，当有查询请求的时候，会遍历所有的分片，增加了查询的时长。

2）配置与节点数量相匹配的分片是，当有查询请求时可以以最快的速度响应，但当扩容节点时则需要均匀分配大量的索引数据。

3）综合上述两种方案可以取折中的办法来实现，具体情况由实际线上环境来决定。

3、Elastic Search查询数据的流程

Elastic Search的集群是无中心节点的，Client向任何一个节点发出查询都是OK的，但是对于Elastic Search来说，整个分片集群才能构建一个完整的index，而对于Lucene来说，单个elastic Search节点内的一个shard就是一个完整的索引。所以当有Client发起查询后，Client所连接的Elastic Search节点需要与集群中其他节点进行通讯，获取其他节点的index数据之后和自己节点的index数据一并返回给Client。

当Client所连接的ES-node宕机，这时候需要的就是一台Smart Client

也可以使用服务总线来进行连接

4、ES集群的状态

状态有三种：

red，yellow，green

green：所有shard的祝福分片都可以正常使用；
yellow：存在某个或某些分片缺少主或副；（会自动修复变为green）
red：存在某个或某些分片同时缺少主或副；（只能人工重新进行索引，或恢复备份。）

ES同样使用quorum机制，当发生网络分区时，只有超过半数票数的node才能够正常工作。