PipeCraft

Roadmap Progress

ข้อมูลเบื้องต้นเกี่ยวกับวิศวกรรมข้อมูล (Introduction to Data Engineering) Python สำหรับ Data Engineering พื้นฐาน Linux & CLI สำหรับวิศวกรข้อมูล Git สำหรับระบบงานข้อมูลและทีมพัฒนา พื้นฐานเครือข่าย เว็บเทคโนโลยี และระบบกระจายศูนย์ (Web Fundamentals, Networking & Distributed Systems) SQL ขั้นสูง (Window Functions & Optimization) ฐานข้อมูลไม่ใช่เชิงสัมพันธ์ (NoSQL Databases & Modern Stores) การออกแบบโครงสร้างข้อมูล (Star/Snowflake & SCD) โครงสร้างพื้นฐานเครือข่ายระบบคลาวด์ (Cloud-based Networking) สถาปัตยกรรม Data Lakehouse (Apache Iceberg & MinIO) Local-first Data Engineering ด้วย DuckDB โครงสร้างพื้นฐานในรูปแบบโค้ด (IaC ด้วย Terraform) การแปลงข้อมูลระดับโปรด้วย dbt-core ข้อตกลงร่วมด้านข้อมูล (Data Contracts) การบริการและการส่งต่อข้อมูลวิเคราะห์ (Data Serving & Reverse ETL) การประมวลผลข้อมูลขนาดใหญ่แบบกระจายด้วย Apache Spark ระบบจัดการเวิร์กโฟลว์ข้อมูล (Airflow, Dagster & Prefect) การประมวลผลข้อมูลแบบเรียลไทม์ด้วย Kafka & Redpanda การจัดการคอนเทนเนอร์และคลัสเตอร์ (Containers & Kubernetes) ระบบ CI/CD และการเฝ้าระวังคุณภาพข้อมูล (CI/CD, Monitoring & Testing) ระบบความปลอดภัยและการควบคุมข้อมูล (Security, Governance & Privacy) ระบบปฏิบัติการและประมวลผลโมเดล (Machine Learning & MLOps) รากฐานของ AWS VPC การจัดการเส้นทางขั้นสูงและ NAT Gateway การเชื่อมต่อหลาย VPC และ Hybrid Cloud VPC Endpoints (PrivateLink) ระบบรักษาความปลอดภัยขอบเขตเครือข่าย สถาปัตยกรรมเครือข่ายสำหรับ EKS IPv6 และการจัดการ IP Address สถาปัตยกรรมเครือข่ายระดับโลก แก่นแท้ของสถาปัตยกรรม Kubernetes สถาปัตยกรรมเครื่องและคอมโพเนนต์ เลเยอร์ที่เชื่อมต่อได้ (Pluggable Layers) การรันบนโปรดักชันระดับองค์กร Apache Flink Stateful Stream Processing Real-Time CDC & Event Sourcing at Scale Low-Latency Stream-Table Joins & Windowing Data Lineage & Metadata Graph Engineering Statistical Anomaly Detection & Data Drift Data Incident Management & Automated DLQ Remediation Cloud Data FinOps & Cost Optimization Mechanics Data Mesh & Multi-Tenant Platform Architecture Vector Databases & AI-Ready Data Infrastructure API Fundamentals, Architectures & Core Components API Versioning, Docs, Real-Time & Microservices Production Reliability, Security & Resiliency World-Class Master Architecture & Traffic Management
บทที่ 9: วิศวกรรมความน่าเชื่อถือและการเฝ้าระวังข้อมูล (Data Quality & Reliability)

Data Lineage & Metadata Graph Engineering

Data Lineage & Observability

การติดตามการไหลเวียนของข้อมูลและสังเกตการณ์ความสมบูรณ์ของระบบ

1. OpenLineage Standard

⚙️ทฤษฎีและกลไกการทำงาน

OpenLineage เป็นมาตรฐานเปิดสำหรับคอลเลกชัน metadata ที่เกี่ยวกับ lineage โดยทำหน้าที่เป็นภาษากลางในการสื่อสารระหว่างเครื่องมือประมวลผลข้อมูล (เช่น Airflow, Spark, dbt) กับระบบ catalog (เช่น Marquez, DataHub, Apache Atlas) การทำงานตั้งอยู่บนหลักการของการปล่อยเหตุการณ์ (Event Emission) ทุกครั้งที่ Job เริ่มหรือเสร็จสิ้น โดยบรรจุข้อมูล Run, Job, Dataset, และ Facets (รายละเอียดเสริม)

💻ตัวอย่างโค้ดหรือการตั้งค่า

การตั้งค่า OpenLineage ใน Airflow (`airflow.cfg`):

[openlineage]
transport = {"type": "http", "url": "http://marquez:5000", "endpoint": "api/v1/lineage"}
namespace = my_production_pipeline
extractors = airflow.providers.openlineage.extractors.bash.BashExtractor

🌍Use Case ในชีวิตจริง

