郑天祺：快手对ClickHouse开源社区最新贡献的功能

导 读

本文主要介绍快手对ClickHouse开源社区最新贡献的功能——Projection。

本文源自郑天祺博士在『快手大数据｜数据构架技术交流会』上的讲演，相关视频回放可用快手APP搜索“快手大数据”观看。

全文分为四个部份：

· ClickHouse背景介绍

· Projection简介与用例

· Projection原理与实现

· 特性对比与生产应用疗效

全文共6355字，预计阅读时长20分钟。

一、ClickHouse背景介绍

01ClickHouse的起源

ClickHouse诞生于日本版的百度统计，旨在提高网页点击日志剖析的性能，ClickHouse即ClickStream和WareHouse的合称。

ClickHouse在2008年的时侯开发下来，目的是为了替换她们原有的MySQL MyISAM引擎，并且实际应用疗效挺好，于是在2016年的时侯进行了开源，性能远超同期的开源竞品。这时国外多个互联网企业先后引入ClickHouse用作OLAP引擎。

开源社区也意识到这一问题，于是将Roadmap渐渐转向统一的、通用的分析型数据库，作为下一步的计划去做研制。

02ClickHouse主要特点

ClickHouse的主要特点对用户侧来说分为三部份：

1.高效的数据读写能力，底层储存是类LSM树的结构，列式储存，有一些比较好的压缩和编码策略。

2.高效的数据处理性能，包括向量化优化、列式组织以及底层的指令优化如CPU指令集优化，代码的质量很高，所以好多做数据剖析的系统会借用ClickHouse作为向量化的库来做数据估算提高。

3.松散的P2P分布式构架，灵活的估算扩充能力，可以很方便的去做大规模的扩充（上千台甚至上万台的规模）。

ClickHouse的主要特点对研制人员来说也是分为三部份：

1.追求高效的实时写入和交互式查询

2.追求系统设计含量，ClickHouse所有操作都是SQL化的，SQL中间的估算结果和状态也可以用SQL进行抒发和储存，所有储存的中间过程都可以用Block来抒发，并且可以序列化和反序列化，可以在任何地方传递。

3.“白盒”计算模式，ClickHouse是一个十分容易做嵌入和扩充的系统，非常适宜研制人员进行借助；“手动挡”应用模式，ClickHouse对于菜鸟来说用上去还是比较费力的，针对这个问题，快手做了一系列的服务包装和构架上的设计。

03ClickHouse在快手OLAP的服务

ClickHouse在快手内部是作为OLAP引擎，提供多集群构架，对于不同业务有不同的集群保障，上层是查询代理层，进行统一的查询管控和接入路由以及统一的监控服务，这样可以把ClickHouse“手动挡”应用模式逐渐弄成一个可用的服务，提供给用户。

同时最底层的数据写入，由于ClickHouse的数据写入须要一些相关的知识，所以把ETL服务抽取下来，用户只要告诉我们，你从那个实时流进来，或者从那个离线的数据源过来，我们就可以提供整套的ETL服务进行包装。

提供的服务包括：支撑存留估算、AB实验、音视频剖析、风控预警等都在ClickHouse上有所应用。整体的规模大约是每晚几千万查询接入，累计百PB储存数据量，上千台ClickHouse节点。

04 开源竞品对比

目前面向 OLAP 领域的主流开源系统有 Kylin，Druid，Doris 等等。

相比于那些竞品，ClickHouse 的优势在于：

1.高效的数据读写性能，使用类 LSM 树结构进行列式储存与压缩。

2. 高效的数据处理性能，广泛使用向量化估算并对关键代码路径进行底层指令优化。

3. 具有极其丰富的剖析算子、高阶函数与嵌套结构等等，能适配多样化的剖析场景。

另一方面，ClickHouse 缺点也是有目共睹。

首先，其欠缺有效的服务管控能力，整体系统于用户是一个 “白盒”，需要较强的专家知识驱动。这种 “手动档” 应用模式几乎难以在生产环境中落地使用。

为此，我们为 ClickHouse 增加了一套 OLAP 服务构架，显著改善了其管控能力。

另一方面，ClickHouse 缺乏事务能力，然而事务常常伴随性能开支，在互联网剖析场景中非高优。

