分析型数据库如何创新

    在群雄逐鹿的 OLAP 数据库市场，开源引擎 ClickHouse 凭借其出色的性能成为公认的黑马。官方称其性能超过了市场上同类的列式数据库，每台服务器每秒可处理数亿到超过十亿行、体积达数十 GB 的数据，运行速度比传统数据库快 100-1000 倍。
  高效运行速度的另一面，还隐含着成本、性能、容量等诸多问题，比如不支持事务，不能够保证数据的一致性和完整性，不存在隔离级别，不支持高并发等等。这导致 2016 年开源的 ClickHouse 难以应对当下更加复杂，数据规模更加巨大的场景需求。

  比如在字节内部，从 2018 年引入 ClickHouse，因为业务的发展，要服务于大量的用户，数据规模变得越来越巨大。由于 ClickHouse 是 Shared-Nothing 的架构，每个节点是独立的，不会共享存储资源等，因而计算资源和存储资源是紧耦合的。这导致扩缩容成本变高，且会涉及到数据迁移，不能实时按需的扩缩容，从而导致资源的浪费。此外，ClickHouse 的紧耦合的架构会导致多租户在共享集群相互影响，另外由于读写在一个节点完成，导致读写受到影响，最后 ClickHouse 在复杂查询上例如多表 join 等的性能支持并不是很好。
    字节 ClickHouse 使用情况 为了解决这些痛点，字节在 ClickHouse 架构基础上进行了升级，于 2020 年在内部启动了 ByConity 项目，并于 2023 年 1 月发布 Beta 版本，将于 5 月底正式对外开源。

  ByConity 是一个开源的云原生数据仓库，采用存储 - 计算分离的架构。它支持多个关键功能特性，如存储计算分离、弹性扩缩容、租户资源隔离和数据读写的强一致性等。通过利用主流的 OLAP 引擎优化，如列存储、向量化执行、MPP 执行、查询优化等，ByConity 可以提供优异的读写性能。

  ByConity 的架构分为三层，如下图所示，服务接入层包含负责客户端数据和服务的接入，也就是 ByConity Server；计算组为 ByConity 的计算资源层，每个 Virtual Warehouse 是一个计算组；数据存储层由分布式文件系统，如 HDFS、S3 等构成。
ByConity 三层技术架构图 除了兼备 ClickHouse 的一些优点外，ByConity 还实现了了诸多新的功能。

  ByConity 的一个重要优势是 存储 - 计算分离的架构，它实现了读写分离和弹性扩缩容。它的优势是高弹性和高扩展性。这种架构确保读操作和写操作不会相互影响，使得计算资源和存储资源解耦，两者可以按需的且独立的扩缩容，确保资源高效利用。此外，ByConity 支持多租户资源隔离功能，保证不同租户之间不会互相影响，使 ByConity 适用于多租户环境，如图 2。
  ByConity 存储 - 计算分离，实现多租户隔离 ByConity 支持 弹性的扩缩容，能够实时、按需的对计算资源进行扩缩容，保证资源的高效利用。并且它能对不同的租户进行 资源的隔离，租户之间不会受到相互影响。其另一个重要功能是 数据读写的强一致性 ，确保数据始终是最新的，读写之间没有不一致。此外，ByConity 采用了主流的 OLAP 引擎优化，例如列存、向量化执行、MPP 执行、查询优化等，来保证提供了 优异的读写性能。

  之所以采用开源的模式，ByConity 项目组是希望能够把项目回馈给社区，同时也希望通过社区的力量加强和完善 ByConity。接下来，ByConity 在 2023 开源社区发展规划中，希望增强 ByConity 的功能、性能和易用性，重点关注开发新的存储引擎、支持更多的数据类型和与其他数据管理工具的集成领域。

        责任编辑：彭菁