供稿 | ByConity技术团队
出品 | CSDN 云计算
ByConity是一款字节跳动开源的云原生数仓引擎。它的一个重要优势是采用存储计算分离的架构，实现了读写分离和弹性扩缩容。这种架构确保读操作和写操作不会相互影响，使得计算资源和存储资源解耦，两者可以按需的且独立的扩缩容，确保资源高效利用，同时保证数据读写的强一致性。此外，ByConity支持多租户资源隔离功能，保证不同租户之间不会互相影响，更加适合多租户环境，同时ByConity采用主流的OLAP引擎优化，提供更加优异的读写性能。
一、ByConity技术背景
ClickHouse是一个开源的列式数据库管理系统，它采用Shared-Nothing的架构，这种架构有以下典型特点：
-
每个节点独立管理一部分数据
-
节点之间没有数据共享
-
存储和计算紧耦合
它的查询执行大致分为两个阶段。第一阶段是每个节点独立处理它管理的数据分片，负责I/O、查询和计算。第二阶段是Coordinator节点将第一阶段每个节点计算的结果进行默认汇总，然后返回给客户端。这种架构可以实现高性能和可扩展性，特别适合固定业务规模的情况下进行高并发查询。同时，由于节点之间无数据共享，扩展性也比较容易实现，可以实现线性扩展。
图 1 Clickhouse架构
但在实际使用过程中，我们发现如下问题：
-
扩缩容代价高：对于快速发展的业务，需要频繁进行扩容操作，而数据的reshuffle以及数据搬迁会影响实际读写操作
-
多租户之间可能会互相影响：不同业务之间可能会有不同的业务特征，导致某些业务在特定时间点上占用了整个集群的资源池，影响其他租户
-
读写操作受到影响：每个节点都必须负责一部分读写任务，当节点资源使用较多时，查询性能可能会受到影响
-
资源使用情况会存在浪费：特别是在多个中小型业务共用同一个集群的情况下，可能会存在资源预估不足或者其他情况导致资源浪费
二、ByConity架构介绍
基于以上使用过程中发现的问题，我们在开源的ClickHouse架构基础上进行了升级，引入了计算与存储分离的架构，将原本计算和存储分别在每个节点本地管理的架构转换为在分布式存储上统一管理整个集群内所有数据的架构，使得每个计算节点成为一个无状态的单纯计算节点，并利用分布式存储的扩展能力和计算节点的无状态特性实现动态的扩缩容。此外，该架构还支持多租户隔离和读写任务的分离。实现了以下优势：
-
高弹性、高扩展性：计算和存储独立扩缩容
-
多租户隔离：不同租户使用不同计算组
-
读写分离：读写使用不同的计算资源
存储计算分离架构
从总体架构上讲，ByConity的存储计算分离架构如图3所示，主要分为三层：共享服务层、计算层和云存储层。
-
共享服务层：主要组件是Cloud Service，是所有查询的入口，会对查询进行解析和优化，生成Query Plan然后下发给计算层处理。它同时相当于一个协调者的角色，负责一些服务、组件和事务的管理，也包含元数据的管理--Metadata Storage。
-
计算层：主要是计算资源组--Virtual Warehouse（简称VW） ，计算资源组件可以动态启停，包括一个 Read VW 和一个 Writer VW。在 Read VW 中，每个 Worker 节点都有一个 Optimizer 和 Runtime 模块，以及一个 Disk Cache 模块来缓存部分数据以减少对分布式存储远端系统的访问，热点数据存储在 Disk Cache 模块中。在 Writer VW 中，数据会先以 ClickHouse 格式写入本地磁盘--Local Disk，然后再批量写入分布式存储，以提高写入性能。
-
云存储层：是分布式统一存储系统，ByConity所有的数据都存储在这一层，在计算层进行查询时，会从云存储层中读取数据。云存储层的具体实现可以采用各种云存储服务，如HDFS、S3等。
除此之外，ByConity还包括一些共享的服务组件，如TSO、Daemon Manager、Resource Manager、后台任务和服务发现等组件。
图 2 ByConity存储计算分离架构
三、ByConity架构优势
资源隔离
在大数据场景下，资源隔离是非常重要的，它可以提高系统的资源利用率、性能、安全性、可靠性和灵活性，帮助企业解决诸多业务痛点问题，如：
-
避免不同租户之间的资源冲突，提高数据安全性和租户使用体验；
-
根据不同的业务场景需求分配不同的资源，提高资源利用率和性能；
-
提高数据安全性，通过隔离不同的数据处理任务或数据库实例，限制访问权限
-
实现弹性扩缩容，根据不同的业务和数据量需求动态调整资源分配；
-
提高系统的可靠性和稳定性，隔离故障，避免对整个系统造成影响。
但ClickHouse并没有对资源隔离做专门的设计，它是通过集群和replication的配置、load_balanding策略，以及指定本地表的写入做到一定的读写分离。对于冷热分离，ClickHouse是通过配置存储策略和使用TTL、TO DISK、TO VOLUME等技术实现。
ByConity通过存储计算分离的架构设计很好的实现了资源隔离，它引入了计算组（Virtual Warehouse 简称：VW）的概念，Virtual Warehouse是计算资源的虚拟组织，可以将计算资源按需划分为多个虚拟集群，在不同租户之间提供物理资源隔离。同时，把原本与计算资源耦合的存储统一到分布式存储管理后，计算资源与存储资源是完全解耦的且无状态的，从而计算节点主要承担的是计算任务，这些任务可以是数据写入、用户查询，也可以是一些后台任务。因此ByConity通过的部署和使用Virtual Warehouse来实现多级资源隔离：
图 3 ByConity计算组
-
租户隔离：ByConity 的Virtual Warehouse是无状态的，可以根据不同的业务和场景进行按需的创建，且每个Virtual Warehouse是独占系统资源，所以会很轻松的实现多租户的隔离。当然，为了提高资源利用率，ByConity也支持Virtal Warehouse之间的资源租借，实现资源共享。
-
计算资源隔离：Virtual Warehouse使得计算资源做到物理层面的隔离，且每个Virtual Warehouse可以包含多个 worker，可以被灵活创建。
读写分离
除了资源隔离外，我们还希望达到读写的分离，读写的分离是将读操作和写操作分别处理。因为在实际业务中，读操作和写操作对硬件资源的要求，以及时间的要求是不同的，所以我们希望用不同的硬件资源去执行读操作和写操作，避免读写互相影响，影响系统性能和浪费资源，具体好处如下：
-
降低存储成本：将读操作和写操作引导到不同的存储节点上，避免不必要的数据复制和冗余。
-
提高查询效率：将读操作引导到专门的读节点上，减少查询等待时间，从而提高数据处理效率和用户体验。
-
降低网络成本：将读操作引导到离用户更近的读节点上，减少数据传输的距离和网络成本。
-
提高系统可用性：将读操作和写操作分别引导到不同的节点上，当某个节点发生故障时，只会影响到该节点上的读或写操作，不会影响到整个系统的可用性
ByConity可以通过Virtual Warehouse实现读写分离，用户可以通过指定读操作和写操作使用哪个Virtual Warehouse，系统会自动将不同的读写请求转发。例如Insert操作使用专门用于写入的计算组，Select操作使用专门用于读取的计算组，读写作业之间不会相互影响。但由于ByConity使用了统一的分布式存储，必然会存在性能的问题，这里ByConity是通过本地缓存（Local Cache）去解决的。
本地缓存
对于大容量的本地缓存管理，ByConity使用Bucket-LRU算法，它是在LRU算法的基础上进行了优化，会将缓存中的数据块分为多个桶，每个桶中保存一定数量的数据块，并对每个桶使用LRU算法进行淘汰。这样可以将缓存中的数据块分散到多个桶中，从而降低了缓存淘汰的频率，同时也减少了LRU算法的开销。即使在计算组扩缩容等导致网络拓扑发生变化时，也依然使用这种机制，避免数据的reshuffling。
图 4 ByConity的缓存力度 Segment
-
针对缓存的粒度，ByConity引入Segment概念，如图4，它是一个介于文件为单位和压缩块为单位的一个缓存粒度，大小可配置，并且适合文件存储。Segment是由多个 Mark 组成的，每个 Mark 包含多个压缩块。当查询需要读取某个Segment时，可以先检查缓存中是否存在该Segment，如果存在，则直接从缓存中读取数据，否则需要从磁盘读取数据。在实际使用中，需要根据数据的特点和需求选择合适的缓存策略，并进行优化和调整，以达到最优的性能和效果。ByConity的缓存策略有以下几种：
-
按照Segment的访问频次：根据数据访问的频次来判断哪些数据是热点数据，并进行缓存。
-
按照Segment的访问范围：有些数据虽然访问频次不高，但是其查询范围较大，也需要被缓存。
-
根据数据更新时间来决定热点数据：对于实时表等场景，新过来的数据往往是热点数据，需要被缓存。
-
基于统计信息来优化缓存策略（开发中）：根据统计信息来决定哪些数据是热点数据，需要被缓存。
ByConity的本地缓存的主要目的是在分布式存储中，通过使用较少成本（容量）的本地高速缓存盘，来缓存数据以减少网络读取带来的性能延迟增加问题。本地缓存的使用可以提高数据的访问速度和响应速度，从而减少对网络的依赖，降低系统的延迟，提高系统的性能和稳定性。
无感扩缩容
随着业务数据翻倍增长，必须通过不断的扩容支撑业务发展，但在ClickHouse的基础上扩容的成本很高，这是因为ClickHouse从架构上没有专门考虑扩缩容，导致需要运维同学手动或者通过自动化脚本去创建新的ClickHouse节点和迁移副本数据来完成扩容，因此存在时间成本和迁移结果校验的问题。再者，在扩容中需要将新的分片部署到新的节点上，这会导致数据不再均衡，需要通过数据再均衡来解决。
ByConity的存储计算分离架构可以天然解决这个问题，能实现业务无感的扩缩容。ByConity扩容分为两种：一种是纵向扩容，即调整Worker的 CPU 核数和内存大小；另一种是横向扩容，通过增、减Worker的数量，提升系统并发能力。这些依然通过ByConity的Virtual Warehouse和Worker去实现：
-
一方面资源管理器（Resource Manager）负责对计算资源进行统一的管理和调度，能够收集各个计算组的性能数据，资源使用量，为读写任务和后台任务动态分配资源并进行扩缩容，提高资源使用率。ByConity 的组件都已经容器化，通过调整 Kubernets 的 replica 数量可以非常方便的对指定的计算组进行扩缩容。除此之外，还可以结合计算组资源使用量，通过设置 kubernets 的扩缩容阈值实现动态扩缩容。
-
另一方面，ByConity的元数据和数据存储在远端，计算节点的无状态化使扩缩容变得十分轻量，只需等计算实例启动完成，即可立即服务，无需额外的数据迁移开销，实现实时扩缩容。
四、ByConity使用场景
ByConity 使用大量成熟 OLAP 技术，例如列存引擎，MPP 执行，智能查询优化，向量化执行，Codegen, Indexing，数据压缩，主要用于 OLAP 查询和计算场景。在实时数据接入、大宽表聚合查询、海量数据下复杂分析计算、多表关联查询场景下有非常好的性能。
| 场景分类 | 场景 | 描述 | 特点 |
| 交互式查询 | 用户自定义查询 | 支持多维查询分析的数据应用 | 自由维度、多表关联、响应快 |
| 自助式报表 | 支持 Tableau 等 BI 工具 | 自由维度、多表关联、响应快 | |
| 用户画像分析 | 支持 DMP 等圈人画像平台 | 自由维度、多表关联、响应快 | |
| 营销效果分析 | 支持流量效果漏斗分析 | 多表关联、实时 | |
| 行为日志分析 | 支持日志探索分析 | 日志检索、数据量大 | |
| 实时数据看板 | 实时业务监控大屏 | 支持 DataV 等可视化大屏 | 实时 |
| 直播数据统计看板 | 支持实时报表 | 实时 | |
| 业务仪表盘 | 支持报表工具 | 统计、响应快 | |
| 系统链路监控 | 支持实时监控应用 | 实时 | |
| 实时数据仓库 | 实时数据接入 | 支持实时数据写入、更新 | 实时数据写入，立即可见 |
| 准实时 ETL 计算 | 支持复杂计算，数据清洗 | 混合负载 |
表 1
五、总结和展望
总结来说ByConity使用了存储计算分离的架构，且在多个方面进行了优化和升级，具有以下的优势和特性：
-
资源隔离：对不同的租户进行资源的隔离，租户之间不会受到相互影响。
-
读写分离：计算资源和存储资源解耦，确保读操作和写操作不会相互影响。
-
弹性扩缩容：支持弹性的扩缩容，能够实时、按需的对计算资源进行扩缩容，保证资源的高效利用。
-
数据强一致：数据读写的强一致性，确保数据始终是最新的，读写之间没有不一致。
-
高性能：采用主流的OLAP引擎优化，例如列存、向量化执行、MPP执行、查询优化等提供优异的读写性能。
图5是接下来ByConity未来发展规划图，未来我们计划从以下几个方面进行优化和改进：
图5 ByConity未来发展规划
-
支持分布式Disk Cache，一方面解决节点重启导致Local Cache丢失的问题，另一方面希望达到全局最优的Cache机制，提升Cache命中率。
-
支持外表服务，例如Hudi和Iceberg等文章来源：https://www.toymoban.com/news/detail-458998.html
-
支持存储服务化，在ByConity存储数据层上，利用Spark引擎或Presto引擎的计算能力执行一些ETL任务等文章来源地址https://www.toymoban.com/news/detail-458998.html
到了这里，关于开源云原生数仓引擎ByConity 存储计算分离架构和优势的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
