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

背景

终于要用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集群的规模也在不断升级；正所谓没有最好的架构，只有最适合的架构，数据中台做性能最强、稳定最好、使用便捷的系统初心不会改变

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

背景