背景

1.ES PAAS管理的集群升级了100+，从7.5升级到7.17 （保证每个大版本最终仅维护一个小版本集群）

2.由于业务使用差异大，也出了不少问题，前面的文章也有提到过Integer类型字段使用terms查询效率低的情况

3.这里再分析一个CPU、IO飙升的场景

现象

1.用户报障：“ES集群写入吞吐量变小了”

2.观察下来发现确实CPU高了，IO也有明显抖动

排查与分析

1.发现YoungGC频率变高了一些，猜测可能是G1GC的问题（我们使用JDK11重新打了ES镜像），经过版本替换，没有明显变化。

参考issue：https://github.com/elastic/ela ... 46169

这可能是另一个场景的case，经过测试，不属于我们的场景。

2.多次执行hot_threads API观察， 发现时不时会出现 update相关函数 消耗的 CPU多。

3.继续使用arthas抓取一段时间的数据，发现是 FST、DocID 读取慢

从图中可以看到Bulk请求执行过程中的getDocID方法占有大量CPU。

4.集群写多读少，使用的是niofs。可知，7.5版本的FST是在堆外，但是_id字段是在堆内。升级到7.17版本后，FST在堆外，该字段也放到了堆外（官方版本应该是7.9就开始放到堆外了）。数据放到堆外，其实也就是文件放到磁盘，读一次之后放到pagecache。

这样也就可以解释了，在upsert类请求多的时候会频繁查询docId，此时如果_id字段没有进入pageCache或者被踢出pageCache，那么就会出现响应慢，并且CPU高、IO高的情况。

5.mmapfs、hybridfs实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障。

测试验证

将FST、BKD等全部改成放到堆内（开源版需要改造）

可以看到，CPU有显著下降，也相对均衡。（之前蓝色线高，是因为该节点有大量的主分片）

结论

1.update、upsert、get等请求如果十分频繁，_id使用offheap将不会是个好的选择，除非给足够的堆外内存，并且保证尽可能常驻内存。

2.不同的业务场景下使用ES的同一版本也会有不一样的效果。

3.mmapfs、hybridfs在频繁update情况下，实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障，可能不会有这么明显的差距。（官方描述写入速度仅降低了1.8%）

4.最后吐槽一下，写入不停的情况下，translog的恢复实在是太慢了，由于大分片恢复/rebalance时，translog不会被清理，导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。

在本文章中，我们将学习如何使用 Elasticsearch Hadoop 处理大量数据。 对于我们的练习，我们将使用一个简单的 Apache access 日志来表示我们的 “大数据”。 我们将学习如何编写 MapReduce 作业以使用 Hadoop 摄取文件并将其索引到 Elasticsearch 中。在我们今天的练习中，我们将使用如下的架构来搭建我们的系统：




 
如上所示，我们在左边的 macOS 中安装 Elasticsearch 及 Kibana，而在 Ubuntu OS 中安装 Hadoop。我们将以最新的 Elastic Stack 8.4.2 来进行展示。

Hadoop 是什么？

当我们需要收集、处理/转换和/或存储数千 GB、数千 TB 甚至更多的数据时，Hadoop 可能是完成这项工作的合适工具。它是从头开始构建的，考虑到这样的想法：

• 一次使用多台计算机（形成一个集群），以便它可以并行处理数据，从而更快地完成工作。我们可以这样想。如果一台服务器需要处理 100 TB 的数据，它可能会在 500 小时内完成。但是如果我们有 100 台服务器，每台只能取一部分数据，例如 server1 可以取第一个 TB，server2 可以取第二个 TB，以此类推。现在他们每个人都只有 1 TB 的数据要处理，而且他们都可以同时处理自己的数据部分。这样，工作可以在 5 小时内完成，而不是 500 小时。当然，这是理论上的和想象的，因为在实践中我们不会减少 100 倍所需的时间，但我们可以非常接近如果条件理想。
• 在需要时可以很容易地调整计算能力。有更多的数据要处理，而问题要复杂得多？将更多计算机添加到集群。从某种意义上说，这就像在超级计算机上增加了更多的 CPU 内核。
• 数据不断增长，因此 Hadoop 也必须能够轻松灵活地扩展其存储容量，以满足需求。我们添加到集群的每台计算机都会扩展 Hadoop 分布式文件系统 (HDFS) 的可用总存储空间。
• 与其他软件不同，它不仅会在硬件故障发生时尝试从硬件故障中恢复。设计理念实际上假设某些硬件肯定会失败。当有数千台计算机并行工作时，可以保证某处某处会不时出现故障。因此，默认情况下，Hadoop 创建数据块的副本并将它们分布在单独的硬件上，因此当偶尔的服务器起火或硬盘或 SSD 死机时，不会丢失任何内容。

总而言之，Hadoop 非常擅长摄取和处理大量信息。它将数据分布在集群中可用的多个节点上，并使用 MapReduce 编程模型在多台机器上同时处理数据（并行处理）。

但这听起来可能有点类似于 Elasticsearch 数据摄取工具所做的事情。尽管它们是为处理相当不同的场景而设计的，但它们有时可能会有些重叠。那么我们为什么以及何时使用其中一个而不是另一个呢？

