短视频热门教程大家下午好，今天给大家介绍一下快手对ClickHouse开源社区的最新贡献——Projection。 首先，让我自我介绍一下。 我去年加入快手。 我也是一名博士。 中国科学院计算技术研究所系统架构博士，ClickHouse社区成员。 ClickHouse开源大约半年以来，我一直是一个活跃的贡献者，贡献了超过300个PR。 我今天的分享分为四个部分：①ClickHouse背景介绍； ② 投影介绍及用例； ③ 投影原理及实现； ④ 功能对比及生产应用效果。
01ClickHouse背景介绍
首先给大家分享一下ClickHouse的背景：
一、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、快手的解决方案
快手提供了一个解决方案——投影，解决了前面提到的三个问题。 方法如下：
该功能已经合并到master中，预计下个月发布。 这是ClickHouse开源5年来最受好评的PR。 已在快手内部使用3个多月了。 欢迎大家尝试一下。
02投影介绍及使用案例
接下来我们简单介绍一下Projection，用一个用例来方便大家理解。
1. 投影概念
首先介绍一下投影的概念。 这个概念并非我们原创，而是来自数据库系统图灵奖获得者、列存储数据库Vertica之父Mike Stonebraker。
投影是一组可以使用表创建语句定义的列。 这个概念在C-Store提出后，他们成立了一家叫Vertica的公司，做列存储数据库。 投影是在 Vertica 数据库中实现和开发的。 它不仅是根据不同的顺序进行存储，而且还支持一些聚合函数，比如sum、min、max以及一些roll-up优化，这些都可以通过Projection机制来完成。
我们借助Projection的思想做了一些扩展，这样你就可以使用任意聚合函数、任意自由组合来参与ClickHouse上的数据汇总计算。 这意味着只要你会编写SQL语句和解析聚合函数，两者都可以预先计算并保证上述优点； 第二点是我们支持Projection中表中的部分数据挂载，部分数据不挂载。 这个好处就是我们不能失去ClickHouse本身的特性，比如：在查询的同时实时写入的能力也能受益。
2. 投影用例介绍
这里我们使用视频分析日志表进行演示。 该表每秒大约有 20,000 条记录。 它有两列，user_id和device_id，基数约为2亿。 还有一个低基数列domain，代表域名，视频的属性包括字节数和时长。 它的排序规则是按照user_id和device_id的顺序排序。
如果根据user_id进行搜索，ClickHouse会非常高效，因为它可以快速命中user_id=100的数据。 在有序结构中，通过二分查找或者其他机制，快速定位到数据后快手如何快速获得100赞，就可以取出数据进行处理。 分析发现，扫描的数据量其实很小，远远小于原来的数十亿行数据。
但如果我们使用device_id来查询，由于第一优先级并不是根据device_id来排序的，所以排序索引基本上就失去了意义。 最后的扫描是全表扫描。 这样的查询，在ClickHouse中，大概需要8秒，而且基本不并发。 此时只能等待查询返回。
我们尝试为此表创建一个投影。 创建Projection的操作很简单，就是对这张表进行alter操作。 Projection定义了你需要查询的列，然后根据device_id进行存储。 选择这些列后，由于是惰性模式，因此可以手动具体化。 为了演示效果，我们手动对这个Projection：p_norm进行MATERIALIZE操作。
操作完成后，重新执行上述查询。 该查询不需要任何修改。 可以看到性能提升了153倍，这说明索引已经生效了，刚刚生效的Projection就是生效的。
3、投影实际应用案例
在实际应用案例中，会有这样的场景：一个用户在行为表中可能有多个查询方法，比如user_id、phone_num、device_id。 不同的人会有不同的查询方式。 这样，在检索数字时，一维排序肯定是不够的。 使用稀疏索引或二级索引还会导致其他问题。 如果使用Projection，可以根据不同口径选择需要的列，进行异构多序列存储，这样就可以针对不同用户的数据访问口径达到加速效果。
让我们看一下 Projection 的一个用例，例如聚合域名（大约 100 个碱基）来分析当天视频流的特征。 其实这个在ClickHouse中的性能已经非常不错了。 17亿条数据，ClickHouse在单机上运行时间约为11秒。 ，已经可以体现出它的效率，但是对于渲染看板还是不够的。 看板旨在实现即兴分析，并且可以通过单击它来查看。
我们现在为此查询定义一个预聚合投影。 我们只需要指明查询需要什么样的加速，比如以hour为粒度，以domain为维度进行group by，然后查看sum和avg的结果，进行MATERIALIZE操作。 。
重新执行刚才的查询语句，可以看到提升非常明显，相当于保存了之前所有的IO操作。 您只需要读取最终预先汇总的中间结果即可。 同时也节省了计算成本，不需要额外的预聚合CPU开销。
当我们想要加速聚合统计分析时，有一个底表，里面有一系列维度和指标。 一般情况下，需要加速的流程是ETL流程。 我们需要为每个不同的Topic准备一些专门的表格，比如：实验表、标签表等，然后进行分析和建模。 使用Projection，这些步骤都可以省略。 对于下面的表，我们可以查看基于端到端的报告，看看数据仓库需要哪些查询。 我们做了一些分析来总结和规范这些查询。 构建多个Projections，让所有报表板及时生效，省去之前的ETL流程和数据仓库建模流程，让报表板智能更快； 由于我们只使用底部表格，因此原始详细数据都在那里。 保证数据一致性。
投影优化的本质是用空间换时间。 我们可以看一下Projection的实际成本。 对于Normal Projection来说，存储开销比较大，达到40%左右。
对于聚合投影来说，开销非常小。 只要设计好预聚合模式，开销基本可以忽略不计。
4. 投影用例总结
综上所述：
03Projection原理及实现 1.Projection主要组成部分
Projection的主要组成部分包括三个部分：Projection定义、Projection存储、Projection查询分析。
2. 投影定义
Projection的定义其实和物化视图类似。 物化视图的定义基本就是CREATE TABLE AS SELECT...通过ORDER BY模式投影更加直观，并且可以按顺序调整结构； GROUP BY就是这样完成的。 聚合会拆解序列并选择预先聚合的部分。 这部分涉及到一点：需要找到里面所有的指标，才能找到中间的状态。 该模式可以采用“手动传输”的方式来实现。 Projection 定义可以帮助你自动实现，这是更好的用户体验。
3. 投影存储
Projection本身是ClickHouse系统下的一个附属Part。 熟悉ClickHouse的同学可能知道ClickHouse是一一存储文件夹的。 每个文件夹称为一个部分。 投影是零件下的子零件。 跟这一部分放在一起，这样他们的分区信息是一致的，并且可以和原始查询的分区剪枝动作保持一致。 同时可以保证所有Part相关操作的一致性，并进行递归处理。 每层都对此部分执行 MERGE。 或 MUTATION，投影也将遵循 MERGE 或 MUTATION。
4.投影查询分析
如果直接使用代码进行投影查询分析会比较复杂。 我们先通过一个用例来介绍一下。
① 查询分析原理
还是上面的video_log表。 我们刚刚创建了Projection，那么我们如何知道下面的查询可以命中Aggregate Projection呢？ 实际上必须能够命中原表，否则查询会报错。 我们现在知道它可以击中 p_agg 的投影。 在这个过程中，首先扩展查询计划。
首先，查询需要从存储中读取列所需的数据，然后进行有效的过滤，最后准备好要聚合的参数，如字节数、持续时间等，最后完成聚合动作。 我们需要看看每一步的Projection数据是否能够提供他们需要的输入，这样我们才能知道Projection是否成功。 让我们仔细看看：
Aggregation层涉及参数准备的过程，参数准备有hour、domain、sum（bytes）、avg（duration）。 需要提供的数据有域、字节和持续时间。
我们可以直接从Projection中获取这些数据，因为在查询定义的过程中，我们已经知道这个查询会分解出什么样的数据输出需求，所以我们可以通过这种方式来命中Projection生成的数据。 进入。
这个模型还可以进一步推导，我们看之前的链接：
这里有一个WHERE执行树。 WHERE执行树本质上是一个DAG表达式。 它表达的是：现在有一组柱子。 这组列是如何通过不断变换形成新的列，并最终生成谓词 equals 的呢？ 确定该谓词是真还是假。
投影也可以满足这个谓词。 从后面往前推快手如何快速获得100赞，支持toStartOfHour，然后截断最下面的输入。 事实上，Projection 中没有日期时间列。 当然，它不需要这一列，因为上面的列已经可以满足整个DAG的计算了。 因此，在WHERE表达式层面也能满足Projection。
同理，无论是Prewhere还是RowPolicy的Projection一直到起点都能满足后，这个Projection就是有效命中。
找到有效的击球预测后，在所有合法的候选预测中找到最佳方法。 因为Projection涉及到很多方面：一是种类很多，有Normal Projection和Aggregate Projection，同一个查询可能都会命中； 同时，Projection是一个懒惰的概念，不同的Projection可能有不同程度的物化。 怎样才能有效呢？ 找出最好的投影？ 这时，我们可以对每个候选进行索引分析，获取其预期的数据扫描量，并将结果缓存起来，这样我们就可以有效判断Projection的好坏。 这样，您只需选择预计扫描数据最少的Projection即可。 无需区分Projection类型是普通投影还是聚合投影。 只要读取的数据量小，计算量肯定小，一定是最优的。 预期的扫描体积包括投影的具体化程度。 然后再利用整体指标分析的结果，避免重复的指标分析。 当最终选定一个Projection时，会通过前面提到的回溯分析过程，推导出该Projection所需的执行流水线，然后将该Projection的执行逻辑与正常的执行逻辑进行合并，得到最终的流水线，让查询任何时候执行，在Projection的任何具体化层面上，执行结果都是一致的，从而实现了前面提到的一致性问题。
② 一致性保证
一致性保证从以下三个方面进行讨论：
04特性对比及生产应用效果
最后介绍一下Projection的特性对比和制作应用效果。
1.投影优缺点
投影优势：
投影缺点：
2. 功能对比总结
首先我们看一下目前Projection对ClickHouse本身的具体化改进对比图。 总体来说，Projection基本上各方面都比较优秀，比如：数据一致性、查询分析能力、数据索引能力、详细的数据存储，最好的是它可以保证非阻塞写入，即实时写入，并且可以对Projection做一些逻辑优化，即在写入过程中不需要Projection，但是在查询过程中，可以命中一些Projection优化。 以优化效果。 这是一个渐进的过程。
3、生产实测结果
接下来我们来说说实际生产的测量结果。 首先这个Projection的效果，包括具体化，基本上是和数据集、查询密切相关的。 数据集规模：每天350亿条记录，粒度为10分钟，预聚合某维度列。 聚合比例约为4/100,000。 这个效果分为两部分：一是聚合函数的使用，比如一、二、三的使用。 此时，改进效果基本是基于聚合函数的使用来体现的。 比如最后一个使用了三个聚合函数，改进效果可能会更明显，因为你的计算量减少得更多； 第二个是并发级别。 Projection基本上不需要任何计算资源，所以当并发量较高的时候，不会有太大的提升，但是却减少了大量的计算资源开销，所以Projection对于看板渲染来说是非常友好的。 例如，如果多人同时打开看板并执行许多聚合查询，则可以提高查询并发度。 很高，可以同时渲染看板。 对于原始表，只能有一个看板。 一旦打开，其他人就无法抽出。
从另一个角度来看，主要问题是存储成本。 存储成本主要取决于聚合指标所使用的功能。 因为我们现在的Projection支持任何功能，所以这个时候就需要考虑哪些指标应该避免。 简单的指标，比如上图中绿色的部分，基本上可以随意构建，不需要任何存储开销。 ，基本上都是KB级别的。
有一些中间的，例如分位数计算和日志摘要，这将需要一些额外的存储。 这个时候聚合效果可能就不明显了。 查询时，包括聚合在内的IO计算成本节省可能不会那么大。 。
最后一种是精确计数，基本没有聚合效应。 相当于将明细数据从列存转为行存，压缩成数组。 不建议在生产中使用。 您可能必须使用其他一些方法，例如位。 图或其他方法。 因此，这还是需要根据数据的具体应用来考虑。
ClickHouse中所有查询信息都是白盒的，一切都提供标准化的查询分析。 每个查询都有一个删除所有文字的文字。 去掉文字后，我们就可以进行标准化查询了。 我们可以每天查看查询日志，看看哪些聚合函数可以相互命中。 然后我们就可以具体化哪些查询值得构建。 搭建好之后，我们可以去一些仪表板看看。 例如，以前的看板基本上有 12 个图表。 原本需要30秒渲染，花了半天时间才4张图表出来。 添加Projection后，1秒就出来了，体验非常好。 统计Projection的所有费用，存储开销其实是比较小的。 刚才提到，如果聚合效果足够的话，存储开销不会太大，大约在20%左右。 同时，没有观察到对写入和MERGE的明显影响，每秒写入数仍然在百万级。
4. 预测总结
综上所述，Projection是ClickHouse中比较好的物化视图，即生产可用的物化视图。
这就是我们将Projection由弱变强，进一步增强ClickHouse在OLAP领域的应用实力。 这种力量有很多方面。 另外一个方面就是Projection有比较大的想象空间。
Projection设计符合ClickHouse基于SQL计算和基于Block存储的设计理念：
发表评论