深圳市建设行业门户网站,展示型商城订单网站建设,长春建站公司模板,注册二级建造师查询入口摘要#xff1a;社区ClickHouse的单机引擎性能十分惊艳#xff0c;但是部署运维ClickHouse集群#xff0c;以及troubleshoot都不是很好上手。本次分享阿里云数据库ClickHouse产品能力和特性#xff0c;包含同步MySQL库、ODPS库、本地盘及多盘性价比实例以及自建集群上云的迁…摘要社区ClickHouse的单机引擎性能十分惊艳但是部署运维ClickHouse集群以及troubleshoot都不是很好上手。本次分享阿里云数据库ClickHouse产品能力和特性包含同步MySQL库、ODPS库、本地盘及多盘性价比实例以及自建集群上云的迁移工具。最后介绍阿里云在云原生ClickHouse的进展情况。
在2023云数据库技术沙龙 “MySQL x ClickHouse” 专场上阿里云数据库ClickHouse技术研发刘扬宽为大家分享一下《阿里云数据库ClickHouse产品和技术》的一些技术内容。 刘扬宽阿里花名留白从事数据存储与数据处理系统研发十余年先后在中科院计算所中国移动苏州研发中心参与存储系统研发。2019年加入阿里云参与内部产品的存储计算分离的架构升级。在云原生ClickHouse的研发中承担存储模块的负责人根据计算层访问存储系统的特点有针对地优化了存储系统提升了云原生ClickHouse的整体性能。 本文内容根据演讲录音以及PPT整理而成。 首先来说我们的ClickHouse是在2019年中旬开源的。虽然开源时间较晚但它的上升势头非常迅猛。我们可以看到在DB-Engine的关系型数据库类目中ClickHouse排在第28位相比去年上升了29位。在DB-Engine的趋势图中红色曲线表示ClickHouse的增长情况。右侧是GitHub上的Star数可以看到虽然ClickHouse开源时间较晚但相比其他同类型的分布式数据库其热度排名遥遥领先。 让我们来看看社区版ClickHouse的系统架构。如前面的嘉宾所介绍ClickHouse是一个Sharding架构。对于集群版的ClickHouse实例来说首先需要创建分布式表并在分布式表上定义Sharding key。数据将被下载到不同的计算节点上并通过节点副本、复制同步机制来保证数据的高可用性。
接下来让我们来看看查询的链路。用户在查询数据时必须使用分布式表并将查询分发到某个查询节点。查询节点会解析分布式表并找到对应的本地表确定集群分布式表下载到哪些节点上并将查询发送到这些节点上。然后每个节点都会进行本地计算并将中间结果返回给Push节点。最终Push节点将所有中间结果进行汇总并返回给用户。这就是ClickHouse上的分布式查询。 ClickHouse提供了多种表引擎其中Meterialized MySQL主要使用ReplacingMergeTree进行去重操作而MergeTree系列是其主打的就是表引擎。此外其他的聚合表引擎都是通过后台合并数据根据自定义的合并逻辑进行聚合运算并不断地聚合数据。因为已经在后台完成了合并所以直接查询这些数据的效率更高。
在ClickHouse的其他社区生态或数据同步系统中创建这些外部表引擎有利于从其他系统同步数据到ClickHouse。右侧的SQL示例展示了ClickHouse用户需要创建的本地表和分布式表其中本地表必须包含排序键。另外如果没有指定分区键它将默认将整个表作为一个分区。用户可以根据某些字段的时间属性或其他属性指定数据的生命周期并告知系统哪些数据可以移动到冷存储或删除。
包括这个tbl可以作用于某些列对这些列进行生命周期管理。例如当数据到达某个确定的状态时可以对其进行更高级别的压缩。在ClickHouse中我们有多个节点的分布式实例必须定义分布式表并指定Sharding key。默认的话就是随机的rand Sharding key。 开源的ClickHouse它的高性能以及高可用分布式存储主要是从这些方面去实现的。首先它的高性能读取在数据存储时它会根据排序键有序地存储数据。然后索引是组建的轻索引它是Block级别的大粒度索引所以在分析场景上是比较适合的。但是ClickHouse对于点查询来说它的性能并不是很好。
ClickHouse具有高吞吐量主要体现在能够支持多点写入并且建议用户进行攒批写操作。它采用LSM树的结构进行写入数据会被有序地写入到磁盘中因此写入吞吐量接近于IO带宽。另外ClickHouse采用P2P架构并支持多种Sharding策略。在示例中展示了rand任意表达式的一种策略。用户也可以根据业务需要选择基于group by或哈希的策略将不同的数据分布到不同的节点上有利于进行分布式查询中的join或log ajj操作。此外ClickHouse支持后台异步执行的Delete和Update操作。
此外由于ClickHouse采用了纯列存储的方式因此具有高压缩比同时支持多种压缩算法。
ClickHouse实现高可用性的方式是通过设置任意数量的副本。内部数据同步是通过JK协调实现的副本之间可以进行多点写入和多点查询这是基于内部复制机制实现的。此外ClickHouse支持不同数量的副本数以适应不同Sharding策略的需求。 ClickHouse是专门为OLAP设计的一种存储引擎。它的底层存储格式是基于MergeTree的逻辑二维表其中每行对应一个或多个数据目录下的PART数据块。在data目录下会有许多索引文件包括primary key index和其他索引文件。对于每个列都有一组对应的数据文件.bin和数据索引文件.mrk。因此每个数据块block的格式如下命名规则为Part名称、Block ID、MergeLevel和Mutation Version如果存在。
在读取数据的过程中系统会根据主键(private key)的索引(index)构建对应要读取的mrk文件的偏移量(offset)。接着根据命中的具体列和该列对应的mrk文件定位到文件的偏移量(offset)最终读取目标的数据块block。这个数据格式可以在互联网和相关材料中找到一些可供解析的内容参考。 这张图可以看出就是ClickHouse因为这个存储格式的设计所以它在写入的时候它的那个写入带宽是非常高的。 ClickHouse在分析场景上的性能非常高这归功于以下几点原因。首先它进行了针对硬件的优化采用了多线程模型能够让多机多核充分发挥CPU的性能。其次它采用了向量化执行并使用了很多Codegen和SIMD指令从而提高了向量化处理的性能。此外它的列存特点使得它非常友好于CPU-Cache。最后它的C代码在设计重构上也进行了很多优化处理了许多细节。
在分析场景上ClickHouse拥有许多近似算法、抽样方法、丰富的数据类型和支持窗口函数的功能。此外它还具备查询队列和资源隔离的特点虽然在这方面的表现相对较弱。
ClickHouse具有预先建模的能力主要体现在用户可以根据底表创建物化视图。这些物化视图可以定义为一些聚合MergeTree在后台不断地进行合并根据建模的逻辑结构在后台进行一些计算。这种建模方式能够大大提高前台查询的速度。 这张图可以看出ClickHouse在许多场景下都有细致的设计。例如它在不同的场景中提供了聚合算子而这些算子针对不同类型的数据提供了不同的计算逻辑。
比如说对于物理数据根据不同的数据大小或物理特性可以采用不同的聚合算子。此外它还可以自适应地使用不同的函数来处理不同的数据量。例如对于唯一键的转换如果数据量较小、中等或超大规模它会选择不同的函数进行处理。
然后他在不同大小的一个内存使用上它也会使用不同的内存分配函数去做做内存分配。 ClickHouse的查询性能非常快。例如在处理一百亿行数据时它可以执行UV操作这种性能非常可观。 这里就是ClickHouse跟同类型的分析型数据库的性能对比这是官网公布的一个PK的数据查询速度还是很快单表过滤分组聚合查询优势显著。 在这张图中我们可以看到 ClickHouse 在灰盒测试中的数据结果。这份测试数据是比较早期的来自 2020 年使用的是 2019 版本。通过时间上的对比我们可以发现 ClickHouse 在灰化之后查询速度是 Vertica 的两倍多。这里也是对Greenplum是不同版本和不同节点的一个比较。
然后这里是具体的一个性能数据他是把get的数据集打包成了一个大宽表。接下来我们也将会介绍ClickHouse的性能表现。需要注意的是在Join场景下ClickHouse的性能相对较弱。但是在大宽表的查询性能上是非常高ClickHouse表现非常出色这个是有目共睹的。 然后再看一下我们社区ClickHouse版对有很多客户用上来之后有以下这些痛点他的写入是有一些限制他推荐你要聚合bach要高频的并发小粒度写。然后它的那个数据一致性是保证数据最终一次性就是修改完就会立即可见这个可见是指我那个多副本之间它的数据全部是保证最终一致性的如果是单机上你去写完他返回提交成功你是可以立即查的。然后它支持那个支持Delete/Update但是异步生效的。而它不支持事务最新版的这个ClickHouse社区版只支持part写入原子性。然后它需要后台的合并来保证主键的唯一性。
ClickHouse在计算层次的限制这个join不是他的优势需要根据不同场景修改SQL进行专门的优化。此外其优化器是否支持CPU优化也有待考虑。用户接口不够友好创建表时需要同时建立本地表和分布式表查询时只能查询分布式表这些细节增加了用户使用ClickHouse的学习成本和困惑。此外ClickHouse的建表习惯与大部分数据库不同并且其数据类型与MySQL有较大差异。此外ClickHouse采用sharding架构存储和计算不分离因此在弹性扩展容时缺乏弹性能力。
第三点是运维方面的限制。ClickHouse相当于手动挡因为其运维不够友好。在扩缩容时数据不会自动re-balance。在副本失败时需要手动重建或恢复。此外数据迁移工具也缺乏实时性不支持备份恢复的功能。对于修改配置有些设置不能持久化生效需要手动修改配置文件或重启server。ClickHouse的调优和运维难度较高需要用户具备一定的技术能力。因此很多用户需要亲自查看源码并使用最新的C标准开发而开发者相对较少C代码量也较大门槛很高。 接下来进行第二部分阿里云数据库的产品简介。阿里云数据库产品定位是为最快最便宜的列式数据库它在极致性能最极低成本、简单灵活的架构、便捷的运维等这几个目标上去主打场景化的最佳解决方案。 我们的主打场景是海量数据分析业务包括大宽表查询和数据hash对齐的join场景等功能这些功能虽然有很多限制但能够满足大部分用户的需求。同时我们的批量更新和删除操作与其对应的part的key是有无关联能够减少后续的更新和删除操作的开销提高性价比特别是对于那些对性价比比较敏感的用户来说。 这份表格对比了阿里云数据库ClickHouse和开源ClickHouse在运维、数据生态专家支持以及内核研发等方面的差异。我们发现在运维方面阿里云的ClickHouse提供了可视化的创建和实际管理集群的功能而自建则只能手动部署。在Failover方面我们的系统具备管控任务流能够自动监控处理异常情况或自动拉起失败节点。容灾备份方面阿里云数据库ClickHouse也提供了备份恢复功能。在安全性上我们支持日志审计、白名单、RAM授权等功能并提供公网SLB和阿里云云网络等安全保障措施。另外我们也支持通过SQL进行参数修改并提供词典管理控制台上可以直接操作。我们还提供完善的监控和多指标报警体系能够对慢SQL进行分析。
在水平或扩缩容节点方面我们可以自动迁移数据。目前我们已经实现了数据无需锁写的迁移并在切换SLB时进行了短暂的切换。在用户权限管理方面我们支持对支持RAM子账号授权。此外在数据生态和数据接入方面我们支持阿里云内部的DMS, SLS, DTS, DataWorks, OSSMysQL外表、ODPS、Kafka这些数据可以从这些系统中同步到ClickHouse行查询分析。我们还提供了专家服务支持为用户业务提供设计和优化建议以及对问题的快速处理。
在内核研发方面我们关注社区版本的更新对bugfix及时响应问题以及在前后兼容的情况下建议用户升级。在内核优化方面我们的分层存储已经在可分离MPP架构的功能上实现同时也可以在我们的云产品上体验到。这就是开源自建会有很多的的用户痛点。 我们阿里云ClickHouse的冷热分层主要优势在于成本。可以提供更高性价比的查询分析引擎。用户在创建表时可以告诉系统数据生命周期的关键字段然后后台会根据这些信息将Data part的数据移至冷盘、OSS或HDD上。这样相较于全部存储在ESSD上整体成本将大幅降低。
在我们的存储设计中针对用户进行数据过滤时产生的大量索引文件和小文件我们也进行了一些优化。我们使用本地盘作为小文件的缓存cache这样在执行许多查询过滤操作时不会直接访问到OSS从而提高查询分析性能。同时我们访问OSS采用流式的IO其吞吐量可达到200 MB至1 GB的带宽这个带宽接近或超过ESSD而成本仅为ESSD的1/10。
对于存储在OSS上的数据主备节点共享一份存储数据。在存储与计算分离的架构中ClickHouse采用存储磁化并按量计费。在计算节点数量方面我们是实现了按需扩容。 第三部分我们将继续介绍阿里云ClickHouse的重要功能特性。主要内容包括数据同步工具、多盘存储以及自建ClickHouse如何迁移到云端的工具介绍。 在本文中我们将介绍如何在阿里云ClickHouse中创建从MySQL库同步到ClickHouse的任务。首先在RDS控制台上选择分析实例并进入到相应的界面。在此界面上填写RDS或MySQL的用户信息。接下来在页面上勾选需要同步的库和表然后点击“创建同步任务”。完成这些操作后我们便可以在控制台上看到同步任务的状态。
对于习惯使用SQL创建任务的用户可以参考页面右下角提供的SQL示例创建MeterializeMySQL并配置同步表的白名单或黑名单以及其他设置。具体的配置信息可在阿里云的官网文档中查阅。
创建并启动同步任务后系统将首先进行全量同步随后进行增量同步。这样用户便可以在ClickHouse中查询同步过来的表并进行相关的数据分析任务。 如果用户在阿里云的ODPS上有大量数据而ODPS无法进行查询分析或运行批处理等非实时查询引擎任务那么可以在ClickHouse中创建ODPS外表。接着通过使用insert into select语句从ODPS外表同步数据到ClickHouse。完成同步后便可以在ClickHouse中进行查询分析。 我们将介绍阿里云ClickHouse产品它是一款主打性价比的解决方案。该产品支持用户购买本地盘这里有和高效云盘和ESSD在规格和价格上的对比分析。我们可以看到HDD的成本要比高效云盘低一半而ESSD的费用是本地盘的六倍多。但使用本地盘也存在一定问题即数据与计算是强绑定的如果本地盘损坏可能会有数据丢失的风险。
然而对于一些用户在存储日志或纯监控场景中或者允许数据丢失的产品场景它们可以接受这一限制。此外有些用户对读写带宽有较高要求而单个ESSD盘的ClickHouse在IO方面存在限制。阿里云的ClickHouse支持用户购买多个云盘或本地盘组成一个RAID零也可以在ClickHouse配置中组建一个结构底层使用LVM从而提供多盘聚合带宽能力。 在多盘性价比方案中我们提供了冷温热三层的分层存储。下面是一个分层存储的架构示意图。当数据需要立即写入时我们会先将其写入云盘ESSD中以便快速合并。然而一段时间后或者当达到特定的TTL时数据会被移动到本地盘。最后如果时间更长数据会被移动到OSS上。因此我们提供了三种不同的分层存储组合以满足不同的使用场景。例如将云盘与OSS组合使用可以实现冷热分层根据TTL进行归档进冷存。而将云盘与本地盘组合使用则可以实现冷温分层将最近N天的频繁查询TTL存储到本地盘中。我们将根据用户的实际业务场景选择最适合的冷温热组合。 如果用户已经存储了大量数据在自建集群中但在使用过程中遇到了前文提到的运维困难和其他无法解决的问题那么可以考虑使用阿里云ClickHouse。我们提供了一个方便的迁移工具其主要原理是解决数据实时同步的问题。但是数据同步可能存在一个问题即原有的实例集群会在后台不断地合并Data Part如果我们在这里捕捉到了数据有可能在后面就会被合并掉。例如我开始追踪一个Part并读取它但当我要同步这个Part时它源头的集群已经将这两个Part合并成了一个这样我就找不到了。为了解决这个数据同步问题我们提供了一个配合Pass Log的方案。 Pass log是我们刚才介绍的一个功能通过该功能我们可以将几个后台的数据进行合并以实现数据的整合。当我们开始同步数据时只同步了其中的一部分即SD1的部分。如果后续需要读取整个合并后的大part我们可以通过追踪part log来了解它是由哪些原始part合并而成的。这样我们就可以直接同步所需的part保证数据的一致性。同时我们还可以将源头part之外的数据删除以确保数据的完整性。 我们的迁移工具名为cksync相较于社区提供的clickhouse-copier工具cksync在语言、资源占用、上手使用、并发模型、write-lock-free以及临时表机制等方面都有其独特的特点和优势。左侧是我们工具的命令行参数列表。 接下来我们将介绍云原生ClickHouse的技术演进的第四部分主要介绍存储计算分离方案以及多计算组。 阿里云云原生ClickHouse采用的架构与第一位嘉宾介绍的ByteHouse类似首先解决了存算分离的问题即数据存储与计算节点解耦。我们的方案是将数据存储在OSS上源数据存储在FDB上并在worker节点上设置了OSS的Cache使用本地盘作为Cache以降低直接访问OSS的网络开销。此外我们采用中心化的controller协调查询命中查询先传递到controller由具体的查询computer worker再将其转发然后controller进行查询计划的生成和数据前期的filter过滤再将要扫描的数据以及执行计划发送给computer worker最终查询结果返回给用户。为了实现读写分离我们将数据的写入和后台合并工作线程分别用不同的服务进程处理从而使计算节点完全无状态。 这张图详细介绍了ClickHouse的存算分离方案。在ClickHouse中这个方案是在抽象的ID层实现的类似于虚拟文件系统中的存算分离。 在那个弹性计算组上我们主要解决的是节点计算资源水平扩缩容的问题。我们可以动态地增加计算节点由多个节点协调所有计算查询任务最后将结果汇总给发起节点并返回查询结果。
为了解决不同业务或多租户之间相互影响的问题我们使用多计算组实现资源隔离。用户可以在控制台上秒级创建并部署计算资源以响应用户的快速查询和大数据量处理从而避免影响常规业务。 OK我今天的分享就到这里。
本次大会围绕“技术进化让数据更智能”为主题汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的6位数据库领域专家深入 MySQL x ClickHouse 的实践经验和技术趋势结合企业级的真实场景落地案例与广大技术爱好者一起交流分享
