阿里云-阿里云ClickHouse企业版技术白皮书

技术白皮书云原生SharedMergeTree引擎&轻量update技术解析推荐语重磅首发：阿里云ClickHouse企业版首发&云原生ClickHouse 31.ClickHouse介绍 32.ClickHouse企业版介绍 43.ClickHouse企业版云原生架构 54.ClickHouse企业版引擎升级 65.ReplicatedMergeTree的挑战 86.SharedMergeTree升级 7.ClickHouse企业版收益 8.SharedMergeTree引擎的兼容性 9.SharedMergeTree的实际应用对比 11.总结 12.企业版邀测 33ClickHouse技术白皮书揭秘询在1秒内完成。这使得ClickHouse成为企业处理大规模数据，构建实时数仓的理想>44阿里云在2020年发布了基于开源社区版本的云数据库ClickHouse社区兼容版，是全球领业版),并于2023年8月末开启邀测。55重磅首发：阿里云ClickHouse企业版首发&云原生ClickHouse技术白皮书揭秘数据库峰会·北京changetheclustersizedynamically;removetheneedforresharding;allowscalingcomplexqueries;noout-of-syncreplicas;数据库峰会·北京ClickHouse企业版采用完全不同与开源社区版本的云原生新架构，针对云环境做了全面适配。新架构基于存储和计算分离的架构基础，采用对象存储数据实现ShareStorage共享存储，所有ClickHouseServer节点都可以访问相同的全局物理数据，单个Server节点实际上是单个没有限制分片的Replica节点，节点之间访问同一份数据副本。66重磅首发：阿里云ClickHouse企业版首发&云原生ClickHouse技术白皮书揭秘云数据库ClickHouse企业版产品架构图MergeTree系列的表引擎是ClickHouse中的主要表引擎。它们负责存储后台进行数据合并，根据特定的引擎进行数据转换等操作。企业版新推出仅在阿里云ClickHouse企业版支持阿里云ClickHouse企业版支持更好复制以实现数据高可用，并通过分片实现集群横向扩展。阿里云ClickHouse社区兼容版并通过基准测试展示其效率。同时当前正在引入轻量级更新LightweightUpdate,与数据的物理副本。对象存储本身实现确保存储具有高可用性和容错性。需要注意的是，尽读写而设计，以提供快速的查询结果。对象存储虽然访问延迟比磁盘较大，但具有高并发算节点实际上是单分片的多个副本。这些节点不是包含相同数据的本地副本节点，而是可重磅首发：阿里云ClickHouse企业版首发&云原生ClickHouse技术白皮书揭秘8通过①垂直升配操作和②垂直缩容操作，我们可以更改节点的规格(CPU和内存)。而通过③水平扩展，我们可以增加计算节点的数量。而无需进行任何物理Resharding或①③ClickHouse企业版使用持久性更好的对象存储来实现数据可用性，所以不需要2)依赖sharding进行集群扩展2)SharedMergeTree引擎下的集群扩展原理提醒一下：ClickHouse企业版计算节点是具有访问共享存储的计算单元，其规格和数量可以更改。基于此机制，SharedMergeTree完全将业务数据和元数据的存储与计算节点分离，并使用Keeper的接口去读取、写入和修改共享元数据。每个计算节点都有一个存储元数据的本地缓存，并通过订阅机制自动获取数据更改的通知。下图描述了如何使用SharedMergeTree将新服务器添加到集群中：Server-1Server-1当Server-3添加到集群时，这个新Server①订阅Keeper中的元数据更改信息并将当前Parts的元数据获取到其本地缓存中。这不需要任何锁机制；新添加的Server-3几乎可以立即参与数据处理，因为它通过从Keeper中只获取必要的元数据信息，找到有哪些数据以及在共享存储中的什么位置。下图描述所有Server节点如何知道新插入的数据，来保证查询数据一致性：>Server-1Server-1还将关于该部分的信Keeper于该Part,以及与文件对应的块位于共享存储中的位置)。ClickHouse向查询的发送者确认插入成功。其他节点(Server-2、Server-3)通过Keeper的订阅机制⑤自动得到存储层中存在新数据的通知，并将更新的元数据提取节点的高可用设置)。1)无缝集群扩展表引擎为所有表添加了共享的元数据存储。它实现了在该存储之上运行的节点几乎无限的扩展。服务器实际上是无状态的计算节点，我们可以立即改变它们的规格和数量，如下示例通过简单地(手动或自动)将每个节点的大小翻倍，或者根据实例负载，将节点数量从三>同时也会使写入吞吐量翻倍。对于SELECT查询，增加节点数会增加并发查询能力，以及单个查询的并发执行。请注意，在ClickHouse企业版中增加(或减少)节点的数量不需shared-nothing架构下的集群中更改节点数量需要更多的工作和时间。如果一个集群当前由三个分片，每个分片由两个副本组成：然后翻倍分片数量需要对当前存储的数据进行resharding和rebalancing:L.L2)插入操作的效率收益可以配置插入的数据仅在指定数量的副本上持久化好时返回给发送者。对于3)更轻量级的强一致性Select查询4)集群吞吐和查询效率的线性提升这对于ClickHouse中的其他新功能具有积极的影响，例如SharedMergeTree为SharedMergeTree能够提供更好的合并吞吐量Parts为了确保查询结果的正确性，用户需要在查询时通过使用FINAL修饰符或使用带有显式8.SharedMergeTree引擎的兼容性SharedMergeTree表引擎现在已经作为ClickHouse企业版中默认的表引擎。ClickHouse企业版支持的MergeTree家族中的所有特殊表引擎，并都会自动基于在我们的测试case中，我们将2022年前六个月的WikiStat数据集加载到ClickHouse企业版中的一张表中。为此，ClickHouse需要从大约4300个压缩文件(一个文件代表一天的一个小时)中加载约260亿条记录。我们使用了四种不同数量节点的配置。每个节点都有30个CPU和120GB内存：请注意，前两个集群配置都使用了一个3节点ClickHouseKeeper服务，每个节点有3个CPU和2GB内存。对于20个节点和80个节点的配置，我们将Keeper的大小增加到每个节点有6个CPU和6GB内存。在数据加载运行期间，我们监控了Keeper,并行使用的节点数量越多，期望数据Parts数量(表分区)是3000个(之前是300个)。少于3000个的健康数量所花费的时间。为此，我们使用系统表上的SQL查询来监控(并可视化)活动Parts随时间的变化。写入参照。如上所述，这个表引擎并不适合支持高数量的副本节点。以下图表显示了将所有Parts合并为少于3000个健康Parts所花费的时间(以秒为单位):我们可以看到，在我们的测试中，后台合并的吞吐量与节点数量呈线性关系。当我们将节点数量从3增至10时，吞吐量也将增加三倍左右。当我们将节点数量再次增加2倍至20,然后增加4倍至80时，吞吐量也分别增加了约两倍和四倍。正如预期的那样，使用ReplicatedMergeTree在随着副本节点数量的增加时无法很好地扩展(甚至在较大的集群大小下会减少写入性能),而SharedMergeTree则随着副本节 为了完整起见，下图显示了将Parts合并少于300个所花费的时间，可以看到3)不同节点数详细结果对比在10个节点的集群中，我们可以看到一些不同之处：写入时间的差异只有19秒。然而，当写入完成时，两种表引擎活动Parts的数量是非常于3000和300个活动Parts所花费的时间也要多两倍。这意味着我们可以更早地通过SharedMergeTree获得更快的查询性能。当写入完成时，大约4千个Parts仍可以进行查询。而大约1万5个数量级时，则是不可行的。对于从WikiStat数据集写入约260亿行的任务，这两种引擎都会创建大约2万3千个初始Parts,每个部分大小约为10MB,包含大约100万行数据：__formatReadableQuantitycountIfevenpartsrowsavgsizeinbytes___大约2万3千个初始Parts均匀分布在这10个副本节点上：__formatReadableQuantitycountIfevent_ __> |||1234567892.41||—nodeid———parts——rowstotal但是SharedMergeTree引擎在数据加载过程中更有效地合并了这些部分：尽管ReplicatedMergeTree在SharedMergeTree之前完成了数据插入过程，但活动parts的数量仍然持续增加到约1万个左右。因为ReplicatedMergeTree引擎仍然在复制队列中有需要在这20个节点之间进行复制的insert操作。通过这个查询我们获取了在复制队列中的insert数。处理该队列花费了将近45分钟。点间通信的开销过高。减轻这种情况的方法是通过手动调整插入查询的一些设置来限制新需要注意的是，测试运行期间Keeper的负载并未过载。以下截图显示了两种表引擎的在我们的80个节点集群中，我们只将数据加载到一个SharedMergeTree表中。我们已插入260亿行的过程在67秒内完成，平均速度为每秒3.88亿行。SharedMergeTree是云原生服务的一个重要基础组成。它使我们能够在以前无法或过于复杂实现的情况下构建新的功能和改进现有功能。许多功能从SharedMergeTree的架构下“LightweightUpdate”-一种可以在使用更少资源的情况下立即使ALTERUpdate查询的结果实时可见的优化。1)开源版本update操作重且效率低个重型操作，可以同步或异步地重写Parts。INSERTINTOT(id,v)VALUES(1,'a),①③②Part-1⑤⑤⑥88DELETEWHEREv='b';⑩①⑩①UPDATEv='e'WHEREid=3在我们上面的示例情况中，ClickHouse①接收一个对空表的插入操作，②将插入的数据以新的Part写入存储中，并③确认插入。接下来，ClickHouse④接收一个更新操作并通过⑤mutatePart-1来执行该操作。该Part被加载到内存中，执行修改，修改后的数据被写入和存储到新的Part-2中(Part-1被删除)。只有在该Part重写完成时，才会将重磅首发：阿里云ClickHouse企业版首发&云原生ClickHouse技术白皮书揭秘27⑥对更新操作的确认返回到更新的发起者。其他更新(或删除数据)也以相同的方式执行。对于较大的Part,这是一个非常重的操作。默认情况下，为了将几个收到的更新融合到单个mutation中，更新操作是异步执行的以减轻重写Parts对性能的影响：INSERTINTO;①②①②④⑦当ClickHouse①接收到更新操作时，更新会被添加到队列中并异步执行，②更新查询立即获得更新的确认。请注意，在更新被后台的mutation物化之前，表中的SELECT操作不会看到更新的数据此外，注意ClickHouse可以将排队的更新融合到单个Part重写操作中。因此，最好的做法是批量更新，并通过单个查询发送数百个更新操作。更新机制Lightweightupdate不再需要显式地对更新查询进行批处理，从用