微信 OLAP WeOLAP 湖仓新场景优化通常

ClickHouse 在微信有着宽泛运行，如何保证其自身查问性能，并能在新场景中联合运行成为了关键疑问。基于该背景，开发团队首先针对ClickHouse 的性能疑问，开发了相应的性能观测工具，并在数据查问、战略试验等场景针对性启动了湖仓读取、bitmap 计算等方面的探求优化，最后将 ClickHouse 在 AI 场景启动落地运行，积淀了融合 OLAP 才干的成熟数据管线。

ClickHouse 在微信团队有着宽泛运行，照实时报表、AB 试验和实时计算等，经过将 Hadoop 相关生态集成到 ClickHouse 中，性能获取了十倍到百倍的优化，能够做到万亿级数仓、亚秒级照应和稳固高可用。

ClickHouse 在微信的集群规模有数千台，Top50 照应时长约 0.34 秒，平均照应时长为 4 秒，查问量级为每天百万级。的重要版本是基于社区的 22.8，大批版本对应社区 23.3。

过去一年咱们探求了 ClickHouse 的一些新的运行场景。在湖仓读取方面，基于 Iceberg/Hive 启动读取和湖上数据加工，来缓解数据孤岛疑问；在试验新场景上，启动画像剖析、人群圈选，撑持实时可见的在线试验系统；另外，也与 AI 启动联合，经过成熟的 OLAP 数据管线为近/离线模型推理启动提效。

作为一个用户，须要感知查问的资源消耗；作为一个运维同窗，须要知道如何优化集群负载；作为一个开发同窗，须要极速定位慢查问的要素。这些都离不开性能观察工具。ClickHouse 提供了一系列方便的性能观测工具，如 Query Log、Query Thread Log、Sampling Query Profiler 和 Flame Graph 等。

首先是最罕用的 Query Log 和 Query Thread Log，经过查问的 query id，可以对这条查问性能启动观察剖析。咱们还可以在代码中参与自定义的 Profile Event，繁难定制一些观测目的。

第二个是 Sampling Query Profiler 和 ClickHouse Flame Graph，经过可视化的火焰图能够直观地对内存和 CPU 启动剖析，在 CH 可以对指定查问启动 profile，允许的最细粒度为 query 级别。它有一个缺陷，会将一个查问触及到的多个线程会聚到一同，造成不可对单个线程的状况启动剖析。咱们针对这个疑问也做了改良优化，使它能允许线程级的单个展现和查问聚合。

第三个是 Processors Profile Log，它可以协助咱们明晰地看到每个算子的耗时，判别算子间能否平衡、能否存在歪斜状况，也可以协助咱们看到算子间的依赖相关。

WeOLAP 团队还自研了性能剖析工具 Profile Engine，从当时和预先两个场景启动优化。在当时对用户提交的 SQL 联合集群信息和表信息启动剖析，并基于索引、分区等给出相应可视化改良倡导；在预先基于制订的规定对大查问和慢查问启动剖析，给出优化倡导。经过这个工具，既可以给经常使用者提出优化倡导，也可以协助经常使用者平衡集群负载。该工具上线后的经常使用成果很不错。

ClickHouse 在湖仓链路中既是存储组件又是计算组件，跨层的存在会造成一些疑问:

咱们的改良目的是让 ClickHouse 作为计算组件，间接读取湖仓数据。

针对上述疑问，咱们采取了如下优化措施：

参与外库成功，防止手动繁琐的建表和元信息不分歧疑问。

ClickHouse 在读取某些 ORC 文件时会很慢，例如示例的 select * 和 select count(1)。

经过火焰图剖析，咱们发现 Apache Arrow 库读取 ORC 有少量的 memcpy，十分影响性能。咱们切换到了 Apache ORC 库启动读取，全体性能优化了 0.5 到 1 倍。

在某些场景会产生 IO 糜费，如图中的 select 一列，在 stripe size 为 4MB 和 64MB 时，对应解压后的大小相等，但 HDFS 读取量差异很大。

ReadBuffer 在读取时很容易 cache 少量咱们不须要的数据，帮咱们缓存很多不须要的列，形成少量 IO 糜费。此外，在读取时会先读 stripe footer，再读 row>

咱们驳回 IO 预读机制对 ORC 的读取性能启动优化。首先，ORC 文件可以提早计算文件中哪些 range 是须要被读取的，基于此，咱们将读取规定改为当读命中某个 range 时，依照 range 粒度口头预读，并将邻近 range 启动兼并，缩小HDFS seek 次数。

在运行该读取优化后，性能优化十分清楚，以图中的读取 6 列为例，原有的 40 秒查问缩短至 3.7 秒，优化了 10 倍。

此外，咱们还做了 HDFS 优化、元信息优化和资源并发链接限度，基于这些优化，在典型场景性能优化了 5 到 10 倍。

在命中剖析、画像圈选中可以经常使用 bitmap 启动查问减速，将原有的交并补逻辑转换为位图操作，相比明细表的聚合或 join 查问，通常可以取得数倍的性能优化。

ClickHouse 数据按前启动拆分运算，在 bitmap 场景中，不用批数据的行数，即使行数相反，其代表的计算上班量也存在很大差异，形成了数据歪斜，其中某个 pipe 的上班量清楚高于别的 pipe，以致拖慢了整个查问。

咱们的处置打算是在口头引擎新增 repartition 阶段，从新启动数据平衡，并将数据散发到一切后续 pipe。在大 bitmap 计算中，数据歪斜场景性能优化约 10%~20%。

咱们经过 ClickHouse Flame Graph 对三个线程的口头环节启动剖析，发现有两个口头线程长期间期待，而另一个口头线程耗时在读取 bitmap，读取开支远大于计算。

ClickHouse 在 mark 级以下没有任何并行化机制，咱们针对性优化成允许行级并行读取，关于大 bitmap 异步启动反序列化读取，并缩小内存拷贝操作。

另外，咱们经过对原有字段编码启动压实，既节俭了存储空间，又优化了性能。

新增内核个性可编码字典 Encode Dictionary，允许单机字典和正本同步字典，允许一切原生 ClickHouse 字典函数，允许 value to key 反查，以及 bitmap to bitmap 编码。

在经过以上优化后，咱们在测试数据集上的性能优化很清楚。在 bitmap32 上，求并集和交加有 10 倍的性能优化，在 bitmap64 上，有百倍的优化。

在实践业务运行上，bitmap64 场景从查不了变为查得快，bitmap32 场景从快到更快，在画像剖析、试验留存剖析和表存储等方面优化成果都很不错。

随着机器学习的兴起，图片或文本经过 embedding 高维向量的模式表白，求解相似度会转换为计算向量间的距离。在离线加工场景经常使用 OLAP 有很多长处，比如可以基于元数据过滤、做一些聚合操作，以及配合 UDF 启动加工等等。此外，咱们也在准确距离运算、ANN 索引等方面做了一些探求性的优化。

咱们基于 ClickHouse 对整套算法链路做了重构，融合 OLAP 成熟数据管线，成功了推理、加工和检索一体化。当有复用需求时，可以间接修负数据管线中的 SQL 性能或 UDF，从而大大降落了经常使用老本。

咱们还做了向量准确检索查问优化，将其封装为 SQL，关于后续的需求可以繁难地启动修正迭代。并且对查问 SQL 启动了性能优化：

另外，咱们还优化了 embedding 计算相关函数，在业务场景中取得了 4 倍的性能优化：

以上就是本次分享的内容，谢谢大家。