ติดตั้ง Spark ด้วย Docker

1สิ่งที่ต้องมีก่อนเริ่ม

2สร้างโครงสร้างโปรเจกต์

mkdir bigdata-lab
cd bigdata-lab
mkdir data notebooks
touch docker-compose.yml

3เขียน docker-compose.yml

version: "3.8"

services:
  spark-master:
    image: bitnami/spark:3.5
    environment:
      - SPARK_MODE=master
      - SPARK_RPC_AUTHENTICATION_ENABLED=no
      - SPARK_RPC_ENCRYPTION_ENABLED=no
    ports:
      - "8080:8080"   # Spark master Web UI
      - "7077:7077"   # Spark master port

  spark-worker:
    image: bitnami/spark:3.5
    environment:
      - SPARK_MODE=worker
      - SPARK_MASTER_URL=spark://spark-master:7077
      - SPARK_WORKER_MEMORY=2G
      - SPARK_WORKER_CORES=2
    depends_on:
      - spark-master

  jupyter:
    image: jupyter/pyspark-notebook:spark-3.5.0
    ports:
      - "8888:8888"   # Jupyter Notebook
      - "4040:4040"   # Spark application UI (เปิดตอนมี job รันอยู่)
    volumes:
      - ./notebooks:/home/jovyan/work
      - ./data:/home/jovyan/data
    environment:
      - JUPYTER_ENABLE_LAB=yes
    depends_on:
      - spark-master

4รัน Cluster

docker compose up -d

docker compose ps
# ควรเห็น 3 container: spark-master, spark-worker, jupyter ที่ status = running

docker compose logs jupyter | grep token

5ทดสอบรัน PySpark ตัวแรก

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("Lab0-FirstConnection") \
    .master("spark://spark-master:7077") \
    .getOrCreate()

print("Spark version:", spark.version)
print("Master:", spark.sparkContext.master)

# ทดสอบสร้าง DataFrame ง่าย ๆ
data = [("Alice", 25), ("Bob", 30), ("Charlie", 35)]
df = spark.createDataFrame(data, ["name", "age"])
df.show()

spark.stop()

Spark version: 3.5.0
Master: spark://spark-master:7077
+-------+---+
|   name|age|
+-------+---+
|  Alice| 25|
|    Bob| 30|
|Charlie| 35|
+-------+---+

6คำสั่งที่ใช้บ่อยและการแก้ปัญหา

7ก่อนรัน: เข้าใจว่าส่วนประกอบใดทำหน้าที่อะไร

Docker Compose ในแล็บนี้ไม่ได้สร้าง “Spark หนึ่งกล่อง” แต่สร้างหลาย Service ที่อยู่ใน Network เดียวกัน ถ้าแยกบทบาทไม่ออก เวลาเกิดปัญหาเราจะ Restart ทุกอย่างโดยไม่รู้ว่าจุดเสียอยู่ตรงไหน

8ตรวจระบบแบบเป็นขั้น ไม่เดาจากหน้าจอเดียว

1. ใช้ docker compose ps ตรวจว่า Container อยู่สถานะ Running
2. เปิด Master UI ตรวจว่า Worker ลงทะเบียนและทรัพยากรตรงค่า Compose
3. จาก Notebook ตรวจ spark.sparkContext.master ว่าชี้ spark://spark-master:7077
4. รัน Action จริง เช่น count() แล้วดู Application ใน UI
5. ดู Executors/Stages เพื่อยืนยันว่า Task ถูกส่งไป Worker ไม่ใช่ Local Mode

print("Spark version:", spark.version)
print("Master:", spark.sparkContext.master)
print("Application ID:", spark.sparkContext.applicationId)
print("Default parallelism:", spark.sparkContext.defaultParallelism)

rdd = spark.sparkContext.parallelize(range(1_000_000), 8)
print("Partitions:", rdd.getNumPartitions())
print("Sum:", rdd.sum())

9ทดลอง Scale Worker แล้ววัด ไม่ใช่เพียงดูว่ามีเพิ่ม

เพิ่ม Worker แล้ว Application ไม่จำเป็นต้องเร็วขึ้น ถ้า RDD มีสอง Partition ต่อให้มีแปด Core ก็มี Task พร้อมกันเพียงสองตัว การทดลองต้องควบคุม Partition, Data Size และวัดหลายรอบ

import time

def benchmark(partitions, n=20_000_000):
    rdd = spark.sparkContext.parallelize(range(n), partitions)
    start = time.perf_counter()
    value = rdd.map(lambda x: (x * 17) % 101).sum()
    return value, time.perf_counter() - start

