舆情分析系统的特点是：
- 数据量很大，一个月可能就有上亿条数据，有来自爬虫的，也有可能是从其他渠道采购过来的；
- 数据有时效性，时间比较近的数据价值比较大；
- 数据查询条件很复杂。
1. 原有架构
我们之前给客户开发了一个舆情分析系统，大致架构如图：
（实际系统跟这个图是有出入的，不过总体意思是这样。图是使用Excalidraw画的）
系统对数据划分了三个层次：
- 最近三个月的是价值最大的，经常需要查询，所以存ES；
- 最近一年的数据也是要用的，只是频类低很多，保存在了MySQL；
- 一年以上的历史数据很少用到，就直接保存到OSS上。
这三个层次也对应不同的成本，通常ES成本最高，MySQL其次，OSS成本最低。这田忌赛马般的安排，主要是为了降低成本。
2. 原有架构的问题
首先最重要的问题是，最近一年的数据查询很慢很慢，只能以任务的形式提交，凌晨的时候安排执行，而且非常耗时耗资源。
原有的设计最近一年的数据都是保存在一个单表上，这会使得开发简单一点，几个亿的文章和评论数据保存在这个单表里，准确说应该是两个表，文章一个表，评论一个表。
那我们对这个表进行分表是否可行呢，例如按月份分表？
不完全有效，分表有助于减少单表的数据量，但是这会使得开发变复杂，而且最重要的问题没有解决，就是文本条件的复杂查询，这个根本就是MySQL的弱项。现有的做法就是将可能的数据都查出来，然后一条一条的在代码中判断过滤，可想而知这个过程是多么的漫长。
3. ElasticSearch的冷热数据分离
ES本身是支持冷热节点的，所谓冷热节点就是存储成本不同的节点，例如热节点直接使用SSD，冷节点则使用普通的HDD，通常情况下，冷数据都会比热数据多很多，这就能大大的节省成本。而且因为冷数据查询性能要求没那么高，还能通过降低节点的CPU和内存来进一步降低冷数据节点的成本，甚至把冷数据的副本数设置为0。在ES中，可以单独的为每一个索引设置冷热属性。
有了这个就很简单的，就是使用冷节点来替换MySQL保存最近一年的数据，如图：
4. 数据怎么从热数据迁移到冷数据
在我们的场景中，冷热数据是按时间区分的，最初的想法就是热数据一个索引，冷数据一个索引，这样就能利用冷热节点的成本优势了。
不过这还有一个问题就是，热数据需要定时任务迁移到冷数据的索引上。这好像也很正常，跟原来从ES迁移到MySQL类似，但是有没有更加简单的方式呢？
这时候就该用到ES的另一个特性了：可以同时查多个索引。
这个特性允许我们进行类似MySQL上的分表，而且还没有MySQL上的弊端（在MySQL中分表，那得对程序逻辑懂大手术，当然现在也有一些中间件可以减轻一些）。结合ES可以对每一个索引单独设置冷热属性，我们的问题就有了解决方案。那就是：
数据在ES中按月份进行划分索引。
从热数据迁移到冷数据那也非常简单，只需要将节点属性改为冷节点就好了。相对于热数据建一个索引，冷数据建一个索引，这能使系统大为简单。
不过这个方案也并不完美，因为热数据本来只需要保存3个月，现在要就需要3到4个月，容量规划就得按4个月来，相当于热节点的成本增加了1/3。
5. 其他的方案
冷热数据分离其实不止使ES能实现，使用MySQL也能实现，但是和ES不同，MySQL要实现冷热数据分离，就得部署两个MySQL集群（一个部署在SSD上，一个部署在HDD上），而ES则是原生就支持的。这个在开发上的差异是很大的，架构也会复杂很多。
还有一个选择，就是使用ClickHouse或者DorisDB之类的MPP数据库（也是列式数据库），分析性能自然比ES强，存储成本也低很多（据网上有人测试，相同的数据，在ES中600TB，而在CH中是100TB，600TB的ES集群在阿里云上存储成本一年可能就得600万，打个六折也得360万，再算上CPU和内存。。。），不过CliHouse部署维护复杂，而DorisDB又不太成熟，暂时还不太上手。
6. 小结
对于大数据系统，对数据进行合理的分层，区分冷热数据，是降低成本和提升效率的重要手段，差别只是以什么方案来实现。
在我们的场景下，使用ES的冷热数据是适合的，但是如果数据真的增加到几百个TB那种，就不适合使用ES了（存储成本一年就得几百万），必须要考虑列式数据库。
