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

ทฤษฎีและกลไกการทำงาน (How it works): การนำโค้ดขึ้นระบบต้องผ่านด่าน CI/CD อัตโนมัติ (เช่น รัน SQLFluff Linting หรือ Dry-Runs) ในองค์กรที่ต้องการความปลอดภัยสูงและห้ามโค้ดหรือข้อมูลไหลออกสู่อินเทอร์เน็ตสาธารณะ จะไม่ใช้เซิร์ฟเวอร์ CI กลางของ GitHub แต่จะติดตั้ง **GitHub Actions Self-Hosted Runners** ซึ่งเป็นเอเจนต์ที่รันอยู่บนเซิร์ฟเวอร์หรือ Kubernetes Cluster ภายใน VPC ของบริษัทเอง ทำให้สามารถเข้าถึงฐานข้อมูลภายในเพื่อรันเทสได้อย่างปลอดภัย

# GitHub Actions snippet configured for a Self-Hosted Runner
name: Data Pipeline CI (Internal)
on: [push, pull_request]

jobs:
  lint-and-dryrun:
    runs-on: [self-hosted, linux, data-eng-vpc] # Target internal runner
    steps:
      - uses: actions/checkout@v3
      - name: Run SQLFluff and Dry Run against internal Dev DB
        run: |
          pip install sqlfluff
          sqlfluff lint models/ --dialect bigquery
          dbt compile --target dev # Communicates with DB inside private network
                    

Use Case ในชีวิตจริง (Real-world Scenario): ธนาคารแห่งหนึ่งป้องกันไม่ให้เซิร์ฟเวอร์รันไทม์ของ GitHub เข้าถึงฐานข้อมูลลูกค้า การใช้ Self-Hosted Runner ช่วยให้ขั้นตอน CI สามารถยิง Dry-run เช็คความถูกต้องของสกีมากับฐานข้อมูลภายในได้โดยไม่ต้องเปิดพอร์ต Firewall สู่โลกภายนอก

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): หาก Runner ตัวเดิมถูกใช้งานซ้ำๆ (Persistent) อาจมีไฟล์ขยะของเทสรอบก่อนหน้าตกค้างทำให้เทสพัง แก้ไขโดยใช้ Ephemeral Runners (เช่น ARC - Actions Runner Controller บน K8s) ที่จะสร้างและทำลายตัวเองทิ้งทุกครั้งที่รันจบ

ทฤษฎีและกลไกการทำงาน (How it works): เพื่อหลีกเลี่ยงตารางข้อมูลอ่านไม่ได้ระหว่างกำลังโหลด (Downtime) วิศวกรข้อมูลจะนำเทคนิค **Blue-Green Deployment** มาใช้: - **Blue Environment**: ตารางที่กำลังใช้งานจริงให้ Dashboard อ่าน - **Green Environment**: ตารางโคลนสเปคใหม่ที่กำลังถูกประมวลผลอยู่เบื้องหลัง เมื่อระบบ Green ประมวลผลและทดสอบ Data Quality ผ่าน จึงจะใช้คำสั่งสลับ View (Alias swapping) ชี้เป้าไปที่ Green ทันที (Zero Downtime)

-- 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): โมเดลคำนวณรายได้บริษัทต้องใช้เวลาประมวลผล 2 ชั่วโมง ทีมงานใช้เทคนิค Blue-Green รันโค้ดชุดใหม่ใส่ตาราง Green จนเสร็จ แล้วค่อยสลับ View ให้ผู้บริหารดู ทำให้ผู้บริหารไม่เคยเจอตารางที่ว่างเปล่าระหว่าง 2 ชั่วโมงนั้น

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การลบตาราง Blue ทิ้งทันทีอาจทำให้คิวรี่ที่กำลังทำงานอยู่ค้างและล้มเหลว (In-flight query failure) แก้ไขโดยหน่วงเวลารอ (Time-travel/Grace period) ประมาณ 30 นาทีก่อนจะ Drop ตาราง Blue ทิ้ง

