現代工程界普遍認為，數據庫系統可以在廣義上分為聯機事務處理（Online Transaction Process，OLTP）和聯機分析處理（Online Analyze Process，OLAP）兩種面向不同領域的數據庫，OLAP數據庫也被稱為數據倉庫。從產品上看，有專門面向OLTP的數據庫，例如MySQL、PostgreSQL、Oracle等，也有專門面向OLAP的數據庫，例如Hive、Greenplum、HBase、ClickHouse等。還有一種嘗試統一兩大類型的HATP（Hybird Analyze Transaction Process）系統，例如TiDB、OceanBase等。

表1-1列出了OLAP和OLTP的一些對比。近年來，隨著技術的發展，OLAP和OLTP之間的界限也在不斷模糊，幾年前OLAP數據庫都不支持事務，近幾年已經出現了一些支持簡單事務的OLAP引擎，ClickHouse也將簡單的事務支持列入Roadmap。另外，隨著分布式技術的發展，部分OLTP數據庫也能處理更大的數據，甚至廠商推出的HATP數據庫，從而直接打破了兩者的界限。

▼表1-1 OLAP和OLTP的對比

OLAP和OLTP在功能上越來越趨于一致，使得在有些場景下OLAP和OLTP可以相互取代，這是否意味著原有分類方法失效了呢？是否未來就不再需要數倉或者不再需要事務數據庫？ClickHouse的極致性能優化能否推動OLAP和OLTP融合？回答這些問題需要理清OLAP和OLTP分類的本質。

OLTP數據庫在進行數據庫設計時使用實體-關系模型（Entity-Relationship Model，E-R Model，簡稱ER模型）。在ER模型的建模過程中有一個非常重要的規范化過程。規范化的目的在于通過一系列手段使得數據庫設計符合數據規范化（Normal Form，NF）的原則。簡單地說，規范化是將數據表從低范式變成高范式的過程。一般情況下，在OLTP中通常將數據規范化為第三范式（3NF）。

一、數據三范式

在規范化的過程中經常使用范式的概念，在數據庫理論中共有6種范式，下面挑選3種常用的范式做簡單介紹以方便讀者理解后續內容。

1、第一范式

第一范式指表中的每個屬性都不可分割，滿足上述條件即滿足第一范式。表1-2展示了一個不滿足第一范式的例子，由于本例中的標簽字還可以細分為性別、年齡、是否為VIP用戶等多個屬性，因此不滿足第一范式。

▼表1-2 不滿足第一范式的用戶標簽表

2、第二范式

第二范式是在第一范式的基礎上，當表中的所有屬性都被主鍵的所有部分唯一確定，即為滿足第二范式。表1-3展示了一個不滿足第二范式的例子，本例中用戶ID和標簽ID組成了主鍵，標簽名稱這兩個屬性只依賴于標簽ID，用戶所在地只依賴于用戶ID，這兩個屬性都不依賴由用戶ID和標簽ID組成的主鍵。從而不滿足第二范式。刪除標簽名稱和用戶所在地即可使得表格滿足第二范式。

▼表1-3 不滿足第二范式的用戶標簽表

3、第三范式

第三范式是在第二范式的基礎上，當表中的屬性不依賴除主鍵外的其他屬性，即為滿足第三范式。表1-3中，來源名稱是不滿足第三范式的，因為來源名稱依賴于來源ID，所以需要將來源ID刪除。表1-3經過規范化之后的合格數據表應該是如表1-4、表1-5所示。

▼表1-4 合格的用戶標簽表

▼表1-5 合格的用戶信息表

4、第零范式

不滿足第一范式的所有情況都被稱為第零范式。表1-2所示的是其中一種情況。數據庫理論中并沒有對第零范式的嚴格定義，由于作者在本書寫作過程中會經常使用第零范式的模型設計，因此在本書中，如果沒有特別說明，第零范式特指存在Map或數組結構的一類表。這類“第零范式”的表設計具備一定的實際意義，在作者的工作中，經常會用到這類設計。靈活應用這類第零范式，可能會收獲意想不到效果。

二、規范化的意義

一般要求在設計業務數據表時，需要至少設計到第三范式，避免出現數據冗余。從表1-3中不難發現出現了標簽名稱和來源名稱的冗余。冗余不僅增加了數據大小，更重要的是，冗余的存在會影響數據庫事務，降低數據庫事務性能。

表1-6展示了一個不合格的表設計，請讀者關注最后兩列，很明顯這是不滿足第三范式的一種設計。表中的最后一列“需要權限”用于設置數據權限，表格中的數據意味著第一行和第三行需要admin權限才能查看。正常情況下沒有問題，如果隨著業務的變化，需要將授權級別為“2 – 非公開”的權限改為admin和manager都有權限查看。對于這種需求，如果使用表1-5的設計，就需要進行全表掃描，將數據表中所有的授權級別為2的數據全部進行修改，這會嚴重降低數據庫性能。

▼表1-6 影響事務性能的表結構

數據庫規范化的意義在于通過規范化降低冗余，提高數據庫事務性能。正是基于這個考慮，在數據庫表設計中，會要求將對數據表進行規范化。

三、規范化的局限

任何架構在有優勢的情況下，一定也會有其局限。對于規范化的數據表，這句話也同樣適用。規范化的數據表能夠降低冗余，進而提高事務性能。同時，規范化的數據表無法支撐分析。

