ระบบ CI/CD และการเฝ้าระวังคุณภาพข้อมูล (CI/CD, Monitoring & Testing)

ทฤษฎีและกลไกการทำงาน (How it works): ในการพัฒนาโปรเจกต์ท่อส่งข้อมูลขนาดใหญ่ เราต้องมั่นใจว่าไม่มีโค้ด SQL ที่จัดรูปแย่ หรือไวยากรณ์เออเร่อหลุดลอยขึ้นระบบหลัก ด่านตรวจสอบ CI จะเริ่มจากการรันเครื่องมือ **SQL Linting (เช่น SQLFluff)** ตรวจกฎไวยากรณ์ และรันโปรเซสจำลองแก้ไขสกีมาแบบแห้ง **Dry-Run** (ยิงเช็คแผนการคอมไพล์บนฐานข้อมูลจริงโดยไม่เขียนข้อมูลลงดิสก์) เพื่อดักเออเร่อ

# GitHub Actions CI workflow snippet executing SQLFluff linter checks
name: Data Pipeline CI

on: [push, pull_request]

jobs:
  lint-and-validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install SQLFluff and Lint SQL Files
        run: |
          pip install sqlfluff
          sqlfluff lint models/ --dialect bigquery
                    

Use Case ในชีวิตจริง (Real-world Scenario): มีนักพัฒนาเผลอพิมพ์คอมม่าเกินหรือพิมพ์คำสั่งเชื่อม SQL ตกหล่น ระบบ CI ของบริษัทจะดักจับเจอจุดพังตั้งแต่จังหวะเปิด Pull Request ทำให้บล็อกข้ามข้อบกพร่องไม่ให้ปนเปื้อนเข้าโปรเจกต์หลัก

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเช็ค Dry-Run ในบางฐานข้อมูลคลาวด์อาจมีค่าใช้จ่ายแฝงจากการดึงข้อมูล Metadata แก้ไขโดยเปิดใช้ระบบจดสิทธิ์จำพวก Local Schema Emulator ในขั้นตอนการตรวจสอบ CI

ทฤษฎีและกลไกการทำงาน (How it works): เพื่อหลีกเลี่ยงระบบสืบค้นข้อมูลล่มระหว่างปรับปรุงระบบวิศวกรรมข้อมูลจะนำเทคนิค **Blue-Green Deployment** มาใช้งาน: - **Blue Environment**: สภาพแวดล้อมระบบเดิมที่กำลังเปิดบริการอ่านข้อมูลให้แดชบอร์ดตามปกติ - **Green Environment**: สภาพแวดล้อมสเปคใหม่ที่ถูกติดตั้งไว้ข้างกัน และทำการคำนวณเขียนตารางเสร็จสิ้น เมื่อระบบ Green ประมวลผลและทดสอบผ่าน สัญญาสิทธิ์ชี้เป้าจะสลับชี้พอร์ต (Schema redirection) สลับดึงไปที่ตาราง Green ทันที ช่วยให้ปลายทางไม่พบปัญหาโหลดค้าง

-- SQL demonstrating seamless blue-green schema swapping via aliases
CREATE OR REPLACE VIEW analytical_marts.active_sales_mart AS 
SELECT * FROM analytical_marts.sales_mart_green; -- Swap reference to updated green table
                    

Use Case ในชีวิตจริง (Real-world Scenario): ตารางสรุปพฤติกรรมลูกค้าที่ใช้อ่านข้อมูลหน้าเว็บหลัก สลับสิทธิ์วิวไปหาตารางใหม่ที่เพิ่งอัปเดต โดยลูกค้าหน้าเว็บตรวจไม่พบระยะเวลาหยุดชะงักของบริการเลย

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การสลับ Green สวนทางไปในขณะที่ยังมีคิวรีค้างคาในตาราง Blue ซึ่งอาจส่งผลให้คำสั่งอ่านล้มเหลว แก้ไขโดยตั้งเวลากวาดล้างและยกเลิกขีดเขียนตาราง Blue หลังจากสลับวิวไปแล้ว 30 นาที

