# การออกแบบ Data Warehouse แบบ Kimball กับ Inmon

**URL:** <https://discuss.dataengineercafe.io/t/data-warehouse-kimball-inmon/332>\
**Category:** General Discussion เรื่อง Data Engineering\
**Tags:** data-warehouse, design, kimball, inmon\
**Created:** [July 12, 2022, 11:55am UTC](https://discuss.dataengineercafe.io/t/data-warehouse-kimball-inmon/332 "2022-07-12T11:55:18Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![zkan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dataengineercafe.io/zkan/32/2_2.png) [@zkan](https://discuss.dataengineercafe.io/u/zkan)\
**Post date:** [July 12, 2022, 11:55am UTC](https://discuss.dataengineercafe.io/t/data-warehouse-kimball-inmon/332/1 "2022-07-12T11:55:18Z")

</div>

อยากมาชวนคุยเรื่องการออกแบบ Data Warehouse แบบ Inmon กับ Kimball กันครับ

 ![kimball-vs-inmon](https://canada1.discourse-cdn.com/flex035/uploads/dataengineercafe/original/1X/994e8aa06580ef46b9e80457534f4c5b6c8f1a7c.png)

## Kimball

เค้าจะเรียกว่า Dimensional Data Warehouse จะเป็นการนำข้อมูลจาก source เอามา denormalize ก่อน หรือทำข้อมูลให้ flat ซึ่งหลาย ๆ คนน่าจะรู้จักกันในชื่อ [star schema](https://en.wikipedia.org/wiki/Star_schema) หรือ [snowflake schema](https://en.wikipedia.org/wiki/Snowflake_schema) นั่นเอง

### ข้อดี

- Reporting เร็ว เพราะว่าข้อมูลค่อนข้าง flat แล้ว ไม่ค่อยมีการ join กันระหว่าง table ทำให้ query เร็ว
- User friendly ด้วย โดยเฉพาะฝั่ง business เพราะว่าการมี denormalized form นั้นทำให้เราไม่ต้องมานั่งดูว่ามี tables อะไรบ้างที่มีความสัมพันธ์ต่อกัน และต้องเอามา join กันท่าไหน

### ข้อเสีย

- เราอาจจะได้ complex ETL เพราะการที่จะ denormalize ได้ เราก็ต้องไป join กันหลาย ๆ tables และต้องคอยดูแลบำรุงรักษา ETL ของเราไปเรื่อย ๆ
- เกิด data duplication ในหลาย ๆ data marts (ในกรณีที่เราแยกออกไปทำ star หรือ snowflake schema ให้ในแต่ละ business unit) และจะเริ่มเสียความเป็น single source of truth ไป ถ้าจัดการได้ไม่ดี
- การออกแบบ ๆ Kimball นี่เป็น ongoing process ครับ เราต้องปรับไปเรื่อย ๆ ตาม business ที่เปลี่ยนแปลงไป

## Inmon

เค้าจะเรียกกันว่า Enterprise Data Warehouse เป็นการนำข้อมูลจาก source เอามา clean ก่อน เสร็จแล้วเก็บใน data warehouse และเก็บอยู่ในรูป normalized form เวลาจะยกไปที่ data marts ตาม business unit ต่าง ๆ เราก็ยกไปเฉพาะข้อมูลที่จะใช้สำหรับ business unit นั้น ๆ หรือให้ business unit นั้น ๆ เข้าถึงข้อมูล หรือ table เฉพาะที่เค้าจะใช้งาน

### ข้อดี

- ข้อมูล cleaned และเป็น single source of truth แน่นอนเลย ตรงนี้ใช้ storage น้อยกว่า Kimball และ less data duplication
- มี normalized data structure เลยสามารถทำ analysis แบบไหนก็ได้
- ข้อมูลต่าง ๆ ในองค์กรที่อยู่ใน data warehouse จะค่อนข้างครบ เพราะเอาเข้ามาง่าย ไม่ต้องมา denormalize ก่อน

### ข้อเสีย

- Reporting จะช้าาาา เพราะว่ามีการ join เยอะ เนื่องจากข้อมูลอยู่ในรูปแบบ normalized form
- เกิด isolated data marts ทำให้เวลาเราอยากจะเปรียบเทียบข้อมูลกันระหว่าง 2 business units หรือ departments จะทำได้ลำบาก หรือถ้าอยากทำจริง ๆ ก็อาจจะต้องสร้างอีก mart หนึ่งมาเพื่อเปรียบเทียบข้อมูลกัน

## สุดท้ายเราจะใช้แบบไหนดี?

ก็ใช้มันทั้ง 2 แบบครับ ฮ่า ๆ 🤣

ผมพบว่าในงานจริง ๆ เราไม่สามารถไปจะไปทางใดทางหนึ่งได้เลย โจทย์แต่ละแบบก็ต้องการวิธีแก้ปัญหาที่แตกต่างกันเนอะ สุดท้ายถ้าเราสามารถเลือกในแบบที่เราสามารถ maximize business value ได้ก็จะแจ่มที่สุดแล้ว 😉

ปล. สรุปมาจาก [Let’s Compare the Kimball and Inmon Data Warehouse Architectures](https://www.youtube.com/watch?v=Tff34jj_V-0)

---

<div class="post-metadata">

**Author:** ![kahnwong](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dataengineercafe.io/kahnwong/32/295_2.png) [@kahnwong](https://discuss.dataengineercafe.io/u/kahnwong)\
**Post date:** [July 12, 2022, 4:16pm UTC](https://discuss.dataengineercafe.io/t/data-warehouse-kimball-inmon/332/2 "2022-07-12T16:16:03Z")

</div>

self-service data pipeline enters the chat!

อันนี้น่าจะเป็นปัญหากะ modern data stack คือ

1. engineer เก็บ source data ลง warehouse / lake
2. analysts / analytics engineers ทำ etl / data pipelines
3. อีกพักใหญ่ๆ จะได้ data silos!

ปัญหามีไว้ให้แก้จริงๆ 😂

edit: fix typo

---

<div class="post-metadata">

**Author:** ![zkan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dataengineercafe.io/zkan/32/2_2.png) [@zkan](https://discuss.dataengineercafe.io/u/zkan)\
**Post date:** [July 14, 2022, 12:04am UTC](https://discuss.dataengineercafe.io/t/data-warehouse-kimball-inmon/332/3 "2022-07-14T00:04:27Z")

</div>

เห็นว่าเค้ามีคุยกันเรื่องนี้ใน dbt community ด้วย

> **[Is Kimball dimensional modeling still relevant in a modern data warehouse?](https://discourse.getdbt.com/t/is-kimball-dimensional-modeling-still-relevant-in-a-modern-data-warehouse/225)**
>
> Is Kimball dimensional modeling still relevant in a modern data warehouse? We see this discussion a lot on dbt Slack, so I’d love to move it to a Discourse post! Comment below with your thoughts!

> **[Inmon vs Kimball in dbt](https://discourse.getdbt.com/t/inmon-vs-kimball-in-dbt/4507)**
>
> Traditionally in Inmon-style data warehouse design, there is an intermediate layer between the raw “data lake” and mart (dimensional) layers. This is either accomplished with data vault (difficult), or a normalized design (easy). Then marts are...