剩下的物化储存特点是 OLAP 分析的一个强需求。ClickHouse 缺乏生产可用的物化视图功能，亟需解决。ClickHouse物化储存有以下三个痛点问题：

1.仅支持一种列排序方法，虽然社区提供了一些解决方法如Z-Curve、Skip-index，但是都存在一些问题。

2.OLAP预聚合模型须要自动操作，需要指定指标、维度，然后查询按照指定好的进行改写，这样就能命中物化的结果。同时明细数据也就不存在了，需要存多个维度表，才能达到预聚合模型的要求。

3.ClickHouse物化视图无一致性保证，在明细表里做聚合查询和在物化表里做聚合查询下来的结果可能不一样。

05 快手的解决方案

快手提供了一个解决方案——Projections解决了上面提及的三个问题，其方式如下：

1.Projection根据不同列进行数据重排

2.Projection使用聚合查询在源表上直接定义出预聚合模型

3.Projection查询剖析能手动选择最优Projection进行查询优化，无需改写查询

4.Projection在任一时刻针对任一数据变换操作均提供一致性保证

这个功能目前早已合并到master，预计下个月会release，是ClickHouse开源5年来最高赞的PR，在快手内部早已使用了3个多月，也欢迎你们尝试使用。

二、Projection简介与用例

01Projection概念

Projection这个概念并不是我们原创的，而是来自Mike Stonebraker，他是数据库系统图灵奖获得者，列存数据库Vertica之父。

Projection是一组列的集合，用建表句子可以定义，这个概念在C-Store提出后，他们创立了一个公司叫Vertica，做列存数据库，Projection在Vertica数据库中落地发展，不仅仅是根据不同的次序做储存，同时还支持部份的聚合函数，比如sum、min、max以及一些下卷的优化，可以通过Projection的机制来完成。

我们利用了Projection的思想来进行了一些扩充，使其可以在ClickHouse上用任意的聚合函数、任意的自由组合参与数据下卷估算，意思就是只要你能写下来的SQL句子和分析型聚合函数，都可以进行预估算，并且保证上面提及的优势；第二点是我们支持一张表部份的数据挂载Projection，部分数据不挂载，这样的优势在于我们可以不遗失ClickHouse本身的特点如：实时写入的能力，同时查询也就能获益。

02Projection用例介绍

这里我们使用视频剖析日志表来进行演示，这个表每秒大约2万条记录数，存在两列，user_id和device_id，基数大约两亿的规模。同时还有一个domain的低基数列，表示域名，然后视频的属性包括bytes、duration两个指标维度。它的排序规则是根据user_id、device_id的次序来进行排序。

如果根据user_id来查，ClickHouse会很高效，因为才能快速的命中user_id=100的数据，在有序的结构中，通过二分查找或则其他的一些机制，快速的定位到数据然后，把数据取下来进行剖析，实际上扫描的数据量是极少的，远比原先的十几亿行数据少。

但是假如我们是用device_id进行查询的话，由于优先的第一次序不是根据device_id来排的，排序索引基本丧失了意义，最终的扫描就是全表扫描，对于这样的一个查询，在ClickHouse 中，大概就要消耗8秒的时间，基本上是不可并发的，只能等待这个点查询返回。

我们尝试为这个表建一个Projection，建Projection的操作很简单，就是对这个表进行一个alter的操作。Projection上面定义了你须要查询的这些列，然后根据device_id进行储存，选出那些列以后，由于它是lazy的模式，可以自动进行物化。为了演示疗效，我们自动对这个Projection：p_norm进行MATERIALIZE操作。

操作完成以后，重新执行前面的查询，查询不需要任何的更改，可以看出性能提高了153倍，就是说索引生效了，生效的就是刚才的Projection。

03Projection实际应用案例

在实际应用案例中，会有这样的场景：一个用户，在行为表中，可能会有多种口径的查询方法，比如user_id ，phone_num，device_id，不同的人会通过不同的方法去查，这样在取数的时侯，通过一维的排序肯定是不够的，如果通过稀疏索引或则二级索引也会带来其他的问题。

如果用Projection的话，可以按照不同的口径，选出须要的列，进行异构多序储存，这样就可以针对不同用户的取数口径，都还能达到提速的疗效。

