DDIA 導讀 CH1 — 資料密集型系統設計的取捨

《Designing Data-Intensive Applications》一書是劍橋大學分散式系統研究員 Martin Kleppmann 於 2017 年所寫的指南，在出版至今已成為系統設計入門必讀的書籍之一。在 2026 年該書再版，我們將在 2026 年的 E+ 後端主題文中，逐一導讀我們在每個章節讀到的重點，以及從中獲得的學習。

在 《Designing Data-Intensive Applications》的第一與第二版，作者都從全局的角度切入，來談個資料密集型應用系統中，應該要關注的面向。

在第一版中，作者從可靠 (reliability)、可擴展 (scalability) 以及可維護 (maintainability) 這三個角度切入來談 。但在第二版，則是透過「在實務系統設計中，團隊的後端負責人應該做什麼取捨」切入來談。由於作者在第二版可靠、可擴展、可維護等概念融入第二章節，我們在這章會著重在第二版的內容，下一次導讀才會談那三個重要的非功能性需求概念。

回到這本書的標題，作者認為在談資料密集型 (data-intensive) 的應用時，都應與「運算密集型」的應用做區別。對於運算密集型的應用來說，核心重點在於如何加速完成運算，所以探討的重點會著重在運算的併行化處理等方向。

不過資料密集型的應用，著重面向則會偏向如何處理資料，包含

• 如何存資料? (在各式各樣資料庫中，該選哪一種來存)
• 如何加速讀到資料? (例如透過快取等手段)
• 如何讓搜尋與過濾資料變快? (例如透過搜尋索引)
• 如何讓同樣的資料更即時被處理? (例如透過串流)
• 如何讓大量累積的資料被定時處理? (例如透過批次處理)

上面這些問題，每一個都是實務上需要做判斷與選擇的，在後續的章節也會分別展開來談。在第一章節則會先從整體的角度，來談一些實務上需要做的取捨。

系統是事務型 (Operational)還是分析型 (Analytical)?

當一個資料系統所需處理的資料量還不大時，其實不太會有區分的需求，SQL 資料庫的靈活性大，要做事務型或分析型任務都沒問題。然而如果資料量體變大，例如電商平台有數十萬商品、社群媒體有百萬使用者時，如果沒有進一步區分事務型與分析型，而是一個系統處理所有任務，通常會遇到一些問題。

最常見的問題是，因為系統除了後端工程師會用以外，資料分析師、資料科學家也會需要用到。但如果系統大到有百萬、千萬級別的資料，資料分析師要調資料出來時，可能會讓系統變得卡頓。這時如果不請資料分析師暫停手邊的分析工作，會讓使用者因為卡頓而有不好的體驗；但如果請資料分析師暫停，那他們沒辦法做分析，就沒辦法進一步創造商業價值。

正是因為有這種搶資源的衝突，現代的大型、資料密集型系統，多半會拆分不同系統來分別處理這兩類任務。具體來說，可以大致歸類為 Online Transaction Processing (簡稱 OLTP) 來處理事務型任務，以及 Online Analytical Processing (簡稱 OLAP) 來處理分析型任務。

OLTP 系統多半是由後端的不同服務組成，會依據使用者的操作，來執行對應的讀取與修改。OLTP 的特點是單次處理的資料量比較小，例如更新某一筆資料；此外，由於是隨著使用者操作來執行，OLTP 處理的資料都會是當前狀態下最新的。

OLAP 則是資料科學家與分析師在使用的系統。由於需要做分析，OLAP 系統多半不會去做資料的修改，而是會聚焦在查詢。同時，查詢的資料範圍比較大 (例如要找某個商家在過去一年的總收入，就得拉出一整年的營收資料來聚合)。業界中常見的 OLAP 包含 BigQuery、Redshift、Snowflake，或是開源的 ClickHouse 等等。

資料倉儲 （Data Warehouse) 與資料湖 (Data Lake)

前面談到，基於分析的需求，在資料密集型應用中，會在 OLTP 系統外，再多拉出另一個單獨的系統處理分析需求，在這個背景下資料倉儲 （Data Warehouse) 的概念被提出，也一度成為最熱門的 OLAP 選項。

資料倉儲是讓資料科學家與分析師，可以隨心所欲查詢、不用擔心影響到 OLTP 的操作。假如今天在整體系統中，有幾個不同的 OLTP 資料庫，例如處理銷售相關的 Sales DB、處理倉儲相關的 Inventory DB，以及處理送貨路線規劃的 Geo DB，可以透過 ETL 的過程 (Extract-Transform-Load 也就是擷取完資料後做轉換與清洗，最後再匯入) 的方式，存到資料倉儲中。資料科學家與分析師，可以直接對資料倉儲做查詢，不用對 Sales DB 或 Inventory DB 做查詢，這樣就不會影響到後端工程師。

資料倉儲雖然好用，但是有個必須面對的取捨。 ETL 過程會先做轉換 (資料清洗、格式統一化等)，這種預先定義好資料結構再載入的方式，雖然能讓查詢時能用輕易用最佳化的 SQL 語句來查，但同時也降低了彈性。

特別是隨著實驗與分析的需求變複雜，很多資料科學家想用的資料，不屬於傳統關聯資料庫的格式，為了讓資料能夠被各類需求都使用，資料湖 (Data Lake) 的概念被提出。資料湖的概念是 ELT，擷取後就載入，載入後的資料沒有強制特定的格式，僅是作為集合，在要用的時候，再轉換成當下需要的格式，這樣一來就能夠因應各類不同的分析需求。

閱讀更多

以上我們導讀了 DDIA 第一章談到的第一個取捨。除了這個取捨外，書中還有談到兩個實務上常見的取捨，完整版的導讀可以在 E+ 成長計畫中的主題文讀到。

對更深入了解這個主題，以及其他前後端開發、軟體工程、AI 工程主題感興趣的讀者，歡迎加入 E+ 成長計畫一起成長 (連結)。