25 คำถามสัมภาษณ์งาน Data Engineering ยอดนิยมในปี 2026

คำถามสัมภาษณ์งาน data engineering ในปี 2026 ก้าวไปไกลเกินกว่าพื้นฐาน SQL แล้ว ทีมจ้างงานในปัจจุบันให้ความสำคัญกับ system design, สถาปัตยกรรม real-time, การเพิ่มประสิทธิภาพต้นทุน และความพร้อมสำหรับ AI บทความนี้รวบรวม 25 คำถามที่ปรากฏบ่อยที่สุดในการสัมภาษณ์ data engineer ตั้งแต่บริษัท startup ไปจนถึง FAANG พร้อมคำตอบที่เขียนขึ้นสำหรับผู้ปฏิบัติงานจริง

คำถามเกี่ยวกับ SQL และการเพิ่มประสิทธิภาพ Query

SQL ยังคงเป็นรากฐานของการสัมภาษณ์งาน data engineering ทุกครั้ง แม้แต่ผู้สมัครระดับ senior ก็ยังต้องเผชิญกับคำถาม SQL โดยมักจะเน้นเรื่องประสิทธิภาพมากกว่า syntax

1. ความแตกต่างระหว่าง window function กับ GROUP BY คืออะไร

GROUP BY จะยุบแถวให้กลายเป็นผลลัพธ์ที่รวบรวมแล้ว ทำให้จำนวนแถวลดลง ในขณะที่ window function คำนวณค่าจากชุดของแถวที่เกี่ยวข้องกับแถวปัจจุบันโดยไม่ยุบรวม ผลลัพธ์ที่ได้ยังคงรักษาทุกแถวดั้งเดิมไว้

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

รูปแบบ window function จำเป็นเมื่อ query ต้องการทั้งรายละเอียดระดับแถวและบริบทของการรวมข้อมูลพร้อมกัน ซึ่งเป็นความต้องการทั่วไปในการตรวจสอบคุณภาพข้อมูลและ reporting pipeline

2. จะเพิ่มประสิทธิภาพ query ที่ช้าบนตาราง fact ที่มี 500 ล้านแถวอย่างไร

แนวทางที่มีโครงสร้างจะได้ผลดีที่สุด:

1. ตรวจสอบ execution plan (EXPLAIN ANALYZE) เพื่อระบุ full table scan, hash join บนคอลัมน์ที่ไม่มี index หรือการล้นไปดิสก์
2. แบ่ง partition ตาราง ตามวันที่หรือคอลัมน์อื่นที่มีความหลากหลายสูงและสอดคล้องกับ filter ของ query
3. เพิ่ม index แบบเจาะจง บนคอลัมน์ที่ถูก filter บ่อย แต่ต้องหลีกเลี่ยงการทำ index มากเกินไป (แต่ละ index เพิ่มภาระในการเขียน)
4. สร้างผลลัพธ์กลางแบบ materialize หาก subquery เดียวกันถูกใช้ซ้ำบน dashboard หลายอัน
5. ดัน predicate ลง เพื่อ filter ตั้งแต่ต้น ลดปริมาณข้อมูลที่ shuffle ระหว่าง stage

สัญญาณสำคัญที่ผู้สัมภาษณ์มองหา: ความเข้าใจว่าการเพิ่มประสิทธิภาพเป็นกระบวนการที่ทำซ้ำและขึ้นกับบริบท ไม่ใช่แค่ checklist

3. อธิบาย CTE กับ subquery กับ temporary table ใช้แต่ละแบบเมื่อไหร่

CTE (Common Table Expression) ช่วยเพิ่มความอ่านง่ายและรองรับ query แบบ recursive query engine ส่วนใหญ่จะ inline CTE เข้าไป ทำให้ประสิทธิภาพเทียบเท่ากับ subquery ส่วน temporary table จะ materialize ข้อมูลในเชิงกายภาพ ซึ่งช่วยได้เมื่อผลลัพธ์กลางเดียวกันถูกใช้ใน query downstream หลายอันในหนึ่ง session ส่วน subquery เหมาะกับการแปลงข้อมูลแบบง่ายและใช้ครั้งเดียว

หลักการทั่วไป: ใช้ CTE เพื่อความชัดเจน, temp table เพื่อการใช้ซ้ำ, และ subquery สำหรับ filter inline ที่ไม่ซับซ้อน

สำหรับการเจาะลึกรูปแบบ SQL ขั้นสูง โปรดดู SQL for Data Analysts: Window Functions, CTEs and Advanced Queries

