Meetup 回顾:存算引擎一体化建设

在大数据与人工智能时代，数据的生成和存储量呈指数级增长。企业面临着如何高效处理和分析海量数据的巨大挑战。在面对如此规模的数据时，数据库究竟该选择存算一体，还是存算分离架构？如何才能提升资源利用率、扩展性，降低运维成本，这是数据从业者都在思考的问题。

在第 20 期 Data Infra 研究社直播活动中，我们邀请到 Databend Labs 联合创始人-吴炳锡、OPPO 存储团队文件系统负责人, CubeFS Maintainer -常亮、OPPO 对象存储研发工程师, CubeFS ObjectStore 主要负责人-唐德义，围绕“存算引擎一体化建设”这一主题与大家分享相关知识。通过三位专家的分享，帮助大家深入理解了大数据时代的存算引擎设计与实践，以及 CubeFS 的架构、特性与实践，Databend 和 CubeFS 的应用等。*

内容大纲：

🙋 CubeFS 文件系统架构设计及应用

• CubeFS 的架构及特性

• CubeFS 在 OPPO 的机器学习等业务场景的落地情况

• 展望 CubeFS 后续的发展方向

🙋 CubeFS **对象存储**关键设计及应用

• CubeFS 的对象存储服务架构及关键特性

• S3 与 POSIX 语义兼容实现高效数据共享

• 对象存储的关键应用和 S3 新特性演进

🙋 存算引擎架构实践：Databend + CubeFS

• 理解存算一体架构的实构及应用，理解日志观测的场景

• 理解 vector 日志收集&加载到 Databend 的流程

• 演示 TPCH-100-SF 在 Databend + CubeFS 运行情况

• 存算分离和存算一体的一些思考

随着数据的爆炸性增长，云存储成为了企业和个人的首选。然而，选择一个安全、可靠、高效的云存储解决方案并非易事。在这个背景下，开源对象存储 CubeFS 应运而生，它以独特的优势和特点，正在重塑云存储的未来。

常亮：CubeFS 文件系统架构设计及应用

CubeFS 最初名为储宝 FS，是国内首个开源分布式存储系统。2019 年由京东捐赠给云原生计算基金会（CNCF）开源，并在 SIGMOD 上发表工业界论文。该论文核心观点是提出了分布式的元数据缓存，解决了当时文件系统的一些痛点，例如元数据的海量存储，查询性能，以及集中式存储带来的锁问题等等。

2021 年，OPPO 开始参与到 CubeFS 社区中，主导和推进了社区运营和版本迭代，并在内部做了大量的应用。2022 年，CubeFS 正式进入 CNCF 的孵化阶段。在此期间，CubeFS 一直在持续不断地进行迭代，补充了大量产品特性，例如对 S3、HDFS 等接口协议的补充，纠删码存储子系统，稳定性提升等等。直到 2023 年底，CubeFS 认为产品已经比较成熟，向 CNCF 提出了毕业申请。目前，CubeFS 已经进入社区资质审查的最后阶段。

CubeFS 架构

添加图片注释，不超过 140 字（可选）

CubeFS 架构中模块非常多，整体上由元数据子系统（Meta Node）、数据子系统（Data Node）和资源管理节点（Master）以及对象网关（Object Node）组成，可以通过 POSIX/HDFS/S3 等接口访问存储数据。其中，数据子系统分为两部分，一个是子系统副本，另一个是纠删码 EC 存储。

今年，CubeFS 还计划推出一个分布式缓存系统，以满足公有云的加速需求，预计未来会在 CubeFS 架构中发挥比较大的作用。

添加图片注释，不超过 140 字（可选）

上图是在论文中 CubeFS 和 Ceph 做的性能对比，去年 OPPO 内部也做过一个类似的对比，基本可以保持类似的水平。大家总会有疑问，文件系统为什么没有本地磁盘快？其实这是因为文件系统、块存储都有网络开销，并且它还有元数据的管理，鱼与熊掌不可兼得。但 CubeFS 在随机写和顺序写上都有一定优势，并且在小文件写性能方面更明显一些。

CubeFS 特性

CubeFS 具有众多特性，特别重要的有以下几个方面：

**多协议。**CubeFS 原生的是 POSIX 接口，大家一般以挂载的形式，像本地盘一样去使用，无需额外的文件系统。它本身是一套共享系统，与块存储有一定区别。可以多客户端共享文件，同时也支持海量元数据存储。此外，CubeFS 还支持 S3 和 HDFS 等多种访问协议，这些协议间访问可互通。例如你在 POSIX 写入数据，可以在 S3 读取， 或在一些其他的内部业务场景读取，这样会更方便些。

**双引擎。**CubeFS 支持多副本及纠删码两种引擎，用户可以根据业务场景灵活选择。