再来看一个Projection的用例，比如根据域名聚合（大概100个基数），来做当天视频流特性剖析，这个显然在ClickHouse上面性能早已很不错了，17亿的数据，ClickHouse单机大约11秒就跑结束了，已经可以彰显它的高效性，但是依然不足以去渲染看板。看板是希望还能即席剖析，点开才能看见。

我们如今为这个查询定义一个预聚合的Projection，只须要表明须要查询的加速是什么样的，比如就是group by以hour为细度，以domain为维度，然后查看sum和avg的结果，进行MATERIALIZE的操作。

重新执行昨天的查询句子，可以发觉提高十分显著，相当于把上面所有的IO操作都省了，只要读最后预聚合的中间结果，同时估算成本也省了，不需要额外预聚合的CPU开支。

当我们要做一个聚合统计剖析提速，有一张底表，会有一系列的维度和指标，正常情况下，需要提速的过程是一个ETL流程，我们须要为每一个不同的Topic打算一些特殊的表如：实验表、标签表等，然后进行剖析建模。

而有了Projection以后，可以把这种步骤都省略了，针对底表，我们可以按照end to end去看报表，看看数仓须要什么查询，我们做一些剖析，把那些查询汇总、归一，建几个Projection，这样所有的报表看板就及时生效了，省去了之前的ETL流程和数仓建模的过程，使看板智能提速；并且因为我们只使用了底表，原始明细数据都在，保障了数据一致性。

Projection优化本质是用空间换时间，我们可以看一下Projection的实际开支。对于Normal Projection，存储开支是比较大的，达到40%左右。

而对于Aggregate Projection，开销是很小的，只要设计好预聚合的模式，那么开支基本可以忽视不计。

04Projection用例小结

1. 我们如今在ClickHouse实现的Projection包含两大类：normal和aggregate

2. 支持使用查询直接定义Projection，不需要人为的为每位指标和维度做设计

3. 对历史数据建立Projection，因为是lazy模式，所以须要进行MATERIALIZE操作

4. 查询无需任何改动即可使用Projection优化

5. 可对单表降低多个Projection，这时候我们有一些优化的模式，可以选择最优的Projection进行优化执行

三、Projection原理与实现

01Projection的主要预制构件

Projection的主要预制构件包含三个部份，分别是：Projection定义、Projection储存、Projection查询剖析。

Projection定义：可以通过用户查询直接定义，也可以手动推测Projection类型和相关属性。

Projection储存：Projection储存主要就是解决一致性的问题，怎么样在ClickHouse物化视图不一致的情况下，通过储存的设计，把物化下来的结果和原始的结果进行强一致的绑定。

Projection查询剖析：回溯分析查询计划，使用标准表达式名称进行匹配验证，使得可以命中Projection，得出正确的查询结果，并按照选下来的Projection重建执行计划，完备的实现一致性的查询疗效。

02 Projection定义

Projection的定义似乎是和物化视图是类似的，物化视图的定义基本上就是CREATE TABLE AS SELECT... Projection通过ORDER BY这些模式比较直观，可以根据次序调整结构；GROUP BY就是用这个方法去做聚合，会把次序拆解，选出上面的预聚合的部份，这部份涉及到一点：需要把上面所有的指标找到中间的那种状态是哪些，这种模式可以用”手动挡”方式实现，Projection的定义可以帮你手动实现，这是比较好的用户体感。

03 Projection储存

Projection本身在ClickHouse系统下是一种伴生的Part，熟悉ClickHouse的朋友可能晓得，ClickHouse的储存是一个一个的文件夹，每一个文件夹称作一个Part，Projection就是在Part下的子Part，跟着这个Part一起走，所以它们的分区信息是一致的，能够同时和原始查询的分区分株的动作一致，同时还能保证所有和Part相关的操作的一致性，并且进行递归处理，每层对这个Part进行MERGE或则MUTATION的时侯，Projection也会跟随一起MERGE或则MUTATION。

04 Projection查询剖析

Projection查询剖析这块倘若直接通过代码来讲比较复杂，下面还是先通过一个用例介绍。

i. 查询剖析原理

