ES集群优化 之 海量时序数据处理

0.24字数 1259阅读 1158

背景

终于要用ES干一件大事了,最近一个需求需要记录用户作品的实时访客行为,有点类似于pv明细日志,记录用户什么时间打开的产品、在里面都做了什么操作,初步预估日流量在5000w左右,月累积15亿+,业务方要求数据保留1年,没有聚合,只需支持任意检索与排序,这么大的数据量如何实现高并发下的查询排序将是一个很大的挑战。

操作流程

经常有同学问我,想用ES但不知道怎么去优化,根据在易企秀多年业务实战经验总结 分别是:集群规划、索引配置、存储策略、索引拆分、冷热分区、段合并等几个维度优化。

集群规划

hot 组 4台:

参数 说明
cpu 16c
内存 48g
硬盘 300g ssd
数据 近3个月
特点 经常读写

cold 组 2台:

参数 说明
cpu 16c
内存 64g
硬盘 1T*2 hdd
数据 历史9个月
特点 没有写、也不怎么读

索引配置

搜索业务不同,并不需要对文档数据的相关度计算,所以索引配置可以做些优化:

1、通过配置index_options优化text field的索引生成方式,es默认除生成倒排以外还会记录文档的词频与term的位置信息,如果只是用来对文档的检索不需要评分与高亮,可优化。

2、禁用field评分,如果该字段不需参与相关度打分那么可禁用,通过将norms设置为false来禁用评分提升检索性能。

3、禁用doc_values,es为提升keyword类型下数据的排序与聚合性能,默认为每一个keyword field都开启了此功能,非必要场景禁用此操作可节省磁盘空间。

4、开启最优化压缩,通过配置"index.codec":"best_compression"开启最优压缩,可节省磁盘空间,但会增大cpu负载。

5、单分片的优势是检索速度快,但并发支持不高;我们大多数业务场景 1-2 个分片足够了(官方建议单分片10-20亿条,20GB 到 40GB存储大小为最佳)。

6、热数据采用两副本,提升数据容错与检索性能,冷数据禁用副本分片,节约存储空间。

7、设置刷新,当月数据设置"index.refresh_interval":"120s",历史索引禁用刷新操作。

8、translog异步操作,"index.translog.durability": "async"

9、term的使用
ES 7对term类型做了性能优化 ,较之前提升37倍多,所以能用term解决的就不要使用数值或文本类型

10、自动生成Id
因为存储的是用户行为日志,所以不存在更新操作,每条日志的唯一标识可随机生成,写入性能提升近1倍。

索引策略

routing,根据某个字段将相同数据发送到相同分片上存储,检索时使用相同路由策略可实现数据的快速获取:

shard_num = hash(_routing) % num_primary_shards

默认使用doc id路由,因为我们存储的是用户作品的访问记录,这里会根据user_id,将同一用户下作品数据的访问记录路由到一个分片:

PUT my_index/my_type/1?routing=user_id
{
  "title": "This is a document"
}

GET my_index/my_type/1?routing=user_id

由于用户的作品量是不同的,且不同作品的传播能力差别也很大,故上面的路由规则实际操作过程中会出现数据倾斜的问题,导致各别节点存储资源,检索压力会特别大,故优化上述路由策略,新增routing_partition_size

shard_num = (hash(_routing) + hash(_id) % routing_partition_size) % num_primary_shards

routing_partition_size 为ES 6.x之后新增配置,取值大于1 且小于主分片数,另外在mapping中还需配置:


{
  "mappings": {
    "_routing": {
      "required": true 
    }
  }
}

经测试 routing 在分片数大于2时使用效果明显

索引拆分(冷热分离)

应用程序内通过系统时间动态生成索引,并将超出3个月的索引通过定时任务归档到cold组 :
1、将data node划分为冷热数据节点

# cat elasticsearch.yml    // 配置文件设置tag区分
node.attr.tag: cold/hot   

# bin/elasticsearch -d -Enode.attr.box_type=hot  //启动设置

2、根据模板按月生成索引,格式如 visitor_2019-01

  
#构建索引模板,滚动新增的索引将按照模板进行创建
curl -X PUT "localhost:9200/_template/visitor" -H 'Content-Type: application/json' -d'
{
  "index_patterns": ["visitor_*"], 
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1,
    "index.routing.allocation.include.tag" : "hot"
  },
 "mappings": {}
}
' 

3、归档历史数据到cold节点

curl -X PUT "${es}/${i}/_settings" -H 'Content-Type: application/json' -d'{
        "number_of_replicas": 0,
        "index.routing.allocation.include.tag": "cold"
     }'

段合并

对于不再进行数据写入的历史索引,强制进行segment合并可大幅提升检索性能


curl -XPOST "http://host/visitor/_forcemerge?only_expunge_deletes=true&max_num_segments=1&flush=true"

结论

想要了解按照上面流程优化后的实际性能,请关注我的下一篇文章 ES数据实测分析

架构的快速迭代源于业务的快速发展,正是由于易企秀近几年的快速发展,ES集群的规模也在不断升级;正所谓没有最好的架构,只有最适合的架构,数据中台做性能最强、稳定最好、使用便捷的系统初心不会改变