Elastic Stack 开源的大数据解决方案

目的

本文主要介绍的内容有以下三点：

一. elastic stack是什么以及组成部分

二. elastic stack前景以及业务应用

三. elasticsearch原理（索引方向）

四. elasticsearch相对薄弱的地方

一、elastic stack是什么以及组成部分

介绍elastic stack是什么，其实只要一句话就可以，就是: 一套完整的大数据处理堆栈，从摄入、转换到存储分析、可视化。

它是不同产品的集合，各司其职，形成完整的数据处理链，因此elastic stack也可以简称为blek。

beats 轻量型数据采集器

logstash 输入、过滤器和输出

elasticsearch 查询和分析

kibana 可视化，可自由选择如何呈现数据

1. beats - 全品类采集器，搞定所有数据类型

filebeat（日志文件）：对成百上千、甚至上万的服务器生成的日志汇总，可搜索。

metricbeat（指标）: 收集系统和服务指标，cpu 使用率、内存、文件系统、磁盘 io 和网络 io 统计数据。

packetbeat（网络数据）：网络数据包分析器，了解应用程序动态。

heartbeat（运行时间监控）：通过主动探测来监测服务的可用性

......

beats支持许许多多的beat，这里列的都是比较的常用的beat，了解更多可以点击链接：beats 社区

2. logstash - 服务器端数据处理管道

介绍logstash之前，我们先来看下linux下常用的几个命令

cat alldata.txt | awk ‘{print $1}’ | sort | uniq | tee filterdata.txt

只要接触过linux同学，应该都知道这几个命名意思

cat alldata.txt #将cat alldata.txt的内容输出到标准设备上
awk ‘{print $1}’ #对上面的内容做截取，只取每一行第一列数据
sort | uniq  #对截取后的内容，进行排序和唯一性操作
tee filterdata.txt #将上面的内容写到filterdata.txt

上面的几个简单的命令就可以看出来，这是对数据进行了常规的处理，用名词修饰的话就是：数据获取/输入、数据清洗、数据过滤、数据写入/输出

而logstash做的也是相同的事（看下图）。

将系统的日志文件、应用日志文件、系统指标等数据，输入到input，再通过数据清洗以及过滤，输入到存储设备中，这里当然是输入到elasticsearch

3. elasticsearch - 分布式文档存储、restful风格的搜索和数据分析引擎

elasticsearch主要也是最原始的功能就是搜索和分析功能。这里就简单说一下，下面讲原理的时候会着重讲到elasticsearch

搜索：全文搜索，完整的信息源转化为计算机可以识别、处理的信息单元形成的数据集合 。

分析：相关度，搜索所有内容，找到所需的具体信息（词频或热度等对结果排序）

4. kibana- 可视化

可视化看下图（来源官网）便知

可以对日志分析、业务分析等做可视化

现在从总体上来了解下，在心中对elastic stack有个清楚的认知（下图）。

二、elastic stack前景以及业务应用1. db-engines 排名

elasticsearch是elastic stack核心，由图可以看出在搜索领域elasticsearch暂时没有对手。

2. es社区

es中文社区也是相当活跃的，会定期做一下分享，都是大公司的宝贵经验，值得参考。

3. 2018年携程的使用情况（让我们看看能处理多大的数据）

集群数量是94个，最小的集群一般是3个节点。全部节点数量大概700+。

最大的一个集群是做日志分析的，其中数据节点330个，最高峰一天产生1600亿文档，写入值300w/s。

现在有2.5万亿文档，大概是几个pb的量

三、elasticsearch（es）原理

因为篇目有限，本篇只介绍es的索引原理。

es为什么可以做全文搜索，主要就是用了倒排索引，先来看下面的一张图

看图可以简单的理解倒排索引就是：关键字 + 页码

对倒排索引有个基本的认识后，下面来做个简单的数据例子。

现在对name做到排索引，记住：关键字 + id（页码）。

对age做到排索引。

对intersets做到排索引。

现在搜索age等于18的，通过倒排索引就可以快速得到1和3的id，再通过id就可以得到具体数据，看，这样是不是快的狠。

如果是用mysql等关系数据库，现在有十多亿数据（大数据嘛）,就要一条一条的扫描下去找id，效率可想而知。而用倒排索引，早到所有的id就轻轻松松了。

在es中，关键词叫term，页码叫posting list。

但这样就行了吗？ 如果name有上亿个term，要找最后一个term，效率岂不是还是很低？

再来看name的倒排索引，你会发现，将armani放在了第一个，tyloo放在了第三个，可以看出来，对term做了简单的排序。虽然简单，但很实用。这样查找term就可以用二分查找法来查找了，将复杂度由n变成了logn。

在es中，这叫term dictionary。

到这里，再来想想mysql的b+tree， 你有没有发现原理是差不多的，那为什么说es搜索比mysql快很多，究竟快在哪里？ 接下来再看。

有一种数据结构叫trie树，又称前缀树或字典树，是一种有序树。这种数据结构的好处就是可以压缩前缀和提高查询数据。

现在有这么一组term： apps, apple, apply, appear, back, backup, base, bear，用trie树表示如下图。

通过线路路径字符连接就可以得到完成的term，并且合用了前缀，比如apps, apple, apply, appear合用了app路径，节省了大量空间。

这个时候再来找base单词，立即就可以排除了a字符开头的单词，比term dictionary快了不知多少。

