1.ClickHouse在快手OLAP的服务
ClickHouse在快手内部是作为OLAP引擎，提供多集群架构，对于不同业务有不同的集群保障，上层是查询代理层，进行统一的查询管控和接入路由以及统一的监控服务，这样可以把ClickHouse“手动挡”应用模式逐步变成一个可用的服务，提供给用户。同时最底层的数据写入，由于ClickHouse的数据写入需要一些相关的知识，所以把ETL服务抽取出来，用户只要告诉我们，你从哪个实时流进来，或者从哪个离线的数据源过来，我们就可以提供整套的ETL服务进行包装。
提供的服务包括：支撑留存计算、AB实验、音视频分析、风控预警等都在ClickHouse上有所应用。整体的规模大概是每天百万查询接入，上百TB存储，上千台ClickHouse节点。
2.开源竞品对比
从上图中可以看出，ClickHouse特性还是比较明显的，就是明细查询和实时写入速度特别快，分析功能很强，支持高阶函数，可以做很多传统SQL做不到的事情，开发起来也比较顺手。
ClickHouse管控能力比较弱，之前也提到了，它是一个“手动挡”应用模式，直接拿来用还是比较费劲的，因此我们通过完善的架构设计和外围设施，增强了它的管控能力，达到了生产可用的效果。
其次就是事务能力，事务往往伴随着性能开销，在互联网分析场景中不是一个高优的需求。
第三个是物化存储能力较弱，而物化是OLAP分析的核心，因此是亟需解决的。
ClickHouse物化存储有以下几个痛点问题：
3.快手的解决方案
快手提供了一个解决方案——Projections解决了前面提到的三个问题，其方法如下：
这个功能目前已经合并到master，预计下个月会release，是ClickHouse开源5年来最高赞的PR，在快手内部已经使用了3个多月，也欢迎大家尝试使用。
4.Projection概念
Projection是一组列的集合，用建表语句可以定义，这个概念在C-Store提出后，他们成立了一个公司叫Vertica，做列存数据库，Projection在Vertica数据库中落地发展，不仅仅是按照不同的顺序做存储，同时还支持部分的聚合函数，比如sum、min、max以及一些上卷的优化，可以通过Projection的机制来完成。
我们借助了Projection的思想来进行了一些扩展，使其可以在ClickHouse上用任意的聚合函数、任意的自由组合参与数据上卷计算，意思就是只要你能写出来的SQL语句和分析型聚合函数，都可以进行预计算，并且保证前面提到的优势；第二点是我们支持一张表部分的数据挂载Projection，部分数据不挂载，这样的优势在于我们可以不丢失ClickHouse本身的特性如：实时写入的能力，同时查询也能够受益。
5.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。
6.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流程和数仓建模的过程，使看板智能提速；并且由于我们只使用了底表，原始明细数据都在，保障了数据一致性。
7.Projection原理与实现
Projection的主要构件包含三个部分，分别是：Projection定义、Projection存储、Projection查询分析。
Projection定义：可以通过用户查询直接定义，也可以自动推断Projection类型和相关属性。
Projection存储：Projection存储主要就是解决一致性的问题，怎么样在ClickHouse物化视图不一致的情况下，通过存储的设计，把物化出来的结果和原始的结果进行强一致的绑定。
Projection查询分析：回溯分析查询计划，使用标准表达式名称进行匹配验证，使得可以命中Projection，得出正确的查询结果，并根据选出来的Projection重建执行计划，完备的实现一致性的查询效果。
8.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的任何物化程度下，执行结果都是一致的，这样就实现了前述的一致性的问题。
9.一致性保障
一致性保障从以下三个方面讨论：
10.Projection优缺点
Projection优点：
Projection缺点：
现在的Projection是基于Part级别的，无法跨Part聚合，预聚合的粒度还是有一些限制无法脱离原始表存储，无法使用不同的生命周期与存储介质配置不支持join，还是一个大宽表的模型，不过对于物化来说，用join的还是比较少11.生产实测结果
接下来说一下生产实测效果。首先，这个Projection包括物化的效果基本都是跟数据集和查询紧相关的。数据集大小：每天350亿条记录，按照10分钟为粒度，取某一个维度列进行预聚合，聚合比大概是十万分之四。这个效果分两部分：一个是聚合函数的使用量，比如说一个、两个或者三个的使用量，这时候提升的效果基本上是根据聚合函数的使用多少来体现的。比如最后这个用了三个聚合函数，可能提升的效果就更明显，因为你的计算量减少的更多；第二个是并发层次，Projection基本上不需要什么计算资源，所以在并发很高的情况下，并不会有太多提升，但是它减少了很多的计算资源开销，因此Projection做看板渲染是非常友好的，比如说多个人同时打开看板，执行很多个聚合查询，查询并发可以提的非常高，可以同时把看板渲染出来，原始表的话可以就一个看板，打开之后，别人就刷不出来了。
ClickHouse所有的查询信息都是白盒的，所有东西都提供规范化的查询分析，每个查询带有一种去掉所有的literal，就是字面量。去掉literal之后，我们可以做规范化的查询，可以每天去看一下查询日志里面聚合函数分别有哪些能够命中，然后我们得出值得建哪些查询的物化，建出来之后，去找一些看板来看，基本上一个看板，比如12张图表，原来渲染时间要30秒，等半天才出来4张图表。加了Projection之后，1秒就出来了，体验感非常好。统计Projection所有的开销，其实存储开销还是比较少的，刚才说的，聚合效果足够的话，存储开销不多，大概20%。同时，写入还有MERGE并没有观测到可见的影响，同样能够保持百万级别的每秒写入数量。