实用指南：[论文阅读] 从 5MB 到 1.6GB 数据：Java/Scala/Python 在 Spark 中的性能表现全解析

从 5MB 到 1.6GB 数据：Java/Scala/Python 在 Spark 中的性能表现全解析

arXiv:2510.19012 (cross-list from cs.DC)
Comparative analysis of large data processing in Apache Spark using Java, Python and Scala
Ivan Borodii, Illia Fedorovych, Halyna Osukhivska, Diana Velychko, Roman Butsii
Comments: CITI 2025, 3rd International Workshop on Computer Information Technologies in Industry 4.0, June 11-12, 2025, Ternopil, Ukraine. The article includes 10 pages, 5 figures, 9 tables
Subjects: Distributed, Parallel, and Cluster Computing (cs.DC); Databases (cs.DB); Programming Languages (cs.PL); Software Engineering (cs.SE)

1. 一段话总结

本研究针对Apache Spark中使用Java、Python、Scala三种编程语言处理大数据的性能展开对比分析，以ETL流程（提取-转换-加载）为核心，将来自open-meteo（1.6GB 2024年小时气温数据）和simplemaps.com（5MB 47k城市地理数据）的数据集加载到Apache Iceberg表中，在统一硬件（Windows 10、16GB RAM、Ryzen 5 4600H）和软件配置（Spark 3.5.1、Iceberg 1.7.1）下测试执行时间；结果显示Python在中小数据集（world_cities表6.71秒、weather_events表46.34秒）处理中更快，而Scala在复杂多步骤ETL任务（weather_hourly_events表374.42秒）中表现最优（优于Java的379.8秒和Python的398.32秒），最终得出“语言选择需结合数据集规模与任务复杂度，需同时考虑Spark参数与语言执行特性”的结论。

---

2. 思维导图

---

3. 详细总结

1. 研究背景与意义

• 研究对象：Apache Spark中Java、Python、Scala三种编程语言的大数据处理性能差异，聚焦ETL全流程（内容提取、转换、加载到Apache Iceberg表）。
• 研究必要性：现有文献多关注单一语言或部分处理阶段，缺乏“统一安装下全周期语言影响”的综合分析；而Spark语言选择会显著影响执行时间、内存消耗、扩展性，尤其大规模数据处理中，几秒延迟可能放大为小时级耗时。
• 核心目标：在相同Spark配置、输入数据集下，对比三种语言的ETL性能，为大数据系统设计供应语言选择依据。

2. 相关工作综述

研究者/年份	研究内容	关键结论
Vergas（2022）	Spark+Scala环境下，Iceberg vs Delta Lake/Hudi（云存储）	Iceberg读速最优（比Hudi快20%、比Delta Lake快10-15%），但更新速度仅为Delta Lake的1/2
Ciesielski（2024）	PySpark+Iceberg处理金融大数据	Iceberg凭借ACID事务和版本控制，降低数据访问时间，适合需数据完整性的场景
Ahmed（2020）	Spark vs Hadoop（10节点集群，60TB存储，WordCount/TeraSort）	Spark性能更优：WordCount快2倍，TeraSort快14倍（Scala实现，原生API兼容）
Ketu（2020）	Spark vs Hadoop（迭代/流处理任务，多语言测试）	Spark迭代任务快2-10倍（内存计算优势）；Scala用于高性能场景，Python用于机器学习集成

3. 研究方法

（1）数据集详情

数据来源	数据内容	数据规模	核心字段
simplemaps.com	全球城市地理信息	5MB CSV，47k条	City、Lat（纬度）、Lng（经度）、Population、Country_iso2
open-meteo	2024年全球小时气温数据	1.6GB CSV	Date（时间戳）、Temperature_2m、Lat、Lng
合并后数据	城市-小时气温关联数据（ETL目标）	-	含气温、地理、人口、国家等综合字段

（2）实验环境配置

• 硬件环境：Windows 10 Home（64位）、16GB RAM、AMD Ryzen 5 4600H（3.00GHz）、Radeon Graphics；JVM堆内存约3934MB，支持12核并行任务。
• 软件环境：
  • 框架：Apache Spark 3.5.1（分布式处理）、Apache Iceberg 1.7.1（分析型表管理）
  • 语言：Java 11.0.14、Scala 2.12.18、Python 3.11
  • 开发工具：PyCharm（Python）、IntelliJ IDEA（Java/Scala）

（3）统一Spark配置（保障实验公平性）

配置参数	描述
master = local[*]	本地多线程模式，利用所有可用CPU核心
spark.sql.catalog.local.type	Iceberg目录类型：Hadoop（基于文件系统存储）
spark.executor.instances = 5	启用5个executor（共6个执行单元）
spark.executor.cores = 2	每个executor分配2个CPU核心
spark.driver.cores = 2	Driver分配2个CPU核心
spark.sql.adaptive.enabled = true	启用自适应查询执行（优化查询计划）
spark.memory.offHeap.enabled = true	启用堆外内存，减少JVM垃圾回收开销

（4）ETL流程设计

