场景:
业务部门将客户画像结果表通过hive映射到es表，其中结果表600W条数据，但每条数据接近2W个标签，数据入到es后主要场景是多字段组合过滤查询后聚合求和。
优化思路
es默认最大字段数是1000,需要增大字段数

hive端优化： hive的取数据的速度大于写入到es的速度，es会由于集群规模问题或者资源问题无法同时接收hive过多的并发数。 由此hive端主要优化是减小map数

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat 将多个小文件打包作为一个整体的inputsplit，减少map任务数
set mapred.max.split.size=256000000;

set mapred.min.split.size.per.node=256000000

set  Mapred.min.split.size.per.rack=256000000

增大map输入split的大小

es端优化：主要分为索引设计层面和数据写入层面

#创建es索引 curl -u ${ESUser}:${ESPasswd} -X PUT -H "Content-Type: application/json" "http://${ESIP}:${ESPort}/${ESIndex}/" -d '{"settings":{"number_of_shards":10,"number_of_replicas": 0},"mappings":{'"cmfe_coscp_tag_cust_base"':{"_all":{"enabled":false}}}}'

#修改es设置curl -u ${ESUser}:${ESPasswd} -X PUT -H "Content-Type: application/json" "http://${ESIP}:${ESPort}/${ESIndex}/_settings" -d'{"index.mapping.total_fields.limit":"5000","refresh_interval":"60s","index.translog.durability":"async"}'

'es.batch.size.entries' = '100', 'es.batch.size.bytes' = '1mb', 'es.batch.write.retry.count' = '10', 'es.batch.write.retry.wait' = '60s',
优化参数详解
精细设置全文域：string类型字段默认会分词，不仅会额外占用资源，而且会影响创建索引的速度。所以，把不需要分词的字段设置为not_analyzed
禁用_all字段
副本数量设置为0:全量数据保存在hadoop es副本数量是可以随时修改的，区别分片数量
使用es自动生成id：es对于自动生成的id有优化，避免了版本查找。因为其生成的id是唯一的
设置index.refresh_interval：索引刷新间隔，默认为1s。因为不需要如此高的实时性，我们修改为30s 
设置段合并的线程数量： "index.merge.scheduler.max_thread_count" : 1
设置异步刷盘事务日志文件："index.translog.durability": "async","index.translog.sync_interval": "30s"

集群层面参数设置

indices.memory.index_buffer_size: 20%,indices.memory.min_index_buffer_size: 96mb
 已经索引好的文档会先存放在内存缓存中，等待被写到到段(segment)中。缓存满的时候会触发段刷盘(吃i/o和cpu的操作)。默认最小缓存大小为48m，不太够，最大为堆内存的10%。对于大量写入的场景也显得有点小。

设置index、merge、bulk、search的线程数和队列数。例如以下elasticsearch.yml设置：
			# Search pool
			thread_pool.search.size: 5
			thread_pool.search.queue_size: 100
			# 这个参数慎用！强制修改cpu核数，以突破写线程数限制
			# processors: 16
			# Bulk pool
			thread_pool.bulk.size: 16
			thread_pool.bulk.queue_size: 300
			# Index pool
			thread_pool.index.size: 16
			thread_pool.index.queue_size: 300

``

大数量写入的场景，会占用大量的网络带宽，很可能使节点之间的心跳超时。并且默认的心跳间隔也相对过于频繁（1s检测一次）此项配置将大大缓解节点间的超时问题
discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s

补充 ：常用线程池参数设置
  threadpool.index.type: fixed 写索引线程池类型
  threadpool.index.size: 64 线程池大小（建议2~3倍cpu数）
  threadpool.index.queue_size: 1000 队列大小
  threadpool.search.size: 64 搜索线程池大小
  threadpool.search.type: fixed 搜索线程池类型 
  threadpool.search.queue_size: 1000 队列大小
  threadpool.get.type: fixed 取数据线程池类型 
  threadpool.get.size: 32 取数据线程池大小
  threadpool.get.queue_size: 1000 
  队列大小threadpool.bulk.type: fixed 批量请求线程池类型 
  threadpool.bulk.size: 32 批量请求线程池大小
 threadpool.bulk.queue_size: 1000 
 队列大小threadpool.flush.type: fixed 
 刷磁盘线程池类型 threadpool.flush.size: 32  刷磁盘线程池大小 threadpool.flush.queue_size: 1000 队列大小