เมื่อรายงานผู้บริหารพังเนื่องจากคอลัมน์ `revenue` ใน Data Warehouse เปลี่ยนประเภทข้อมูล ทีม Data Engineering ใช้ Marquez (ที่รับข้อมูล OpenLineage) เพื่อไล่สายกลับไป (Root Cause Analysis) จนพบว่า Spark job ที่ดึงข้อมูลจากระบบ ERP ต้นทาง มีการเปลี่ยน schema โดยไม่ได้แจ้งล่วงหน้า

⚠️ข้อควรระวังและวิธีแก้

Pitfall: การส่ง Lineage event ที่มีขนาดใหญ่มากเกินไปจาก Spark SQL ที่มี query ซับซ้อน ทำให้ HTTP endpoint ทำงานช้าหรือ timeout
Mitigation: ใช้ Kafka transport แทน HTTP สำหรับระบบสเกลใหญ่ เพื่อให้การส่ง event เป็นแบบ asynchronous และเพิ่ม buffer ป้องกันคอขวด

2. Apache Atlas Graph Queries & Blast Radius Analysis

⚙️ทฤษฎีและกลไกการทำงาน

Apache Atlas เก็บข้อมูล metadata และ lineage ในรูปแบบ Graph Database (ใช้ JanusGraph/HBase ด้านหลัง) ทำให้เราสามารถสืบค้น (Query) ความสัมพันธ์ของข้อมูลได้อย่างรวดเร็ว Blast Radius Analysis คือการใช้ Graph Traversal เพื่อประเมินว่า หากตารางต้นทาง (Source) เสียหายหรือเปลี่ยนแปลง จะมีตารางปลายทางและแดชบอร์ดใดบ้างที่ได้รับผลกระทบ

💻ตัวอย่างโค้ดหรือการตั้งค่า

ตัวอย่างการใช้ Gremlin-style query เพื่อหา Impact (Downstream):

// REST API Payload หา entity ที่ได้รับผลกระทบใน 3 ระดับ
{
  "guid": "c76d2962-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "direction": "OUTPUT",
  "depth": 3,
  "limit": 100
}

🌍Use Case ในชีวิตจริง

ทีมพัฒนาซอฟต์แวร์ต้องการลบตาราง `user_profiles_v1` ในฐานข้อมูลหลัก Data Engineer รัน Blast Radius Analysis ผ่าน Atlas และพบว่าโมเดล Machine Learning ในฝ่ายการตลาดยังคงพึ่งพาฟีเจอร์จากตารางนี้อยู่ ทำให้สามารถระงับการลบและวางแผน migration ได้ทัน

⚠️ข้อควรระวังและวิธีแก้

Pitfall: Graph query อาจใช้ทรัพยากรมหาศาลและ timeout หากระบบมี nodes มากและค้นหาด้วย depth ที่ลึกเกินไป
Mitigation: ควรจำกัด parameter `depth` ไม่เกิน 3-5 ระดับ และทำ caching สำหรับตารางหลักที่มีการสืบค้นบ่อย

🛠️Weekend Sandbox Challenge

เป้าหมาย: สร้าง pipeline ทดสอบพร้อมติดตั้ง OpenLineage

  1. ติดตั้ง Airflow และ Marquez ผ่าน Docker Compose
  2. ตั้งค่า OpenLineage transport ใน Airflow ชี้ไปที่ Marquez
  3. เขียน DAG สั้นๆ ที่มี 2 tasks (Extract, Load) และรัน DAG
  4. เปิดหน้า UI ของ Marquez เพื่อตรวจสอบ Lineage graph ที่ปรากฏขึ้นโดยอัตโนมัติ

🗣️Senior Technical Interview Q&As

Q: การทำ Data Lineage แบบ Column-level แตกต่างจาก Table-level อย่างไรในแง่ของความซับซ้อนและประโยชน์?

A: Table-level บอกแค่ว่าตาราง A ไปตาราง B แต่ Column-level เจาะจงว่าคอลัมน์ x จากตาราง A นำไปสู่คอลัมน์ y ในตาราง B ความซับซ้อนคือต้องทำ SQL Parsing ในระดับ AST (Abstract Syntax Tree) เพื่อวิเคราะห์ SELECT/JOIN ให้ถูกต้อง ประโยชน์คือทำให้ประเมินผลกระทบกรณี PII (ข้อมูลส่วนบุคคล) หรือการเปลี่ยนชนิดข้อมูลได้แม่นยำมาก ไม่ต้องรื้อโค้ดหาเอง

Q: หากเราใช้เครื่องมือที่ไม่รองรับ OpenLineage โดยตรง จะเชื่อมต่อระบบ Lineage อย่างไร?

A: เราสามารถสร้าง Custom Extractor หรือยิง HTTP REST API ของ OpenLineage ด้วยตัวเอง (Custom HTTP requests) ภายในโค้ดของเรา เพื่อส่ง Job/Run/Dataset events ตามมาตรฐาน schema ของ OpenLineage เมื่อทำงานเสร็จหรือเกิด error

Deep Dive & Production Architecture

Architecture Diagram
Technical Architecture Diagram block with Step-by-Step Breakdown

