三星Zero-ETL：计算下沉存储，告别数据搬家

数据存储前沿技术

发布于 2026-04-02 10:44:19

1040

阅读收获

洞悉NDP如何将Spark ETL卸载到存储端，实际降低网络I/O 瓶颈，实现TCO下降30%。
掌握三星DSS架构演进路径，从分离式超融合到RDMA-S3，指导AI/ML负载的存储选型。
理解混合云下数据主权痛点，通过zETL下推核心IP算法，确保隐私安全同时利用云DWH。
量化Zero-ETL在高密度场景的优势，为证券分析提供三星存储方案的投资逻辑。

全文概览

在大数据和AI时代，海量数据如洪水般涌来，你是否还在为传统ETL流程中数据反复跨网络传输的I/O瓶颈和天价TCO买单？三星Zero-ETL架构横空出世，以“近数据处理”（NDP）为核心，将计算任务直接下沉到存储层，避免了从S3或EFS拉取数据的低效搬迁。想象一下：原本需要16个昂贵Spark Executor节点的集群，如今只需1台瘦计算服务器，就能让底层“胖存储”（双路48核EPYC+512GB内存）高效完成清洗、过滤甚至ML计算。这不仅仅是硬件升级，更是范式转变——从“计算拉数据”到“数据找计算”。文章通过架构对比和量化收益（性能+40%、成本-30%），揭示了在混合云场景下，如何兼顾数据主权与云端弹性。面对AI训练中35%的Opex被数据传输吞噬，你准备好拥抱这种颠覆了吗？

👉 划线高亮观点批注

大数据时代的处理架构中，计算和存储分离，数据需要通过ETL流程将分散的、异构的原始数据（Extract）提取出来，借助强大的分布式计算框架（如本图强调的 Apache Spark）进行数据的清洗和处理（Transform），最后统一存储（Load）到目标数据仓库中。

整个流水线的最终业务目标是打通数据孤岛，为企业的数据分析（Analytics）和商业智能（BI）提供高质量、结构化的数据支撑。

在 Samsung Zero-ETL 架构下，传统上极为消耗网络带宽的“数据抽取（E）”和“数据转换（T）”过程，不再需要将庞大的数据集搬移到上层独立的计算集群（如 Spark）中执行。相反，这些计算任务被直接下推到了数据所在的底层存储层。这种“让计算靠近数据”的设计，从根本上消除了大量数据在存储网络中的来回传输，能够显著降低网络延迟、减少 I/O 瓶颈，并大幅提升数据流水线整体的执行效率与性能。

图片系统地阐述了近数据处理（Near Data Processing, NDP）存储架构的开发者生态、技术控制手段及其带来的商业价值。

易用性与生态: 为数据工程师（ETL开发者）提供了一个高度优化的框架（特别是针对对象存储），使得将计算任务“卸载”到存储端变得标准化。
灵活性与可编程性: 通过标准的 REST API，用户不仅可以编排复杂的数据流，还能完全自定义要在存储端执行的具体计算逻辑。
显著的成本效益: 通过践行“计算找数据”的 NDP 理念，避免了海量数据的无效搬迁，从而节省了网络带宽成本，并减少了对外部昂贵计算集群的依赖，最终实现整体拥有成本（TCO）的显著降低。

图片通过直观的拓扑架构对比，硬核地展示了 Samsung Zero-ETL（基于计算型存储/近数据处理）相比于传统云原生大数据架构（AWS EMR + EFS）在硬件部署上的巨大差异与优势。

传统架构的痛点 (存算分离导致的资源浪费): 左侧的基准架构代表了典型的“存算分离”。为了处理底层 EFS 中的数据，需要部署庞大且昂贵的独立计算集群（1个大 Master 节点 + 16个大 Executor 节点）。这不仅硬件成本高（TCO 高），而且海量数据需要在 EFS 和 16 个节点之间来回传输，造成严重的网络 I/O 瓶颈。
Zero-ETL 架构的颠覆 (胖存储、瘦计算): 右侧的架构中，独立的计算层被大幅削减（从 16 个物理计算节点缩减到仅 1 台服务器运行 4 个 Executor）。之所以能做到这一点，是因为底层的存储节点被赋予了企业级的服务器算力（双路 48 核 EPYC CPU + 512GB 内存）。
技术结论: 三星的方案将传统的“计算拉取数据”变为了“算力下沉到存储”。因为数据清洗和转换工作直接在拥有强悍算力的底层存储节点内完成了，上层就不再需要维持庞大的、昂贵的 Spark 集群，完美呼应了“节省 TCO”和“减少数据传输”的技术主张。