ETL เทียบกับ ELT และสถาปัตยกรรม Data Pipeline

คำถามเกี่ยวกับการออกแบบ pipeline จะทดสอบความคิดเชิงสถาปัตยกรรม ผู้สัมภาษณ์ต้องการเห็นการวิเคราะห์การแลกเปลี่ยน ไม่ใช่การเชียร์เครื่องมือ

4. ETL กับ ELT: จะเลือกแบบไหนเมื่อใด

| เกณฑ์ | ETL | ELT | |----------|-----|-----| | ตำแหน่งการแปลง | ก่อนโหลด (compute ภายนอก) | หลังโหลด (compute ใน warehouse) | | เหมาะสำหรับ | ระบบ legacy, schema ที่เข้มงวด | cloud warehouse (BigQuery, Snowflake) | | ความยืดหยุ่นของ schema | ต่ำ (การแปลงล็อก schema ตั้งแต่ต้น) | สูง (ข้อมูลดิบพร้อมสำหรับการแปลงใหม่) | | โมเดลต้นทุน | compute นอก warehouse | ต้นทุน compute warehouse เพิ่มตามการแปลง | | ความสดของข้อมูล | latency สูงกว่า (ขั้น transform) | latency ต่ำกว่า (โหลดก่อน, transform ตามต้องการ) |

ELT ครองตลาดใน stack cloud-native สมัยใหม่เพราะ storage ราคาถูก, compute ขยายได้แบบยืดหยุ่น และการเก็บข้อมูลดิบช่วยให้ schema พัฒนาได้ ส่วน ETL ยังคงมีความเกี่ยวข้องเมื่อข้อกำหนดด้านกฎหมายบังคับให้มีการแปลงข้อมูลก่อนเข้า warehouse (เช่น การปกปิด PII)

5. ออกแบบ data pipeline แบบ idempotent ทำไมความเป็น idempotency จึงสำคัญ

ความเป็น idempotency รับประกันว่าการรัน pipeline หลายครั้งด้วย input เดียวกันจะได้ผลลัพธ์เหมือนกันโดยไม่มีการซ้ำซ้อนของข้อมูล สิ่งนี้สำคัญเพราะ pipeline ล้มเหลวและถูก retry ได้

กลยุทธ์การใช้งาน:

• รูปแบบ upsert (MERGE หรือ INSERT ... ON CONFLICT) โดยใช้ natural key หรือ composite key
• Partition overwrite: แทนที่ทั้ง partition ของวันที่แทนการ append
• Deduplication ที่ขั้นเขียน: กำหนด ID แบบ deterministic (hash ของ business key + event timestamp)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

แนวทางนี้รับประกันว่าการ retry การรันของวันที่ 11 เมษายนจะแทนที่ partition ของวันที่ 11 เมษายน ไม่ใช่การเพิ่มแถวซ้ำซ้อน

6. Data lineage คืออะไร และเหตุใดจึงสำคัญใน pipeline production

Data lineage ติดตามต้นกำเนิด การเคลื่อนย้าย และการแปลงข้อมูลตลอดทั้ง pipeline ซึ่งตอบคำถามว่า: ตัวเลขนี้มาจากไหน, มีการแปลงอะไรบ้าง และระบบ downstream ใดที่พึ่งพาข้อมูลนี้

คุณค่าในเชิงปฏิบัติ: เมื่อ dashboard แสดงค่าที่ไม่คาดคิด lineage ช่วยให้วิเคราะห์สาเหตุรากเหง้าได้ในเวลาไม่กี่นาทีแทนที่จะเป็นชั่วโมง เครื่องมืออย่าง OpenLineage, dbt docs และ lineage แบบ cloud-native (column-level lineage ของ BigQuery) ช่วยทำให้สิ่งนี้เป็นอัตโนมัติ

Streaming และการประมวลผลข้อมูลแบบ Real-Time

คำถามเกี่ยวกับ streaming ได้เปลี่ยนจาก "Kafka คืออะไร" ไปสู่การตัดสินใจเชิงสถาปัตยกรรมว่าเมื่อใดและอย่างไรที่จะใช้ streaming

7. Batch กับ streaming: จะตัดสินใจใช้แบบไหนอย่างไร

การตัดสินใจขึ้นอยู่กับความต้องการด้าน latency ไม่ใช่ความชอบทางเทคโนโลยี:

• Batch: ยอมรับได้เมื่อผู้บริโภคข้อมูลยอมรับความล่าช้าในระดับนาทีถึงชั่วโมง สร้าง, ทดสอบ และ debug ง่ายกว่า มีต้นทุนการดำเนินงานต่ำกว่าสำหรับ workload ส่วนใหญ่
• Streaming: จำเป็นเมื่อตรรกะทางธุรกิจขึ้นอยู่กับความสดของข้อมูลระดับต่ำกว่านาที: การตรวจจับการฉ้อโกง, การกำหนดราคาแบบ real-time, dashboard แบบ live
• Micro-batch: ทางสายกลางที่ใช้ได้จริง (เช่น Spark Structured Streaming) ให้ความใกล้เคียงกับ real-time พร้อมความเรียบง่ายแบบ batch

คำตอบที่แข็งแกร่งที่สุดจะยอมรับว่า pipeline ส่วนใหญ่ควรเริ่มต้นเป็น batch และย้ายไปเป็น streaming เมื่อ SLA ด้าน latency ที่เป็นรูปธรรมเรียกร้องเท่านั้น

8. อธิบายสถาปัตยกรรมของ Kafka: topic, partition, consumer group

Kafka จัดระเบียบข้อมูลเป็น topic (ช่องทางตรรกะ) แต่ละ topic แบ่งออกเป็น partition (log ที่มีลำดับและเปลี่ยนแปลงไม่ได้) กระจายอยู่บน broker ต่างๆ Producer เขียน record ลงใน partition (แบบ round-robin หรือตาม key) Consumer group ทำให้การอ่านเป็นแบบขนาน: แต่ละ partition ถูกกำหนดให้กับ consumer หนึ่งตัวเท่านั้นภายใน group ซึ่งเปิดทางให้มีการขยายในแนวนอน

การแลกเปลี่ยนหลัก: partition มากขึ้นเพิ่มความขนาน แต่เพิ่มภาระให้ broker (file handle, replication) จุดเริ่มต้นทั่วไปคือ 6-12 partition ต่อ topic และขยายตามความต้องการ throughput

9. จะจัดการกับข้อมูลที่มาถึงช้าใน streaming pipeline อย่างไร

ข้อมูลที่มาถึงช้าเป็นสิ่งที่หลีกเลี่ยงไม่ได้ในระบบแบบกระจาย มีสามแนวทาง:

1. Watermark: กำหนดเกณฑ์ (เช่น 10 นาที) ที่เกินไปแล้วข้อมูลที่มาช้าจะถูกทิ้ง Apache Flink และ Spark Structured Streaming รองรับสิ่งนี้โดยกำเนิด
2. Reprocessing window: รันการรวมข้อมูลใหม่เป็นระยะสำหรับ window เวลาล่าสุดเพื่อเก็บข้อมูลที่มาช้า
3. Delta/upsert sink: เขียนไปยัง store ที่เปลี่ยนแปลงได้ (Delta Lake, Apache Iceberg) ที่รองรับการ update ทำให้ record ที่มาช้าสามารถแก้ไขผลลัพธ์ก่อนหน้าได้

แนวทางที่เหมาะสมขึ้นอยู่กับว่าผู้บริโภค downstream ต้องการความหมายแบบ exactly-once หรือสามารถยอมรับความสอดคล้องแบบ eventual ได้

Data Modeling และการออกแบบ Schema

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

10. Star schema กับ snowflake schema: การแลกเปลี่ยนคืออะไร

Star schema ทำการ denormalize ตาราง dimension ให้เป็นตารางแบน กว้าง ที่ join กับตาราง fact กลาง ในขณะที่ snowflake schema ทำการ normalize dimension ให้เป็น sub-dimension

| ด้าน | Star | Snowflake | |--------|------|-----------| | ประสิทธิภาพ query | เร็วกว่า (join น้อยกว่า) | ช้ากว่า (join มากกว่า) | | Storage | สูงกว่า (ข้อมูลซ้ำซ้อน) | ต่ำกว่า (normalize แล้ว) | | ความซับซ้อน | เข้าใจง่าย | ความสัมพันธ์ซับซ้อนกว่า | | การบำรุงรักษา | อัปเดต dimension ยากกว่า | อัปเดต sub-dimension ง่ายกว่า | | เหมาะสำหรับ | BI/รายงาน (read-heavy) | สถานการณ์ที่ต้องการการ normalize ที่เข้มงวด |