for p in [1, 2, 4, 8, 16, 32]:
    value, elapsed = benchmark(p)
    print(p, "partitions:", round(elapsed, 3), "seconds")

รอบแรกอาจรวม Startup/JIT/Container Warm-up จึงควรรันซ้ำและรายงาน Median อย่าเคลม Speedup จากการจับเวลาครั้งเดียว งานเล็กเกินไปยังถูก Scheduling Overhead กลบจน Worker มากช้ากว่าเดิมได้

10Resource Limit และความจริงของ Docker Desktop

ค่า SPARK_WORKER_CORES เป็นทรัพยากรที่ Worker ประกาศ ไม่ได้สร้าง CPU จริง ถ้า Docker Desktop ได้ CPU สี่ Core แล้วกำหนด Worker สองตัว ตัวละสี่ Core ทั้งคู่กำลังแย่ง CPU เดิม Oversubscription อาจทำให้ Context Switching เพิ่ม

Memory ก็เช่นกัน Worker ประกาศได้มากกว่าที่ Container/VM มีจริง แต่เมื่อใช้จริงอาจถูก Kill ควรตรวจ Docker Desktop Resource, Container Limit, Spark Worker Memory และ Executor Memory ให้สอดคล้องกัน

docker stats
docker inspect spark-worker --format '{{json .HostConfig.Memory}}'
docker compose exec spark-worker bash -lc 'nproc; free -h'

11Volumes, Network และ Port Mapping

Bind Mount ทำให้ไฟล์ Notebook/Data อยู่บน Host และไม่หายเมื่อ Container ถูกสร้างใหม่ แต่ Path ฝั่ง Container ต้องตรงกับ Code ส่วน Named Volume เหมาะกับข้อมูลที่ Docker จัดการให้ ความต่างนี้สำคัญเวลา Backup และส่งงาน

localhost ใน Container หมายถึง Container นั้นเอง Service จึงคุยกันผ่านชื่อ spark-master บน Compose Network ส่วน Browser บน Host ใช้ localhost:8080 นี่คือคนละมุมมองของ Network

12Failure Drill: ทำให้พังอย่างมีแผน

การตั้งระบบสำเร็จยังไม่พอ เราต้องรู้ว่าเมื่อ Worker หาย Spark แสดงอะไร เริ่ม Job ที่ใช้เวลานาน แล้วหยุด Worker ระหว่างงาน สังเกต UI, Log และผลลัพธ์

# ใน Notebook: งานที่นานพอให้ทดลองหยุด Worker
slow = spark.sparkContext.parallelize(range(50_000_000), 64) \
    .map(lambda x: ((x * 31) % 1009) ** 2)
print(slow.sum())

# อีก Terminal
docker compose stop spark-worker
docker compose logs --tail=100 spark-master
docker compose start spark-worker

ผลขึ้นกับจังหวะและ Configuration งานอาจ Retry, ช้าลง หรือ Fail เป้าหมายไม่ใช่รับประกันว่าจะสำเร็จทุกครั้ง แต่ฝึกอ่านหลักฐานและอธิบาย Recovery Path

13Checklist ส่งแล็บและสรุปขั้นตอนถัดไป

• ภาพ docker compose ps และ Master UI ที่เห็น Worker
• ค่า Master/Application ID จาก Notebook
• ตาราง Benchmark Partition อย่างน้อย 5 ค่า รันซ้ำพร้อม Median
• ภาพ Stage/Task ของ Action หนึ่งงาน
• บันทึก Failure Drill ว่าหยุดอะไร เห็นอะไร และระบบฟื้นอย่างไร
• ไฟล์ Compose พร้อมคำอธิบาย Volume/Port/Resource

สรุปและขั้นตอนถัดไป: ตอนนี้เรายังไม่ได้เรียน RDD อย่างจริงจัง แต่สร้างสนามทดลองที่มองเห็น Driver, Executor, Worker และ Task แล้ว Lab 1 จะใช้สนามนี้พิสูจน์ Lazy Evaluation, Partition, Shuffle และ Cache โดยต้องอ่าน UI ควบคู่กับผลลัพธ์ ไม่ใช่เชื่อโค้ดเพียงด้านเดียว

20วิธีทำแล็บให้ได้มากกว่าคำว่า “รันผ่าน”

