บทที่ 5: Data Generation in Source Systems
2 min readประเภทของ Source Systems
| ชนิด | ตัวอย่าง | ลักษณะ |
|---|---|---|
| Files | CSV, JSON, XML, Excel | ใช้แลกเปลี่ยนข้อมูลระหว่างระบบ |
| APIs | REST (REpresentational State Transfer), GraphQL, gRPC, Webhooks | REST = HTTP verbs (GET/POST/PUT/DELETE), GraphQL = ยืดหยุ่นกว่า (query เฉพาะฟิลด์ที่ต้องการ), Webhooks = reverse API (source ส่งให้เราเมื่อมี event) |
| OLTP (Online Transaction Processing — ประมวลผลธุรกรรม) | PostgreSQL, MySQL | เก็บ state ปัจจุบันของ application, ACID, high concurrency (รองรับการทำรายการพร้อมกันจำนวนมาก) |
| OLAP (Online Analytical Processing — วิเคราะห์ข้อมูล) | Columnar databases | สร้างมาเพื่อ analytics queries ขนาดใหญ่ |
| NoSQL (Not Only SQL) | Key-value, Document, Wide-column, Graph, Search, Time series | แต่ละแบบเหมาะกับ use case ต่างกัน — ไม่มี schema ตายตัว, scale แนวนอนได้ดี |
| Message Queues | SQS, RabbitMQ | ส่ง messages แบบ async, message ถูกลบเมื่อ consume |
| Event-Streaming Platforms | Kafka, Kinesis | Append-only log, retain ไว้นาน, replay ได้ |
State vs Events
- CRUD: เก็บ state ปัจจุบัน — record ถูก overwrite
- Insert-Only: insert record ใหม่ทุกครั้ง — เก็บ history แต่ query ซับซ้อน
- CDC (Change Data Capture): จับแต่ change events — insert, update, delete แต่ละครั้ง
CDC — Change Data Capture
การสกัด change events จาก database โดยไม่ต้องทำ full scan:
- Log-based CDC: อ่านจาก database binary log (WAL — Write-Ahead Log, บันทึกการเปลี่ยนแปลงก่อน execute) — นิยมใช้ Debezium + Kafka
- Managed CDC: cloud DB ส่ง event โดยตรง
- ข้อดี: ได้ history ทั้งหมด, ทำ near real-time analytics ได้
- ข้อควรระวัง: กิน resources (memory, disk, CPU, network) — ต้องทดสอบก่อนเปิด production
Consistency Models
- ACID (Atomicity — ทุกอย่างสำเร็จหรือล้มเหลวพร้อมกัน, Consistency — ข้อมูลต้องถูกต้องตามกฎ, Isolation — transactions ไม่รบกวนกัน, Durability — เมื่อ commit แล้วข้อมูลไม่หาย): รับประกันความถูกต้องของข้อมูล — ใช้ใน RDBMS
- BASE (Basically Available — พร้อมใช้เสมอ, Soft-state — state เปลี่ยนได้, Eventual consistency — สักพักจะ consistent เอง): ตรงข้ามกับ ACID — ยอมให้ข้อมูลไม่ consistent ชั่วครู่เพื่อ performance — ใช้ใน NoSQL หลายตัว
- Eventual consistency: ผ่อนปรน consistency เพื่อเพิ่ม performance/scalability แต่เสี่ยง data loss ถ้าไม่เข้าใจผลกระทบ
Communication กับ Source System Owners
สำคัญที่สุดในการทำงานกับ source systems — สร้าง Data Contract (ข้อตกลงว่าข้อมูลอะไร, วิธีไหน, ความถี่เท่าไร), SLA (Service-Level Agreement — ข้อตกลงระดับบริการ)/SLO (Service-Level Objective — เป้าหมายระดับบริการ), feedback loop, และอย่ามอง source systems เป็น "ปัญหาของคนอื่น"