ในทางปฏิบัติ star schema ครองตลาดใน analytics warehouse (BigQuery, Snowflake, Redshift) เนื่องจากประสิทธิภาพ query และความเรียบง่ายเหนือกว่าการประหยัด storage ศึกษาเพิ่มเติมใน โมดูลสัมภาษณ์ data modeling

11. Slowly changing dimension (SCD) คืออะไร อธิบาย Type 1, 2 และ 3

SCD ติดตามวิธีที่คุณสมบัติของ dimension เปลี่ยนแปลงไปตามเวลา:

• Type 1: เขียนทับค่าเดิม ไม่มีประวัติ เรียบง่ายแต่สูญเสียข้อมูล
• Type 2: เพิ่มแถวใหม่พร้อมการติดตามเวอร์ชัน (valid_from, valid_to, is_current) เก็บประวัติทั้งหมด เป็นที่นิยมที่สุดใน warehouse production
• Type 3: เพิ่มคอลัมน์สำหรับค่าก่อนหน้า (current_city, previous_city) ประวัติจำกัด (ติดตามการเปลี่ยนแปลงเพียงครั้งเดียว)

Type 2 เป็นตัวเลือกเริ่มต้นสำหรับ dimension ทางธุรกิจส่วนใหญ่ (ที่อยู่ลูกค้า, หมวดหมู่สินค้า, แผนกพนักงาน) เนื่องจาก audit trail และการรายงานย้อนหลังต้องการสิ่งนี้

12. จะ model ข้อมูล event อย่างไรให้รองรับทั้ง real-time analytics และการจัดเก็บระยะยาว

แนวทางแบบสองชั้น:

1. Hot layer: stream event เข้า store แบบ real-time (Apache Druid, ClickHouse หรือ Materialized View ใน warehouse) ที่ปรับให้เหมาะกับการรวมข้อมูลแบบ low-latency บนข้อมูลล่าสุด
2. Cold layer: นำ event ดิบเข้า lakehouse (Delta Lake, Iceberg) แบ่ง partition ตามวันที่ เก็บไว้ไม่จำกัดสำหรับการวิเคราะห์แบบ ad-hoc และการทำ feature engineering สำหรับ ML

Hot layer ใช้ schema แบบ pre-aggregated หรือ denormalized เพื่อความเร็ว ส่วน cold layer เก็บรายละเอียดทั้งหมด job การกระทบยอดเป็นระยะจะตรวจสอบว่าทั้งสองชั้นตรงกัน

Apache Spark และการประมวลผลแบบกระจาย

คำถามเกี่ยวกับ Spark เน้นการเข้าใจเรื่องความขนานและประสิทธิภาพ ไม่ใช่แค่การเรียก API

13. อะไรทำให้เกิด data skew ใน Spark และจะแก้อย่างไร

Data skew เกิดขึ้นเมื่อ partition หนึ่งมีข้อมูลไม่ได้สัดส่วนกับ partition อื่น ทำให้ task เดียวกลายเป็นคอขวดของ stage ทั้งหมด

สาเหตุที่พบบ่อย: การ join บน key ที่มีค่าบางค่าครอบงำ (key ที่เป็น null, product ID ยอดนิยมเพียงตัวเดียว) หรือการ partition ตามคอลัมน์ที่มีความหลากหลายต่ำ

วิธีแก้ไข:

• Salting: เพิ่ม suffix แบบสุ่มเข้ากับ key ที่ skew, join บน key ที่ salted แล้ว จากนั้นรวมข้อมูลเพื่อลบ salt ออก
• Broadcast join: หากฝั่งหนึ่งมีขนาดเล็กพอ (โดยปกติ <200MB) ให้ broadcast เพื่อหลีกเลี่ยง shuffle ทั้งหมด
• AQE (Adaptive Query Execution): Spark 3.x+ สามารถตรวจจับและแยก partition ที่ skew ได้อัตโนมัติขณะ runtime

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

วิธีนี้จะกระจายภาระงานอย่างสม่ำเสมอให้กับ executor ต่างๆ กำจัดคอขวดได้

14. อธิบายความแตกต่างระหว่าง transformation กับ action ใน Spark

Transformation (map, filter, select, join) เป็นแบบ lazy: สร้างแผนเชิงตรรกะแต่ไม่ได้เรียกใช้งานอะไรเลย ส่วน action (count, collect, write) จะเป็นตัวกระตุ้นให้เกิดการคำนวณจริงโดยส่งแผนไปยัง cluster