• 多副本存储引擎：副本之间的数据为镜像关系，通过强一致的复制协议来保证副本之间的数据一致性，用户可以根据应用场景灵活的配置不同副本数。

• 纠删码存储引擎：纠删码引擎具备高可靠、高可用、低成本、支持超大规模(EB)的特性，根据不同 AZ 模型可以灵活选择纠删码模式。如前面所讲，纠删码子系统是一个独立的存储子系统，具备完备的接入，内部调度存储，以及数据管理。它不仅仅可以接受 CubeFS 的数据写入，也可以应用到其他系统的接入。它可以以多 AZ 的形式进行部署，能够节省一定的成本。相对多副本子系统，虽然它是基于 CPU 计算，数据流的读取性能跟多副本相比有些差异，但是它的成本有更大的优势，更多用的是 HDD 磁盘存储。

混合云场景下 AI 业务加速

添加图片注释，不超过 140 字（可选）

AI 是目前比较火的场景，CubeFS 可以为混合云场景下的 AI 业务加速。其实像 OPPO 这样的大型企业，在 GPU 资源紧张的情况下，也会使用一些公有云存储。通常算法比较容易迁移，但数据出于保密需要往往存储到大后方，这样就带来一个问题，公有云到私有云之间存在网络延迟。效率比较低下的情况就造成了计算资源的浪费，基于这种情况，需要考虑做一些数据的迁移，但消耗还是非常大。在这种情况下，OPPO 给 CubeFS 做了一个一级加速，将热点数据和元数据都缓存到客户端，客户端用 GPU 做相应的训练，读取这个节点。在第一次读取的时候，数据会相应加载上来。后续这样反复的读取场景，就可以直接从本地读取，不需要跨网络。未来，公有云肯定是一个比较重要的场景，CubeFS 推出分布式缓存可以解决单节点的存储限制。有一些 AI 模型的语料可能需要更大的空间，单节点需要不断地扩展空间，分布式缓存利用多节点可以有效解决这样的限制。

QoS 流控

添加图片注释，不超过 140 字（可选）

OPPO 在内部部署 CubeFS 时，多业务客户端请求可能存在 LPS 突发的情况，这会影响到其他业务。所以在多业务场景中需要一个中央流控管理机制，上图右侧管理节点中的 QoS manager 就是这样的方案。那么如何与端侧的 QoS manager SDK 进行通讯及流量分发？首先它是一个自适应的流控系统，当你起了一个多线程多任务，这个流控系统可以给相应的多任务节点分配更多的流量。有时系统中会存在网络抖动，流控系统可以把 Master 节点分配的流量给到客户端节点。如果客户端消耗不了，就需要 master 节点动态获取客户端的数据情况，适当调大流量的上限，这样就能够满足整个业务的带宽需求。这套系统也可以外接其他存储系统，为后面的混合云做准备，形成一套自适应的，能够控制多种存储介质的流控系统。

POSIX 接口原子性

添加图片注释，不超过 140 字（可选）

接口原子性是解决分布式环境下，数据分布不同节点操作时出现异常的场景。有人可能会觉得原子性和事物很像，但原子性与事物并不完全相同，事物需要一个快照形式，需要不同的数据存储，CubeFS 的原子性可以做到以最小的代价恢复数据。

回收站

添加图片注释，不超过 140 字（可选）

回收站是今年推出的一个新特性，解决了很多用户误删误操作的痛点。CubeFS 对数据有比较好的恢复支持，通过把数据放到子目录下的 trash 文件夹存储一定时间来保障数据安全，在这个时间范围内的误删除数据都可以找回。

添加图片注释，不超过 140 字（可选）

上图是 CubeFS 正在开发中的一些重点特性。短期内会推出的 3.40 版本有两大特性，一个是自动化迁移，包括磁盘的外盘自动迁移，副本异常的自动修复。第二个特性是快照的卷目录级别的快照，这会以一个开发实验版本的形式推出。

唐德义：CubeFS 对象存储关键设计及应用

添加图片注释，不超过 140 字（可选）

对象存储是 CubeFS 的一个子系统，它对外提供兼容 S3 的协议，其他业务接入时可以直接用 S3 的 SDK 访问对象系统 object node。对象存储的 Bucket 相当于文件系统中的 volume 概念，它会定期从 master 资源管理节点拉卷的状态信息。同时，CubeFS 在读写时支持冷卷和热卷，热卷是写三副本，直接写到 data node 中；冷卷通过 blob stor SDK 的方式写到子系统，写完还会把元数据记录下来，存到 Meta node 中。

CubeFS 对象存储服务的基础能力

添加图片注释，不超过 140 字（可选）