ทฤษฎีและกลไกการทำงาน (How it works): ระบบเฝ้าระวังประสิทธิภาพฮาร์ดแวร์ทำงานโดยใช้ **Prometheus** สแกนดึงสถิติตามพอร์ตวิเคราะห์ (Metrics Scraping) เช่น ข้อมูลเปอร์เซ็นต์ RAM, อัตราดิสก์เต็ม, และเวลารันจ๊อบเฉลี่ยของ Airflow/Spark จากนั้นนำประวัติข้อมูลไปพล็อตสรุปภาพจัดเรียงบนกราฟแดชบอร์ด **Grafana** เพื่อช่วยอำนวยความสะดวกในการตรวจจับคอขวดระบบงาน

# Prometheus scraping configuration script for monitoring targets
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'pipecraft-airflow'
    static_configs:
      - targets: ['airflow-statsd-exporter:9102']
  - job_name: 'spark-executors'
    static_configs:
      - targets: ['spark-master:4040']
                    

Use Case ในชีวิตจริง (Real-world Scenario): แดชบอร์ดตรวจสอบสุขภาพระบบพล็อตสถิติการรันจ๊อบ Spark และแจ้งเตือนทีมวิศวกรวิล่วงหน้าเมื่อพบอัตราการกินแรมไต่สูงเกือบเต็มพิกัดโหนด เพื่อส่งทีมวิศวกรเข้าไปช่วยแก้ไขขนาดคลัสเตอร์ก่อนเครื่องจริงจะหยุดทำงาน

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): สถิติ Prometheus บวมโตและกินดิสก์เซิร์ฟเวอร์จนเกือบเต็ม แก้ไขโดยเปิดใช้งานนโยบายจำกัดวันกักเก็บสถิติเก่าล่วงหน้า (Metrics Retention Policy เช่น เก็บประวัตินานเพียง 30 วัน)

ทฤษฎีและกลไกการทำงาน (How it works): ระบบ **Data Quality Observability** ทำหน้าที่วิเคราะห์ลึกกว่าเรื่องความพังของเซิร์ฟเวอร์ โดยจะเข้าไปเฝ้าตรวจนิ่งของตัวเลขข้อมูลดิบ (เช่น จำนวนเรคคอร์ดนำเข้าเฉลี่ยรายวัน, อัตราส่วนฟิลด์ที่เป็น Null, หรือความเบี่ยงเบนของสถิติค่าสูงสุด/ต่ำสุด) เพื่อดักระแสตรรกะข้อมูลเพี้ยน

# Python logic checking raw data quality metrics using Soda SQL / Great Expectations
from great_expectations.dataset import PandasDataset

def validate_dataframe(df):
    ge_df = PandasDataset(df)
    # Define rules: amount column values must be positive and non-null
    res = ge_df.expect_column_values_to_be_between(column="amount", min_value=0.0)
    if not res["success"]:
        raise ValueError("Data Quality Check Failed: Negative sales volumes detected!")
                    

Use Case ในชีวิตจริง (Real-world Scenario): มีโปรแกรมเมอร์ต้นทางแก้ไขโค้ดแอปและยิงข้อมูลยอดเงินซื้อส่งเป็นค่า 0 ดักจับความเบี่ยงเบนระบบ Observability จะสแกนเจอค่าเฉลี่ยตารางลดลงฮวบ และสั่งยกเลิกเพื่อความปลอดภัยของสถิติรายงานธุรกิจ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การรันระบบทดสอบคัดกรองข้อมูลดิบขนาดใหญ่ทุกล็อตรันหน่วงเวลาจ๊อบยาวเกินไป แก้ไขโดยสุ่มประเมินเฉพาะส่วนแบ่งกลุ่มประชากร (Statistical sampling validation) ในขั้นตอนนี้