บทที่ 3: Designing Good Data Architecture
4 min readData Architecture คืออะไร?
การออกแบบระบบเพื่อรองรับความต้องการข้อมูลที่เปลี่ยนแปลงไป โดยใช้ flexible and reversible decisions ผ่านการประเมิน trade-offs. เป็น subset ของ Enterprise Architecture (ที่ครอบคลุม business, technical, application architecture ด้วย) แบ่งเป็น Operational Architecture (what ต้องทำ) และ Technical Architecture (how จะทำ)
Figure 3-2. Operational and technical data architecture
9 Principles of Good Data Architecture
- Choose Common Components Wisely: เลือกเครื่องมือที่ใช้ร่วมกันทั้งองค์กร ลด silo
- Plan for Failure: ทุกอย่างล้มเหลวได้ ต้องรู้ Availability (ความพร้อมใช้งาน), Reliability (ความน่าเชื่อถือ), RTO (Recovery Time Objective: เวลาที่ยอมรับให้กู้คืนได้), RPO (Recovery Point Objective: ระยะเวลาข้อมูลสูญเสียที่ยอมรับได้)
- Architect for Scalability: scale up (รับ load สูง) และ scale down (ลดต้นทุน), elastic system, scale to zero
- Architecture Is Leadership: data architect ต้อง mentor ทีม ไม่ใช่ command-and-control bottleneck
- Always Be Architecting: มี baseline, target, และ sequencing plan
- Build Loosely Coupled Systems: สื่อสารผ่าน API เท่านั้น (Bezos API Mandate)
- Make Reversible Decisions: เลือก two-way doors เท่าที่ทำได้
- Prioritize Security: zero-trust (ไม่เชื่อใจใครในระบบโดยค่าเริ่มต้น) + shared responsibility model (cloud รับผิดชอบ security of cloud, ผู้ใช้รับผิดชอบ in cloud)
- Embrace FinOps: cost-aware engineering, ระวัง cost attacks
Major Architecture Concepts
| Concept | คำอธิบาย |
|---|---|
| Tight vs Loose Coupling | Loose = สื่อสารผ่าน abstraction layers (API, message bus) |
| Monolith vs Microservices | Monolith ไม่ได้แย่เสมอไป. เริ่มแบบ monolith แล้วแยกเมื่อโต |
| Single vs Multitenant | Multitenant = หลายทีม/ลูกค้าใช้ร่วมกัน → ระวัง noisy neighbor และ data isolation |
| Event-Driven Architecture | Events = สิ่งที่เกิดขึ้นใน business → production → routing → consumption |
| Brownfield vs Greenfield | Brownfield = ปรับปรุงของเดิม, Greenfield = เริ่มใหม่ |
| Distributed Systems & Scalability | Horizontal scaling (leader-follower, เพิ่ม node แทน scale เครื่องเดียว). 4 คุณสมบัติหลัก: Scalability, Elasticity (scale ขึ้น/ลงอัตโนมัติ, บางระบบ scale to zero), Availability, Reliability |
Batch Architectures
- Data Warehouse (Inmon): Top-down: enterprise data warehouse ก่อน → data marts
- Kimball: Bottom-up: star schema (facts + dimensions), data marts ก่อน
- ETL vs ELT: ETL แปลงข้อมูลก่อนโหลดเข้า warehouse ส่วน ELT (นิยมในยุค cloud) โหลด raw data เข้า staging area ก่อน แล้วค่อย transform โดยใช้ compute power ของตัว warehouse เอง
- Cloud Data Warehouse: Redshift → BigQuery/Snowflake. Separate compute from storage, pay-as-you-go
- Data Lake: HDFS (Hadoop Distributed File System)/cloud object storage → มักกลายเป็น data swamp (ที่ทิ้งข้อมูลเละ) ขาด schema management
- Data Lakehouse: Databricks: รวมข้อดี data warehouse (ACID: Atomicity, Consistency, Isolation, Durability) + data lake (object storage, multiple engines)
- Modern Data Stack: cloud-based, plug-and-play, off-the-shelf components
Figure 3-10. Basic data warehouse with ETL: data source → ETL system → warehouse → data marts
Streaming Architectures
- Lambda Architecture: speed layer (streaming) + batch layer. แต่ manage 2 systems → error-prone
- Kappa Architecture: stream-processing platform เป็น backbone เดียว. ยังไม่ widely adopted
- Dataflow Model (Beam): ทุกอย่างคือ events. unbounded = stream, bounded = batch (stream ที่มี window)
Figure 3-14. Lambda architecture: speed layer + batch layer มาบรรจบกันที่ serving layer
Figure 3-15. Kappa architecture: ใช้ stream-processing platform เดียวทำหน้าที่ทั้ง ingestion, storage, serving
Data Mesh (Zhamak Dehghani)
Decentralization ของ monolithic data platform: 4 เสาหลัก:
- Domain-oriented decentralized ownership
- Data as a product
- Self-serve data infrastructure as a platform
- Federated computational governance
Figure 3-18. Simplified example of a data mesh architecture (จากหนังสือ Data Mesh โดย Zhamak Dehghani)
| If your situation is... | Consider |
|---|---|
| Greenfield, ทีมเล็ก, ต้องการเริ่มเร็ว | Kimball (bottom-up, data marts ก่อน) |
| องค์กรใหญ่, ต้องการ standard เดียว | Inmon (top-down, EDW ก่อน) |
| Data หลากหลายประเภท, ยังไม่รู้จะใช้ยังไง | Data Lake → ระวัง data swamp. ลงทุนกับ governance |
| ต้องการ ACID + object storage ราคาถูก | Data Lakehouse (Databricks/Delta Lake) |
| ทีมเล็ก, ไม่อยากจัดการ infra เอง | Modern Data Stack (managed services) |
| หลายทีม, หลาย domain | Data Mesh (domain ownership, data as product) |
| Real-time + batch จำเป็นทั้งคู่ | Lambda → ถ้าซับซ้อนเกิน, ลอง Kappa |
| Real-time อย่างเดียว | Kappa หรือ Dataflow (Beam) |