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 架构
CubeFS 架构中模块非常多,整体上由元数据子系统(Meta Node)、数据子系统(Data Node)和资源管理节点(Master)以及对象网关(Object Node)组成,可以通过 POSIX/HDFS/S3 等接口访问存储数据。其中,数据子系统分为两部分,一个是子系统副本,另一个是纠删码 EC 存储。
今年,CubeFS 还计划推出一个分布式缓存系统,以满足公有云的加速需求,预计未来会在 CubeFS 架构中发挥比较大的作用。
上图是在论文中 CubeFS 和 Ceph 做的性能对比,去年 OPPO 内部也做过一个类似的对比,基本可以保持类似的水平。大家总会有疑问,文件系统为什么没有本地磁盘快?其实这是因为文件系统、块存储都有网络开销,并且它还有元数据的管理,鱼与熊掌不可兼得。但 CubeFS 在随机写和顺序写上都有一定优势,并且在小文件写性能方面更明显一些。
CubeFS 特性
CubeFS 具有众多特性,特别重要的有以下几个方面:
**多协议。**CubeFS 原生的是 POSIX 接口,大家一般以挂载的形式,像本地盘一样去使用,无需额外的文件系统。它本身是一套共享系统,与块存储有一定区别。可以多客户端共享文件,同时也支持海量元数据存储。此外,CubeFS 还支持 S3 和 HDFS 等多种访问协议,这些协议间访问可互通。例如你在 POSIX 写入数据,可以在 S3 读取, 或在一些其他的内部业务场景读取,这样会更方便些。
**双引擎。**CubeFS 支持多副本及纠删码两种引擎,用户可以根据业务场景灵活选择。
多副本存储引擎:副本之间的数据为镜像关系,通过强一致的复制协议来保证副本之间的数据一致性,用户可以根据应用场景灵活的配置不同副本数。
纠删码存储引擎:纠删码引擎具备高可靠、高可用、低成本、支持超大规模(EB)的特性,根据不同 AZ 模型可以灵活选择纠删码模式。如前面所讲,纠删码子系统是一个独立的存储子系统,具备完备的接入,内部调度存储,以及数据管理。它不仅仅可以接受 CubeFS 的数据写入,也可以应用到其他系统的接入。它可以以多 AZ 的形式进行部署,能够节省一定的成本。相对多副本子系统,虽然它是基于 CPU 计算,数据流的读取性能跟多副本相比有些差异,但是它的成本有更大的优势,更多用的是 HDD 磁盘存储。
混合云场景下 AI 业务加速
AI 是目前比较火的场景,CubeFS 可以为混合云场景下的 AI 业务加速。其实像 OPPO 这样的大型企业,在 GPU 资源紧张的情况下,也会使用一些公有云存储。通常算法比较容易迁移,但数据出于保密需要往往存储到大后方,这样就带来一个问题,公有云到私有云之间存在网络延迟。效率比较低下的情况就造成了计算资源的浪费,基于这种情况,需要考虑做一些数据的迁移,但消耗还是非常大。在这种情况下,OPPO 给 CubeFS 做了一个一级加速,将热点数据和元数据都缓存到客户端,客户端用 GPU 做相应的训练,读取这个节点。在第一次读取的时候,数据会相应加载上来。后续这样反复的读取场景,就可以直接从本地读取,不需要跨网络。未来,公有云肯定是一个比较重要的场景,CubeFS 推出分布式缓存可以解决单节点的存储限制。有一些 AI 模型的语料可能需要更大的空间,单节点需要不断地扩展空间,分布式缓存利用多节点可以有效解决这样的限制。
QoS 流控
OPPO 在内部部署 CubeFS 时,多业务客户端请求可能存在 LPS 突发的情况,这会影响到其他业务。所以在多业务场景中需要一个中央流控管理机制,上图右侧管理节点中的 QoS manager 就是这样的方案。那么如何与端侧的 QoS manager SDK 进行通讯及流量分发?首先它是一个自适应的流控系统,当你起了一个多线程多任务,这个流控系统可以给相应的多任务节点分配更多的流量。有时系统中会存在网络抖动,流控系统可以把 Master 节点分配的流量给到客户端节点。如果客户端消耗不了,就需要 master 节点动态获取客户端的数据情况,适当调大流量的上限,这样就能够满足整个业务的带宽需求。这套系统也可以外接其他存储系统,为后面的混合云做准备,形成一套自适应的,能够控制多种存储介质的流控系统。
POSIX 接口原子性
接口原子性是解决分布式环境下,数据分布不同节点操作时出现异常的场景。有人可能会觉得原子性和事物很像,但原子性与事物并不完全相同,事物需要一个快照形式,需要不同的数据存储,CubeFS 的原子性可以做到以最小的代价恢复数据。
回收站
回收站是今年推出的一个新特性,解决了很多用户误删误操作的痛点。CubeFS 对数据有比较好的恢复支持,通过把数据放到子目录下的 trash 文件夹存储一定时间来保障数据安全,在这个时间范围内的误删除数据都可以找回。
上图是 CubeFS 正在开发中的一些重点特性。短期内会推出的 3.40 版本有两大特性,一个是自动化迁移,包括磁盘的外盘自动迁移,副本异常的自动修复。第二个特性是快照的卷目录级别的快照,这会以一个开发实验版本的形式推出。
唐德义:CubeFS 对象存储关键设计及应用
对象存储是 CubeFS 的一个子系统,它对外提供兼容 S3 的协议,其他业务接入时可以直接用 S3 的 SDK 访问对象系统 object node。对象存储的 Bucket 相当于文件系统中的 volume 概念,它会定期从 master 资源管理节点拉卷的状态信息。同时,CubeFS 在读写时支持冷卷和热卷,热卷是写三副本,直接写到 data node 中;冷卷通过 blob stor SDK 的方式写到子系统,写完还会把元数据记录下来,存到 Meta node 中。
CubeFS 对象存储服务的基础能力
前面说到 Bucket 等同于 volume,那 object 就对应着存储的文件。基于语义转换,CubeFS 天然可以做到 POSIX 和 S3 接口协议的数据共享。CubeFS 对象存储服务保留了文件系统中原有的 dentry/inode 概念,将文件系统中的目录结构呈现为对象的元数据的平铺结构,天然同时支持“扁平”和“层次”命名空间管理的设计。
使用对象存储服务,人们会比较多地用到分段对象管理功能。相对于普通上传,分段对象管理可能要更复杂一点。它重点分为三个步骤,第一步是初始化分片,第二步是上传具体的每一个分片,最后一步是分段对象的合并。
QoS 刚才在文件系统中讲过,S3 中其实也支持这样的能力。在存储引擎看来,无论是 data node 还是 Blob store,都没有租户的概念。但对象存储是基于 Bucket 和租户概念对外提供服务的,可能会出现租户或者 Bucket 资源抢占问题,这就需要做到访问资源的隔离。
首先是对外接入节点的单机流控。Object node 会限制单节点的连接数,避免连接数过多,S3 过载;第二个是多租户之间的隔离,不同租户之间的流控策略可以是不一样的;第三是租户内部。租户内部又可分为多种流控类型,比如某些业务 IOPS 比较高,QoS 流控就可以适当放宽一点。有些流业务可能是大对象,对于这种流量型的,业务可以用带宽流控,避免影响到其他业务。
CubeFS 对象存储服务的高级特性
上图是目前 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 可靠性也达不到要求,可能就会通过跨区域复制的方式,给两个地域之间的数据做同步容灾。
这是 CubeFS 对象存储的未来规划。S3 重点功能的演进包括数据、磁盘缓存、对象多版本能力、混合云管理和数据处理能力。
吴炳锡:存算引擎架构实践,Databend + CubeFS
AI 时代,数据是新质生产力,也是 AI 的第一战场。而海量数据意味着海量存储与海量计算。Databend 遇到的很多用户都是因为需要大量的计算, 需要用到几万个核心,成本非常高。在海量数据下,如果只是单纯把它存起来,Data node 用量会非常大,但 CPU 和内存并不会打满。如果想做海量计算,其实是非常有挑战的。
而另一方面,现在 x86 服务器 CPU 和内存都非常便宜,很多国产服务器内存 1T 都很正常,NVME 3T 起步,SATA 盘几十 TB 也比较常见,单机容量轻松可以达到几百 TB。
在私有化部署场景中,我们发现很多部署 S3 对象存储的公司,有着大量空闲的计算和内存资源。而 Databend 的计算存储分离架构可以充分地利用这些计算资源,如果客户本身有容器化的建设能力和规模化管理能力,就可以部署 Databend 来支撑整个计算任务。
Databend 的定位是一个云原生数仓,在创立之初就将对象存储作为存储层 ,这样带来的好处是可以做到按需付费,同时也不用考虑副本的概念。你只要付出普通盘八分之一的价格,就可以享受到云上多 AZ 的容灾能力,基本上不用再担心数据会挂掉。此外,它也提供数据加密功能,所有数据都是直接加密的。
在对象存储支撑方面,Databend 支持了包括 S3、Blob、MiniIO、HDFS、IPFS 在内的 20 多种对象存储协议,并且将这种能力开源了一个 OpenDAL 项目,捐给了 Apache 基金会,现在已经成为 Apache 毕业项目。很多金融公司、大企业都在使用 OpenDAL 做对象存储的访问。
在 Databend 的架构中放弃了分区理念,基于微分区,一个 block 100 到 200 M,并且在压缩之后,可以达到 10M 左右大小的文件,一份数据可以被多个集群访问。
在与很多客户的交流中,我们发现客户经常遇到一些问题。比如有的客户环境中有十几个网关,遇到问题想查日志非常困难,用 ES 搞的话最多能查 15 天内的,想回溯基本不可能。还有做审计的客户,MySQL 日志动不动一天上百 TB,如果遇到问题想要查询基本很困难。
Databend 解决问题的方式是通过 Databend 加对象存储,去处理海量的数据计算,可以轻松完成上亿或者百亿级别数据的计算。目前,Databend 用户中已经有单表过到万亿级别,压缩后还能达到 PB 级别,没压缩的话可能有十几 PB。在这样的存算分离架构下,你基本不用担心容量的问题,而且现在对象存储价格非常便宜,只需要付出普通盘八分之一的价格。
用 Vector 收集网关日志
上图是我们近期遇到的一个用户场景,一个 S3 的网关应用,大概十几台机器,每天大概 2 亿+的访问量。用户反馈现在慢了,一个具体的访问异常也要在 10 多台机器上找日志, 很难了解资源的现状。我们就想知道哪个 Bucket 访问 大,都有什么在访问它。虽然对象存储本身有每个桶的访问量统计,但是想拿出一个整体视图级别的统计就做不到。我们当时建议用户把日志直接加载到 Databend 里分析,整个过程可以达到秒级,可以查出来哪些 Bucket 每天的访问量多少,每个小时的访问量多少,每五分钟的情况是什么样子。很快就定位到有哪些不该出现的访问。
这是一个蛮常见的场景,通常的架构包括数据收集获取,收集完进入 Kafka,再做数据清洗,清洗后再进 ES 或者 ClickHouse,后面再接 Kibana 进行数据分析。这个流程需要画一个非常复杂的架构图,
但现在利用 Databend+CubeFS 以一个简单化的架构就可以搞定。
Vector 从前端采集完数据后,把数据转写到一个 Bucket 里面,Databend 从这个 Bucke 里面把数据加载过来,加载完就可以做一些 SQL 方面的请求和分析报表的过程。Vector 是 Data Dog 公开的一个高性能、灵活、易于配置的开源日志收集组件,用于收集、处理和传输日志、指标和事件数据。它也是基于 Rust 写的,并且也使用了 OpenDAL 来访问对象存储 。利用这套方案,亿级别或者几十亿级别的日志数据分析,基本都是秒级完成。
关于存算一体的思考,推荐大家阅读上图中链接的文章。这篇文章时间很早,当时正处于互联网的 web2.0 阶段,我经常有个疑惑,架构师到底要做什么?如何把一个程序能够做到更健康、更健壮?看到这篇文章后茅塞顿开,文中提出了七个观点:按功能分割,按水平切分,避免分布式事务,异步策略解耦程序,将过程转变为异步的流,虚拟化所有层,适当使用缓存。
现在的存算分离,其实还是在虚拟化所有的层, 它可以把你的功能层化虚拟化更好地拆分,更好地扩容,甚至做功能拆分, 做到不同的服务访问不同的集群,这都属于存算分离中的一些点。当你把这些东西理解透后,你会发现存算分离是存算一体的基础。
版权声明: 本文为 InfoQ 作者【Databend】的原创文章。
原文链接:【http://xie.infoq.cn/article/6e687fb95d7eff6d85519e77b】。文章转载请联系作者。
评论