反映出现代AI数据堆栈与经典冯诺依曼计算架构的冲突。在高密度数据处理场景，因传输带宽产生的数据传输成本已经使经典计算架构不堪重负。

图表从左至右展示了架构的四个演进阶段，右下角的图例解释了三个关键工作负载图标：绿色文档代表合成数据 (Synthetic Data)，青色原子代表 ML 计算单元 (ML Compute units)，红色漏斗代表数据过滤 (Data Filtering)。

初始状态 (最左侧未标号框): 传统的 AWS 云原生架构。计算层（Spark集群）在最上方，中间是 AWS EMR 计算实例，底层是标准的 Amazon S3 存储（蓝色圆柱体）。此时，所有的数据生成、过滤和 ML 计算图标都悬浮在存储层之上，意味着庞大的数据必须通过网络拉取到计算层处理。
阶段 1 (Disaggregated Hyperconverged object storage - 分离式超融合对象存储): 引入了 DSS (Disaggregated Storage) 架构，分为 DSS Host 和 DSS Target + zETL。底层存储硬件替换为带有计算能力的黑色固态硬盘节点。
阶段 2 (Offload Synthetic Data Generation and Filtering - 卸载合成数据生成与过滤): 观察图标移动，红色的“数据过滤”和绿色的“合成数据”生成任务，被成功**下推（Offload）**到了底层的“DSS Target + zETL”存储目标层中执行。
阶段 3 (Offload ML Compute Functions near to data - 将 ML 计算功能卸载到靠近数据的位置): 青色的“ML 计算单元”图标也随之下沉到了底层的存储目标层。此时，核心计算任务已实现“近数据处理”。
阶段 4 (S3 over RDMA): 在算力下沉的基础上，进一步优化网络协议，采用基于 RDMA（远程直接内存访问）的 S3 协议，以极低的延迟和极高的吞吐量连接 Host 和 Target。

===

图片是一张极具说服力的技术落地与商业价值论证图，它不仅提出了理念，还给出了具体的实施路径和量化收益。

明确了“数据重力”是 AI/ML 时代的昂贵负担： 在海量数据训练中，单纯在网络中搬运数据的成本已经吃掉了过多的利润（35% 的 Opex）。
提供了清晰的“计算下推”落地路线图： 通过四个阶段，展示了如何将数据过滤、数据合成甚至机器学习的计算功能，一步步从上层昂贵的 Spark 计算集群剥离，卸载（Offload）到具备近数据处理能力的底层智能存储（DSS Target + zETL）中。结合 RDMA 技术，彻底打通了性能任督二脉。
用数据证明了 Zero-ETL 的绝对优势： 针对高强度计算场景（如土壤水分计算），相比传统的 AWS EMR 存算分离架构，三星的 Zero-ETL 架构在数据规模剧增时表现出极强的性能韧性，最终实现了 “性能提升 40% 的同时，成本下降 30%” 的双赢局面。

图片展示了一个典型的基于混合云（Hybrid Cloud）架构的数据仓库/数据湖屋部署模型，并详细说明了三星 DSS 和 Zero-ETL 技术在其中的关键作用。

其核心观点是解决数据主权、隐私安全与云端算力利用之间的矛盾：企业出于安全或合规考虑，将核心业务数据（采用 Parquet+Iceberg 格式）保留在本地数据中心（On-prem）。通过引入三星的 DSS 高性能存储和 zETL 技术，企业可以利用云端（Cloud）强大的 DWH 引擎进行查询调度。最关键的突破在于，云端可以将计算逻辑（甚至包含企业核心 IP 的机器学习算法）以二进制形式“下推（Offload）”到本地存储端执行。这不仅大幅节省了跨云专线（Direct Connect）的昂贵网络带宽，实现了近数据计算，还确保了企业的敏感数据和核心算法绝不出本地机房，完美兼顾了云的弹性和本地的安全性。

当下热议的数据资产，因主权和隐私安全门槛而一直无法利用，主要门槛即数据面临域外ETL过程，如果大数据行业和硬件厂商能够统一近数据处理的API/协议规范，未来基于意图的ETL过程下沉到域内，数据资产的盘活和利用就会规范很多。