從 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. 思維導圖

（一）Spark簡介-Java&Python版Spark_#python

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()優化關聯速度。
  1. 加載階段：數據寫入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 性能的開發者來説，這篇論文的結論直接能用，是一篇 “實用型” 的研究。