Clickhouse实时数仓建设

Clickhouse是一个开源的列式存储数据库，其主要场景用于在线分析处理查询（OLAP），能够使用SQL查询实时生成分析数据报告。今天，笔者就为大家介绍如何使用Clickhouse来构建实时数仓，来满足一些实时性要求较高的使用场景。

2.1 什么是OLAP场景

在介绍Clickhouse构建实时数仓之前，我们先来了解一下OLAP的使用场景，通常OLAP的使用场景包含如下特征：

• 绝大多数是读取请求；
• 数据以相当大的Batch进行更新；
• 已存储的数据不能随意修改；
• 对于读取，从数据存储中提取相当多的行，但是只提取列的一小部分；
• 大宽表，即每个表包含着大量的列；
• 查询相对较少（QPS很小）；
• 对于简单查询，允许有较低的延迟，比如50ms~100ms；
• 列中的数据相对较小，比如字符串长度很短；
• 处理单个查询时需要高吞吐量；
• 事务非必须；
• 对数据一致性要求低；
• 每一个查询有一个大表，除了它其他都是很小的；
• 查询结果明显小于源数据。

通过观察这些特征，我们可以看出，对于OLAP场景与其他业务场景（比如OLTP、KV等）有所不同，因此想要使用OLTP或者KV来高效的处理数据分析查询场景，并不是非常完美的解决方案。

2.2 Clickhouse更适合OLAP的原因

Clickhouse更适合OLAP场景，对于大多数查询而言，处理速度至少提高了100倍，下面我们可以通过图片来详细了解其中的原因：

2.2.1 行式

 2.2.2 列式

接下来，给大家分析一下这2张图发生了什么。

2.2.3 输入与输出

• 针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的 I/O 消耗；
• 由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了 I/O 的体积；
• 由于 I/O 的降低，这将帮助更多的数据被系统缓存。

例如，查询 “统计每个广告平台的记录数量” 需要读取 “广告平台ID” 这一列，它在未压缩的情况下需要 1 个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以 10 倍的压缩率被压缩。当采用快速压缩算法，它的解压速度至少在 10 亿字节（未压缩数据）每秒。换而言之，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。

2.2.4 CPU

由于执行一个查询需要处理大量的行，因此在整个向量上执行所有操作将比在每一行执行所有操作更加高效。同时，这将有助于实现一个几乎没有调用成本的查询引擎。如果你不这样来操作，使用任何一个机械硬盘，查询引擎都不可避免的停止CPU进行等待。所以，在数据按列存储并且按列执行是很有意义的。

这里有两种方法可以来实现这一点，它们分别是：

• 向量引擎：所有的操作都是为向量而不是为单个值编写的。这意味着多个操作之间不再需要频繁的调用，并且调用的成本基本可以忽略不计。操作代码包含一个优化的内部循环；
• 代码生成：生成一段代码，包含查询中的所有操作。

这是不应该在一个通用数据库中实现的，因为这在运行简单查询时是没有意义的。但是也有例外，比如，MemSQL使用代码生成来减少处理SQL查询的延迟（这里只是为了比较，分析型数据库通常需要优化的是吞吐而不是延迟）。

这里需要注意，为了提高CPU效率，查询语言必须是声明型的（SQL或者MDX），或者至少一个向量（J，K）。查询应该只包含隐式循环，允许进行优化。

2.3 Clickhouse构建实时数仓的场景

一般来说，使用Clickhouse构建实时数仓的场景，主要包含如下：

• 数据探索：通过即席查询做业务上的归因推测；
• 数据看板：展示所关注的核心指标；
• 数据实验：将新的算法模型，放在 A/B 实验平台上做假设验证，看模型是否符合预期；
• 实时监控：对业务指标进行实时监控，观察实时效果。

在上述场景中，使用者都非常看重实时性，希望查询响应速度快。

在引入Clickhouse之前，我们通常使用主流的Hadoop生态来构建数仓，但是，Hadoop生态构建的数仓会有些痛点：

• 时效性差：基本上是分钟级别，甚至是小时级别，导致分析过程偏长；
• 开发周期长：由于传统架构数仓理念的多层架构，使得更新一个指标的成本代价会很高。
• 架构复杂：在一套成熟运行很久的系统框架下，难以实现流批一体，间接导致模块无法复用，代码需要写多套，数据口径难以收敛，数据存储冗余。

经过对业界的主流技术进行调研对比，使用Clickhouse作为OLAP的主要核心引擎，其原因如下：

• 效率：真实数据的实验场景下，Clickhouse要比传统的Hadoop生态（比如Hive）要快很多；
• 开源：数据实验、算法特征等场景的个性化需求，能够对Clickhouse进行引擎层面的改动。

在使用原生Clickhouse时，在数据流量增大时会有很多问题：

• 稳定性：原生的Clickhouse存在设计缺陷，分布式下的Clickhouse集群对Zookeeper存在依赖，随着数据的增长（体量非常大的情况下）Zookeeper会成为Clickhouse瓶颈；
• 门槛较高：需要对Clickhouse有较深的经验积累，对于经验不足和经验丰富的两类人员，部署出来的Clickhouse集群的性能差别会很大。

2.4 ClickHouse生态建设

想要比较好的解决Clickhouse的易用性和稳定性，需要生态来支撑，整体的生态方案有以下几个重要部分，它们分别是：

• 数据网关：用来管理请求，智能分配；
• 数据分流：缓冲大流量数据，读写控制；
• 集群管理：整体集群的数据迁移、数据均衡、容灾切换等；
• 数据监控：查询耗时监控、慢查询分析、异常指标监控等。

基于Clickhouse生态建设，有以下几个典型的应用场景：

1. BI分析与看板

由于数据探索是随机的，很难通过预构建的方式来解决，如果使用Hadoop的生态只能实现小时到分钟的级别。在引入Clickhouse后，在单表千亿级别的数据量下，大多数查询都是很快的，对于数据分析师来说是非常友好的。

2. 实验平台

使用Hadoop生态做 A/B 实验的时候，前一天要把所有的实验数据统计出来，做好预聚合。第二天才能查询实验效果。使用Clickhouse来做实时JOIN，效果非常的好。

 3. 实时特征计算

虽然实时特征计算不是Clickhouse的强项，但是通过相关优化，还是可以实现。

Clickhouse OLAP的生态相对于Hadoop生态，性能提升是比较明显的，通过流批一体提供更加稳定可靠的服务，使得业务决策更加迅速，实验结论更加准确。

5.结束语