Apache Beam vs Spark 2026: เปรียบเทียบ Pipeline แบบรวมและคำถามสัมภาษณ์

Apache Beam และ Spark เป็นสอง framework ประมวลผลข้อมูลที่ได้รับความนิยมสูงสุดในปี 2026 Beam 2.76 (สิงหาคม 2026) และ Spark 4.2 (กรกฎาคม 2026) ทั้งคู่จัดการ workload แบบ batch และ streaming ได้ แต่ปรัชญาการออกแบบต่างกันโดยพื้นฐาน Beam ทำ abstraction ของ execution engine ในขณะที่ Spark มี runtime แบบรวมที่ผสานรวมกันอย่างแน่นหนา

โมเดลความพกพาของ Beam vs Engine แบบรวมของ Spark

Apache Beam แยกโมเดลการเขียนโปรแกรมออกจากการประมวลผล คำจำกัดความ pipeline เดียวสามารถทำงานบน Google Cloud Dataflow Apache Flink Apache Spark หรือ runner อื่นได้โดยไม่ต้องเปลี่ยนโค้ด การ abstraction นี้มาจาก Beam SDK ที่สร้างการแสดงผล pipeline แบบพกพาที่ runner ที่เข้ากันได้สามารถตีความได้

Spark 4.2 ใช้แนวทางตรงกันข้าม DataFrame API, Structured Streaming และ MLlib ใช้ Catalyst optimizer และ Tungsten execution engine ร่วมกัน การผสานรวมอย่างแน่นหนานี้ทำให้สามารถปรับแต่งอย่าง Adaptive Query Execution ที่ปรับแผนขณะ runtime ตามสถิติข้อมูลจริง

# beam_pipeline.py
import apache_beam as beam
from apache_beam.options.pipeline_options import PipelineOptions

# โค้ดเดียวกันทำงานบน Dataflow, Flink หรือ Spark runner
options = PipelineOptions([
    '--runner=DataflowRunner',  # สลับเป็น FlinkRunner หรือ SparkRunner
    '--project=my-project',
    '--region=us-central1',
    '--temp_location=gs://my-bucket/temp'
])

with beam.Pipeline(options=options) as pipeline:
    (pipeline
     | 'ReadEvents' >> beam.io.ReadFromPubSub(topic='projects/p/topics/events')
     | 'ParseJSON' >> beam.Map(lambda x: json.loads(x))
     | 'FilterValid' >> beam.Filter(lambda e: e.get('status') == 'valid')
     | 'WindowByMinute' >> beam.WindowInto(beam.window.FixedWindows(60))
     | 'CountPerWindow' >> beam.combiners.Count.Globally()
     | 'WriteToBQ' >> beam.io.WriteToBigQuery('project:dataset.table'))

เวอร์ชัน Spark ที่เทียบเท่าผูกติดกับ Spark runtime โดยตรง:

# spark_streaming.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col, window

spark = SparkSession.builder \
    .appName("EventProcessing") \
    .config("spark.sql.adaptive.enabled", "true") \
    .getOrCreate()

# Spark 4.2: โหมด ANSI เปิดใช้งานโดยค่าเริ่มต้น การตรวจสอบประเภทเข้มงวดขึ้น
events = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "broker:9092") \
    .option("subscribe", "events") \
    .load()

processed = events \
    .select(from_json(col("value").cast("string"), schema).alias("data")) \
    .filter(col("data.status") == "valid") \
    .groupBy(window(col("data.timestamp"), "1 minute")) \
    .count()

processed.writeStream \
    .format("bigquery") \
    .option("table", "project.dataset.table") \
    .outputMode("append") \
    .start()

ความพกพาของ Beam ทำให้สามารถสร้างสถาปัตยกรรม cloud-agnostic ได้แต่เพิ่ม translation layer การประมวลผลโดยตรงของ Spark โดยทั่วไปแสดง latency ต่ำกว่าสำหรับการดำเนินการที่เทียบเท่าบน hardware เดียวกัน

เปรียบเทียบ Windowing และการประมวลผล Event-Time

ทั้งสอง framework จัดการ semantics ของ event-time แต่ API สะท้อนมรดกที่ต่างกัน โมเดล windowing ของ Beam มาจาก Dataflow Model paper (2015) ซึ่งถือว่า window เป็นองค์ประกอบ pipeline ชั้นนำ Spark ปรับ windowing สำหรับ Structured Streaming โดยผสานรวมกับ DataFrame API

Session windows แสดงความแตกต่างชัดเจนที่สุด Beam ถือว่า session เป็นกลยุทธ์ windowing แบบ native:

# beam_sessions.py
from apache_beam import window