在es中，这叫term index

现在我们再从整体看下es的索引

先通过trie树快速定位block（相当于页码）, 再到term dictionary 做二分查找，得到posting list。

索引优化

es是为了大数据而生的，这意味着es要处理大量的数据，它的term数据量也是不可想象的。比如一篇文章，要做全文索引，就会对全篇的内容做分词，会产生大量的term，而es查询的时候，这些term肯定要放在内存里面的。

虽然trie树对前缀做了压缩，但在大量term面前还是不够，会占用大量的内存使用，于是就有es对trie树进一步演化。

fst（finite state transducer ）确定无环有限状态转移器 （看下图）

可以看appear、bear 对共同的后缀做了压缩。

posting list磁盘压缩

假设有一亿的用户数据，现在对性别做搜索，而性别无非两种，可能"男"就有五千万之多，按int4个字节存储，就要消耗50m左右的磁盘空间，而这仅仅是其中一个term。

那么面对成千上万的term，es究竟是怎么存储的呢？接下来，就来看看es的压缩方法。

frame of reference （for） 增量编码压缩，将大数变小数，按字节存储

只要能把握“增量，大数变小数，按字节存储”这几个关键词，这个算法就很好理解，现在来具体看看。

现在有一组posting list：[60, 150, 300,310, 315, 340], 按正常的int型存储，size = 6 * 4（24）个字节。

按增量存储：60 + 90（150）+ 150（300） + 10（310） + 5（315）+ 25（340），也就是[60, 90, 150, 10, 5, 25]，这样就将大数变成了小数。

切分成不同的block：[60, 90, 150]、[10, 5, 25]，为什么要切分，下面讲。

按字节存储：对于[60, 90, 150]这组block，究竟怎么按字节存储，其实很简单，就是找其中最大的一个值，看x个比特能表示这个最大的数，那么剩下的数也用x个比特表示（切分，可以尽可能的压缩空间）。

[60, 90, 150]最大数150 < 2^8 = 256，也就是这组每个数都用8个比特表示，也就是 3*8 = 24个比特，再除以8，也就是3个字节存在，再加上一个8的标识位（说明每个数是8个比特存储）,占用一个字节，一共4个字节。

[10, 5, 25]最大数25 < 2^5 = 32，每个数用5个比特表示，3*5=15比特，除以8，大约2个字节，加上5的标识位，一共3个字节。

那么总体size = 4 + 3（7）个字节，相当于24个字节，大大压缩了空间。

再看下图表示

posting list内存压缩

同学们应该都知道越复杂的算法消耗的cpu性能就越大，比如常见的https，第一次交互会用非对称密码来验证，验证通过后就转变成了对称密码验证，for同样如此，那么es是用什么算法压缩内存中的posting list呢？

roaring bitmaps 压缩位图索引

roaring bitmaps 涉及到两种数据结构 short[] 、bitmap。

short好理解就是2个字节的整型。

bitmap就是用比特表示数据大数据堆栈，看下面的例子。

posting list：[1, 2, 4, 7, 10] -> [1, 1, 0, 1, 0, 0, 1,0, 0, 1]，取最大的值10，那么就用10个比特表示这组posting list，第1, 2, 4, 7, 10位存在，就将相对应的“位”置为1，其他的为0。

但这种bitmap数据结构有缺陷，看这组posting list： [1, 3, 100000000] -> [1, 0, 1, 0, 0, 0, …, 0, 0, 1 ]，最大数是1亿，就要1亿的比特表示，这么算下来，反而消耗了更多的内存。

那如何解决这个问题，其实也很简单，跟上面一样，将大数变成小数。

看下图：

第一步：将每个数除以65536，得到（商，余数）。

第二步：按照商，分成不同的block，也就是相同的商，放在同一个block里面，余数就是这个值在这个block里面的位置（永远不会超过65536，余数嘛）。

第三步：判断底层block用什么数据结构存储数据，如果block里面的余数的个数超过4096个，就用short存储，反之bitmap。

上面那个图是官网的图，看下我画的图，可能更好理解些。

到这里，es的索引原理就讲完了，希望大家都能理解。

四、elasticsearch（es）相对薄弱的地方1. 多表关联

其实es有一个很重要的特性这里没有介绍到，也就是分布式，每一个节点的数据和，才是整体数据。

这也导致了多表关联问题，虽然es里面也提供了nested& join 方法解决这个问题，但这里还是不建议用。

那这个问题在实际应用中应该如何解决？ 其实也很简单，装换思路，es无法解决，就到其他层解决，比如：应用层，用面向对象的架构，拆分查询。

2. 深度分页

分布式架构下，取数据便不是那么简单，比如取前1000条数据，如果是10个节点，那么每个节点都要取1000条，10个节点就是10000条，排序后，返回前1000条，如果是深度分页就会变的相当的慢。

es提供的是scroll + scroll_after，但这个采取的是缓存的方式，取出10000条后，缓存在内存里，再来翻页的时候，直接从缓存中取，这就代表着存在实时性问题。

来看看百度是怎么解决这个问题的。

一样在应用层解决，翻页到一定的深度后，禁止翻页。

3. 更新应用

频繁更新的应用，用es会有瓶颈，比如一些游戏应用，要不断的更新数据，用es不是太适合，这个看大家自己的应用情况。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!