还是里面的video_log表，我们刚刚也创建了Projection，那如何晓得下边的查询才能命中Aggregate Projection呢？事实上，它肯定是能命中原表的，否则查询就报错了。我们如今晓得，它是才能命中p_agg这个Projection的，在这个过程中，首先把这个查询计划展开一下。

首先查询须要从储存里把列须要的数据读下来，然后进行有效的过滤，最后打算好要聚合的参数，比如bytes、duration，最后完成聚合的动作。我们须要看每一步Projection的数据能不能提供她们所须要的输入，这样的话能够晓得这个Projection是否命中。

接下来详尽的瞧瞧：

Aggregation这一层涉及到参数打算的过程，就是hour、domain、sum(bytes)、avg(duration)这几个环节。需要提供的数据是domain、bytes、duration。

而这种数据，我们可以直接从Projection中获取到，因为在查询定义的过程中，就早已晓得这个查询会分解出什么样的数据输出的需求，于是就可以通过这样的方法去命中Projection所形成的输入。

这个模式还可以继续推论，再瞧瞧上一个环节：

这里有一个WHERE执行树，WHERE执行树本质上是一个DAG表达式，它抒发的意思是：现在有一组列，这一组列怎么样通过不断的变换产生新的列，最后形成一个子句equals，判断这个子句是真还是假。

Projection也是可以满足这个子句的。从后向前推，它支持toStartOfHour，然后把最里边的输入截断，实际上，Projection上面没有datetime这一列，当然，它也不需要这一列，因为前面的这些列就可以满足整个DAG的估算，因此，在WHERE表达式这一级上，Projection也是可以满足的。

同理，不管是Prewhere还是Row Policy等仍然到起点，Projection都可以满足以后，这个Projection就是一个有效的命中。

找到有效命中的Projection以后，要在所有合法的Projection候选中，找到其中最优的形式。

因为Projection涉及到好多方面：一个是类型多，有Normal Projection、Aggregate Projection，在同一个查询里都有可能命中；同时Projection是个lazy的概念，可能不同的Projection物化程度并不一样，怎么样才能有效地发觉哪一个Projection是最好的？这时候我们可以对每一个候选进行索引剖析，得出其预期数据扫描量，并缓存结果，这样才能有效的判定这个Projection是好还是不好。

这样只须要选择预期扫描数据最少的Projection，不用分辨Projection类型是normal还是aggregate，只要读取的数据量少，计算量肯定也少，那么一定是最优的。预期的扫描量包含了Projection的物化程度。

然后再把整体的索引剖析的结果进行复用，避免重复的进行索引剖析。当最终选择某个Projection以后，将借助前述的回溯剖析过程倒推Projection所须要的执行管线，再把Projection的执行逻辑和normal的执行逻辑进行合并，得到一个最终的管线，使得查询在任何时刻、Projection的任何物化程度下，执行结果都是一致的，这样就实现了前述的一致性的问题。

ii. 一致性保障

一致性保障从以下三个方面讨论：

INSERT：当数据块写入时，其作为数据源向所有定义的Projections提供输入，形成Projection Parts，最终和原始数据合并建立出带有Projection的Part目录。

SELECT：当查询命中某一Projection时，形成的查询计划将确保所有数据形成符合预期的结果。针对Projection Parts的数据，将在运行时动态重构并在不引入额外估算开支的前提下与其余数据合并。

MUTATION：Projection在定义时记录了其关联依赖的原始列信息。当对应的列发生变化时，所有相关的Projection将被重新物化，形成新的Part将包含一致的Projection Part进行原子递交

四、特性对比与生产应用疗效

01 Projection优缺点

Projection优点：

1. SELECT，INSERT，UPDATE，DELETE等操作的一致性保障

2. 查询无需任何改动能够命中Projection，并手动匹配最优Projection进行估算

3. 可直接通过待优化的查询进行定义，用户要优化一个查询，可以把查询丢给Projection，做一些中间阶段的预聚合，并且预聚合的过程才能手动泛化匹配其他查询

Projection缺点：

1. 现在的Projection是基于Part级别的，无法跨Part聚合，预聚合的细度还是有一些限制。

2. 无法脱离原始表储存，无法使用不同的生命周期与储存介质配置。

3. 不支持join，还是一个大宽表的模型，不过对于物化来说，用join的还是比较少。

02 特性对比汇总