การประเมินแบบ lazy นี้ช่วยให้ Catalyst optimizer ของ Spark จัดลำดับการดำเนินการใหม่ ดัน predicate ลง และกำจัด shuffle ที่ไม่จำเป็นก่อนที่ข้อมูลใดๆ จะเคลื่อนย้าย การเข้าใจความแตกต่างนี้เป็นสิ่งจำเป็นสำหรับการ debug: transformation ที่ดูช้าจริงๆ แล้วไม่มีปัญหา คอขวดอยู่ที่ action ที่เรียกใช้มัน

15. ความแตกต่างระหว่าง repartition() กับ coalesce() คืออะไร

repartition(n) ทำการ full shuffle เพื่อสร้าง partition จำนวน n ตัวพอดี กระจายข้อมูลอย่างสม่ำเสมอ ใช้เพื่อเพิ่มความขนานหรือปรับสมดุล partition ที่ skew

coalesce(n) ลดจำนวน partition โดยไม่มีการ shuffle โดยการรวม partition ที่อยู่ติดกัน ใช้เพื่อลดจำนวน partition ก่อนเขียน (หลีกเลี่ยงไฟล์เล็กๆ จำนวนมาก)

กฎ: coalesce เพื่อลดจำนวน, repartition เพื่อเพิ่มหรือปรับสมดุลใหม่

Orchestration และการจัดการ Pipeline

คำถามเกี่ยวกับ orchestration จะทดสอบความสมบูรณ์ในการดำเนินงาน: pipeline รัน, ล้มเหลว และฟื้นตัวอย่างไรใน production

16. เปรียบเทียบ Airflow, Dagster และ Prefect จะเลือกใช้แต่ละอันเมื่อใด

| คุณสมบัติ | Airflow | Dagster | Prefect | |---------|---------|---------|--------| | ความสมบูรณ์ | สมบูรณ์ที่สุด, ชุมชนใหญ่ที่สุด | กำลังเติบโต, แข็งแกร่งในทีม ML/data | Cloud-first, DX ดี | | abstraction หลัก | DAG ของ task | Asset (เน้นข้อมูลเป็นหลัก) | Flow และ task | | การทดสอบ | ยากกว่า (ระดับ DAG) | ทดสอบ asset ในตัว | ทดสอบระดับ task ดี | | Dev บนเครื่อง local | ต้องใช้ Docker/container | รันแบบ local โดยกำเนิด | รันแบบ local โดยกำเนิด | | เหมาะสำหรับ | ETL ซับซ้อน, รันนาน | Data mesh / ทีมเน้น asset | ทีมที่ต้องการโครงสร้างพื้นฐานน้อย |

Airflow ยังเป็นมาตรฐานอุตสาหกรรมสำหรับ data platform ที่สมบูรณ์แล้ว Dagster เหมาะกับทีมที่คิดในเชิง data asset มากกว่าลำดับของ task ส่วน Prefect ดึงดูดทีมที่ต้องการ orchestration แบบ Airflow แต่มีภาระการดำเนินงานน้อยกว่า สำหรับการเตรียมสัมภาษณ์เฉพาะ Airflow โปรดดู โมดูล Airflow fundamentals

17. จะจัดการกับความล้มเหลวของ pipeline และการแจ้งเตือนใน production อย่างไร

กลยุทธ์จัดการความล้มเหลวระดับ production ประกอบด้วย:

1. Retry พร้อม backoff: ความล้มเหลวชั่วคราว (timeout ของเครือข่าย, ข้อจำกัด rate ของ API) จะแก้ได้ด้วย retry แบบ exponential
2. Dead-letter queue: message ที่มีปัญหาจะถูกส่งไปยัง queue แยกเพื่อการตรวจสอบด้วยตนเองโดยไม่บล็อก pipeline
3. Circuit breaker: หลังจาก N ครั้งของความล้มเหลวติดต่อกัน ให้หยุด pipeline และแจ้งเตือนแทนที่จะท่วมระบบ downstream ด้วยข้อมูลที่ไม่ดี
4. Observability: log ที่มีโครงสร้าง, metric (ระยะเวลา task, จำนวนแถว, อัตราการผิดพลาด) และการตรวจสอบคุณภาพข้อมูล (Great Expectations, dbt test) ในแต่ละ stage ของ pipeline
5. ระดับการแจ้งเตือน: P1 (pipeline ล่ม, ข้อมูลหาย) ปลุก on-call ส่วน P2 (คุณภาพข้อมูลเลื่อน) ส่งแจ้งเตือนทาง Slack สำหรับวันทำการถัดไป