前面说到 Bucket 等同于 volume，那 object 就对应着存储的文件。基于语义转换，CubeFS 天然可以做到 POSIX 和 S3 接口协议的数据共享。CubeFS 对象存储服务保留了文件系统中原有的 dentry/inode 概念，将文件系统中的目录结构呈现为对象的元数据的平铺结构，天然同时支持“扁平”和“层次”命名空间管理的设计。

添加图片注释，不超过 140 字（可选）

使用对象存储服务，人们会比较多地用到分段对象管理功能。相对于普通上传，分段对象管理可能要更复杂一点。它重点分为三个步骤，第一步是初始化分片，第二步是上传具体的每一个分片，最后一步是分段对象的合并。

添加图片注释，不超过 140 字（可选）

QoS 刚才在文件系统中讲过，S3 中其实也支持这样的能力。在存储引擎看来，无论是 data node 还是 Blob store，都没有租户的概念。但对象存储是基于 Bucket 和租户概念对外提供服务的，可能会出现租户或者 Bucket 资源抢占问题，这就需要做到访问资源的隔离。

首先是对外接入节点的单机流控。Object node 会限制单节点的连接数，避免连接数过多，S3 过载；第二个是多租户之间的隔离，不同租户之间的流控策略可以是不一样的；第三是租户内部。租户内部又可分为多种流控类型，比如某些业务 IOPS 比较高，QoS 流控就可以适当放宽一点。有些流业务可能是大对象，对于这种流量型的，业务可以用带宽流控，避免影响到其他业务。

CubeFS 对象存储服务的高级特性

添加图片注释，不超过 140 字（可选）

上图是目前 CubeFS 对象存储服务支持的 S3 高级特性：

**权限管控：**支持 Bucket Policy。该特性主要用在多用户之间的桶授权，或是桶公共读。比如某一个桶的一些对象，希望在互联网上的业务可以直接共享，这里就可以考虑 Bucket Policy。或者这个 Bucket 授权公共后可以有一些 CDN 缓存加速的，也可以用 Bucket Policy 公共授权。此外，该特性还支持 Bucket/Object ACL。其实 AWS S3 目前已经不太推荐用 Bucket ACL，因为它权限管控的策略某种程度上可以转化为 policy。但如果某些业务需要更细粒度的权限管控，比如桶里不同对象的权限管控粒度不一样，就可以用到 object ACL。

授权访问： 服务端生成好预签名，下载或者将上传链接下发给客户端，然后拿着链接上传或者下载就可以了。这样客户端不会感知你的 AK/SK，你也不会暴露 AK/SK。还有一种情况，手机端用的比较多的叫 STS token，可以基于你owner 的 AK/SK 和过期时间去生成一个临时的 STS token。 这个 STS token 权限非常小，只可以上传和下载特定的对象，并且是有效时间内的。

**Web浏览器：**如果希望在 Web 浏览器端访问 CubeFS，就会涉及到一个 CORS 跨域的访问问题。S3 本身就支持这种能力。

**数据保护：**去年 CubeFS 推出了对象锁定的功能，可以支持桶里面的某些对象在一定时间内不能被覆盖或者删除。对于需要归档的一些数据或一些合规数据可以用此功能。

通知机制：事件通知功能是正在做的，还没有正式发布的一项功能。你可以制定一些事件，比如上传事件，下载事件，分片上传，分片合并等，制定一些消息队列投递到里面，然后通过消息队列结果的方式，拿到这个事件。

**生命周期管理：**你可以配置这个桶某些目录的对象。比如希望 CubeFS S3 帮忙把这部分对象管理起来，某一段时间后清理掉。

**跨区域复制：**主要用在多集群的数据迁移，或是容灾备份的场景。CubeFS 部署架构是多数据中心，多 AZ 的，用户有些业务的数据要求特别高，觉得多地域，多 AZ 可靠性也达不到要求，可能就会通过跨区域复制的方式，给两个地域之间的数据做同步容灾。

添加图片注释，不超过 140 字（可选）

这是 CubeFS 对象存储的未来规划。S3 重点功能的演进包括数据、磁盘缓存、对象多版本能力、混合云管理和数据处理能力。

吴炳锡：存算引擎架构实践，Databend + CubeFS

添加图片注释，不超过 140 字（可选）

AI 时代，数据是新质生产力，也是 AI 的第一战场。而海量数据意味着海量存储与海量计算。Databend 遇到的很多用户都是因为需要大量的计算， 需要用到几万个核心，成本非常高。在海量数据下，如果只是单纯把它存起来，Data node 用量会非常大，但 CPU 和内存并不会打满。如果想做海量计算，其实是非常有挑战的。

