SKhynix：存储即计算 OASIS 加速数据分析

阅读收获

• 理解计算存储如何通过近数据处理（Near-Data Processing）突破I/O瓶颈，掌握将SQL操作下沉到存储层的核心设计思路
• 认识到数据感知（CSD理解数据结构）是计算存储从“块操作”升级到“对象处理”的关键，Substrait和Apache Arrow在其中扮演了标准化桥梁角色
• 看清计算存储从OCS 1.0到OASIS的演进路径——从单一控制器计算到前端、设备级、驱动器级的三级资源池化
• 掌握评估计算存储方案的两个核心指标：数据移动量压缩比（MB→KB）和端到端加速比（4x+）

全文概览

在高性能计算环境中，数据分析正面临前所未有的挑战。你是否想过，当科学家们运行一次复杂的模拟分析时，实际上有多少数据在“无效移动”？Google的数据显示，其核心服务的I/O操作占据了总执行时间的30%到40%——这意味着近一半的计算资源被浪费在了数据搬运上。

更严峻的是，全球数据量正从2010年的2 ZB爆发式增长到2025年的预计181 ZB。如果继续沿用“计算归计算、存储归存储”的传统架构，数据移动将成为整个系统最大的性能瓶颈。

那么，是否可以让存储设备“学会”处理数据？在FMS25峰会上，一项名为OASIS的研究成果给出了答案——通过将数据感知型计算存储设备（CSD）集成到对象存储系统中，实现了查询执行的下沉。测试结果表明，该方案不仅将分析速度提升了4倍以上，更将数据移动量从兆字节级压缩到了千字节级。

这是否意味着“存储即计算”的时代正在到来？

👉 划线高亮 观点批注

1. 数据分析系统的挑战 指出HPC中数据分析的四大核心问题：过度读取、数据量持续增长、数据移动导致的计算与I/O负担加重，以及非必要数据移动造成的性能瓶颈。

2. Google端到端执行时间分解 图表显示，BigQuery、Spanner与BigTable三大服务的查询中，I/O耗时占比突出，约占总执行时间的30%至40%（图中高亮区域）。

3. 全球数据量快速增长 柱状图呈现2010至2025年数据总量趋势：从2010年的2 ZB 预计增长至2025年的181 ZB，巨大橙色箭头强调了这一近乎指数级的上升态势。

核心目标： 利用计算存储技术，在数据本地执行查询，最大限度减少数据移动。

1. 传统数据分析架构： 计算与存储分离。查询在计算系统执行，需从存储系统（如SSD阵列）大量读取数据，造成显著的 "I/O瓶颈" 与 "大规模数据移动"。

2. 基于计算存储的数据分析架构： 将 "查询执行" 下沉至 "计算存储系统"。数据在存储端完成过滤与计算，仅将精简后的分析结果传输至主机，从而实现 "减少数据移动"。

右侧 的架构示意图让我想起前两年大数据技术领域很火的“算子下推”概念，即大数据领域已经实现过在软件架构层面将搜索、排序等前置动作下沉到存储节点，而计算型存储是从硬件上的系统设计。

左侧对比图：数据无关 vs. 数据感知 (Data-agnostic vs Data-aware)

• 数据无关 (Data-agnostic)： 传统的计算存储只能看到底层的“块 (Block)”，无法理解数据结构。它需要不断的交互来获取 LBA (逻辑块地址) 和数据结构等信息。
• 数据感知 (Data-aware)： 这种模式能直接识别“对象”。应用端只需告知数据标识符（ID、Key、名称等），存储端就能直接理解并处理这些具备结构化特征（如姓名、电话等示例数据）的对象。

右侧架构图：基于对象的计算存储 (OCS) 系统 展示了数据如何在三层架构中流动：

• Client (客户端)： 最顶层，负责发起请求。
• OCS Frontend Server (前端服务器)： 中间层，起到承上启下的作用。
• OCSA Appliance (计算存储设备)： 最底层，直接连接 SSD 阵列。
• 核心组件： 每一层都内置了 Substrait（用于统一查询规划）和 Apache Arrow（用于高效的内存列式格式）。
• Object Pass-through (对象透传)： 图片展示了一个贯穿三层的垂直蓝色通道，表示对象数据可以透明地在各层间传递和处理。

图片展示了从“盲目处理块数据”到 “智能处理对象数据” 的技术演进。

• 技术协同： 通过 Apache Arrow 提供高性能内存数据格式，以及 Substrait 提供标准化的查询描述，解决了计算下沉时的兼容性问题。
• 抽象层级提升： 将存储接口从低级的块地址（LBA）提升到了高级的对象（Object），使存储系统能够“理解”它所存储的内容。
• 系统化架构： 建立了一个从客户端到存储硬件的端到端 OCS 系统，实现了真正意义上的数据感知计算，从而更高效地支持存储内分析。

图片的主要观点是实现了全路径的计算卸载与资源池化：

• 从单点到全面： OASIS 不再仅仅依赖 OCSA 控制器的计算能力，而是通过集成 Data-aware CSD，将计算能力进一步下沉到颗粒度更小的磁盘内部。
• 智能动态调度： 通过整合前端、设备级和驱动器级的所有可用资源，OASIS 能够更从容地应对“大规模并发分析请求”，解决了 OCS 1.0 中计算资源受限的瓶颈。
• 垂直整合： 这是对前一张图中“数据感知”理念的深化，将 SQL 查询卸载（SQL Offloading）真正贯穿到了存储系统的每一个神经末梢。