18. อะไรทำให้ pipeline "พร้อมสำหรับ production" เทียบกับ prototype

ความพร้อมสำหรับ production หมายถึง: การรันแบบ idempotent, การ retry อัตโนมัติ, การ monitor และแจ้งเตือน, การตรวจสอบข้อมูลที่ขั้น ingestion และ transformation, เอกสาร data contract, การนิยาม pipeline แบบควบคุมด้วย version control และเส้นทาง rollback ที่ผ่านการทดสอบแล้ว ส่วน prototype ไม่มีสิ่งเหล่านี้ ช่องว่างระหว่างทั้งสองเป็นที่ที่หนี้ทางเทคนิคของ pipeline ส่วนใหญ่สะสม

Cloud Data Platform และสถาปัตยกรรม Lakehouse

คำถามเกี่ยวกับ cloud platform จะประเมินว่าผู้สมัครเข้าใจเรื่องต้นทุน, ขนาด และการแลกเปลี่ยนเชิงสถาปัตยกรรมเหนือกว่า syntax เฉพาะของผู้ให้บริการหรือไม่

19. Lakehouse คืออะไร และทำไมจึงกลายเป็นสถาปัตยกรรมที่ครองตลาด

Lakehouse ผสมผสานความยืดหยุ่นของ data lake (schema-on-read, การเก็บข้อมูลดิบ, รูปแบบไฟล์หลากหลาย) เข้ากับความน่าเชื่อถือของ data warehouse (ACID transaction, การบังคับ schema, การเพิ่มประสิทธิภาพ query) เทคโนโลยีอย่าง Delta Lake, Apache Iceberg และ Apache Hudi ทำสิ่งนี้ได้โดยการเพิ่มชั้น metadata/transaction ลงบน object storage (S3, GCS, ADLS)

Lakehouse ชนะเพราะมันกำจัดชั้น ETL ที่มีต้นทุนสูงระหว่าง lake และ warehouse รองรับทั้ง query แบบ BI และ workload แบบ ML บนข้อมูลเดียวกัน และใช้ประโยชน์จาก object storage ราคาถูก

20. จะเพิ่มประสิทธิภาพต้นทุนของ cloud warehouse อย่างไร (BigQuery, Snowflake, Redshift)

กลยุทธ์การเพิ่มประสิทธิภาพต้นทุน:

• Partition และ cluster ตาราง เพื่อลดจำนวน byte ที่ scan ต่อ query
• ตั้งค่าขนาด warehouse ให้เหมาะสม (Snowflake) หรือ slot reservation (BigQuery) ตามรูปแบบของ workload
• Auto-suspend ทรัพยากรที่ไม่ได้ใช้งาน: warehouse ของ Snowflake ควร auto-suspend หลังจาก 1-5 นาทีที่ไม่มี activity
• Monitor ต้นทุนต่อ query: view INFORMATION_SCHEMA.JOBS ของ BigQuery เปิดเผย query ที่มีต้นทุนสูง
• ใช้ materialized view สำหรับการรวมข้อมูลที่ถูกคำนวณซ้ำๆ
• Archive ข้อมูลเย็น ไปยังชั้น storage ที่ถูกกว่าด้วย lifecycle policy

สัญญาณในการสัมภาษณ์: ผู้สมัครที่คิดถึงต้นทุนในฐานะข้อจำกัดทางวิศวกรรมชั้นหนึ่ง ไม่ใช่เรื่องที่คิดทีหลัง

Data Quality และ Governance

คำถามเกี่ยวกับคุณภาพข้อมูลแยกแยะ engineer ที่ ship pipeline กับคนที่ดูแล data platform ที่น่าเชื่อถือ

21. จะใช้การตรวจสอบคุณภาพข้อมูลใน pipeline อย่างไร

การตรวจสอบคุณภาพข้อมูลควรอยู่ในสามขั้นตอน:

1. Ingestion: ตรวจสอบความสอดคล้องของ schema, ตรวจ primary key ที่เป็น null, ยืนยันเกณฑ์จำนวนแถวเทียบกับต้นทาง
2. Transformation: ยืนยันกฎทางธุรกิจ (เช่น รายได้ > 0, วันที่อยู่ในช่วงที่ถูกต้อง), ตรวจสอบ referential integrity ข้ามตาราง
3. Serving: monitor การเลื่อนของ metric (การลดลง 50% อย่างกะทันหันของผู้ใช้งานรายวันมักบ่งชี้ปัญหา pipeline ไม่ใช่การเปลี่ยนแปลงทางธุรกิจ)