而另一方面，现在 x86 服务器 CPU 和内存都非常便宜，很多国产服务器内存 1T 都很正常，NVME 3T 起步，SATA 盘几十 TB 也比较常见，单机容量轻松可以达到几百 TB。

在私有化部署场景中，我们发现很多部署 S3 对象存储的公司，有着大量空闲的计算和内存资源。而 Databend 的计算存储分离架构可以充分地利用这些计算资源，如果客户本身有容器化的建设能力和规模化管理能力，就可以部署 Databend 来支撑整个计算任务。

添加图片注释，不超过 140 字（可选）

Databend 的定位是一个云原生数仓，在创立之初就将对象存储作为存储层 ，这样带来的好处是可以做到按需付费，同时也不用考虑副本的概念。你只要付出普通盘八分之一的价格，就可以享受到云上多 AZ 的容灾能力，基本上不用再担心数据会挂掉。此外，它也提供数据加密功能，所有数据都是直接加密的。

在对象存储支撑方面，Databend 支持了包括 S3、Blob、MiniIO、HDFS、IPFS 在内的 20 多种对象存储协议，并且将这种能力开源了一个 OpenDAL 项目，捐给了 Apache 基金会，现在已经成为 Apache 毕业项目。很多金融公司、大企业都在使用 OpenDAL 做对象存储的访问。

在 Databend 的架构中放弃了分区理念，基于微分区，一个 block 100 到 200 M，并且在压缩之后，可以达到 10M 左右大小的文件，一份数据可以被多个集群访问。

添加图片注释，不超过 140 字（可选）

在与很多客户的交流中，我们发现客户经常遇到一些问题。比如有的客户环境中有十几个网关，遇到问题想查日志非常困难，用 ES 搞的话最多能查 15 天内的，想回溯基本不可能。还有做审计的客户，MySQL 日志动不动一天上百TB，如果遇到问题想要查询基本很困难。

Databend 解决问题的方式是通过 Databend 加对象存储，去处理海量的数据计算，可以轻松完成上亿或者百亿级别数据的计算。目前，Databend 用户中已经有单表过到万亿级别，压缩后还能达到 PB 级别，没压缩的话可能有十几 PB。在这样的存算分离架构下，你基本不用担心容量的问题，而且现在对象存储价格非常便宜，只需要付出普通盘八分之一的价格。

用 Vector 收集网关日志

添加图片注释，不超过 140 字（可选）

上图是我们近期遇到的一个用户场景，一个 S3 的网关应用，大概十几台机器，每天大概 2亿+的访问量。用户反馈现在慢了，一个具体的访问异常也要在 10多台机器上找日志， 很难了解资源的现状。我们就想知道哪个 Bucket 访问 大，都有什么在访问它。虽然对象存储本身有每个桶的访问量统计，但是想拿出一个整体视图级别的统计就做不到。我们当时建议用户把日志直接加载到 Databend 里分析，整个过程可以达到秒级，可以查出来哪些 Bucket 每天的访问量多少，每个小时的访问量多少，每五分钟的情况是什么样子。很快就定位到有哪些不该出现的访问。

这是一个蛮常见的场景，通常的架构包括数据收集获取，收集完进入 Kafka，再做数据清洗，清洗后再进 ES 或者 ClickHouse，后面再接 Kibana 进行数据分析。这个流程需要画一个非常复杂的架构图，

但现在利用 Databend+CubeFS 以一个简单化的架构就可以搞定。

添加图片注释，不超过 140 字（可选）

Vector 从前端采集完数据后，把数据转写到一个 Bucket 里面，Databend 从这个 Bucke 里面把数据加载过来，加载完就可以做一些 SQL 方面的请求和分析报表的过程。Vector 是 Data Dog 公开的一个高性能、灵活、易于配置的开源日志收集组件，用于收集、处理和传输日志、指标和事件数据。它也是基于 Rust 写的，并且也使用了 OpenDAL 来访问对象存储 。利用这套方案，亿级别或者几十亿级别的日志数据分析，基本都是秒级完成。

添加图片注释，不超过 140 字（可选）

关于存算一体的思考，推荐大家阅读上图中链接的文章。这篇文章时间很早，当时正处于互联网的 web2.0 阶段，我经常有个疑惑，架构师到底要做什么？如何把一个程序能够做到更健康、更健壮？看到这篇文章后茅塞顿开，文中提出了七个观点：按功能分割，按水平切分，避免分布式事务，异步策略解耦程序，将过程转变为异步的流，虚拟化所有层，适当使用缓存。

现在的存算分离，其实还是在虚拟化所有的层， 它可以把你的功能层化虚拟化更好地拆分，更好地扩容，甚至做功能拆分， 做到不同的服务访问不同的集群，这都属于存算分离中的一些点。当你把这些东西理解透后，你会发现存算分离是存算一体的基础。