1. 提取阶段：Spark读取CSV文件，通过header=true识别表头、inferSchema=true自动推断数据类型（三种语言代码见表7）。
2. 转换阶段：
   • 数据清洗：dropDuplicates()移除重复项；to_date()转换时间格式。
   • 表关联：用join()基于Lat/Lng字段合并城市与天气数据，小数据集（城市数据）用broadcast()优化关联速度。
3. 加载阶段：数据写入Iceberg表，采用overwrite模式（保留历史数据）+ overwrite-mode=dynamic（最小化重写批次），三种语言代码见表8。

4. 实验结果

（1）各语言执行时间对比（核心结果）

Apache Iceberg表名	Java（秒）	Scala（秒）	Python（秒）	性能排序
world_cities（小数据集）	9.62	9.13	6.71	Python > Scala > Java
weather_events（中材料集）	50.56	47.72	46.34	Python > Scala > Java
weather_hourly_events（繁琐大数据集）	379.8	374.42	398.32	Scala > Java > Python

（2）Apache Iceberg存储结构

• schema组织：按语言分3个独立目录（worldcities_java/scala/python），每个目录含3张表（weather_events、world_cities、weather_hourly_events）。
• 分区策略：
  • weather_hourly_events表：按temperature_dt（日期，一级分区）和country_iso2（国家ISO2，二级分区）分层，子目录嵌套存储（见图3、4）。
• 文件格式：
  • 数据文件：Parquet（列存格式，减少IO开销，支持压缩），每个分区目录下含.parquet数据文件和.parquet.crc校验文件（见图5）。
  • 元数据文件：metadata目录存储表schema、事务历史、版本信息，保障ACID特性。

5. 结论与未来方向

• 核心结论：
  1. 性能与数据集规模非线性相关：Python适合中小数据集（高-level API高效，JVM开销小）；Scala适合复杂ETL（原生Spark语言，优化更充分，比Python快6%）。
  2. 语言执行特性影响性能：即使安装相同，JVM预热时间、垃圾回收、序列化效率仍导致执行时间差异。
• 未来研究方向：
  1. 扩展表格式对比：研究Delta Lake、Apache Hudi与Iceberg的性能差异。
  2. 云原生环境测试：验证不同集群规模、资源分配下的性能稳定性。
  3. 优化策略迭代：针对不同语言设计定制化Spark配置。

---

4. 关键问题

问题1：三种编程语言在Apache Spark处理不同规模内容集时的性能差异具体表现如何？造成差异的核心原因是什么？

• 答案：
  性能差异随数据集规模变化显著：①小/中数据集（world_cities、weather_events）：Python最快（6.71秒、46.34秒），优于Scala（9.13秒、47.72秒）和Java（9.62秒、50.56秒），原因是Python高-level API简洁，无需JVM启动预热， overhead更低；②复杂大数据集（weather_hourly_events）：Scala最优（374.42秒），优于Java（379.8秒）和Python（398.32秒），原因是Scala是Spark原生语言，支持低-level函数调用，与Catalyst优化器集成更紧密，且避免Python与JVM间的序列化开销（Py4J桥接损耗）。

挑战2：本研究中Apache Iceberg的存储设计（如分区、文件格式）对ETL流程性能有哪些关键影响？

• 答案：
  Iceberg的存储设计从三方面优化ETL性能：①分层分区策略：weather_hourly_events表按temperature_dt（日期）+ country_iso2（国家）分区，查询时仅读取目标分区数据（如特定日期+国家），减少IO量；② Parquet列存格式：数据按列存储，ETL转换中仅需加载目标字段（如气温、经纬度），比行存减少50%以上数据传输，且支持高效压缩（降低磁盘占用）；③ACID事务与动态覆盖：通过overwrite-mode=dynamic仅重写更新数据，避免全表重写，同时metadata目录记录版本历史，保障数据一致性，减少重试开销（尤其复杂关联任务）。

问题3：为确保实验结果的公平性与可复现性，本研究在实验环境和Spark配置上做了哪些关键控制？

• 答案：
  研究通过“硬件统一、软件版本固定、配置参数一致”保障公平性：①硬件环境统一：固定使用Windows 10、16GB RAM、AMD Ryzen 5 4600H处理器，JVM堆内存3934MB，12核并行任务，避免硬件差异影响；②软件版本固定：Spark 3.5.1、Iceberg 1.7.1、Java 11、Scala 2.12.18、Python 3.11，排除版本兼容性导致的性能波动；③Spark参数一致：所有语言共享相同配置（如master=local[*]、5个executor、自适应查询启用、堆外内存开启），且ETL流程（读CSV、转换、写Iceberg）的逻辑完全一致（仅语言语法差异），确保性能差异仅源于语言特性。

总结

这篇论文没有讲复杂的理论，而是用 “接地气” 的实验解决了大信息开发的实际痛点 ——Spark 语言选型。它的价值不在于提出新算法，而在于用统一、可复现的实验，把 “经验之谈” 变成了 “数据结论”：小 / 中数据集选 Python（兼顾效率和性能），复杂大数据集选 Scala（性能最优），Java 可作为稳定备选。对于得优化 Spark ETL 性能的开发者来说，这篇论文的结论直接能用，是一篇 “实用型” 的研究。