แล็บนี้ไม่ได้วัดว่าเราพิมพ์คำสั่งตามตัวอย่างได้ครบหรือไม่ เพราะการรันผ่านอาจเกิดจากความบังเอิญ ค่า Default หรือข้อมูลที่เล็กเกินไปจนมองไม่เห็นปัญหา เป้าหมายคือฝึกตั้งสมมติฐาน เปลี่ยนตัวแปรครั้งละอย่าง เก็บหลักฐาน และอธิบายผลด้วยแนวคิดของระบบกระจาย ถ้าผลไม่ตรงกับที่คาด นั่นไม่ใช่ความล้มเหลว แต่เป็นจุดเริ่มต้นของคำถามที่ดี

1. คาดก่อนรัน: เขียนหนึ่งหรือสองประโยคว่าคิดว่าจะเกิดอะไรและเพราะอะไร
2. กำหนดสิ่งที่คุม: ใช้ข้อมูล โค้ด และทรัพยากรเดิม แล้วเปลี่ยนเฉพาะตัวแปรที่กำลังศึกษา
3. เก็บหลักฐาน: บันทึกเวลา แผนการทำงาน Metric, Log หรือภาพ Spark UI ไม่อาศัยความรู้สึกว่า “เร็วขึ้น”
4. อธิบายกลไก: เชื่อมผลกับ Partition, Shuffle, State, Memory, Network หรือ Scheduling
5. บอกข้อจำกัด: ผลจาก Laptop และข้อมูลจำลองอาจไม่เหมือน Production ให้ระบุสิ่งที่ยังสรุปไม่ได้

21สมุดบันทึกการทดลอง

อย่าจดเฉพาะผลลัพธ์สุดท้าย ควรจด Environment ด้วย เช่น Spark version, Python version, จำนวน Core, Memory, จำนวน Partition, Seed และขนาดข้อมูล เปรียบเหมือนใบเสร็จและสูตรอาหารที่ทำให้คนอื่นย้อนทำจานเดิมได้ หากไม่มีข้อมูลเหล่านี้ ผลที่ดูน่าเชื่อถืออาจทำซ้ำไม่ได้

22ชุดการทดลองหลัก: สภาพแวดล้อม Spark บน Docker

23บันไดแก้ปัญหาเมื่อผลไม่เป็นอย่างที่คิด

เวลางานล้ม อย่าเริ่มด้วยการลบทุกอย่างแล้วติดตั้งใหม่ เพราะเราอาจทำลายหลักฐานที่บอกสาเหตุ ให้ไล่จากชั้นนอกเข้าสู่ชั้นในเหมือนช่างไฟที่ตรวจตั้งแต่ปลั๊ก สายไฟ ฟิวส์ ไปจนถึงเครื่องใช้ไฟฟ้า

1. ยืนยันอาการ: คัดลอก Error แรก ไม่ใช่เฉพาะบรรทัดสุดท้าย และบันทึกคำสั่งที่ทำให้เกิดซ้ำ
2. ลดปัญหา: ใช้ข้อมูลเล็กที่สุดและโค้ดสั้นที่สุดที่ยังทำให้ Error เกิด
3. ตรวจสัญญาข้อมูล: ดู Schema, Type, Null, Key และ Path ก่อนสงสัย Cluster
4. ตรวจ Plan และ UI: ดูว่างานเริ่มจริงหรือค้างอยู่ก่อนสร้าง Job; แยกปัญหา Driver, Executor และ Storage
5. ตรวจทรัพยากร: ดู Memory, Disk, Port, Permission และ Container status
6. เปลี่ยนทีละจุด: เมื่อแก้แล้ว ให้ย้อนอธิบายว่าการเปลี่ยนนั้นจัดการสาเหตุใด

24คำถามชวนคิดหลังทำแล็บ

1. ผลที่เห็นเกิดจาก Algorithm หรือเกิดจากการจัดวางข้อมูลและข้อจำกัดของเครื่อง?
2. ถ้าข้อมูลใหญ่ขึ้นหนึ่งร้อยเท่า ขั้นตอนไหนจะพังก่อน และเรามีหลักฐานอะไร?
3. ถ้าเครื่องหนึ่งหายไประหว่างงาน คำตอบจะยังถูกต้องหรือเพียงแค่งานยังรันต่อได้?
4. ค่า Default ใดช่วยเราอยู่ และค่าใดอาจกลายเป็นกับดักเมื่อขึ้น Production?
5. ถ้าต้องอธิบายผลให้เพื่อนที่ไม่ได้เห็นหน้าจอ เรามีหลักฐานครบพอหรือยัง?

