云原生数据分析正朝着分离计算与存储的方向快速演进。公共云的数据湖和对象存储提供了大规模、低成本的持久化能力,但也带来了越发显著的延迟问题,尤其是在处理交互式在线分析处理(OLAP)场景时。为了解决延迟瓶颈,许多云数据库采用了查询下推(query pushdown)技术,将简单过滤、投影等操作下放到存储层执行,从而减少跨网络传输的数据量。然而,当对象存储使用纠删码(erasure coding)来节省空间并提高可靠性时,传统的查询下推受到严重限制。Fusion 提出了一套协同设计方案,通过在纠删码构造和文件放置拓扑上做出有针对性的优化,让查询下推在纠删码环境中同样高效可用,从而显著降低延迟并保持接近最优的存储效率。 查询下推与纠删码的冲突本质源于存储对象的物理拆分方式。
现代对象存储经常将大文件切分为固定大小的块(block),然后对块进行纠删码条带化分布到不同存储节点上。若需要读取对象中某个小范围的数据,存储系统往往仍需跨多个节点重新组装条带,从而触发额外的网络开销与高尾延迟。即便下推只涉及读取对象中少量的"可计算单位"(例如 Parquet 文件的行组或列页),条带划分的不当会导致这些单位被跨节点分散,从而破坏了下推的延迟优势。 Fusion 的核心思想是协同优化纠删码条带构造与对象内部的可计算单元布局。设计目标包括最大化单节点或少节点可完成的下推计算、避免可计算单位被条带化过程碎片化、以及在不显著增加存储冗余的前提下提升读取效率。为此,Fusion 提出了一种新的条带构造算法和文件放置策略,使得常见的列式分析格式(例如 Parquet)的行组或页级结构能够作为完整的可计算单元被保留在单个或少数节点上,从而在执行过滤、投影等操作时只需读取更少的数据和更少的节点。
在条带构造上,Fusion 不再仅基于固定大小的块进行简单划分,而是将文件的逻辑可计算边界纳入条带划分决策。例如,对于 Parquet 文件的 RowGroup 或 ColumnChunk,Fusion 优先将这些边界对齐到条带边界,避免跨条带切割产生的碎片。与此配合,Fusion 设计了可变宽度条带分配策略,允许条带跨越不同大小的逻辑单元,从而在保证纠删码恢复能力和并行性的同时,显著减少查询下推时需要参与计算或传输的条带数目。 文件放置拓扑的协同设计是 Fusion 的另一关键。传统对象存储往往采用均匀散布策略将条带片(stripe chunk)分配到所有节点,以获得负载均匀性和高可靠性。但对于查询下推场景,需要考虑访问局部性:将相关的可计算单位放在相对有限的节点集合中,可以在下推时减少跨集群通信。
Fusion 将文件内部的相关页或列紧密放置在同一条带或同一节点组,并通过机架感知与拓扑感知的放置策略,兼顾性能与可靠性,避免单节点或机架故障导致的数据不可用风险。 纠删码参数选择在 Fusion 设计中同样扮演重要角色。常见的 Reed-Solomon 类纠删码提供了很好的存储效率,但在恢复和读取路径上可能需要从更多节点聚合数据。Fusion 基于查询模式分析与统计信息建议合适的纠删码配置,使得在常见小范围读取时仅需访问有限的条带片,从而降低延迟并减少网络流量。为了进一步优化,Fusion 还探索了局部可修复码(locally repairable codes)以及混合冗余策略,在不同温度数据上采用不同的纠删码参数,以在性能与空间效率间取得平衡。 Fusion 的条带构造算法背后结合了离线分析与启发式在线调度。
系统在文件写入或对象导入阶段分析文件格式的元数据(例如 Parquet 的 RowGroup 大小、列统计信息、索引),据此确定最佳的条带边界与放置位置。对于现有对象,Fusion 提供了在线重布局机制,在不影响可用性的前提下将文件的条带重排到更适合查询下推的拓扑。此外,Fusion 支持与计算层的协同:查询引擎可以把过滤条件与列选择信息告知对象存储层,使得存储侧可以更精确地判断哪些条带需要参与计算,从而避免不必要的数据读取和网络传输。 在评估中,Fusion 在常用的 TPC-H 基准测试上展示了显著的延迟与尾延迟改善。论文报告显示,相较于现有纠删码对象存储,Fusion 在中位延迟上提升约64%,在尾延迟上提升约81%。在真实 SQL 查询负载上的实验表明,Fusion 的中位与尾延迟分别可提高约40%和48%。
这些改进源于两个方面:首先,条带与可计算单位对齐使查询下推可以在更少节点本地完成;其次,拓扑敏感的放置策略减少了跨机架或跨节点的数据重组需求。令人关注的是,这些性能提升并非以高额的存储开销换取,Fusion 在论文中声称只带来了约1.2%的额外存储开销,相较于最优纠删码配置几乎可以忽略不计。 实际部署 Fusion 需要考虑与现有云对象存储生态的兼容性。Parquet、ORC 等列式格式在数据湖中普及,为 Fusion 的可计算单元定位提供了天然基础。对于使用 S3 接口的存储系统(如 AWS S3、MinIO、Ceph RGW),Fusion 的设计可以通过在网关或对象存储后端集成条带构造逻辑实现。对于深度依赖特定纠删码实现的系统,需要将 Fusion 的条带策略与底层纠删码配置相结合。
许多开源对象存储(如 Ceph)和云供应商都支持自定义纠删码配置,因此在工程上具备可行性。 从系统工程角度看,Fusion 也考虑了写入性能、恢复与故障处理机制。条带对齐和特定放置策略可能在写入路径引入额外的组织成本,但 Fusion 采用批量化与异步重排技术将这些开销摊薄。故障恢复方面,Fusion 保持与现有纠删码恢复流程的兼容,当节点或机架失效时,系统依然可以利用纠删码信息进行重建。为减少重建期间对查询性能的影响,Fusion 还支持优先级调度与后台重构策略,确保在线查询的稳定性。 在安全与多租户场景下,Fusion 的放置优化需要与访问控制隔离机制配合。
为了避免针对特定租户的数据热点集中在少数节点带来风险,系统可以对放置策略引入最小散列约束与跨租户隔离策略。同时,审计和加密等功能同样适用于 Fusion 的存储布局,保证数据保护不因性能优化而受到削弱。 尽管 Fusion 在论文中展示了强有力的结果,但在实际商业化推广时仍有若干挑战。首先,不同用户的查询模式多样,如何在通用性与针对性之间取得平衡是核心问题。Fusion 倾向于针对交互式、高选择性查询进行优化,但对于大规模全表扫描或写密集工作负载的场景,其收益可能有限。其次,云供应商的底层实现差异也会影响 Fusion 的可移植性。
某些托管对象存储对底层条带与放置策略并不开放,导致无法直接部署 Fusion 的完整设计。最后,系统需长期维护并跟随文件格式演进(例如 Parquet 和 Arrow 的更新),以保证优化策略持续有效。 展望未来,Fusion 的思想为面向分析的对象存储开辟了新的方向。随着云数据库对延迟敏感性的增强,存储层必须从单纯提供字节服务转向与计算协同优化。进一步的研究可以探索自动化的查询模式识别与自适应条带重构,使系统根据实时负载动态调整纠删码参数和放置策略。结合智能网络设备和 DPU(数据处理单元)等近存计算能力,还可以把部分下推逻辑前移到更靠近存储介质的位置,进一步压缩延迟。
对企业工程团队而言,评估 Fusion 风格的优化需要从数据格式、查询分布、故障模型与合规约束等多维度出发。首要步骤是分析现有查询日志与数据访问模式,识别高频率的选择性查询和受益最大的数据集。随后,可以在小范围或冷数据上试验条带对齐与放置策略,度量延迟、吞吐与存储开销的变化。与云供应商协作或选择开源对象存储后端进行深度集成,将有助于充分发挥技术优势。 总的来看,Fusion 提供了一条具有现实意义的路径,解决纠删码对象存储环境中查询下推的性能瓶颈。通过把文件格式语义纳入条带构造、通过放置拓扑提高局部计算能力,并在纠删码参数上做出面向查询访问模式的选择,Fusion 在不牺牲可靠性与存储效率的情况下,为交互式分析负载带来了实质性的延迟改善。
随着云计算与数据湖生态的进一步成熟,这类存储与计算协同的设计将成为提升大规模数据分析性能的重要方向。 。
