1、es写入报错及写入性能低问题排查
使用es的java 客户端 jestClient 进行bulk批量写入es 数据时，经过多次调整并行度，bulk批量写入的条数后，es 写入性能始终在 2.7w条/s 左右徘徊，并且在写入用户档案时，在大约1亿条 左右时，es会报【index has read-only-allow-delete block】
【index has read-only-allow-delete block】 该错误是由于es 部署的数据节点，磁盘存储使用率超过90%【由用户自行配置】，为避免集群出现问题，es将数据索引上锁，无法写入数据导致的。
代码中将写入es的错误信息返回给方法的调用者，方法调用者将该错误collect 收集后返回driver 端，当失败数据太大时，driver端 内存放不下这些数据，就会报oom
在数据写入任务运行时，查看es集群监控发现，只有单个节点的cpu使用率超过了90%，心想可能任务为单线程写入，将bulkData方法中的
修改为异步写入
经测试发现性能没有明显提升，且集群依然为单节点写入。
这时想起了es写入原理，如下图
即然不是代码出现问题，就将问题定位到集群，es是使用写入数据的id，根据路由规则定位到该数据具体写入哪个分片的，查看当前写入数据的分片，发现该索引分片数为1，副本数也为1，由于当前数据索引是在代码中建立的，将代码中创建索引的settings 添加如下代码
【当前集群数据节点为8个，所以将该索引的分片数设置为8，为提高写入性能，将分片副本数设置为0，如果对数据可靠性有要求，可以将分片副本数设置为1，或等待数据写入完成后，修改副本分片数】
运行写入任务
数据共写入2.2亿 + 1.4亿条，【在写入 用户档案 任务时，同时开启了 消费数据 写入任务】
用户档案 使用40分钟写入成功，消费数据 使用20分钟写入成功