25สิ่งที่ต้องส่ง

• Notebook หรือ Source code ที่รันจากต้นจนจบได้ โดยไม่พึ่งลำดับคำสั่งที่ซ่อนอยู่
• README ระบุวิธีเริ่มระบบ Version, Dependency และคำสั่งที่ใช้
• สมุดบันทึกอย่างน้อยสามการทดลอง มีสมมติฐาน ตัวแปร หลักฐาน และข้อสรุป
• ภาพหรือ Export จาก Spark UI/Query Plan ที่วงส่วนสำคัญและมีคำอธิบาย
• กรณีผิดพลาดอย่างน้อยหนึ่งกรณี พร้อมการวิเคราะห์ ไม่ตัดทิ้งเพราะ “ทำไม่สำเร็จ”
• ข้อจำกัดของผลและสิ่งที่จะทดลองต่อ หากมีข้อมูลหรือเครื่องมากขึ้น

26เกณฑ์ตรวจงานแบบสั้น

27สรุปและขั้นตอนถัดไป

หัวใจของแล็บนี้ไม่ใช่จำคำสั่ง แต่คือการมองเห็นว่า สภาพแวดล้อม Spark บน Docker ตัดสินใจอย่างไรเมื่อข้อมูล งาน และทรัพยากรถูกกระจายออกจากกัน เมื่อทำเสร็จแล้วควรตอบได้สามเรื่อง: ระบบทำอะไร หลักฐานใดแสดงว่ามันทำเช่นนั้น และเงื่อนไขใดทำให้พฤติกรรมเปลี่ยน

ก่อนเปิดแล็บถัดไป ลองย่อสิ่งที่เรียนรู้ให้เหลือหนึ่งภาพ หนึ่งตาราง และสามประโยค หากย่อไม่ได้ อาจยังมีส่วนที่เราเห็นผลแต่ยังไม่เข้าใจกลไก ให้กลับไปเลือกการทดลองที่เล็กลง แล้วค่อยต่อภาพกลับขึ้นมาใหม่

28สถานการณ์จำลอง: จากข้อมูลก้อนเล็กไปสู่งานที่เริ่มมีปัญหา

ให้เริ่มด้วยข้อมูลก้อนเล็กที่ตรวจคำตอบด้วยมือได้ จากนั้นขยายเป็นสามระดับ โดยไม่เปลี่ยนความหมายของโจทย์ ระดับแรกใช้ตรวจความถูกต้อง ระดับที่สองใช้เปิดให้เห็น Parallelism และระดับที่สามใช้เปิดให้เห็นคอขวด วิธีนี้ช่วยแยกคำถามสองข้อที่มักปนกัน คือ “คำตอบถูกหรือไม่” กับ “ระบบรองรับขนาดงานได้หรือไม่” ระบบที่เร็วแต่ตอบผิดไม่มีประโยชน์ และระบบที่ตอบถูกเฉพาะข้อมูลสิบแถวก็ยังไม่ใช่คำตอบของงานขนาดใหญ่

29อ่าน Spark UI ให้เป็นเรื่องราว ไม่ใช่เพียงหน้าจอสีสวย

เริ่มจาก Job ว่าถูกสร้างเพราะ Action ใด แล้วลงไปที่ Stage เพื่อดูว่า Shuffle แบ่งเส้นทางตรงไหน จากนั้นจึงดู Task ว่ากระจายตัวสม่ำเสมอหรือมีตัวใดลากยาว สุดท้ายดู Executor ว่างานไปอยู่เครื่องใด ใช้ Memory เท่าไร และมี Failure หรือ Retry หรือไม่ ลำดับนี้เหมือนอ่านแผนที่จากประเทศ จังหวัด ถนน แล้วจึงถึงบ้าน หากกระโดดไปดู Task หนึ่งตัวทันที เราอาจเห็นอาการแต่ไม่เห็นบริบท

การจับภาพ UI ควรใส่ลูกศรหรือคำอธิบายว่ากำลังใช้ภาพนั้นสนับสนุนข้อสรุปใด ภาพทั้งหน้าที่ไม่มีคำอธิบายเหมือนแนบผลตรวจสุขภาพโดยไม่บอกว่าค่าไหนผิดปกติ หลักฐานที่ดีไม่จำเป็นต้องเยอะ แต่ต้องเชื่อมกับคำถามได้ตรงจุด

30แยกความถูกต้อง ความเร็ว และความทนทานออกจากกัน

