| name | pipeline-review |
| description | ตรวจโค้ด data pipeline (dbt, Airflow, Spark, SQL scripts) หา failure mode เฉพาะทาง data engineering ที่ code review ทั่วไปมองไม่เห็น — idempotency, backfill, late-arriving data, schema drift, incremental correctness — รายงานเรียงตามความรุนแรงพร้อม file-line และวิธีแก้ Trigger on "ตรวจ pipeline", "pipeline review", "รีวิว dag", "ตรวจ dbt", "รีวิว etl", or when the user asks to review data-pipeline code. |
pipeline-review — หา "พังเงียบ" ก่อนมันหาเรา
หลักที่ถือตลอดการตรวจ: พังเงียบ (job เขียวแต่ข้อมูลผิด) ร้ายแรงกว่าพังดัง (job แดง) เสมอ — เรียง severity ตามนี้ ไม่ใช่ตามลำดับที่เจอ
Phase 0 — อ่านของจริงก่อนตัดสิน
- ระบุ stack จากโครง repo:
dags/ (Airflow), models/ (dbt), Spark jobs, cron + SQL scripts
- ไล่ flow จริงต้นน้ำ→ปลายน้ำอย่างน้อย 1 เส้นเต็มๆ: source → staging → transform → serving — ห้ามตรวจเป็นไฟล์โดดๆ เพราะ failure mode ส่วนใหญ่อยู่ที่รอยต่อ
- หา config ที่ซ่อนพฤติกรรม: schedule, retry policy, incremental strategy, partition keys
Phase 1 — ไล่ 8 เลนส์
| # | เลนส์ | คำถามที่ต้องตอบได้จากโค้ด |
|---|
| 1 | Idempotency | รัน task เดิมซ้ำ (retry/manual rerun) แล้วได้ผลเดิมไหม? INSERT เปล่าๆ = duplicate; ต้องเป็น MERGE / DELETE+INSERT ใน scope / partition overwrite |
| 2 | Backfill | สั่งรันย้อนอดีตได้ไหม? logic ที่ผูก now() / CURRENT_DATE แทน execution date = backfill พังทันที |
| 3 | Late data | ข้อมูลที่มาช้ากว่ารอบประมวลผลหายไปไหน? มี lookback window / watermark ไหม? |
| 4 | Schema drift | ต้นทางเพิ่ม/ลบ/เปลี่ยน type คอลัมน์ แล้วเกิดอะไร — พังดัง (ยังดี) หรือกลืนเงียบ (SELECT *, schema auto-merge = อันตราย) |
| 5 | Incremental correctness | ขอบเขต incremental มีรูไหม — >= vs > ซ้ำ/หล่น, timezone ปน, clock skew ระหว่างระบบ |
| 6 | Partition / performance | full scan ที่ควร prune, filter หลัง join แทนที่จะก่อน, small files, skewed keys |
| 7 | Failure & retry | task ตายกลางทางทิ้ง state ครึ่งๆ ไหม (ตารางชั่วคราวค้าง, ไฟล์เขียนครึ่งเดียว)? retry ปลอดภัยก็ต่อเมื่อข้อ 1 ผ่าน |
| 8 | Observability | รู้ได้ยังไงว่าข้อมูลผิด ไม่ใช่แค่ job ล่ม — row count เทียบรอบก่อน, freshness check, dq tests ครอบ column สำคัญไหม |
เลนส์ไหนไม่เจอปัญหา ข้ามไป — รายงานเฉพาะของจริง อย่า pad รายการให้ดูขยัน
Phase 2 — รายงาน
เรียงตาม severity:
- 🔴 พังเงียบ — ข้อมูลผิด/หาย/ซ้ำ โดยไม่มีใครรู้
- 🟠 พังดัง — job ล้มเมื่อเจอเงื่อนไข (backfill, retry, schema เปลี่ยน)
- 🟡 ประสิทธิภาพ/ต้นทุน — ช้าหรือแพงเกินจำเป็น
- ⚪ โครงสร้าง — ดูแลยาก แต่ยังไม่ผิด
แต่ละข้อ: file:line + สถานการณ์จริงที่จะพัง (เล่าเป็นเหตุการณ์ ไม่ใช่ทฤษฎี) + วิธีแก้ที่เจาะจงกับ stack นั้น + เทสที่กันไม่ให้กลับมา (dbt test / assertion / sensor) ถ้าเขียนได้
กติกา
- ทุก finding ต้องชี้หลักฐานในโค้ดได้ — ห้ามกล่าวหาจาก pattern ทั่วไปโดยไม่เปิดไฟล์ยืนยัน
- ไม่แน่ใจพฤติกรรมของ tool/เวอร์ชัน (dbt incremental strategy, Airflow catchup) ให้เช็คเอกสารจริง ไม่ตอบจากความจำ
- ถ้า user ขอ ให้ลงมือแก้ตามรายงานได้ — แก้ทีละข้อจาก 🔴 ลงมา พร้อมเทสประกบ
