极速数仓ClickHouse步入云原生新纪元
内容介绍：
一、ClickHouse优势&场景
二、ClickHouse架构
三、最佳实践
四、总结与展望
主讲人
王鹏程
ClickHouse核心研发团队技术总监
接下来将由 ClickHouse 核心研发团队技术总监王鹏程、长桥航行服务架构负责人 刘文全 共同带来极速数仓 ClickHouse 步入云原生新纪元。
ClickHouse Enterprise 技术解析
大家好，是 ClickHouse 核心研发团队技术总监王鹏程，给大家介绍一下 ClickHouse Enterprise 版本在阿里云上版本的技术解析、技术前瞻、2024年的技术规划。
下面正式开始。个人是今年3月份加入 ClickHouse 的。
一、ClickHouse优势&场景
今年在阿里云上线了ClickHouse Enterprise版本，ClickHouse Enterprise 是云原生版本。在阿里云提供的基础设施上做了相关的优化和适配。
介绍ClickHouse 相关的生态。在世界排名1000的公司里超过50%的企业在使用 ClickHouse ，包括各行业，例如金融分析、网络及市场分析、用户行为分析、 BI 、可观测性 Ctrip 、LoT设备、网络分析等厂商都在大规模使用 ClickHouse 存储非常多的数据。
为什么大部分都在使用 ClickHouse ？因为 ClickHouse 有非常独特的相关优势。 ClickHouse 是可以轻量级超快速查询的引擎，本身定义 ClickHouse 是一个 real time 的数仓，即你在ClickHouse查询基本可达到快速的结果。也在做相关的评测，包括自己维护的bench里长期保持最快速的 benchimarke 。由于 ClickHouse 是CER 写的，因此它可以达到非常高的资源利用率。对于标准SQL的支持和对ClickHouse 做过十多年的扩展，包括各行业的 ETL 函数和其他多样的函数都是非常丰富的。包括数据元的支持，例如常见的 SAN 、阿里云的 OSS 、各种对象存储、基于ADP上各种文件支持，把它直接抽象成数据文件、数据表做查询非常方便。像最新的 Delta Lake 、Iceberg 、 Hudi 的相关知识，也做非常多的集成。
二、ClickHouse架构
为了做到相关的快速查询，给大家介绍 ClickHouse 的架构，主要是云原生这个版本。今年在广州举行的 RDB 会议上，发布了 ClickHouse 的 Paper ，主要讲述多年来ClickHouse在工程上的实践和探索。在整体架构上做了创新，较核心的东西都在架构图上，基本可以管窥。整体来说，是一个发展多年的数据湖仓架构，整体分成了许多的模块。
首先最上层粉色的是 processing ，基本上数仓都是此种架构的。整体来说 ClickHouse 做的比较创新的点做 table engine 的抽象非常完整，做的深。
可以把很多的数据源，甚至把 mysql 或者 PG 的数据库当成一个表，做 ClickHouse 的数据源进行查询或过滤。做了较多创新，使得在阿里云做的云原生版本有比较好的落地。
ClickHouse比较经典的查询引擎是存储引擎。它是Replicated MergeTree在工业上用的较多。在这里做了相关的查询优化，进行升级，目前升级成了shart Replicated MergeTree。整体来说可以把数据的存储全部放在 SI 上，基于 SI 相关的数据存储能力，再把计算和后台相关的work 进行分离。
讲一下细节上的，看ClickHouse存储层的架构。整体来说ClickHouse本身把数据做非常多的 part 存储。支持普通的 insert ，也支持异步的 insert 。异步的 insert 会先放在buffer中，进行 margin ，做成一个非常大的 part ，真正往上写的时会在 margin 上进行更高的 part ，进行高吞吐的写入。
经典的 ClickHouse 架构是通过节点同步，同步完把数据 margine进行写入。但在云原生版本里，做了较大的改动。 INSERT 是通过单独的note和shrt的方式进行insert，最后 marge 时单独选出节点进行marge 。避免了像在 Replicated MergeTree 上进行重复 marge 。
ClickHouse计算层架构是较开创先河的。之前掀起过一阵风潮，大家都在说向量化查询引擎，ClickHouse在向量化查询引擎是比较开创先河的数据库。在向量化查询引擎里不仅做了SIMD优化，多核并行优化，在阿里云新的版本做了多节点并行优化和性能优化。ClickHouse的Paper里特别介绍了查询引擎，写过C++或代码的同学都知道编译器在编译的过程中会弹出探测CPU的架构进行相关编译，运用指令集相关的产品把进行向量化的运行的编译。由于本身编译的机器和运行机器大概流程不是同一个机器，以及编译器本身的局限性，导致向量化的抽象不是非常多真正的被应用。
ClickHouse做了深入的优化，把 GIT 的优化和 SIMD 优化结合，在SQL转化成 AST 在转化成 ASSA 的运行过程中，会探测当时运行的CPU架构，对它进行动态的向量化查询的指令集翻译。这就导致ClickHouse在这方面查询性能一骑绝尘的局面。
在Join上用了较多 HashTable的 build ，也做了非常多的相关优化。大家如果感兴趣，可以看一下ClickHouse发布的paper，里面有详细介绍还有相关的业绩对比，时间问题，不能展开太多。据我所知， ClickHouse 在接入层是较领先的存在。比如原先支持九十多种格式和五十多种外部系统集成，无论是怎样的格式、压缩方式，分片或者是不分片、放怎样的的存储系统，比如FTP、NTP、甚至SI架构OSS存储都可以直接当成表查询，不用手动下载数据。在Table Function、Table Engine、Passive、Active、都做了较领先的探索和集成。
在 ClickHouse 整体性能上做了优化，在 Paper 上着重和相关的ARAP 等业界较领先的厂商做了对比，在大部分查询情况下，ClickHouse能保持优势。ClickHouse从开源到2024年，一直在做相关性能优化，这也是非常持续的过程。
从 LTS 版本优化的体现上看，整体的性能一直在做相关查询延迟的优化。很多厂商使用开源版的ClickHouse做自建，对比ClickHouse自建和ClickHouse cloud相关的对比。
如果有非常强的技术实例，对C++和ClickHouse的结构比较熟悉，很多厂商都选择自建，自建是非常开源的情况，ClickHouse的repale大概有2000多的 country built 。而 country built大多都是ClickHouse用户，用着就变成了贡献者。
基于开源的模改，国内有非常多的 ClickHouse 分支，相关架构的灵活性、功能应用性都有相关的优势，当然也可以购买相关的支持服务，会有相应的支持，主推的还是 ClickHouse cloud 版本，这是全托管的版本，在全世界前四的云上做了深度集成与合作。好处就是非常flexible ，无需做复杂管理，自己去维护就需要经验丰富的 DBA 做相关维护以及后端运维工程师的支持。
在云端广泛的生态环境支撑包括各种 cdc 工具，kalfka、datelake支持。 cloud 版本支持分钟级开启服务，从准备使用、注册到服务开启基本是分钟级的情况。在阿里云上实现了skill up、skill down，横向、纵向的 skill 的功能做的非常好。
阿里云的基础设施在容器上做了非常多的创新，阿里云可以在不重启容器的情况下对 CPU 的 limit 在容器上做弹升，ClickHouse cloud版本也支持相关。如果只在云上开了16格ClickHouse 的实例，查询压力较大，可直接在不重启任何服务的情况下弹升到64格，查询之后再弹降，比较灵活的方式，不会浪费资金且无限等待。还可以做横向的skill，如果一个节点不能搞定服务，会动态进行横向节点的skill。
第二，能做到比较踏实的 PI 结构。当然还有巨大的优势，自建时是用本地硬盘，了解到很多厂商还是用 NSSE 、做ClickHouse存储，一般数仓数据很大，如果用SSD，再考虑用多少副本，对于存储资源的浪费也非常大。以阿里云为例，用块存储和用 SIM 的价格优势是有非常大的区别。云版本是把数据放在对象存储，这能获取存储成本的优势。
现在在ClickHouse阿里云上企业版的产品特性，基本能做到scaleup、scaleout的横向、纵向伸缩。若用对象存储去存储，可做的几乎容量无限的扩展，Object storage延迟上不如本地硬盘，但数仓一般是吞吐，性能基本上做到与自建的没有区别。也做了存储相关的优化，在云原生版本使用自研版本 c+的 keeeper 做了metadata存储和协调工具，也没有 replica 之间冗余的通信。
在ClickHouse企业版做了基于负载的秒级serverless能力，本身做了存算分离无需再做额外的东西，在监控图上基本可以做到非常方便的skill。触发时间大概在15秒的量级，非常迅速。
今年也逐渐推出几个新的特性，主要提出两个阶段。第一个是 distributed cache ，在存算法分离基础上，把case节点单独做抽象。基本上在使用的过程中cache 做相关独立的部署。
不会因为cache 的skill或者是计算节点skill，做出一些cache的miss。还有stateless worker，之前版本的计算节点会做一些后台工作，像一些Merges或compute相关后台的工作，还会有一些计算节点。后面的版本会做stateless worker，并移到stateless worker中进行使用。并更好的资源分离，core节点只用于core查询，后台看不到的东西全是不用core节点做了。我们也有很多功能，可以在链接中进行讨论，相关人员也会积极在上面与大家讨论我们roadmap的规划和解答。ClickHouse在国内有很多相关资深的用户，像长桥。
长桥证券基于阿里云数据库ClickHouse的行情服务建设实践
在证券行情业务上，长桥证券也是在迁移到阿里云上之后使用ClickHouse。包括我们中间调研的过程和存储的转换，和使用ClickHouse带来哪些好处。
我们在ClickHouse基础上，又有什么样的预期业务的规划。主要是公司业务，因为技术是随着业务的发展去逐渐迭代的，通过一个业务背景来介绍我们在存储上面临的挑战。其次是在这种挑战之下，我们在技术选型上，我们做了什么样的评估，怎么去做了一个演进。最终是在ClickHouse的基础上希望去做迭代的哪些功能，去完善我们的业务。
首先介绍一下我们公司，我们是长江证券，其实如果大家接触过港美股，应该是有听过的，虽然我们的时间相比于很多证券公司、金融公司都不是很长。我们是19年的时候公司注册成立的，是由新加坡以及包香港那边的资深的金融管理者，以及互联网的一些技术专家，组成了一个团队。
然后在21年的时候也是获得了一个500万美元的一个投资，在23年的时候，我们就拿到了比如最佳外汇的解决方案、最佳的经济收付款解决方案，以及杰出的金融科技证券商。截止到2024年，我们拥有了新加坡、香港、美国与新西兰已经超过了21张的金融牌照。然后在香港也是拥有了1、4、9类牌照，包括证券股票股票的交易、虚拟资产期权衍生工具，超过有三万多种的金融品。然后在全球市场，我们也遇到了很多技术上的挑战。
一个是本身的接入端，其实行情业务上，我们为所有的接入端，APP端、web端、桌面端，包括以及像很多程序员炒股风格的，喜欢写一些脚本代码去操作的时候，我们也提供了API的一个接入端。然后我们在这些所有的接入端上，实际上是一套统一的解决方案，没有进行一个完全的隔离。所以有两个点非常的具有挑战，一个是我们的行情市场数据。我们现在的行情市场数据有美股的、港股的、期权的，品种还是比较多的，同时我们会进行一个简单的计算，比如经常看到的一些K线图，或者是指标，都是一些快速计算之后，然后大家才能够去看到的。所以我们对于存储的需求，业内用的比较多的是持续式的数据库。
同时希望它是有一个简单的聚合分析能力的。比如在成交数据写入之后，有些用户是希望能够去进行一些简单分析，或是自己做一些内部通用的分析计算时，最终都是希望能够一秒内完成我们实时数据的写入，所以是一个非常典型的real time的一个场景。同时在去做一些技术选型时，也希望数据库底层，包括我们自己的程序上，其实都是尝试去在金融上更贴切一点，支持design lation。因为如果只做一个市场，可以只固定一个精度。我们有全球的市场，我们针对美国市场，针对包括一些虚拟资产，它的精度是非常的高的。然后这种情况下，希望他能够原生的支持一些decimal类型。然后同时还有一个是时间函数的问题，也面临了很多实际上的挑战。所以在数据库上也是希望能够在时间函数上支持的足够丰富。
在业务的场景情况下，也是做了很多的调研。首先原来的存储模型是很简单粗暴，因为最开始是一个业务高速发展的阶段，所以当时不同的业务做了不同的存储选型。比如我们在支持香港市场、中国A股市场以及新加坡市场的时候，PG其实已经能够满足我们的写入需求了。但是随着美股市场的发展，然后期权的发展，包括我们原先在AAW上去构建服务的时候，我们发现只有redis的IO能够承载我们美股的业务量。同时WDB，它写入性能其实是非常好的。所以在AW上也是用了DMDB去满足我们期权。期权因为是有百每秒百万的一个标的数量，所以并发写入量非常恐怖。
我们也是选择了打dynamoDB的一个方案。但是这样就会造成技术上的一个非常痛苦点，我们的存储太多了,在进行一个数据分析的时候，尤其是我们现在业务正变得逐渐复杂的时候，我们要去做很多数据分析，做很多数据清洗。然后用户他对一些数据质量，包括我们自己在数据质量提升上的需求也越来越多了,要做很多数据清洗操作。这个时候我们就发现我们要对每一个市场，每一个存储的模型都要单独的去做清洗，也是我们的数据清洗服务变得非常的复杂。同时我们的数据写入服务也是做了隔离，然后这时他的最终写入的目标也是不一样的。后面希望能够满足在云上的一个通用性。
另一个是希望能把存储层完成统一。我们需要选择一种存储方案去满足我们整体的业务方向。Redis其实在用PG和redis遇到最大的问题就是成本太高了。因为只是当天的数据，整个承载量还好。但是因为金融市场它是随着时间的推移，它的数据量会日益增加。
如果我们五年以后，十年以后，我们的数据量会膨胀到什么样的程度？在PG上这一点其实非常恐怖，存了比如说A股存了十年，然后美股只存了几个月的数据。但是在PG上的一个数据量已经膨胀到了成本上每年都要去重新评估的，redis同时也是一样的问题。Redis其实在传统的一个技术上，它只是作为一个开始来使用的。但是当时也是为了能够保证我们的业务能够并发写入，所以我们把它当成了一个DB来用。但是这样会导致我们把它当成DB时，它的成本是非常高昂的。
同时我们的业务规模，比如中间还接过美股的夜盘市场，后面可能会接入一些其他海外的市场。这时，不可能每来一个市场，要为他再专门做一个存储。所以现在的市场加上我们的存储方案，已经扩展性已经非常复杂了。一个是性能上的问题，PG其实在应对一些查询场景的时候，性能还是非常优秀的。
但是在美股的行情上，美股是高峰，因为它的标的数量有一万多，所以高峰写入时，数据量都是万以上的。这时会导致我们的PG在美股峰值的时候压力非常大，同时也会导致我们的查询受影响。会有一个数据清洗的过程，数据清洗的过程会对全市场的数据做一次类似回放的操作，像很多量化分析的一个场景。这时DB的压力也是非常大的，会导致整个DB只能承载数据清洗场景。会blow写入或block很多我们其他的产品操作。
本身运维也是比较困难的，用redis模型时，我们在进行数据清洗、数据修复，包括去后台让运营、产品或者商务去做一些数据分析的时候，其实很难拿到数据。在选择ClickHouse之前，我们也对比了很多数据库，列出了当时认为非常能满足我们需求的几个。他们得到的DB其实是PG上的一个插件，当时选择它的原因是因为我们原生的数据库就是PG，如果能有一个插件的形式就能满足比如数据分析、数据存储以及原生的数据类型的扩展，它是一个非常好的迭代方案。但是最终的目标上还是不能够解决我们在数据清洗之后大批量写入的一个问题。
同时也是美股期权场景下高并发写入的时候，场景没有解决，但是查询分析性能还是比较好的。当时调研之后，是在海外地区AWS上才能支持，在国内地区的版本都是不支持的。所以当时也是消耗很多的精力在这个上面去做了比对。相比之下是大家非常关注的实习数据库，选择一个稍微成本可控的TDNG。实际数据库跟ClickHouse重叠点是非常多的。因为底层是一个劣势的存储，所以在大量数据存储的情况下，它的压缩效率是非常可观的。整体上压缩之后，我们写入大量数据的时候，它占的一些存储资源都不大，同时也是加了开始的优化。但是发现在阿里云上的表现，是一个非常复杂的成本，里面涉及到了实力费用，资源费用，网络费用，叠加的一个费用。
同时有很多语法，是自己的一些分析语法。跟我们现有的查询场景，分析场景不能支持通用。然后在ClickHouse上，也是非常惊喜的发现好处，是支持我们按PG来建表。这意味在做数据迁移时，是能直接把原来的PG数据，或是存在了S3或OSS上的数据，能直接加载到ClickHouse中。在前面提到有很多分散式的存储，就是分了很多市场的存储数据能够在这里面得到统一。
同时它在金融支持上，即demo类型或者时间函数都是支持的比较非常好的。它最大的好处是批量写入能力。在测批量写入能力的时候，会发现我们用十年的数据写进去之后，再继续大批量的写入，它的性能是没有任何影响的。可以看一下当时的过程，当时主要选的是A股的数据，因为当时美股没有存这么多数据，所以选了A股13年的数据来作为批量写入，并且当时我们也做了一个4C16G的单实例，共做了两个场景，一个场景是按单标，因为很多场景它的标的活跃度不一样，所以按单标进行批量的写入。
首先我们先在里面插入了11条数据，然后接着再去不停的写，最后50万条数据分十次写进去了，平均耗时大概在7秒左右，并且这个写入的性能是非常可观的。不管我们有没有数据，也不管里面当时的数据量存入了多少，当我们不停的新增写入的时候，它都能够保持在7秒左右的级别。当然我们用的资源可能与官方的资源也不太一致，在这个资源下进行测试，并做了简单的查询分析，即我们在这里没有详细的描述，即在写入之后，我们又尝试针对ticket的数据做简单的量化分析的时候，会发现这个分析的过程也是非常快的，他在聚合查询的场景下，随着数据量的增加，他的表现能力依然是非常优秀的，没有明显的降低。所以后面就准备用click house来进行对底层数据的完全的重构。
一方面是历史数据，即实时数据写入的困难。在PG里大部分都是历史数据，而click house实际上是能够满足历史数据加实时数据两种场景。所以我们就完全使用了云上的play house作为数据存储。另一方面是新加坡、香港和A股的数据，它们在全部迁移到gay house之后，相比于原来的PG存储降了五倍。而原来PG存储签上去的时候，预估可能要个1T的资源来存储我们所有的市场，但实际上签上去之后100G就已经够了。因为有很多K线图都长得一样，并且成交也不活跃。
在这种场景下，house实际上是有优化的，即数据重复的场景，实际上是劣势存储的优势。所以当时我们的使用量也是让我们觉得非常的意外。并且在后面还特意做了一次缩容，并把资源缩到很小。同时原来的批处理逻辑在做数据迁移的时候是没有针对clean house做优化的。但是在没有做优化的场景下，它的写入速度依然比PG快了十倍。所以我们最近还在针对house进行优化，因为house推荐的方式是进行批写入，优化的目的是对我们自己的业务来适配，并优化这部分写入数据。所以实际上的写入速度是远超十倍的。
从数据量上来讲，还有一个最大的好处是期权跟美股得到了统一。因为期权在整个技术上是存储最头痛的问题。在美股活跃的时候，它有一百多万的期权标，并且他这一百多万的期权标可能会在活跃的场景下同时写入100万的写入量，在我们已经用到的这个产品之前所用的到产品上是很难支撑上的。对于CK的这段时间的观察，其支撑上是没有什么压力的，包括最近新增的其他业务，以及接入的美股的快速行情，其中在我们接入了美股的total view的60档盘口的行情的时候，我们依然用CK来承载的这个数据量，并且它在所有市场的实力上，以及集群里都是没有问题的。
在实时数据场景下，是用redis来承载，并且还是保留了redis的实时数据，因为只是我们会把tick级的数据直接写入到the house。因为tick的数据相比简单计算的数据压力还是很大的。但是在第一个数据写入的时候，我们做了一个P优化。所以第一个数据在多市场的情况下是完全能够承载的。并且这个数据写入之后还有一个好处是大部分的市场数据都是根据ticker来构建出来的，所以我们的清洗服务是直接能够在CK上得到一个统一的。因为只要有这个数据，那么其他的金融数据都可以从这个数据上进行产生，所以我们整个的数据信息复杂度和数据处理的复杂度都大大降低了。
在存储资源上。首先存储资源降的是最明显的，大概有四倍的降低，而写入性能上大概是十倍。运维压力是指的原先找运维处理的时候。比如我们redis有问题或PG有问题，这全都需要关注。在文件存储和单mdb存储中，运维复杂度是非常高的，它们全都在一个上面，并且都有相应的存储告警，这使运维关注的点大大降低了。
但是我们也遇到了一个比较头疼的问题，即查询的问题。今年的用户量增加的是非常多的，随着这部分的用户量增加，查询的QPS已经达到了一个不可预期的增长地步。比如今天是这个数量，明天可能就是两倍的数量，这时候如果我们穿透到DB之后，会发现在DB、CK上查询的时候，它能支持的并发查询能力是稍微弱的。但是我们本来也有一个内置的内存数据库，所以我们利用了内存数据库的能力来扩展这部分的查询能力，从而提供一个高QPS的场景和复杂的场景。
在这之后，我也希望能够沟通一下，因为后面的数据分析需求也是非常多的。在service模式下，比如我们做一些计算、分析。我们希望是把数据聚合之后，能够对所有市场的数据都能够做统一的分析计算，这样就能够为投资者提供一个全球市场的数据分析能力。因为在有些场景下，他是希望比对中国市场和美国市场的趋势。然后在这种场景下，在我们做完数据统一之后，会发现这个业务场景就非常容易实现了。所以我们也希望能把这部分分析能力带出去，带到个人量化或者机构量化上。
所以我们也希望能够基于clear house做一些计算上的扩展。并且我们也有一个自己的计算语言，希望大家可以去了解一下，它叫navy，并且它在clear house上完成了数据的统一。在之后我们希望能够在这种数据统一的基础上，在量化回测数据清洗以及更专业的数据分析上，不停的迭代我们现在的产品，从而做到为大家提供一个更开放的计算平台，或者一个数据分的能力，让大家能体验到在全球市场数据下可以自己动手，比如我不想看你们的技术指标，我有我自己的技术指标，我就可以通过这些能力完成对应的分析。