🟢 Basic Level (ปูพื้นฐานภาษาเข้าใจง่าย / Core Concepts)

ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): แนวคิดพื้นฐานของการวางโครงสร้างระบบให้ทำงานได้อย่างถูกต้อง ตั้งแต่การเชื่อมต่อเครือข่าย การกำหนดขอบเขตทรัพยากร ไปจนถึงการสื่อสารระหว่างส่วนประกอบต่างๆ ในระบบคลาวด์

ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): โครงสร้างการตั้งค่าเบื้องต้น

# Basic Structural Configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: basic-system-config
data:
  mode: "development"
  log_level: "info"

Use Case ในชีวิตจริง (Real-world Scenario): ระบบแอปพลิเคชันภายในองค์กร หรือบริการทั่วไปที่มีปริมาณการใช้งานคงที่ ที่เน้นความง่ายในการจัดการและแก้ไขปัญหา

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การละเลยการตั้งค่าความปลอดภัยพื้นฐาน แนะนำให้ใช้เครื่องมือตรวจสอบอัตโนมัติ (Linter/Scanner) ตั้งแต่ขั้นตอนการพัฒนา

🟡 Intermediate Level (โค้ด/คอนฟิกไวยากรณ์จริง / Real Implementation)

ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): การออกแบบสถาปัตยกรรมระดับกลางที่คำนึงถึงความทนทาน (Resiliency) การขยายตัว (Scalability) และการควบคุมเส้นทางการส่งข้อมูลเครือข่ายอย่างมีประสิทธิภาพ

ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): การกำหนด Network Policy และ Resource Limits

# Intermediate Access Control & Scaling
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-gateway-policy
spec:
  podSelector:
    matchLabels:
      role: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: myproject

Use Case ในชีวิตจริง (Real-world Scenario): แพลตฟอร์มอีคอมเมิร์ซที่มียอดผู้ใช้งานเพิ่มขึ้นแบบฉับพลันในบางช่วงเวลา (Spike Traffic) เช่น ช่วงแคมเปญส่งเสริมการขาย

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การคอนฟิก Policy ผิดพลาดอาจทำให้ Service ตัดขาดจากระบบ เฝ้าระวังด้วยการทดสอบการเชื่อมต่อ (Connectivity Test) ทุกครั้งที่เปลี่ยนค่า

🔴 Professional Level (Under-the-hood & Performance/FinOps)

ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): การวิเคราะห์เชิงลึกไปถึงการทำงานระดับ Kernel (เช่น eBPF) และการทำ Optimization ทรัพยากรคลาวด์ พร้อมกับการนำแนวคิด FinOps มาใช้ควบคุมค่าใช้จ่ายโดยไม่ลดทอนประสิทธิภาพ

ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): การปรับจูน Resource ควบคู่กับ HPA และ Node Affinity

# Professional FinOps & Performance Tuning
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: high-performance-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: data-processor
  minReplicas: 3
  maxReplicas: 150
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

Use Case ในชีวิตจริง (Real-world Scenario): ระบบ Streaming Data Platform ระดับโลกที่ต้องประมวลผลข้อมูลระดับ Petabytes ต่อวัน พร้อมจัดการ Cost Optimization ขั้นสูง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเกิด OOMKilled แบบเงียบๆ หรือปัญหา Cloud Cost Spikes ควรตั้งแจ้งเตือนผ่าน Budget Alerts และทำ Profiling ประสิทธิภาพแอปพลิเคชันอย่างสม่ำเสมอ

🏢 Real-World Enterprise Scenario (เคสระบบการเงิน/Big Tech)

ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): โครงสร้างระบบสำหรับองค์กรขนาดใหญ่ที่เน้น Multi-Region Active-Active, การทำ Disaster Recovery (DR) อัตโนมัติ, และการปฏิบัติตามมาตรฐานความปลอดภัยขั้นสูงสุด (Compliance & Governance)

ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): Infrastructure as Code (IaC) สำหรับ Enterprise Environment

# Enterprise Multi-AZ Infrastructure
module "enterprise_core_network" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
  
  name = "prod-banking-core-vpc"
  cidr = "10.100.0.0/16"
  azs  = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
  
  private_subnets = ["10.100.1.0/24", "10.100.2.0/24", "10.100.3.0/24"]
  public_subnets  = ["10.100.101.0/24", "10.100.102.0/24", "10.100.103.0/24"]
  
  enable_nat_gateway = true
  single_nat_gateway = false
  one_nat_gateway_per_az = true
  
  enable_vpn_gateway = true
}

Use Case ในชีวิตจริง (Real-world Scenario): ระบบ Core Banking ของธนาคารข้ามชาติ หรือระบบ Payment Gateway ที่ต้องมี Uptime 99.999% และห้ามมีข้อมูลสูญหาย (Zero Data Loss)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ความล้มเหลวระดับศูนย์ข้อมูล (Data Center Outage) แก้ไขด้วยสถาปัตยกรรม Multi-Region failover อัตโนมัติ และซ้อมแผน Disaster Recovery ทุกไตรมาส