เครื่องมือ: dbt test (schema และแบบ custom), Great Expectations, Soda Core, Monte Carlo (data observability) วิธีที่ดีที่สุดคือการรวมการตรวจสอบเข้ากับ DAG ของ pipeline โดยตรงเพื่อให้ความล้มเหลวบล็อกการประมวลผล downstream

22. Data contract คืออะไร และมันป้องกันการพังของ pipeline อย่างไร

Data contract คือข้อตกลงที่เป็นทางการระหว่างผู้ผลิตข้อมูลและผู้บริโภค โดยระบุ: schema (ชื่อคอลัมน์, ประเภท, ความสามารถในการเป็น null), SLA ด้านความสด (ข้อมูลพร้อมภายใน 6 โมงเช้า UTC), ความคาดหวังด้านปริมาณ (ระหว่าง 1 ล้านถึง 10 ล้านแถวต่อวัน) และกฎทางความหมาย (field สถานะมีเพียง ACTIVE, INACTIVE, SUSPENDED)

เมื่อผู้ผลิตเปลี่ยน schema โดยไม่อัปเดต contract การตรวจสอบอัตโนมัติจะจับความไม่ตรงกันได้ก่อนที่จะแพร่ไปยัง downstream สิ่งนี้เปลี่ยนความล้มเหลวของ pipeline จากการเสียหายของข้อมูลแบบเงียบไปสู่ข้อผิดพลาดที่ชัดเจนและสามารถดำเนินการได้

System Design และสถาปัตยกรรม

รอบ system design เป็นมาตรฐานสำหรับตำแหน่ง data engineering ระดับกลางถึง senior คำถามเหล่านี้ทดสอบการคิดแบบ end-to-end

23. ออกแบบ real-time analytics pipeline สำหรับแพลตฟอร์ม e-commerce

การออกแบบที่ดีจะครอบคลุม:

Ingestion: event clickstream และ event ธุรกรรมไหลเข้าสู่ topic ของ Kafka แบ่ง partition ตาม user_id เพื่อรับประกันลำดับภายใน session ของผู้ใช้

Processing: job ของ Flink หรือ Spark Structured Streaming บริโภคจาก Kafka, เสริม event ด้วยข้อมูล catalog สินค้า (broadcast join จากตาราง dimension), คำนวณการรวมข้อมูลในระดับ session และช่วง 5 นาที

Serving: metric ที่รวมแล้วถูกนำเข้าสู่ store OLAP แบบ real-time (ClickHouse หรือ Apache Druid) สำหรับ query dashboard ที่มี latency ต่ำกว่าหนึ่งวินาที ส่วน event ดิบถูกนำเข้า Delta Lake/Iceberg สำหรับการวิเคราะห์ย้อนหลัง

คุณภาพข้อมูล: schema registry (Confluent หรือ AWS Glue) ตรวจสอบ schema ของ event ที่ขั้น ingestion การตรวจสอบคุณภาพข้อมูลแบบ streaming จะแจ้งความผิดปกติ (การลดลงอย่างกะทันหันของปริมาณ event) และส่งไปยัง topic แบบ dead-letter

การจัดการความล้มเหลว: offset ของ consumer ใน Kafka เปิดทางให้มีการประมวลผลแบบ exactly-once ด้วย checkpointing job แบบ streaming จะรีสตาร์ทอัตโนมัติจาก checkpoint ล่าสุดเมื่อเกิดความล้มเหลว

24. จะย้าย pipeline ETL แบบ legacy ไปยัง stack สมัยใหม่อย่างไร

การย้ายดำเนินตามรูปแบบ strangler fig:

1. ตรวจสอบ: จัดทำรายการ pipeline ที่มีอยู่ทั้งหมด, แหล่งที่มา, การแปลง และผู้บริโภค ระบุการพึ่งพาและ SLA
2. รันขนาน: สร้าง pipeline ใหม่เคียงข้างอันเดิม ทั้งสองบริโภคแหล่งที่มาเดียวกันและเขียนไปยัง target แยก
3. การตรวจสอบ: เปรียบเทียบผลลัพธ์ระหว่าง pipeline เก่าและใหม่ query การกระทบยอดอัตโนมัติแจ้งความแตกต่าง
4. Cutover: เมื่อผลลัพธ์ตรงกันภายในเกณฑ์ที่ยอมรับได้เป็นเวลา 2 สัปดาห์ขึ้นไป ให้สลับผู้บริโภคไปยัง target ใหม่ เก็บ pipeline เก่าในโหมดอ่านอย่างเดียวสำหรับการ rollback
5. ยกเลิกใช้งาน: หลังจากช่วงความเสถียร ปิด pipeline แบบ legacy

