《IEEE Access》：The Hidden Cost of Container Networking: CNI Overlay Throughput Constraints in Kubernetes-Managed Apache Spark Versus Native Hadoop MapReduce on Bare-Metal Edge Hardware
编辑推荐：
研究人员考察了将大规模数据处理框架从裸金属服务器迁移至云原生环境对系统性能的影响。具体而言，研究人员在200 GB TeraSort工作负载下，比较了部署于裸金属基础设施的传统Hadoop MapReduce与运行于Kubernetes上的Apache Spa
研究人员考察了将大规模数据处理框架从裸金属服务器迁移至云原生环境对系统性能的影响。具体而言，研究人员在200 GB TeraSort工作负载下，比较了部署于裸金属基础设施的传统Hadoop MapReduce与运行于Kubernetes上的Apache Spark。分析表明，Spark将整体执行时间缩短约4.5×。通过对CPU、内存、磁盘和网络组件的系统遥测（telemetry）检查，研究人员识别出导致该性能提升的硬件与软件因素。研究结果显示，Hadoop遗留架构因大量持久化磁盘写入导致CPU I/O等待状态延长；相比之下，Spark利用DDR5 RAM与操作系统页缓存减少对物理存储的依赖，维持近连续的用户态计算。然而，该内存处理引入了Kubernetes容器网络接口（CNI）的开销。尽管Spark消除了物理存储瓶颈，其软件定义网络Overlay限制了集群内数据混洗（shuffle），导致网络吞吐量大幅低于原生裸金属速率。研究人员得出结论：尽管云原生Spark在速度敏感任务上较传统MapReduce具有明显性能优势，但实现高吞吐需高带宽内存配置并部署内核级eBPF网络技术以缓解Kubernetes网络开销。
研究背景与动机
过去十年，工业4.0与边缘计算催生持续高容量异构数据流，大数据架构由单体Hadoop集群向存算分离、容器编排与内存计算演进。然而在资源密集的裸金属边缘硬件上，从YARN调度的Hadoop MapReduce迁移到Kubernetes托管的Apache Spark时，执行行为与资源瓶颈缺乏同硬件、同负载下的联合拆解。已有文献或抽象掉底层硬件，或只评估孤立组件，未见同时报告CPU等待分解、OS页缓存行为与CNI吞吐退化的综合对照。为此，研究人员在异构裸金属微集群上以200 GB TeraSort为负载，对legacy Hadoop/YARN栈与modern Kubernetes/Spark/MinIO栈做架构级teardown，回应RQ1（CPU I/O wait差异）、RQ2（VXLAN CNI相对裸金属网络吞吐惩罚）、RQ3（迁移硬件配置原则）。该文发表于《IEEE Access》。
主要技术方法
测试床为三台物理机映射四个逻辑节点，含AMD与Intel微架构，Ubuntu 24.04 LTS；传统栈用Apache Hadoop v3.3.6原生部署HDFS+YARN，云原生栈用Kubernetes v1.35.1配Flannel（vxlan后端）作CNI，Apache Spark v3.5.1以cluster模式跑executor pod，对象存储用MinIO，GPU设备插件不安装故计算全在CPU/DDR5。负载为TeraGen生成200 GB数据后TeraSort，单轮端到端执行；用dstat每5秒采CPU（usr/wai）、内存（used/cache）、磁盘、网络net/total聚合吞吐，做四层遥测分解。无样本队列，属工程基准测试。
研究结果
IV-A 整体执行时间：Spark完成200 GB TeraSort需505 s，Hadoop MapReduce需2310 s，加速4.5×。Spark峰值CPU约95%（近连续usr），Hadoop约85%且伴高wai；两者节点内存均用至~100 GiB/128 GiB。
IV-B CPU利用率：Hadoop时序中I/O Wait占比大，CPU频陷NVMe写停滞；Spark将中间RDD留DDR5与页缓存，usr态近连续，wai极低，印证4.5×来源。
IV-C 内存使用：Hadoop显式用存偏高（JVM开销），页缓存作写缓冲；Spark页缓存承载RDD只读工作集，应用内存与Hadoop相近但语义不同。
IV-D 磁盘I/O：Hadoop读写持续>2000 MB/s、峰值~3000 MB/s饱和NVMe；Spark读近零、写仅stage边界瞬发峰值~2900 MB/s（5 s采样）、均值371 MB/s，shuffle不落盘。
IV-E 网络流量：dstat net/total含同机loopback，物理跨节点受2.5 GbE限。Hadoop聚合收包单采样瞬峰~4000 MB/s（因中间数据多落本地盘）；Spark shuffle阶段持续发~500 MB/s，该持续天花板上限即CNI vxlan封装/解封+虚拟路由所致，回答RQ2约8×峰值落差。
讨论与结论翻译
讨论指出瓶颈由存储层迁移至软件定义网络层：Spark用DDR5+页缓存消去磁盘等待，却暴露CNI overlay的封装税；该税属CNI路径属性，Flink/Dask等同径框架预期有类似天花板（待实测）。实践三原则——（1）shuffle密集负载优先扩DDR5而非NVMe；（2）VXLAN CNI如Flannel限制混洗吞吐，eBPF类（Cilium）或host-network应作默认；（3）dstat拆usr/wai是判别存储界/计算界瓶颈的低开销诊断法。威胁效度含单负载TeraSort、单CNI、3节点、单轮无置信区间、硬件特定等。
结论部分翻译：本文在异构裸金属微集群实证比对Hadoop与Kubernetes托管Spark，200 GB TeraSort下Spark提速4.5×；RQ1归因DDR5 RAM与OS页缓存削去Hadoop传统磁盘I/O wait；RQ2示CNI overlay将集群内shuffle持续吞吐压至~500 MB/s，相较裸金属Hadoop瞬峰~4000 MB/s呈约8×峰值差，为云原生栈残余主瓶颈。核心发现是瓶颈迁移（bottleneck migration）：从裸金属MapReduce到云原生Spark并未消除约束，而是将约束由存储层移至软件定义网络层。后续工作包括同集群比Flannel VXLAN/Calico BGP/Cilium eBPF、HDFS vs MinIO隔离微基准（TestDFSIO与warp）、扩TPC-DS/WordCount/PageRank及RAPIDS GPU栈。
