一、前言

       
近期有个项目用spark向es(版本5.x)写入数据,该项目是离线任务,每天创建一个index存数据,随着数据量的增大(2亿+,峰值有5亿+)。性能出现问题:写入时间过长,es响应不过来等




二、 调整策列

       1.由于该项目是离线任务,并不是需要实时查询,可以将es中的near real-time search属性 设置为-1
。默认情况下写入到es的数据并不是马上就刷到磁盘,而是先buffer起来(内存),但是这个时候客户端是读取不到该数据,为了实时查询,需要定期(默认1s)将该数据刷写到介于es和磁盘之间的filesystem
cache (内存),写入到filesystem cache 是可以被客户端读取到的, 默认属性由于快速的刷数据导致很多小量的filesystem
cache,该属性是在创建表的时候设置的 (关于near real-time search 原理 见链接:点击打开链接
<https://www.elastic.co/guide/en/elasticsearch/guide/current/near-real-time.html>


    2.index.translog.durability 默认值是request,该属性类似于hbase
中的WAL,是为了防止写入的数据丢失,在index或者delete的时候需要将“改变”写入到translog中。在每个请求提交后,就将写在translog中的“改变”刷新到磁盘中。可以设置为async,该值表示先将“改变”写入到内存 
满足下面其中一个条件再刷到磁盘 condition1:缓存数据达到512M(default) condition2 : 缓存时间达到5s(default)
。当然设置为async后牺牲了一定的数据安全性。设置详情见官网链接:点击打开链接
<https://www.elastic.co/guide/en/elasticsearch/reference/5.5/index-modules-translog.html>

          3. 设置es.batch.size.bytes 以及es.batch.size.entries的数值,该数值表示es
bulk操作中的batch大小和条数。这些设置对应到每个task中。(hadoop/spark 配置信息见链接:点击打开链接
<https://www.elastic.co/guide/en/elasticsearch/hadoop/5.5/configuration.html>)

          4. 其他设置: 不需要分词可以设置为not_analyzed ,自动生成id ,根据集群的信息适当的增加shard num
,spark 获取的数据是否存在数据倾斜等




三、 最后

       
调整上面的配置后,速度提升了5倍多,而且很还少出现es响应不过来的信息。由于本人能够有限,对上面的描述有误的地方欢迎提出,同时有其他优化方案也可以分享!

         

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信