# Session gap 30 นาที รับข้อมูลล่าช้าถึง 1 ชั่วโมง
windowed = (
    events
    | 'SessionWindow' >> beam.WindowInto(
        window.Sessions(30 * 60),  # Gap 30 นาทีปิด session
        trigger=beam.trigger.AfterWatermark(
            early=beam.trigger.AfterProcessingTime(60),
            late=beam.trigger.AfterCount(1)
        ),
        allowed_lateness=3600,  # รับข้อมูลล่าช้าถึง 1 ชั่วโมง
        accumulation_mode=beam.trigger.AccumulationMode.ACCUMULATING
    )
)

Spark ต้องการการประมวลผลแบบ stateful สำหรับ sessions:

# spark_sessions.py
from pyspark.sql.streaming import GroupState, GroupStateTimeout

def update_session(key, events, state: GroupState):
    # จัดการ session ด้วยตนเองกับ state API
    session_data = state.getOption() or {"count": 0, "start": None, "end": None}
    
    for event in events:
        ts = event.timestamp
        if session_data["end"] and (ts - session_data["end"]).seconds > 1800:
            # Gap เกิน 30 นาที ส่งออก session ก่อนหน้า
            yield session_data
            session_data = {"count": 0, "start": ts, "end": ts}
        
        session_data["count"] += 1
        session_data["end"] = ts
        if not session_data["start"]:
            session_data["start"] = ts
    
    state.update(session_data)
    state.setTimeoutDuration(30 * 60 * 1000)  # Timeout 30 นาที

# Spark 4.2 Arbitrary State API v2
result = events \
    .groupByKey(lambda e: e.user_id) \
    .flatMapGroupsWithState(
        update_session,
        outputMode="append",
        stateType=session_schema,
        timeoutConf=GroupStateTimeout.ProcessingTimeTimeout
    )

สำหรับการเตรียมสัมภาษณ์เกี่ยวกับหัวข้อเหล่านี้ ดูโมดูล คำถามสัมภาษณ์ Apache Beam และ Dataflow

ประสิทธิภาพ: ข้อมูล Benchmark 2026

การเปรียบเทียบโดยตรงต้องการการตั้งค่าอย่างระมัดระวังเพราะ Beam ทำงานบน Spark เป็นตัวเลือก runner หนึ่ง การเปรียบเทียบที่เกี่ยวข้องคือ Beam-on-Dataflow vs native Spark

Benchmark ล่าสุดจาก Databricks และ Google Cloud แสดง:

การปรับปรุงประสิทธิภาพของ Spark 4.2 มาจากหลายคุณสมบัติ:

• โหมด ANSI เริ่มต้น: semantics SQL เข้มงวดขึ้นจับ error เร็วขึ้น
• ประเภทข้อมูล VARIANT: จัดการข้อมูลกึ่งโครงสร้างแบบ native
• Adaptive Query Execution: ปรับแต่งแผนขณะ runtime
• รองรับ Java 21: virtual threads ลด overhead

Beam 2.76 นำเสนอ:

• รองรับ Flink 2.0 runner: stateful streaming ระดับ production
• CDC offset persistence: DebeziumIO FileSystemOffsetRetainer
• การผสานรวม ADK: รองรับ Google Agent Development Kit ใน Python SDK

คำถามสัมภาษณ์ที่พบบ่อย: Beam vs Spark

การสัมภาษณ์เทคนิคสำหรับตำแหน่ง data engineering มักเปรียบเทียบสอง framework นี้ นี่คือคำถามที่ปรากฏในการสัมภาษณ์ปี 2026 พร้อมความลึกของคำตอบที่คาดหวัง

Q1: เมื่อไหร่ควรเลือก Beam แทน native Spark?

ประเด็นคำตอบที่คาดหวัง:

• การ deploy แบบ multi-cloud หรือ hybrid ที่โค้ด pipeline ต้องทำงานโดยไม่เปลี่ยนแปลง
• สภาพแวดล้อม Google Cloud ที่ Dataflow ให้โครงสร้างพื้นฐานที่จัดการให้
• Semantics event-time ซับซ้อนที่ต้องการ session windows หรือ custom triggers
• ทีมที่มีความเชี่ยวชาญ Beam จากพื้นฐาน Dataflow

คำตอบธงแดง: "Beam ดีกว่าเสมอเพราะพกพาได้" ความพกพามีค่าใช้จ่าย overhead

Q2: การ abstraction runner ของ Beam ส่งผลต่อการ debug อย่างไร?

ประเด็นคำตอบที่คาดหวัง:

