前言

对于一个软件系统，无论其业务逻辑复杂到何种程度，最终都将体现到一条（批）数据的CRUD操作上，即创建、查询、更新与删除。正如人类面临生死的轮回，数据亦是如此。一条数据从被创建出来开始，随着时间的逝去，其价值逐渐变小，最终被删除。尽管在有些场景下，我们对客户承诺其数据会被永久保存，但这也是相对而言的。

• Hot（热数据）
  • 被频繁查询或更新
  • 对访问的响应时间要求很高，通常在10毫秒以内
• Cold（冷数据）
  • 不允许更新，偶尔被查询
  • 对访问的响应时间要求不高，通常在1~10秒内都可以接受

冷热分离异构系统

相比单体系统而言，将冷热数据分离到两个系统中，必然会带来整体的复杂性，需要在性能、成本、复杂度等因素之间做的一个权衡。实践中，通常需要结合具体的业务，考虑下面几件事：

• 冷热数据系统的选型
• 确定冷热数据分割线
• 如何进行数据的迁移
• 如何应对跨系统的查询

在系统选型上，对于热数据系统，需要重点考虑读写的性能问题，诸如MySQL、Elasticsearch等会成为首选；而对于冷数据系统，则需要重点关注低成本存储问题，通常会选择存储在HDFS或云对象存储（比如AWS S3）中，再选择一个相应的查询系统。冷热数据是按照时间推移来区分的，因此必然要敲定一个时间分割线，即多久以内的数据为热数据，这个值通常会结合业务与历史访问情况来综合考量。对于超过时间线的数据，会被迁移到冷数据中，迁移过程需要确保两点：不能对热数据系统产生性能影响、不能影响数据查询。数据分离后，不可避免的会出现某个查询在时间上跨到两个系统里面，需要进行查询结果的合并，对于统计类查询就可能会出现一定的误差，需要在业务层面有所妥协。

这里介绍两个冷热分离的实践方案，供大家参考。

络行为数据分析系统

业务背景是，我们有很多UTM产品部署在用户的 络边界，对进出的 络数据进行扫描，扫描结果会上传到服务端进行处理、存储，从而提供统计分析查询功能，用户通过产品管理界面可以查看最近6个月的 络行为分析数据、定制日/周/月 表。

在该系统中，我们需要为所有用户保留6个月的数据，而根据我们的统计分析，90%以上的请求访问的是最近1个月的数据，因此采用热数据系统保留35天数据，其他的迁移到冷数据系统中存储。为了配合数据挖掘相关功能，目前冷数据保留2年。该系统的数据是只读的，且对外主要提供统计类查询，因此热数据采用Elasticsearch来存储，利用其聚合分析能力提供高性能查询。冷数据以Parquet的格式保存在AWS S3上，通过AWS Athena实现查询。AWS Athena是一款基于Presto的托管数据查询系统，根据查询时所扫描的数据量来收费，不查询不收费，采用该系统可以充分利用云服务的优势，避免自己维护一套冷数据查询系统。

数据实时上传到服务端后，会进入数据流中，通过Spark Streaming程序处理后写入到Elasticsearch，提供近实时数据查询。与此同时，实时数据也会备份到AWS S3。每天夜里，会启动一个Spark程序，加载前一天的备份数据进行处理并写入AWS S3，作为冷数据存储。该系统中，Elasticsearch中的Index按天分割，每天冷数据生成后会将冷热分割线往前推移，并删除热数据中对应的Index。

冷热分离同构系统

正如前文所述，冷热分离异构系统会带来整体的复杂性，主要表现在：需要维护两套系统，在业务逻辑中需要显式知道从哪里查询数据，甚至查询语法都不一样。很多开源框架在看到这一痛点后，开始在自己的体系下引入冷热分离的特性，试图以透明、统一的方式来应对冷热分离的需求。这里以Elasticsearch为例，来探讨下业界在冷热分离同构系统的诸多方案。

从Elasticsearch 5.0开始，便支持在一个集群中存放冷热数据，其核心思路是：在集群中放入不同配置的机器，将其打上不同的属性，比如下图中的Node 1/2/3便是高配置机器，用于存放热数据，属性为Hot，Node 4/5是低配置机器，用于存放冷数据，属性为Cold；当创建一个新的Index时，指定其数据分配到Hot属性的机器上；一段时间后，再将其配置修改为分配到Cold属性机器上，Elasticsearch便会自动完成数据迁移。

Elasticsearch 6.6之后，X-Pack中引入了Index Lifecycle Management机制，进一步简化了上述操作，我们不再需要自己定期去发送API做数据迁移了，只需要在Policy中设定Hot、Cold的生命周期即可，Elasticsearch会自动完成一切。

结束语

Bruce
2020/06/14 下午