Hadoop vs Logstash/Elasticsearch

首先，我们不应该考虑哪个比哪个更好。 每个人都擅长为其创造的工作。 每个都有优点和缺点。

为了尝试给你绘制一个图片并让你了解我们何时使用其中一个，让我们考虑以下场景：

• 当我们需要从数十亿个网站中提取数据时，就像谷歌这样的搜索引擎所做的那样，我们会发现像 Elasticsearch 及 Hadoop 这样的工具非常有用和高效。
• 当我们需要以这样一种方式存储数据并对其进行索引以便以后可以快速有效地搜索时，我们会发现像 Elasticsearch 这样的东西非常有用。
• 最后，当我们想要收集实时数据时，例如来自互联网上许多交易所的美元/欧元价格，我们会发现像 Logstash 这样的工具非常适合这项工作。

 
更多阅读，请参阅 https://elasticstack.blog.csdn ... 97392

背景

1.对于7版本（大版本）集群希望只维护一个版本，最终选择7.17，对同大版本的7.5版本集群进行升级

2.根据官方描述，_id放到堆外性能损失非常小可以忽略，且对BKD进行了优化

3.升级完成，一段时间之后，收到用户报障

4.抽样检查了下部分升级的集群，其中部分受到影响，部分不受影响。且每个集群内存均有一定优化（预期内）

调查&分析

1.发现is_deleted文档特别多，怀疑是7.17版本对于碎片过于敏感。做forcemerge，没什么效果。

2.GET _nodes/hot_threads 查看耗时部分，结果展示笼统，没得到关键信息。

3.给语句加上profile，查看耗时部分。
<br /> GET index-v1/_search<br /> {"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}<br />

从脱敏的简化结果中可以看出来，主要是 status、pId 字段耗时高，这两个字段都是integer类型，并且使用了terms查询。
<br /> {<br /> "took": 554,<br /> "timed_out": false,<br /> "_shards": {<br /> "total": 3,<br /> "successful": 3,<br /> "skipped": 0,<br /> "failed": 0<br /> },<br /> "hits": {<br /> "total": {<br /> "value": 5,<br /> "relation": "eq"<br /> },<br /> "max_score": null,<br /> "hits": [<br /> ...<br /> ]<br /> },<br /> "profile": {<br /> "shards": [<br /> {<br /> "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",<br /> "searches": [<br /> {<br /> "query": [<br /> {<br /> "type": "BooleanQuery",<br /> "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",<br /> "time_in_nanos": 415205306,<br /> "breakdown": {<br /> ...<br /> "build_scorer": 415028271<br /> },<br /> "children": [<br /> {<br /> "type": "TermQuery",<br /> "description": "xid:111111111",<br /> "time_in_nanos": 102656,<br /> "breakdown": {<br /> .....<br /> "build_scorer": 86264<br /> }<br /> },<br /> {<br /> "type": "PointInSetQuery",<br /> "description": "status:{2 3 4}",<br /> "time_in_nanos": 220394978,<br /> "breakdown": {<br /> ....<br /> "build_scorer": 220385119<br /> }<br /> },<br /> {<br /> "type": "ConstantScoreQuery",<br /> "description": "ConstantScore(platform:aaa platform:bbb)",<br /> "time_in_nanos": 341845,<br /> "breakdown": {<br /> .....<br /> "build_scorer": 282277<br /> },<br /> "children": [<br /> {<br /> "type": "BooleanQuery",<br /> "description": "platform:aaa platform:bbb",<br /> "time_in_nanos": 329042,<br /> "breakdown": {<br /> .....<br /> "build_scorer": 277752<br /> },<br /> "children": [<br /> {<br /> "type": "TermQuery",<br /> "description": "platform:aaa",<br /> "time_in_nanos": 62446,<br /> "breakdown": {<br /> .....<br /> "build_scorer": 37931<br /> }<br /> },<br /> {<br /> "type": "TermQuery",<br /> "description": "platform:bbb",<br /> "time_in_nanos": 15093,<br /> "breakdown": {<br /> .....<br /> "build_scorer": 6981<br /> }<br /> }<br /> ]<br /> }<br /> ]<br /> },<br /> {<br /> "type": "PointInSetQuery",<br /> "description": "pId:{1 2}",<br /> "time_in_nanos": 194164297,<br /> "breakdown": {<br /> ....<br /> "build_scorer": 194160452<br /> }<br /> }<br /> ]<br /> }<br /> ],<br /> "rewrite_time": 40044,<br /> "collector": [<br /> {<br /> "name": "SimpleFieldCollector",<br /> "reason": "search_top_hits",<br /> "time_in_nanos": 144012<br /> }<br /> ]<br /> }<br /> ]<br />

4.单个的profile无法说明问题，进一步排查：使用arthas工具获取一段时间内的火焰图

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题：https://discuss.elastic.co/t/v ... 152/3

6.integer类型的terms查询性能较差，看起来官方描述的BKD相关优化指的是range

7.测试验证，将字段改成keyword，查看结果，CPU查询耗时恢复到正常范围