clickhouse是一款非常优秀的OLAP数据库系统，2016年刚开源的时候就因为卓越的性能表现得到大家的关注，而近两年国内互联网公司的大规模应用和推广，使得它在业内声名鹊起，更受到了大家一致的认可。从网络上公开分享的资料和客户使用的案例总结来看，clickhouse主要是应用在实时数仓和离线加速两个场景，其中有些实时业务为了追求极致的性能会上全ssd的配置，考虑到实时数据集的有限规模，这种成本尚能够接受，但是对于离线加速的业务，数据集普遍会很大，这个时候上全ssd配置的成本就会显得昂贵了，有没有办法既能满足较高的性能又能把成本控制的尽量低？我们的想法是弹性伸缩，把数据存储到低廉的对象存储上面，然后通过动态增加计算资源的方式满足高频时段的高性能需求，通过回收计算资源的方式缩减低频时段的成本，所以我们把目标放在了存算分离这个特性上。

一.存算分离现状

clickhouse是存算一体的数据库系统，数据是直接落在本地磁盘上（包括云硬盘），关注社区动态的读者已经知道最新的版本可以支持数据持久化到对象存储（aws s3）和HDFS上了，当前这一章节是我们对clickhouse做了简单的适配性改造，把对象存储从s3扩展到了obs，然后展示把clickhouse的数据存储到obs上的过程：

1.配置s3磁盘

2.创建表并灌入数据

3.本地盘数据文件

4.对象存储obs上数据文件

从上面的图片可以发现，本地磁盘上的数据文件内容记录了obs上的对象名(uuid)和对象大小，它反映的是一种clickhouse本地数据文件和obs上对象之间的“映射关系”，注意这个“映射关系”是持久化在本地的，意味着需要冗余以满足可靠性；而obs上的数据文件名全是uuid。

然后进一步，我们看到社区也在努力把clickhouse往存算分离的方向推进：

v21.3版本引入的Add the ability to backup/restore metadata files for DiskS3，允许把本地数据文件到obs对象的“映射关系”、本地数据目录结构的元数据属性等等，放到obs对象的属性里（object的metadata），这样解耦了数据“映射关系”和数据目录在本地的限制，也解除了维持本地“映射关系”文件可靠性而至少双副本的成本问题；
v21.4版本引入的S3 zero copy replication，使得多个副本间可以共享一份远端数据，显著的降低了存算一体引擎多副本的存储开销；等等。

但是事实上，通过验证测试可以发现当前阶段存算分离距离可以上生产还有很长路要走，比如：${path}/metadata目录下的信息（表定义sql文件、atomic库下表示唯一性的UUID和数据目录UUID的对应关系等）怎么持久化到对象存储上、弹性扩容计算资源时候数据如何快速添加到新的计算节点上（缩容时候数据从计算节点移除）、修改本地磁盘文件和修改远端对象如何保障一致性、节点宕机如何快速恢复等等棘手的问题。

二.我们的实践

在云原生的时代，存算分离是趋势也是我们的工作方向，在这一章节我们继续把obs当作拉远了的磁盘来使用，接下来的讨论将围绕华为公有云对象存储obs来展开。

1.引入obs文件语义

首先需要重点介绍下华为云对象存储obs和其他竞品的最大差异化特性：obs的并行文件桶支持文件语义，支持文件和文件夹的rename操作（背后是轻量级的元数据修改）。这点对于我们在接下来的系统设计和弹性伸缩实现上很有价值，所以我们把obs的c驱动集成进了clickhouse，然后修改了clickhouse的处理逻辑，这样数据在obs上和本地磁盘上长的一模一样了（原来obs上是扁平、无序的uuid文件名集合）：

Local Disk：

OBS：

有了完整的文件语义数据目录结构后，再逐一对merge、detach、attach、mutate以及回收part等操作做了适配修改，保持本地磁盘文件和obs对象间的一致性，这是继续下面两个场景化应用工作的基础，现在这部分已经完成。

2.离线场景

From bottom to top，我们再来看系统结构，离线加速场景中因为数据已经全部在对象存储obs上，数据不再需要备份冗余，所以可以去除对zookeeper的依赖，每个shard一个replica，充分释放每个节点上每个CPU核的计算能力：

然后是扩缩容节点时候的数据均衡功能，通过obs的rename操作完成对part级别的低成本移动（耗时将在毫秒级，这是个优势项），如果发生节点宕机，新节点需要从对象存储侧恢复出本地数据文件目录后再加载。

3.融合场景

ok，在上面离线场景的基础上我们继续融入实时场景（下图中的“实时集群”部分），不同业务的clickhouse集群，可以通过冷热分离分层存储的方式（这一功能相对比较成熟，业内普遍采用它来降低实时数仓的存储成本），把冷数据从实时集群里淘汰出来，再通过obs rename操作挂载到“离线集群”中，这样我们可以覆盖数据从实时到离线的完整的生命周期（有些从hive到clickhouse的ETL过程可以被省略了）：

三.未来的展望

前面的实践是我们在存算分离方向的第一次尝试，无论是离线场景还是实时融合场景，都是以obs的文件语义为基础的，当前还在不断的改进优化中，另外，从宏观的角度来看，仍旧是把obs作为拉远了的磁盘来使用，不过感谢obs的高吞吐，相同计算资源的前提下ssd和obs跑Star Schema Benchmark的性能延迟在5x左右，但是存储成本得到了显著的10x降低，有可观的经济价值。

未来，我们会在前面工作的基础上，继续去除obs作为拉远磁盘的属性，把单个表的数据统一在一个数据目录下，收编clickhouse的元数据，把它做成无状态的计算节点，达到sql on hadoop的效果，类似impala那样的MPP数据库。