快手对ClickHouse开源社区最新贡献的功能——Projection
大家晚上好，今天我给你们介绍一下快手对ClickHouse开源社区最新贡献的功能——Projection。首先自我介绍一下，我是今年加入快手的，也是中科院计算所系统结构博士，ClickHouse Community Member。ClickHouse从开源以来，大概半年后，我就是上面活跃的贡献者，目前早已贡献了300多个PR。今天我的分享分为四个部份：① ClickHouse背景介绍；② Projection简介与用例；③ Projection原理与实现；④特性对比与生产应用疗效。01ClickHouse背景介绍
首先和你们分享下ClickHouse的背景：
1. ClickHouse的起源
ClickHouse诞生于日本版的百度统计，旨在提高网页点击日志剖析的性能，ClickHouse即ClickStream和WareHouse的合称。在2008年的时侯开发下来，目的是为了替换她们原有的MySQL MyISAM引擎，并且实际应用疗效挺好，于是在2016年的时侯进行了开源，性能远超同期的开源竞品。这时国外多个互联网企业先后引入ClickHouse用作OLAP引擎。开源社区也意识到这一问题，于是将Roadmap渐渐转向统一的、通用的分析型数据库，作为下一步的计划去做研制。
2. ClickHouse主要特点
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物化储存有以下几个痛点问题：
5. 快手的解决方案
快手提供了一个解决方案——Projections解决了上面提及的三个问题，其方式如下：
这个功能目前早已合并到master，预计下个月会release，是ClickHouse开源5年来最高赞的PR，在快手内部早已使用了3个多月，也欢迎你们尝试使用。
02Projection简介与用例
接下来简单介绍一下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秒的时间，基本上是不可并发的，只能等待这个点查询返回。
http://www.qianxianly.com/data/attachment/forum/20240510/1715342686381_0.png
我们尝试为这个表建一个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用例小结
总结一下：
03Projection原理与实现1. Projection的主要预制构件
Projection的主要预制构件包含三个部份，分别是：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。
http://www.qianxianly.com/data/attachment/forum/20240510/1715342686381_1.png
而这种数据，我们可以直接从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的任何物化程度下，执行结果都是一致的，这样就实现了前述的一致性的问题。
② 一致性保障
一致性保障从以下三个方面讨论：
04特点对比与生产应用疗效
最后介绍一下Projection的特点对比和生产应用疗效。
1. Projection优缺点
Projection优点：
Projection缺点：
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化的设计理念：
页:
[1]