ทฤษฎีและกลไกการทำงาน (How it works): การมอนิเตอร์ระดับแพลตฟอร์มใช้ **Prometheus** วิ่งดึง (Scrape) สถิติตัวชี้วัดการทำงาน (Metrics) เช่น CPU, RAM, Network I/O จากพอร์ตของแอปพลิเคชัน (เช่น Airflow statsd หรือ Spark exporter) ตามรอบเวลา จากนั้นนำข้อมูลไปสร้างแดชบอร์ดบน **Grafana** และเขียน **Alert Rules** ประเมินผลแบบเรียลไทม์ หากค่าพุ่งทะลุเกณฑ์ที่กำหนด Grafana จะส่งสัญญาณเตือน (Alert) ออกไปทันที

# Grafana Alerting Rule YAML snippet for high memory usage
apiVersion: 1
groups:
  - orgId: 1
    name: InfrastructureAlerts
    rules:
      - alert: SparkExecutorOOMWarning
        expr: (process_resident_memory_bytes / system_total_memory_bytes) > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Spark Executor {{ $labels.instance }} memory > 85%"
                    

Use Case ในชีวิตจริง (Real-world Scenario): Grafana Alert Rule จับได้ว่า Kafka Broker ตัวหนึ่งมีการใช้งานดิสก์เกิน 85% ติดต่อกัน 5 นาที จึงยิงข้อความเตือนเข้า Slack ทีม Data Platform ก่อนที่ดิสก์จะเต็ม 100% จนระบบล่ม ทำให้ทีมขยายดิสก์ได้ทันเวลา

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ปัญหา Alert Spike หากตั้งเงื่อนไขไวไป (เช่น แรมเกิน 90% แค่ 1 วินาทีก็เตือนเลย) จะสร้างเสียงเตือนขยะ (Alert Fatigue) แก้ไขโดยกำหนดหน่วงเวลาประเมินด้วยคำสั่ง `for: 5m` ใน Alert Rule เพื่อกรอง Noise ออก

ทฤษฎีและกลไกการทำงาน (How it works): แตกต่างจาก Hardware Monitoring ระบบ **Data Observability** จะตรวจสอบเนื้อหาข้อมูล (Data Health) - **Data Drift**: ข้อมูลต้นทางมีลักษณะทางสถิติเปลี่ยนไป (เช่น ค่าเฉลี่ยรายได้ลูกค้าจาก 50,000 พุ่งเป็น 200,000) - **Concept Drift**: พฤติกรรมเป้าหมายเปลี่ยนไปจนทำให้โมเดล ML ไม่แม่นยำเหมือนเดิม เครื่องมือประเมิน (เช่น Great Expectations หรือ Evidently) จะตรวจสอบค่าทางสถิติของข้อมูลทุกแบตช์ก่อนอนุญาตให้โมเดล ML ทำงานต่อ

# Python logic checking for Data Drift using evidently
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset

def check_data_drift(reference_data, current_data):
    report = Report(metrics=[DataDriftPreset()])
    report.run(reference_data=reference_data, current_data=current_data)
    
    if report.as_dict()["metrics"][0]["result"]["dataset_drift"]:
        raise Exception("ALERT: Significant Data Drift Detected. Halting Model Inference.")
                    

Use Case ในชีวิตจริง (Real-world Scenario): ในช่วงโปรโมชั่น 11.11 รูปแบบการซื้อของลูกค้าเปลี่ยนไปอย่างสิ้นเชิง (Concept Drift) ระบบ Observability จับความผิดปกติของสถิติกระจายตัวได้และหยุดการยิงคำสั่งซื้ออัตโนมัติ พร้อมส่งแจ้งเตือนให้ Data Scientist เข้ามาตรวจสอบโมเดล

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การรันตรวจเช็คทางสถิติกับข้อมูลขนาดเพตะไบต์ทุกครั้งจะใช้เวลานานและเปลืองค่าคอมพิวต์ แก้ไขโดยใช้การสุ่มตัวอย่าง (Statistical Sampling) หรือตรวจสอบเฉพาะฟิลด์ที่มีความสำคัญระดับวิกฤต (Critical features)