=== 左右架构框图对比了能力升级：

• OCS Version 1.0 (左侧)： 由 OCS Frontend 和 OCSA 组成，计算资源集中于 OCSA 控制器，面对多并发分析请求时能力受限。
• OASIS (右侧)： 引入“利用可用计算资源”机制，在 SSD 层新增 Data-aware CSD。分析任务（放大镜图标）可同时在 OCS Frontend、OCSA 和 Data-aware CSD 三层并行执行。

图片展示了 SK hynix 研发的硬件级解决方案，标志着计算存储从软件定义向专用硬件实现的落地。

• 真正的“存储即计算”： 该驱动器不仅是存储介质，更是一个微型分析引擎，能读懂 Parquet 对象并直接执行 SQL 逻辑。
• 标准化集成： 通过采用 Substrait（统一查询语言）和 Apache Arrow（统一内存格式），该硬件可以无缝集成到现代大数据生态系统中。
• 性能优化： 通过在驱动器内部完成数据过滤和聚合，仅输出极小体积的 Arrow 结果集，最大限度地利用了单盘带宽并释放了主机 CPU 压力。

图片展示了 OASIS 系统的协同计算艺术：

• 层级解耦与分工：它不再让单一的 CPU 负担所有工作，而是根据计算复杂度和数据量，将 SQL 操作分配到最合适的层级执行。
• 效率最大化：遵循“数据过滤在底层，复杂逻辑在高层”的原则。底层的 CSD 通过 Filter 和 Projection 极大地减少了向上层传输的数据量，而顶层的 Presto 则专注于无法下沉的复杂函数处理。
• 全栈并行：通过这种垂直优化，系统形成了一个从磁盘到引擎的完整流水线，显著提升了大规模数据分析的吞吐量。

===

图片将系统自上而下分为四个主要层级，并展示了各层负责的典型操作：

• 分析引擎层 (Analytics Engine Layer)：
  • 硬件/软件：由 Presto 引擎组成，配备 CPU 和 RNIC。
  • 负责操作：用户自定义函数 (User Defined Function)。这是逻辑最复杂、最接近用户的部分。
• 前端层 (Frontend Layer)：
  • 硬件：OCS Frontend 节点。
  • 负责操作：连接 (Join)。负责处理来自不同存储节点的数据关联逻辑。
• OCSA 层 (OCSA Layer)：
  • 硬件：OCSA (Object-based Computational Storage Appliance) 设备层。
  • 负责操作：聚合 (Aggregate) 和 排序 (Sort)。在设备端对汇总的数据进行初步加工。
• CSD 层 (CSD Layer)：
  • 硬件：最底层的 Data-aware CSD (数据感知型计算存储驱动器)。
  • 负责操作：过滤 (Filter)、投影 (Projection) 和 子查询 (Sub Query)。这是最靠近数据源的一层，负责剔除无关数据，只向上层传递必要的信息。

图片的主要观点是展示了 OASIS 架构在实际 HPC 场景下的强大拆解能力：

• 精准减负：通过将最耗资源的数据扫描和初步过滤（红色部分）卸载到 Data-aware CSD，极大减少了向上层传输的数据量。
• 逻辑下沉：原本需要在计算引擎中完成的 JOIN 等操作被成功下沉到 OCSA 设备层，实现了存储内部的分布式计算。
• 标准化流程：证明了利用 Substrait 可以将复杂的工业级 SQL 查询透明地转换为跨层级的硬件执行计划，实现了从软件定义到硬件加速的闭环。

图片通过数据确立了 OASIS 系统在存储技术领域的领先地位：

• 量级的突破：相比传统方式，OASIS 不仅将执行速度加快了 4 倍以上，更通过 Data-aware CSD 的近数据处理能力，将数据移动量从“兆字节级 (MB)”压缩到了“千字节级 (KB)”。
• 架构演进的验证：从 OCS 到 OASIS 的性能阶梯（2.4x 4.1x）清晰地证明了利用全系统计算资源和集成数据感知硬件的必要性。
• 实际应用价值：在处理如科学模拟等海量 Parquet 数据时，OASIS 能够有效解决带宽瓶颈，让分析效率产生质的飞跃。

• HPC 环境下的挑战：在高性能计算（HPC）环境中，数据分析往往需要从存储节点向计算节点传输远超必要的数据量，从而导致了严重的过度数据移动问题。
• 解决方案——OASIS：针对上述低效问题，该方案提出了计算存储（Computational Storage）。通过将数据感知型 CSD（Data-aware CSDs） 集成到基于对象的计算存储系统（OASIS） 中，显著增强了近数据处理能力。
• 标准化需求：为了实现计算存储的广泛部署，标准化至关重要。这不仅包括 SSD 硬件层级的标准化，还包括应用程序与存储软件栈之间，以及计算节点与存储节点之间的全面标准化。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

• 计算存储的全面落地需要哪些层面的标准化努力？硬件接口、软件协议、应用生态，谁才是决定成败的关键？
• 数据感知型CSD在处理非结构化数据（如日志、图片）时，是否会遇到与结构化数据不同的技术挑战？
• OASIS架构能否与现有的Presto、Spark等大数据引擎无缝集成？这对企业的技术选型意味着什么？

原文标题：Vertical query optimization using Data aware CSD for data analytics[1]

Notice：Human's prompt, Datasets by Gemini-3-Pro

#FMS25 #xPU卸载与计算型存储

---【本文完】---