使用hive往elasticsearch的映射外部表中插入数据，

报错：

Caused by: org.elasticsearch.hadoop.EsHadoopException: Could not write all entries [166/1047616] (maybe ES was overloaded?). Bailing out...

分析：

ES涉及到该部分源码如下：
    public void flush() {
        BulkResponse bulk = tryFlush();
        if (!bulk.getLeftovers().isEmpty()) {
            String header = String.format("Could not write all entries [%s/%s] (Maybe ES was overloaded?). Error sample (first [%s] error messages):\n", bulk.getLeftovers().cardinality(), bulk.getTotalWrites(), bulk.getErrorExamples().size());
            StringBuilder message = new StringBuilder(header);
            for (String errors : bulk.getErrorExamples()) {
                message.append("\t").append(errors).append("\n");
            }
            message.append("Bailing out...");
            throw new EsHadoopException(message.toString());

}

 官方说法：If you configure your hive query to use a combined input format to lower the number of splits on the job then that would give ES larger and fewer batches of records, and fill up its task queue less frequently.

由以上加百度相关资料可知，出现此问题的原因是hadoop与es下入速度不一致，或者说hive的写入速度大于es的接收速度，es由于集群规模问题或者资源问题无法同时接收hive过多的并发数。

对于以上问题，解决思路如下：

1.增加es接收速度和效率

增加重试次数

2.减少hive的并发请求

减少hadoop任务/工作的数量

减少文档/大小的数量

解决方案：

方案一：增加es接收速度

1.在创建es在hive中的映射表时，将建表语句中的参数es.batch.size.enries设置大一些。另外es是有重试机制的，默认重试三次，每次重试等待时间10秒，这是可配参数，通过修改参数"es.batch.write.retry.count"和"es.batch.write.retry.wait"修改即可。优化无黄金法则，具体需要按实际情况调试。

2.安装es的时候对elasticsearch.yml进行修改，使用bulk，建议每个请求大小建议在5-15MB，逐步增大测试,当接收到EsRejectedExecutionException，就说明已经到达节点的瓶颈了，就需要减少并发或者升级硬件增加节点。

当写入数据时，确保bulk请求时轮询访问所有节点，不要发送所有请求到一个结点导致这一个节点要在内存存储所有请求的数据去处理。

其他参数按实际情况优化，示例如下：

indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb

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

# 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

indices.fielddata.cache.size: 40%

discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s

大数量写入的场景，会占用大量的网络带宽，很可能使节点之间的心跳超时。并且默认的心跳间隔也相对过于频繁（1s检测一次）
具体参数优化及解释详见：https://blog.csdn.net/wmj2004/article/details/80804411

另附es写入性能优化：https://blog.csdn.net/jamesjxin/article/details/50512106

方案二：限制hive的请求数量

控制hive执行的map数

减少map数，减少split文件的数量(100000000为100M切分一个文件，可适当增大)，合并小文件

set mapred.max.split.size=100000000;

set mapred.min.split.size.per.node=100000000;

set mapred.min.split.size.per.rack=100000000;

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

附控制hive任务中的map数和reduce数：https://www.cnblogs.com/xiohao/p/6404042.html以及https://blog.csdn.net/jiedushi/article/details/8448292