相关链接
官方文档—es性能调优文档
ES索引写入性能优化_Jimmy的专栏-CSDN博客_es写入优化
阿里云elasticsearch实践（最大限度提高写入速度）

导语：在腾讯金融科技数据应用部的全民 BI 项目里，我们每天面对超过 10 亿级的数据写入，提高 ES 写入性能迫在眉睫，在最近的一次优化中，有幸参与到了 Elasticsearch 开源社区中。
本文是腾讯开源团队投稿。
背景
为了更便捷地分析数据，腾讯金融科技数据应用部去年推出了全民 BI 的系统。这个系统通过 Elasticsearch 进行基础的统计，超过 10 亿级的数据量需要尽可能快速地导入到 ES 系统中。即使经过多次的参数优化，我们依然需要几个小时才能完成导入，这是系统此前存在的一大瓶颈。
在这样的背景下，我们开始决定进一步深入 ES，寻找优化点。
优化前的准备
我们准备了 1000 万的数据，并在原程序(Spark 程序写入)上进行了几轮单机压测，得到了一些基本的性能数据。
机器配置：CPU 24核，内存 64G
ES 基本配置：
堆内存 31G
其他参数调整包括 lock memory，translog.durability 调整成 async 等(更详细的策略可以参见
https://github.com/elastic/elasticsearch/issues/45371)
文档数：1000 万，字段 400 个(没有 text 字段)
写入耗时：26 分钟
CPU：80%+
寻找理论值
在往下进入深水区之前，我们需要先回顾一下 ES 本身，ES 本身是在 Lucene 基础上设计的分布式搜索系统，在写入方面主要提供了：
事务日志和成组提交的机制提高写入性能并保证可靠性
提供 schema 的字段定义(映射到 Lucene 的字段类型)
要进行优化，首先得验证一个问题：Lucene 的极限速率能到达多少，所以我在我的本机上构建了这样的一个测试。
Macbook Pro 15，6核12线程
数据量 1000 万，每个 document 400 个字段，10 个线程并发(考虑 mac cpu Turbo 4.5G ，服务器 2.4G(24核)，所以只采用 10 线程并发)
验证写入耗时 549s(约 10 分钟)。
26 分钟 —> 10 分钟，意味着理论上是可行的。那剩下的就看如何接近这个极限。因为那说明一定是 ES 本身的一些默认特性导致了写入速率无法提升。
下面的介绍忽略了一些相对简单的参数调优，比如关闭 docvalues，这个对于非 text 字段，ES 默认开启，对于不需要 groupby 的场景，是不必要的，这个可以减少不少性能。
经过初步的参数优化写入耗时降低到了 18 分钟，这是后面继续往下优化的基础。
理解 ES 写入的机制
ES 的写入流程(主分片节点)主要有下面的几步
根据文档 ID 获取文档版本信息，判断进行 add 或 update 操作
写 Lucene：这里只写内存，会定期进行成组提交到磁盘生成新分段
写 translog：写入文件
▲ translog 作用
除了上面的直接流程，还有三个相关的异步流程
定期进行 flush，对 Lucene 进行 commit
定期对 translog 进行滚动(生成新文件)，更新 check point 文件
定期执行 merge 操作，合并 Lucene 分段，这是一个比较消耗资源的操作，但默认情况下都是配置了一个线程。
优化第一步 — 参数调优
写 Lucene 前面已经优化过，那么第一步的文档查找其实是在所有分段中进行查找，因为只提供了一个线程进行 merge，如果 merge 不及时，导致分段过的，必然影响文档版本这一块的耗时。
所以我们观察了写入过程中分段数的变化：
▲ 写入过程中分段的变化
观察发现，分段的增长速度比预期的快很多。按照默认配置，index_buffer=10%，堆内存 31G 的情况，按 Lucene 的写分段机制，平均到每个线程，也有 125M，分段产生的速度不应该那么快。而这个问题的根源就是 flush_threshold_size 默认值只有 512M ，这个参数表示在当未提交的 translog 日志达到该阈值的时候进行一次刷盘操作。
▲ 小分段的产生
▲ 调整后比较缓和的分段增长
测试结果一看：18 分钟！基本没有效果！
理论上可行的方案，为什么却没有效果，带着这个疑问继续潜入深水区。
优化继续 — 线程分析
这时候就需要进行堆栈分析了，多次取样后，发现了下面的一个频繁出现的现象：
▲ 被堵塞的线程
发现很多线程都停在了获取锁的等待上，而 writeLock 被 rollGeneration 占用了。
写线程需要获取 readLock
rollGeneration 拿走了 writeLock，会阻塞 readLock
而在高 flush_threshold_size 的配置下，rollGeneration 发生了 300+ 次，每次平均耗时 560ms，浪费了超过 168s，而这个时间里写入线程都只能等待，小分段的优化被这个抵消了。
这里有很多的关联关系，lush 操作和 rollGeneration 操作是互斥的，因为 flush 耗时较长(5~10 秒左右)，在默认 flush_threshold_size 配置下，rollGeneration 并没有这么频繁在 100 次左右，提高 flush_threshold 放大了这个问题。
初步优化方案提交
因为我们在写入过程中使用的 translog 持久化策略是 async，所以我很自然地想到了把写日志和刷盘异步化。
▲ 初版提交社区的方案
一开始的方案则想引入disruptor，消除写线程之间的竞争问题，后面因为es的第三方组件检查禁止使用sun.misc.Unsafe (disruptor无锁机制基于Unsafe实现)而放弃。
基于这个方案，测试结果终于出现了跨越：13分钟。
初版的方案问题比较多，但是它有两个特点：
足够激进：在配置为 async 策略时，将底层都异步化了
凸显了原方案的问题：让大家看到了 translog 写入的影响
Elastic 创始人加入讨论
没想到的是，在社区提交几次优化后，竟然吸引了大佬 Simon Willnauer 的加入。
Simon Willnauer
Elastic 公司创始人之一和技术 Leader
Lucene Core Commiter and PMC Member
Simon 的加入让我们重新复盘了整个问题。
通过对关键的地方增加统计信息，我最终明确了关键的问题点在于 FileChannel.force 方法，这个操作是最耗时的一步。
sync 操作会调用 FileChannel.force，但没有在 writer 的对象锁范围中，所以影响较小。但是因为 rollGeneration 在 writeLock 中执行，所以阻塞的影响范围就变大了
跟社区讨论后，Simon 最后建议了一个折中的小技巧，就是在关闭原 translog 文件之前(writeLock 之外)，先执行一次刷盘操作。
▲ 代码修改
这个调整的效果可以让每次 rollGeneration 操作的耗时从平均 570ms 降低到 280ms，在我的基准测试中(配置 flush_threhold_size=30G，该参数仅用于单索引压测设计，不能在生产环境使用)，耗时会从 18 分钟下降到 15 分钟。
事实上，这并不是一个非常令人满意的解决方案，这里选择这个方案主要出于两点考虑：
1.未来新的版本将考虑不使用 translog 进行副分片的 recovery，translog 的滚动策略会进行调整(具体方案 elasitc未透露)
2.这个修改非常的风险非常小
提交社区
最后根据讨论的最终结论，我们重新提交了 PR，提交了这个改动，并合并到了主干中。
总结和待续
下面是 ES 写入中的影响关系和调用关系图，从图中可以看到各个因素直接的相互影响。
▲ InternalEngine 中的影响关系
最近提交的优化实时上只优化了 rollGeneration，而实际上这里还有一些优化空间 trimUnreferenceReader，这个也在跟社区沟通中，并需要足够的测试数据证明调整的效果，这个调整还在测试中。
而在我们目前实际应用场景中，我们通过调整下面两个参数提高性能：
index.translog.flush_threshold_size 默认 512M，可以适当调大，但不能超过 indexBufferSize*1.5 倍/(可能并发写的大索引数量)，否则会触发限流，并导致 JVM 内存不释放！
index.translog.generation_threshold_size(默认 64M，系统支持，但官方文档没有的参数，超过该阈值会产生新的 translog 文件)，要小于 index.translog.flush_threshold_size，否则会影响 flush，进而触发限流机制
参考文档
张超《Elasticsearch源码解析与优化实战》
原文：https://mp.weixin.qq.com/s/KvFv_zrD_rnbfisUFo31tg
作者：开源中国
来源：我信公众号，开源中国
免费分享java技术资料，需要的朋友可以在关注后私信我

导语：在腾讯金融科技数据应用部的全民BI项目里，我们每天面对超过10亿级的数据写入，提高es写入性能迫在眉睫，在最近的一次优化中，有幸参与到了elasticsearch开源社区中。
背景

为了更便捷地分析数据，腾讯金融科技数据应用部去年推出了全民BI的系统。这个系统通过elasticsearch进行基础的统计，超过10亿级的数据量需要尽可能快速地导入到es系统中。即使经过多次的参数优化，我们依然需要几个小时才能完成导入，这是系统此前存在的一大瓶颈。

在这样的背景下，我们开始决定进一步深入es，寻找优化点。
优化前的准备

我们准备了1000万的数据，并在原程序（spark程序写入）上进行了几轮单机压测，得到了一些基本的性能数据。

机器配置：CPU 24核，内存 64G

ES基本配置：

· 堆内存31G

· 其他参数调整包括lock memory，translog.durability调整成async等(更详细的策略可以参见https://github.com/elastic/elasticsearch/issues/45371)

文档数：1000万，字段400个（没有text字段）

写入耗时：26分钟

CPU：80%+
寻找理论值

在往下进入深水区之前，我们需要先回顾一下es本身，es本身是基于lucene基础上设计的分布式搜索系统，在写入方面主要提供了：

· 事务日志和成组提交的机制提高写入性能并保证可靠性

· 提供schema的字段定义（映射到lucene的字段类型）

要进行优化，首先得验证一个问题：lucene的极限速率能到达多少，所以我在我的本机上构建了这样的一个测试。

Macbook pro 15，6核12线程

数据量1000万，每个document 400个字段，10个线程并发（考虑mac cpu Turbo 4.5G ，服务器2.4G（24核），所以只采用10线程并发）

验证写入耗时549s（约10分钟）。

26分钟 —> 10分钟，意味着理论上是可行的。那剩下的就看如何接近这个极限。因为那说明一定是es本身的一些默认特性导致了写入速率无法提升。

下面的介绍忽略了一些相对简单的参数调优，比如关闭docvalues，这个对于非text字段，es默认开启，对于不需要groupby的场景，是不必要的，这个可以减少不少性能。

经过初步的参数优化写入耗时降低到了18分钟，这是后面继续往下优化的基础。
理解es写入的机制

es的写入流程（主分片节点）主要有下面的几步

· 根据文档id获取文档版本信息，判断进行add或update操作

· 写lucene：这里只写内存，会定期进行成组提交到磁盘生成新分段

· 写translog：写入文件


[ translog作用 ]

除了上面的直接流程，还有三个相关的异步流程

· 定期进行flush，对lucene进行commit

· 定期对translog进行滚动（生成新文件），更新check point文件

· 定期执行merge操作，合并lucene分段，这是一个比较消耗资源的操作，但默认情况下都是配置了一个线程。
优化第一步-参数调优

写lucene前面已经优化过，那么第一步的文档查找其实是在所有分段中进行查找，因为只提供了一个线程进行merge，如果merge不及时，导致分段过的，必然影响文档版本这一块的耗时。

所以我们观察了写入过程中分段数的变化：



[ 写入过程中分段的变化 ]
观察发现，分段的增长速度比预期的快很多。按照默认配置，index_buffer=10%,堆内存31G的情况，按lucene的写分段机制，平均到每个线程，也有125M，分段产生的速度不应该那么快。

而这个问题的根源就是flush_threshold_size默认值只有512M ，这个参数表示在当未提交的translog日志达到该阈值的时候进行一次刷盘操作。


[ 小分段的产生 ]



[ 调整后比较缓和的分段增长 ]
测试结果一看：18分钟！基本没有效果！

理论上可行的方案，为什么却没有效果，带着这个疑问继续潜入深水区。
优化继续-线程分析

这时候就需要进行堆栈分析了，多次取样后，发现了下面的一个频繁出现的现象：



[ 被堵塞的线程 ]
发现很多线程都停在了获取锁的等待上，而writeLock被rollGeneration占用了。

写线程需要获取readLock

rollGeneration拿走了writeLock，会阻塞readLock

而在高flush_threshold_size的配置下，rollGeneration发生了300+次，每次平均耗时560ms，浪费了超过168s，而这个时间里写入线程都只能等待，小分段的优化被这个抵消了。

这里有很多的关联关系，lush操作和rollGeneration操作是互斥的，因为flush耗时较长（5~10秒左右），在默认flush_threshold_size配置下，rollGeneration并没有这么频繁在100次左右，提高flush_threshold放大了这个问题。
初步优化方案提交
因为我们在写入过程中使用的translog持久化策略是async,所以我很自然的想到了把写日志和刷盘异步化。



[ 初版提交社区的方案 ]
一开始的方案则想引入disruptor，消除写线程之间的竞争问题，后面因为es的第三方组件检查禁止使用sun.misc.Unsafe （disruptor无锁机制基于Unsafe实现）而放弃。

基于这个方案，测试结果终于出现了跨越：13分钟。

初版的方案问题比较多，但是它有两个特点：

· 足够激进：在配置为async策略时，将底层都异步化了

· 凸显了原方案的问题：让大家看到了Translog写入的影响
Elastic创始人加入讨论

没想到的是，在社区提交几次优化后，竟然吸引了大佬Simon Willnauer的加入。

Simon Willnauer

· elastic公司创始人之一和技术Leader

· Lucene Core Commiter and PMC Member

Simon的加入让我们重新复盘的整个问题。

通过对关键的地方增加统计信息，我最终明确了关键的问题点在于FileChannel.force方法，这个操作是最耗时的一步。

sync操作会调用FileChannel.force，但没有在writer的对象锁范围中，所以影响较小。但是因为rollGeneration在writeLock中执行，所以阻塞的影响范围就变大了

跟社区讨论后，Simon最后建议了一个折中的小技巧，就是在关闭原translog文件之前（writeLock之外），先执行一次刷盘操作。



[ 代码修改 ]
这个调整的效果可以让每次rollGeneration操作的耗时从平均570ms降低到280ms,在我的基准测试中（配置flush_threhold_size=30G,该参数仅用于单索引压测设计，不能在生产环境使用），耗时会从18分钟下降到15分钟。

事实上，这并不是一个非常令人满意的解决方案，这里选择这个方案主要出于两点考虑：

1.未来新的版本将考虑不使用Translog进行副分片的recovery，translog的滚动策略会进行调整（具体方案elasitc未透露）

2.这个修改非常的风险非常小
提交社区

最后根据讨论的最终结论，我们重新提交了PR，提交了这个改动，并合并到了主干中。
总结和待续

下面是es写入中的影响关系和调用关系图，从图中可以看到各个因素直接的相互影响。


[ InternalEngine中的影响关系 ]
最近提交的优化实时上只优化了rollGeneration，而实际上这里还有一些优化空间trimUnreferenceReader，这个也在跟社区沟通中，并需要足够的测试数据证明调整的效果，这个调整还在测试中。

而在我们目前实际应用场景中，我们通过调整下面两个参数提高性能：

· index.translog.flush_threshold_size 默认512M，可以适当调大，但不能超过indexBufferSize*1.5倍/(可能并发写的大索引数量)，否则会触发限流，并导致JVM内存不释放！

· index.translog.generation_threshold_size（默认64M，系统支持，但官方文档没有的参数，超过该阈值会产生新的translog文件），要小于index.translog.flush_threshold_size，否则会影响flush,进而触发限流机制
参考文档

1.张超《Elasticsearch源码解析与优化实战》