spark 向elasticsearch 优化写入数据

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/lidaxueh_heart/article/details/81046513

 一、前言

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

 

二、 调整策列

       1.由于该项目是离线任务,并不是需要实时查询,可以将es中的near real-time search属性 设置较高的阈值30s或者-1 。默认情况下写入到es的数据并不是马上就刷到磁盘,先放在 in-memory buffer,但客户端是读取不到in-memory buffer中的数据,为了实时查询,需要定期(默认1s)将该数据刷写到介于es和磁盘之间的filesystem cache 即refresh,该操作轻量级的 。写入到filesystem cache相当于创建新的segment  是可以被客户端读取到的, 默认属性(阈值是1s)由于快速的刷数据导致很多小量的filesystem cache,同时写入到filesystem cache仍然有一些性能消耗,所以根据应用的使用场景,如果是关注写入速度并不关注实时查询,可以适当调整默认的阈值的,该属性是在创建索引(属性值为:index.refresh_interval)的时候设置 的 。关于near real-time search 原理 见官网链接:Near Real-Time Search

       2.index.translog.durability 默认值是request,该属性类似于hbase 中的WAL,是为了防止数据写入后 ,还没有落盘之前 出现宕机导致数据丢失。client提交request后,除了在in-memory buffer 添加新的文档/操作,还需要在translog 追加新的文档/操作 ,以保证数据的可靠性 。 其实translog.durability 属性可以设置为async,当然async并不能保证新的文档/操作一定写入到trans-log,如果写到translog 没有成功 刚好这时也出现宕机,重启后从translog恢复时就会有数据丢失,所以我们需要在做好数据可靠性和写入效率之间做好权衡后再设置 。translog在  满足下面其中一个条件时 会执行commit 请求即filesystem cache 刷写到磁盘  condition1:缓存数据达到512M(default) condition2 : 缓存时间达到5s(default),commit成功后translog会删除 。更详情文档见官网链接:Making Changes Persistent

       3. 设置es.batch.size.bytes 以及es.batch.size.entries的数值,该数值表示es bulk操作中的batch大小和条数。这些设置对应到每个task中。hadoop/spark 相关配置信息见链接:点击打开链接

       4. 其他设置: 不需要分词可以将字段类型设置为not_analyzed 、让es自动生成id 、根据es集群的配置调整合适的shard num 、spark写入是否存在数据倾斜以保证分布式计算的集群的优势 等

 

三、 最后

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

         

展开阅读全文

没有更多推荐了,返回首页