以表1-3～表1-5為例，表1-4和表1-5為表1-3進行規范化后的合格用戶標簽表。如果需要按照用戶所在城市來統計年齡分布，是無法單獨使用表1-4完成的。必須對表1-4和表1-5進行連接（join）操作，得到的新表才能用于分析。而在絕大多數數據庫系統中，join操作的過程相對于查詢來說比較慢。

四、數倉建模的本質

通過前文的分析，我們可以得出一個推論：高范式的表適合事務處理，而低范式的表適合分析處理。從中我們可以得出數倉建模的本質：逆規范化。數倉建模本質上就是一個逆規范化的過程，將來自原始業務數據庫的規范化數據還原為低范式的過程，從而用于快速分析。

在實際建模過程中，數倉經常提到的寬表本質上就是一個低范式的表。寬表將所有相關聯的列全部都整合到一張表中，用于未來的分析，這樣做的好處就是所有相關信息都在這張寬表中，理論上在進行分析時就不需要進行任何join操作了，因為可以直接進行相關的分析，所以提高了分析速度。這樣做的缺點就是數據冗余，從而難以支持事務能力。

大部分數據倉庫都是基于低范式數據集進行優化的，讀者在使用OLAP引擎時一定要時刻記住這一點，避免將OLTP數據庫中的原始高范式數據直接用于OLAP分析，否則分析效果可能會差強人意。而應該通過逆規范化的過程將高范式數據集還原為低范式數據集，再由OLAP進行分析。

五、OLTP和OLAP的底層數據模型

OLAP和OLTP的本質區別在于底層數據模型的不同。OLAP更適合使用低范式的數據表，而OLTP則更適合使用高范式的數據表。無論它們之間的功能是否越來越相似，只要其底層數據模型不同，那么它們之間的區別就永遠存在，結構決定功能。

ClickHouse是一個面向OLAP的數倉，很多的優化都是面向低范式數據模型的，并沒有對高范式數據模型進行很好的優化。甚至在有些場景下，ClickHouse的join能力會成為整個系統的瓶頸。

ClickHouse更適合處理低范式數據集，特別是第零范式的數據集。ClickHouse對第零范式的數據集進行了比較多的優化。

六、維度建模

在使用OLAP進行數據分析時，需要對原始數據進行維度建模，之后再進行分析。維度建模理論中，基于事實表和維度表構建數據倉庫。在實際操作中，一般會使用ODS（Operational Data Store，運營數據存儲）層、DW（Data Warehouse，數據倉庫）層、ADS（Application Data Service，應用數據服務）層三級結構。

1、ODS層

ODS層一般作為業務數據庫的鏡像。在項目中，數倉工程師通常通過數據抽取工具（例如Sqoop、DataX等）將業務庫的數據復制到數倉的ODS層，供后續建模使用。ODS層的數據結構和業務數據庫保持一致，建立ODS的原因在于，通過復制一份數據到ODS層，可以避免建模過程直接訪問業務數據庫，從而對業務數據庫帶來影響，避免影響線上業務。

2、 DW層

將數據導入ODS層后，即可對ODS層的數據進行清洗、建模，最終生成DW層的數據。其中生成DW層的本質即為本章提到的逆規范化的過程。由于ODS中的數據本質上是業務數據庫的副本，因此ODS中的數據是高范式的數據，不適合進行OLAP分析。這也導致了在進行OLAP分析前需要將高范式的ODS數據通過一些手段逆規范化到低范式的數據。低范式的數據作為DW層的數據，對外提供分析服務。

在逆規范化時，可能會產生一些中間結果，這些中間結果也可以存儲于DW層中，因此在DW中有時會再次進行細分，劃分成DWD（Data Warehouse Details，數據倉庫明細）層、DWM（Data Warehouse Middle，數據倉庫中間）層、DWS（Data Warehouse Service，數據倉庫服務）層三個更細分的層次。

ODS層的數據通過清洗后存儲到DWD層，DWD層本質上是一個去除了臟數據的高質量的低范式的數據層。DWD層的數據通過聚合，形成寬表并保存到DWM層中。DWM層已經是低范式的數據層了，可以用于OLAP分析。在某些場景中，可以對DWM層的數據進行業務重新聚合，以支持更復雜的業務，此時需要生成的數據保存到DWS層中。

在這3個細分的DW層中，并不是所有場景下都需要齊備的。DW層的本質就是對高范式的數據進行逆規范化，生成低范式數據的過程。讀者只需要把握住這個核心即可，在實際的維度建模過程中，根據業務的實際需求進行建模，不需要在所有的場景下都機械地遵循DWD層、DWM層、DWS層的三層架構。

3、ADS層

ADS層保存供業務使用的數據的結果，DW層的數據可以用于OLAP分析，但分析過程通常比較慢，無法支撐實時的業務需求，因此需要引入ADS層作為緩存，向上支撐業務。同樣的，ADS層也不是必須的，需要根據業務實際來選擇，ClickHouse的高性能計算引擎可以在一定程度上取代ADS層。

ADS層數據本質上面向業務的，高度業務化的數據。可以認為是基于DW層分析的結果，很多情況下是指標、標簽等計算結果。本書在后續內容中使用ADS名詞時，如無特殊說明，均指基于DW層分析后的業務化的結果。

本文摘編自《ClickHouse性能之巔：從架構設計解讀性能之謎》，經出版方授權發布。

關于作者：陳峰，資深大數據專家和架構師，ClickHouse技術專家，滴普科技（2B領域獨角獸）合伙人兼首席架構師。