• Stack trace อ้างอิงทั้ง Beam SDK และการ implement ของ runner
• การปรับแต่งเฉพาะ runner อาจทำงานต่างกัน (checkpoint Flink vs checkpoint Spark)
• Metrics API ให้ monitoring แบบรวม แต่ dashboard runner แสดงรายละเอียดต่างกัน
• ทดสอบกับ DirectRunner ก่อน deploy ไปยัง production runner

Q3: อธิบาย semantics exactly-once ในทั้งสอง framework

คำตอบที่คาดหวัง:

# Beam: exactly-once ผ่านการรับประกันของ runner
# Dataflow ให้ exactly-once สำหรับทั้ง sources และ sinks
# SDK จัดการการลบซ้ำและการประสานงาน checkpoint

with beam.Pipeline() as p:
    (p
     | beam.io.ReadFromPubSub(subscription='...')  # อ่าน exactly-once
     | beam.Map(process)
     | beam.io.WriteToBigQuery(...)  # เขียน exactly-once พร้อม retry
    )

# Spark: exactly-once ผ่าน checkpointing และ idempotent sinks
spark.readStream \
    .format("kafka") \
    .load() \
    .writeStream \
    .option("checkpointLocation", "/checkpoint")  # กู้คืน state
    .foreachBatch(idempotent_write)  # ลบซ้ำระดับแอปพลิเคชัน
    .start()

สำหรับหัวข้อสัมภาษณ์ streaming เพิ่มเติม ดู โมดูล PySpark

Q4: จะ migrate Spark batch job ไปยัง Beam อย่างไร?

คำถามนี้ทดสอบความเข้าใจทั้งสอง API ประเด็นสำคัญ:

1. Map การดำเนินการ DataFrame ไปยัง PCollections และ transforms
2. แทนที่ spark.read ด้วย Beam I/O connector ที่เหมาะสม
3. แปลง UDF เป็นฟังก์ชัน beam.Map หรือ beam.ParDo
4. จัดการ partitioning ต่างกัน (Reshuffle ของ Beam vs repartition ของ Spark)
5. ทดสอบกับ DirectRunner ก่อน deploy ไปยัง production runner

เลือกเครื่องมือที่เหมาะสม: เมทริกซ์การตัดสินใจ

การเลือกขึ้นอยู่กับบริบทขององค์กรมากกว่าความสามารถทางเทคนิค ทั้งสอง framework จัดการ workload data engineering ส่วนใหญ่ได้อย่างมีประสิทธิภาพ

สำหรับ การตัดสินใจรูปแบบ ETL/ELT พิจารณาปริมาณข้อมูลและข้อกำหนด latency ก่อนเลือก framework

สถาปัตยกรรมในโลกจริง: แนวทาง Hybrid

หลายองค์กรใช้ทั้งสอง framework รูปแบบทั่วไป:

[Streaming Ingestion]     [Batch Processing]     [ML Training]
        |                        |                    |
   Beam/Dataflow           Spark บน Databricks    Spark MLlib
        |                        |                    |
        v                        v                    v
    BigQuery  <----- dbt -----> Delta Lake -----> Model Registry

Beam จัดการ streaming ingestion ที่ autoscaling ของ Dataflow ตรงกับรูปแบบ traffic Spark ประมวลผล batch workload ที่เศรษฐศาสตร์ของ cluster ดีกว่าสำหรับการคำนวณต่อเนื่อง ทั้งคู่ไหลไปยัง data warehouse แบบรวม

สถาปัตยกรรมนี้กล่าวถึงใน บทเรียน Apache Spark พร้อมรายละเอียดการนำไปใช้

สรุปการเลือก Beam vs Spark

• Beam 2.76 ให้ความสามารถในการพกพา runner บน Dataflow, Flink 2.0 และ Spark แลกเปลี่ยนประสิทธิภาพเพื่อความยืดหยุ่นในการ deploy
• Spark 4.2 ให้การผสานรวมที่แน่นขึ้นระหว่าง SQL, streaming และ ML workload ด้วยคุณสมบัติเช่นประเภท VARIANT และ Adaptive Query Execution
• Session windows และ trigger ซับซ้อนเหมาะกับโมเดล windowing แบบ native ของ Beam มากกว่า
• ประสิทธิภาพ batch บน hardware ที่เทียบเท่ามักจะดีกว่าใน Spark เนื่องจากการปรับแต่ง Catalyst/Tungsten
• คำถามสัมภาษณ์เน้นที่ trade-offs มากกว่าการประกาศว่า framework ใดเหนือกว่า
• สถาปัตยกรรม hybrid ที่ใช้ทั้งสอง framework เป็นเรื่องปกติในสภาพแวดล้อม production
• การเปรียบเทียบค่าใช้จ่ายขึ้นอยู่กับรูปแบบ workload: pricing per-GB ของ Dataflow vs การจัดสรร cluster Spark