压制es-hadoop这头野兽的方式来了～

背景

每天elasticsearch集群在上午某个时间段CPU几乎打满，此时访问elasticsearch的服务rt会跟着抖动，通过排查发现是由于这个时间段会有数据通过hive任务写到elasticsearch，这个hive任务使用的是ES-Hadoop插件做的数据导入，整个问题的罪魁祸首已经发现了，那么应该怎么去解决呢？

优化方案一

ES-Hadoop组件已经发展多年，按道理说已经很成熟了，一般出现这种问题大概率都是使用不当的缘故，因此通过查看 官网配置 来查看是否使用不当，通过一番查看下来大致看到两个比较相关的配置

es.batch.size.entries: 控制每批写到Elasticsearch的消息条数
es.batch.write.retry.wait：控制重试批次之间时间间隔
1
2

通过反复针对这两个参数调优后发现，基本没太大的收益，此时elasticsearch集群CPU的突刺仿佛一把利刃插进心脏一样，不甘心，一定要将它消灭，此时又参考了网上不少优秀的文章例如 https://cloud.tencent.com/developer/article/1612108 这位大佬写的，但是并没有解决我的问题，继续摸索下一个方案

优化方案二

ES-Hadoop配置方式行不通，那么换个思路，咱们是通过Hive来将数据写到elasticsearch集群的，那么如果咱们将Hive任务的并行度降低些行不行呢？想到这里不禁喜悦起来，感觉自己又行了

通过下面几个配置来控制Hive写elasticsearch的并行度

set hive.exec.reducers.max=20;
set tez.am.vertex.max-task-concurrency=20;
set hive.tez.auto.reducer.parallelism=false;
1
2
3

虽然已经大幅降低并行度了，但是elasticsearch的CPU还是高居不下，仿佛在说，你过来打我呀～

优化方案三

通过上面两个失败的方式后，通过思考