前提概要
十年前，我们曾经将存储设备实时数据的数据库从 MongoDB 迁移到 HBase，当时还专门写了一篇文章记录了前后的始末：最后，我们把设备实时数据存放到了 HBase 里。
在十年内的时光里，HBase 陪伴我们走过了技术的快速增长时代，见证了数据量从几百万条到几十亿条的增长过程。期间，我们还不断总结过经验，在我们的使用基础上缝缝补补，巩固 HBase 的使用，参见曾经总结的一些文章:
然而，随着时间的推移，十年后的今天，我们终于还是要跟 HBase 说再见了，它还是到了要退休的年纪了。
HBase 很好很强大，但是……
HBase 很好很强大，非常好，在我们之前精心设计的 row key 下，HBase 的性能非常好，查询一台设备的历史数据往往能在 10ms 之内出结果，对于聚合数据，在我们的 down sampling 方案下，查询半年的数据也能在 50ms 以内出结果。陪伴我们的业务系统高效稳定地运行了十年。
然而，也到了不得不说再见的时候了。
增加 / 修改查询太复杂了
HBase 只提供了一套 Java API 的方式查询，只提供了有限的几种查询算法。每个查询都得独立编写一套 Java 代码实现查询逻辑。
每次新增或修改查询简直是一种煎熬，可能过一段时间就压根看不懂之前是怎么查数据的，光 Scan 中的 startRow 和 stopRow 就能让人头疼半天，得仔细回忆 row key 的设计，小心翼翼的反复核对 startRow 和 stopRow 的值，才能保证查询的正确性。
写过 HBase 查询的同学一定知道我在说什么。
原本的设计不够用了
随着业务的逐步发展，原本单设备历史数据查询 + down sampling 的聚合查询方案已经不够用了，我们已经开始有了更复杂的查询需求，之前总是在外部进行数据处理，无形中提高了上层应用的复杂度。
比如我们有了联合多台设备分析的需求，那么势必需要将多台设备的实时数据全部拉出来，然后进行离线计算得到结果。HBase 的查询方式已经无法满足这种需求了，因为数据量非常大，将这些数据全部取出离线计算还需要消耗大量的资源。最重要的是，以前 down sampling 的方式聚合数据无法直接参与这种复杂的计算，它的结果是不正确的（相当于先对每个变量聚合取平均值之后再参与公式计算，很明显结果是不对的）。
HBase 更新不给力，商业化公司支持度也越来越少
...本文是付费文章
以上是此文章的预览内容