质量实时数仓从 Elasticsearch 到 ClickHouse

felix9ia ... 2022-9-20 大约 7 分钟

# 质量实时数仓从 Elasticsearch 到 ClickHouse

Elasticsearch 其实不太满足我们 OLAP 的业务场景了，所以想趁着重构的机会，将存储引擎替换掉，目前备选有 Druid 和 ClickHouse，但更倾向于 ClickHouse，目前正在实际使用对比评估中。

ClickHouse (opens new window) 更加符合我们实时查询和范围聚合两种高频使用场景，且能够满足后期的多维度分析场景，具备而更好的扩展性。以下是对存储引擎切换方案的梳理。

质量重构的理想目标是，在提供可以更加复杂的分析场景下，能更提前预警与提供决策。向一个更加智能的 OLAP 系统进行迭代。而存储的选择是这一切的开始与基石，需要谨慎选择。

针对我们目前系统的使用场景。

一旦我们选择调整到 ClickHouse，可以收获：

低延迟的实时大数据存储与查询

Elasticsearch 在性能上要求更高。
更快的聚合

这在 Elasticsearch 依赖更多的内存，查询条件有门槛比较困难且废人工。

而 ClickHouse 为列式存储并提供物化视图， SQL 查询更加容易上手
更复杂的多维度分析

Elasticsearch 基无能为力，或者需要大量冗余来实现。而列式存储的 ClickHouse 是天生的优势。

当然选择新服务一定会带来一定的代价：

从未来的收益和代价来看，ClickHouse 值得。以下是对此次存储选型方案的调研与梳理。

如果把重构分为以下三个阶段的话：

现阶段，使用 Spark 进行第 1 阶段 -- 数据分析，基本度过了阵痛期，后面就是完善细节。

但是对于存储和查询流程的实现还是有些许迟疑。

**如果我们路径依赖的继续选用 Elasticsearch 进行存储，会面临系统后续迭代的种种分析挑战，甚至会导致再一轮的重构。**具体分析如下：

我们的质量分析系统是一个：

联机分析处理 OLAP（On-Line Analytical Processing）, OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

~~而不是：~~

~~联机事务处理OLTP（on-line transaction processing），OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。~~

在我们系统是 OLAP 的大前提下，当前的质量只是做到了数据的呈现，并没有支持复杂的分析操作，更别提决策支持。

而目前我们的存储 - Elasticsearch 是不太符合 OLAP 系统的使用场景的。在 Druid 官网进行了对比 druid-vs-elasticsearch (opens new window) ，译文如下：

所以，既然我们是在做 OLAP 的事情，当然要选择 OLAP 的产品，而在 OLAP 领域的存储方案是相对成熟的。

先尝试分清 OLAP 的分类。

Multi-dimensional OLAP，多维OLAP

MOLAP的优点和缺点都来自于其数据预处理 ( pre-processing ) 环节。数据预处理，将原始数据按照指定的计算规则预先做聚合计算，这样避免了查询过程中出现大量的临时计算，提升了查询性能，同时也为很多复杂的计算提供了支持。

但是这样的预聚合处理，需要预先定义维度，会限制后期数据查询的灵活性；如果查询工作涉及新的指标，需要重新增加预处理流程，损失了灵活度，存储成本也很高；同时，这种方式不支持明细数据的查询。

Relational OLAP

Hybrid OLAP

而在 OLAP 数仓方案中，分为：

所以，我们对比了市面上的解决方案，想从中选择出适合我们的存储引擎，如下是我们梳理出的关注点。可以查看 Apache Druid vs. Apache Kylin vs. Apache Pinot vs. ClickHouse vs. InfluxDB (opens new window) 查看具体的对比。

以及我们整理出来的: