[论文阅读] 从 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流程设计
- 提取阶段：Spark读取CSV文件，通过
header=true识别表头、inferSchema=true自动推断数据类型（三种语言代码见表7）。 - 转换阶段：
- 数据清洗：
dropDuplicates()移除重复项；to_date()转换时间格式。 - 表关联：用
join()基于Lat/Lng字段合并城市与天气数据，小数据集（城市数据）用broadcast()优化关联速度。
- 数据清洗：
- 加载阶段：数据写入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）。
- weather_hourly_events表：按
- 文件格式：
- 数据文件：Parquet（列存格式，减少IO开销，支持压缩），每个分区目录下含
.parquet数据文件和.parquet.crc校验文件（见图5）。 - 元数据文件：
metadata目录存储表schema、事务历史、版本信息，保障ACID特性。
- 数据文件：Parquet（列存格式，减少IO开销，支持压缩），每个分区目录下含
5. 结论与未来方向
- 核心结论：
- 性能与数据集规模非线性相关：Python适合中小数据集（高-level API高效，JVM开销小）；Scala适合复杂ETL（原生Spark语言，优化更充分，比Python快6%）。
- 语言执行特性影响性能：即使配置相同，JVM预热时间、垃圾回收、序列化效率仍导致执行时间差异。
- 未来研究方向：
- 扩展表格式对比：研究Delta Lake、Apache Hudi与Iceberg的性能差异。
- 云原生环境测试：验证不同集群规模、资源分配下的性能稳定性。
- 优化策略迭代：针对不同语言设计定制化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 性能的开发者来说，这篇论文的结论直接能用，是一篇 “实用型” 的研究。