Projection：快手对ClickHouse的重磅贡献

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

大家下午好，今天我给大家介绍一下快手对ClickHouse开源社区最新贡献的功能——Projection。首先自我介绍一下，我是去年加入快手的，也是中科院计算所系统结构博士，ClickHouse Community Member。ClickHouse从开源以来，大概半年后，我就是里面活跃的贡献者，目前已经贡献了300多个PR。今天我的分享分为四个部分：① ClickHouse背景介绍；② Projection简介与用例；③ Projection原理与实现；④ 特性对比与生产应用效果。

01

ClickHouse背景介绍

首先和大家分享下ClickHouse的背景：

1. ClickHouse的起源

ClickHouse诞生于俄罗斯版的百度统计，旨在提升网页点击日志分析的性能，ClickHouse即ClickStream和WareHouse的统称。在2008年的时候开发出来，目的是为了替换他们原有的MySQL  MyISAM引擎，并且实际应用效果很好，于是在2016年的时候进行了开源，性能远超同期的开源竞品。这时国内多个互联网企业先后引入ClickHouse用作OLAP引擎。开源社区也意识到这一问题，于是将Roadmap逐渐转向统一的、通用的分析型数据库，作为下一步的计划去做研发。

2. ClickHouse主要特性

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

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

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

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

ClickHouse的主要特性对研发人员来说也是分为三部分：

• 追求高效的实时写入和交互式查询。

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

• “白盒”计算模式，ClickHouse是一个非常容易做嵌入和扩展的系统，非常适合研发人员进行利用；“手动挡”应用模式，ClickHouse对于新手来说用起来还是比较费劲的，针对这个问题，快手做了一系列的服务包装和架构上的设计。

3. ClickHouse在快手OLAP的服务

ClickHouse在快手内部是作为OLAP引擎，提供多集群架构，对于不同业务有不同的集群保障，上层是查询代理层，进行统一的查询管控和接入路由以及统一的监控服务，这样可以把ClickHouse“手动挡”应用模式逐步变成一个可用的服务，提供给用户。同时最底层的数据写入，由于ClickHouse的数据写入需要一些相关的知识，所以把ETL服务抽取出来，用户只要告诉我们，你从哪个实时流进来，或者从哪个离线的数据源过来，我们就可以提供整套的ETL服务进行包装。

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

4. 开源竞品对比

目前面向 OLAP 领域的主流开源系统有 Kylin，Druid，Doris 等等，相比于这些竞品，ClickHouse 的优势在于：1. 高效的数据读写性能，使用类 LSM 树结构进行列式存储与压缩；2. 高效的数据处理性能，广泛使用向量化计算并对关键代码路径进行底层指令优化；3. 具有非常丰富的分析算子、高阶函数与嵌套结构等等，能适配多元化的分析场景。另一方面，ClickHouse 缺点也是有目共睹。首先其缺乏有效的服务管控能力，整体系统于用户是一个 “白盒”，需要较强的专家知识驱动。这种 “手动档” 应用模式几乎无法在生产环境中落地使用。为此，我们为 ClickHouse 增加了一套 OLAP 服务架构，显著改善了其管控能力。另一方面，ClickHouse 缺乏事务能力，然而事务往往伴随性能开销，在互联网分析场景中非高优。

剩下的物化存储特性是 OLAP 分析的一个强需求。ClickHouse 缺乏生产可用的物化视图功能，亟需解决。

ClickHouse物化存储有以下几个痛点问题：

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

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

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

5. 快手的解决方案

快手提供了一个解决方案——Projections解决了前面提到的三个问题，其方法如下：

• Projection按照不同列进行数据重排

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

• Projection查询分析能自动选择最优Projection进行查询优化，无需改写查询

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

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

02

Projection简介与用例

接下来简单介绍一下Projection，以一个用例来介绍，这样便于大家理解。

1. Projection概念

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

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

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

2. Projection用例介绍

这里我们使用视频分析日志表来进行演示，这个表每秒大概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。

3. Projection实际应用案例

在实际应用案例中，会有这样的场景：一个用户，在行为表中，可能会有多种口径的查询方式，比如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，开销是很小的，只要设计好预聚合的模式，那么开销基本可以忽略不计。

4. Projection用例小结

总结一下：

• 我们现在在ClickHouse实现的Projection包含两大类：normal和aggregate

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

• 对历史数据构建Projection，因为是lazy模式，所以需要进行MATERIALIZE操作

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

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

03

Projection原理与实现

1. Projection的主要构件

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

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

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

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

2. Projectio定义

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

3. Projection存储

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

4. Projection查询分析

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

① 查询分析原理

还是上面的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的任何物化程度下，执行结果都是一致的，这样就实现了前述的一致性的问题。

② 一致性保障

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

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

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

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

04

特性对比与生产应用效果

最后介绍一下Projection的特性对比和生产应用效果。

1. Projection优缺点

Projection优点：

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

• 查询无需任何改动就能命中Projection，并自动匹配最优Projection进行计算

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

Projection缺点：

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

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

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

2. 特性对比汇总

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

3. 生产实测结果

接下来说一下生产实测效果。首先，这个Projection包括物化的效果基本都是跟数据集和查询紧相关的。数据集大小：每天350亿条记录，按照10分钟为粒度，取某一个维度列进行预聚合，聚合比大概是十万分之四。这个效果分两部分：一个是聚合函数的使用量，比如说一个、两个或者三个的使用量，这时候提升的效果基本上是根据聚合函数的使用多少来体现的。比如最后这个用了三个聚合函数，可能提升的效果就更明显，因为你的计算量减少的更多；第二个是并发层次，Projection基本上不需要什么计算资源，所以在并发很高的情况下，并不会有太多提升，但是它减少了很多的计算资源开销，因此Projection做看板渲染是非常友好的，比如说多个人同时打开看板，执行很多个聚合查询，查询并发可以提的非常高，可以同时把看板渲染出来，原始表的话可以就一个看板，打开之后，别人就刷不出来了。

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

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

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

ClickHouse所有的查询信息都是白盒的，所有东西都提供规范化的查询分析，每个查询带有一种去掉所有的literal，就是字面量。去掉literal之后，我们可以做规范化的查询，可以每天去看一下查询日志里面聚合函数分别有哪些能够命中，然后我们得出值得建哪些查询的物化，建出来之后，去找一些看板来看，基本上一个看板，比如12张图表，原来渲染时间要30秒，等半天才出来4张图表。加了Projection之后，1秒就出来了，体验感非常好。统计Projection所有的开销，其实存储开销还是比较少的，刚才说的，聚合效果足够的话，存储开销不多，大概20%。同时，写入还有MERGE并没有观测到可见的影响，同样能够保持百万级别的每秒写入数量。

4. Projection总结

Projection总结起来就是ClickHouse里面更好的物化视图，也就是生产可用的物化视图。

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

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

• 首先Projection是存在Part里面的，Projection不仅能看到数据，还能看到数据的指针，我们可以通过Projection，直接存下来该Projection对应的数据的位置，这就是二级索引，所以Projection是可以做二级索引的。第二个是位图索引，ClickHouse是有位图的聚合函数的，这个聚合函数也是可以直接被存下来的，所以Projection也是可以直接存储位图的，再加上ClickHouse本身的PREWHERE机制，可以做到用Projection物化出一堆东西，然后来做位图索引。

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

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

在文末分享、点赞、在看，给个3连击呗~

社群推荐：

关于我们：

🧐分享、点赞、在看，给个3连击呗！👇