首先看一下目前Projection对ClickHouse本身的物化提高对比图，整体上来看，Projection基本全方面都是优秀的，如：数据一致性、查询剖析能力、数据索引能力、明细数据储存、最优秀的一点是可以保证无阻塞写入，也就是实时写入性，能够做一些逻辑上的Projection的优化，也就是在写入过程中不需要Projection，但是在查询的过程中一部分Projection的优化就能命中才能起到优化的疗效。这是一个渐进的过程。

03 生产实测结果

首先，这个Projection包括物化的疗效基本都是跟数据集和查询紧相关的。数据集大小：每天350亿条记录，按照10分钟为细度，取某一个维度列进行预聚合，聚合比大约是十万分之四。这个疗效分两部份：一个是聚合函数的使用量，比如说一个、两个或则三个的使用量，这时候提高的疗效基本上是按照聚合函数的使用多少来彰显的。比如最后这个用了三个聚合函数，可能提高的疗效就更显著，因为你的估算量降低的更多；

其次是并发层次，Projection基本上不需要哪些估算资源，所以在并发很高的情况下，并不会有太多提高，但是它降低了好多的估算资源开支，因此Projection做看板渲染是十分友好的，比如说多个人同时打开看板，执行好多个聚合查询，查询并发可以提的特别高，可以同时把看板渲染下来，原始表的话可以就一个看板，打开以后，别人就刷不下来了。

从另外一个角度看，主要就是储存成本。存储成本主要是看聚合指标使用的函数，因为我们现今的Projection支持任意函数，这时候就要考虑什么指标得规避，简单的指标例如上图中红色部份的，基本可以随意建，没有哪些储存开支，基本都是KB级的。

有一些中间的，比如做quantile估算，做log摘要，会有一些额外的储存，这时候聚合疗效可能就不太显著，查询的时侯可能IO上包括聚合的计算成本上节约的就不是这么厉害了。

最后这个就是精确的计数，基本没有聚合疗效，相当于把明细数据从列存转为行存，压成了一个字段，这种就不建议在生产中使用，可能得用一些别的手段如位图或则其它的方式。所以这个还是要按照数据的具体应用来做一些审视。

ClickHouse所有的查询信息都是白盒的，所有东西都提供规范化的查询剖析，每个查询带有一种去除所有的literal，就是字面量。去掉literal以后，我们可以做规范化的查询，可以每晚去看一下查询日志上面聚合函数分别有什么就能命中，然后我们得出值得建什么查询的物化，建下来以后，去找一些看板来看，基本上一个看板，比如12张图表，原来渲染时间要30秒，等半天才下来4张图表。加了Projection以后，1秒就下来了，体验感非常好。

统计Projection所有的开支，其实储存开支还是比较少的，刚才说的，聚合疗效足够的话，存储开支不多，大概20%。同时，写入还有MERGE并没有观测到可见的影响，同样还能保持百万级别的每秒写入数目。

04 Projection总结

一言总结，Projection是ClickHouse上面更好的物化视图，也就是生产可用的物化视图。

这就是我们把Projection从弱做到强，进一步提高ClickHouse在OLAP领域的应用硬度。这个强是有多方面的，还有一方面就是Projection的想像空间比较大。

Projection设计符合ClickHouse估算SQL化，存储Block化的设计理念：

1. 首先Projection是存在Part上面的，Projection除了能看到数据，还能见到数据的表针，我们可以通过Projection，直接存出来该Projection对应的数据的位置，这就是二级索引，所以Projection是可以做二级索引的。

第二个是位图索引，ClickHouse是有位图的聚合函数的，这个聚合函数也是可以直接被存出来的，所以Projection也是可以直接储存位图的，再加上ClickHouse本身的PREWHERE机制，可以做到用Projection物化出一堆东西，然后来做位图索引。

2. Projection本身就是表，表在ClickHouse里是支持编码的，也支持压缩和Part的各类格式变换，这个能力也是在Projection上建立的，我们可以精细的调优。比如调了一个次序，发现这个次序可能用另一个列编码更合适，那我们可以把这个也加到Projection上，就是在Projection上建立Projection

3. 提供Projection与原始表分离储存的能力，同时保证一致性，当然这上面还须要和社区多沟通，这个点还是比较有意思的。