ประเด็นสำคัญ: อย่าทำการย้ายแบบ big-bang เด็ดขาด รันทั้งสองระบบขนานกันจนกว่าจะสร้างความมั่นใจได้

25. Dashboard ที่สำคัญแสดงตัวเลขที่ไม่ถูกต้อง อธิบายกระบวนการ debug ของคุณ

แนวทางแบบมีระบบ:

1. กำหนดขอบเขตของปัญหา: metric ใดที่ผิด ตั้งแต่เมื่อไหร่ ทุก dimension หรือ filter ที่เฉพาะเจาะจง
2. ตรวจสอบชั้น serving: query warehouse โดยตรงเพื่อยืนยันว่าปัญหาอยู่ที่เครื่องมือ dashboard (caching, ตรรกะ filter) หรือตัวข้อมูลเอง
3. ติดตาม lineage ย้อนหลัง: ติดตามข้อมูลจากตาราง dashboard ย้อนกลับไปในแต่ละขั้นตอนการแปลง ตรวจสอบจำนวนแถวและ metric สำคัญในแต่ละ stage
4. ระบุจุดที่แตก: stage ที่ค่าที่คาดไว้แตกต่างจากค่าจริงคือตำแหน่งของสาเหตุรากเหง้า
5. ตรวจสอบสาเหตุที่พบบ่อย: การเปลี่ยนแปลง schema ในระบบต้นทาง, การรัน pipeline ที่ล้มเหลวโดยไม่ถูกแจ้งเตือน, ข้อมูลที่มาถึงช้าและพลาด window ประมวลผล หรือการ deploy ที่เปลี่ยนตรรกะการแปลง
6. แก้ไขและป้องกัน: วางแพตช์สำหรับปัญหาทันที, เพิ่มการตรวจสอบคุณภาพข้อมูลที่จะดักจับได้ และอัปเดต runbook

คำถามนี้ทดสอบความเป็นผู้ใหญ่ในการตอบสนองต่อเหตุการณ์ ผู้สัมภาษณ์ต้องการเห็นการคิดที่มีโครงสร้าง ไม่ใช่การเดาแบบสุ่ม

การเตรียมตัวสำหรับสัมภาษณ์งาน Data Engineering

Track เตรียมตัวสัมภาษณ์งาน data engineering บน SharpSkill ครอบคลุมหัวข้อเหล่านี้พร้อมการฝึกฝนแบบ interactive ใน รูปแบบ ETL/ELT, data modeling, Airflow, BigQuery และอื่นๆ

สรุป

• SQL window function, CTE และการเพิ่มประสิทธิภาพ query ยังคงเป็นพื้นฐานไม่ว่าจะระดับใด
• การตัดสินใจ ETL เทียบกับ ELT ควรขับเคลื่อนด้วยความต้องการด้าน latency, ความต้องการด้าน data governance และต้นทุนโครงสร้างพื้นฐาน ไม่ใช่การตามกระแส
• Idempotency, data contract และการตรวจสอบคุณภาพข้อมูล แยก pipeline ระดับ production ออกจาก prototype
• คำถามเกี่ยวกับสถาปัตยกรรม streaming เน้นที่การแลกเปลี่ยน (batch, streaming, micro-batch) มากกว่าความรู้เฉพาะเครื่องมือ
• ตัวเลือก data modeling (star เทียบกับ snowflake, ประเภทของ SCD) ควรสอดคล้องกับรูปแบบการบริโภค ไม่ใช่ทฤษฎี best practice
• คำตอบ system design ควรครอบคลุมการจัดการความล้มเหลว, การเพิ่มประสิทธิภาพต้นทุน และ observability ควบคู่ไปกับเส้นทางปกติ
• ผู้สมัครที่แข็งแกร่งที่สุดแสดงการแก้ปัญหาที่มีโครงสร้างและการใช้เหตุผลอย่างตรงไปตรงมาเกี่ยวกับการแลกเปลี่ยน