สามเรื่องนี้สัมพันธ์กันแต่ทดแทนกันไม่ได้ งานอาจเร็วขึ้นเพราะเผลอทิ้งข้อมูลบางส่วน งานอาจทนต่อ Worker หายแต่สร้างข้อมูลซ้ำ หรือคำตอบอาจถูกแต่ใช้ทรัพยากรมากเกินจำเป็น ทุกครั้งที่ปรับระบบจึงควรตรวจทั้งสามแกน ไม่ประกาศชัยชนะจากเวลาเพียงตัวเดียว

1. ความถูกต้อง: สร้างข้อมูลจิ๋วที่รู้คำตอบล่วงหน้า ใส่ Null, Duplicate, Key ที่ไม่มีคู่ และค่าขอบเขต แล้วตรวจผลทีละกรณี
2. ความเร็ว: วัดหลายรอบ แยก Warm-up ออกจากรอบจริง ระบุขนาดข้อมูลและทรัพยากร และรายงานทั้งค่ากลางกับช่วง ไม่เลือกเฉพาะรอบที่ดีที่สุด
3. ความทนทาน: ทำให้ส่วนหนึ่งล้มอย่างตั้งใจ ตรวจว่างาน Retry, Resume หรือคำนวณใหม่จาก Lineage และตรวจว่าคำตอบหลังการกู้ไม่ซ้ำหรือขาด
4. ต้นทุน: เวลาเร็วขึ้นอาจแลกกับ Memory, Storage, Network หรือความซับซ้อนในการดูแล ให้บันทึกสิ่งที่จ่ายเพิ่มเสมอ

31จาก Error Message ไปสู่คำอธิบาย

ให้เลือก Error จริงหนึ่งครั้งจากแล็บแล้วเขียน Postmortem สั้น ๆ โดยไม่กล่าวโทษผู้ใช้หรือเครื่องมือ เริ่มจากผลกระทบ ตามด้วยลำดับเหตุการณ์ สาเหตุใกล้ตัว สาเหตุราก วิธีแก้เฉพาะหน้า และวิธีป้องกันซ้ำ ตัวอย่างเช่น “Job ล้มเพราะ Out of Memory” ยังเป็นเพียงอาการ สาเหตุรากอาจเป็นการ collect ข้อมูลทั้งหมดมายัง Driver, Broadcast ตารางใหญ่เกินไป หรือ Partition หนึ่งก้อนใหญ่ผิดปกติ ซึ่งมีวิธีแก้คนละแบบ

จุดสำคัญคือแยก “แก้ให้งานผ่านครั้งนี้” ออกจาก “แก้ไม่ให้เกิดซ้ำ” การเพิ่ม Memory อาจช่วยงานรอบนี้ แต่ถ้าข้อมูลโตต่อเนื่อง ปัญหาจะกลับมา การเปลี่ยนรูปแบบ Aggregation, ลดข้อมูลก่อน Shuffle หรือเลิกดึงทุกอย่างเข้า Driver อาจแตะสาเหตุได้ตรงกว่า

32แบบฝึกสอนกลับ: อธิบายให้เพื่อนฟังในห้านาที

จับคู่กับเพื่อนแล้วผลัดกันอธิบาย สภาพแวดล้อม Spark บน Docker โดยห้ามเริ่มจากชื่อ Class หรือ API ให้เริ่มจากปัญหาที่ระบบกำลังแก้ ใช้ภาพหนึ่งภาพและตัวอย่างข้อมูลไม่เกินสิบแถว ผู้ฟังมีหน้าที่ถามว่า “รู้ได้อย่างไร” และ “ถ้าข้อมูลใหญ่ขึ้นจะเกิดอะไร” วิธีนี้ช่วยเปิดจุดที่เราจำคำสั่งได้แต่ยังเชื่อมเหตุผลไม่ครบ

• นาทีที่ 1: ปัญหาคืออะไร และเหตุใดเครื่องเดียวหรือวิธีตรงไปตรงมาจึงเริ่มไม่พอ
• นาทีที่ 2: ข้อมูลและงานถูกแบ่งอย่างไร ส่วนใดอยู่ที่ Driver และส่วนใดอยู่ที่ Executor
• นาทีที่ 3: จุดใดต้องสื่อสารข้ามเครื่อง และต้นทุนเกิดตรงไหน
• นาทีที่ 4: แสดงหลักฐานหนึ่งชิ้นจากแล็บแล้วตีความ
• นาทีที่ 5: บอกข้อจำกัดหนึ่งข้อและการทดลองถัดไปหนึ่งอย่าง