現(xiàn)代工程界普遍認(rèn)為，數(shù)據(jù)庫系統(tǒng)可以在廣義上分為聯(lián)機(jī)事務(wù)處理（Online Transaction Process，OLTP）和聯(lián)機(jī)分析處理（Online Analyze Process，OLAP）兩種面向不同領(lǐng)域的數(shù)據(jù)庫，OLAP數(shù)據(jù)庫也被稱為數(shù)據(jù)倉庫。從產(chǎn)品上看，有專門面向OLTP的數(shù)據(jù)庫，例如MySQL、PostgreSQL、Oracle等，也有專門面向OLAP的數(shù)據(jù)庫，例如Hive、Greenplum、HBase、ClickHouse等。還有一種嘗試統(tǒng)一兩大類型的HATP（Hybird Analyze Transaction Process）系統(tǒng)，例如TiDB、OceanBase等。

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

▼表1-1 OLAP和OLTP的對(duì)比

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

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

一、數(shù)據(jù)三范式

在規(guī)范化的過程中經(jīng)常使用范式的概念，在數(shù)據(jù)庫理論中共有6種范式，下面挑選3種常用的范式做簡單介紹以方便讀者理解后續(xù)內(nèi)容。

1、第一范式

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

▼表1-2 不滿足第一范式的用戶標(biāo)簽表

2、第二范式

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

▼表1-3 不滿足第二范式的用戶標(biāo)簽表

3、第三范式

第三范式是在第二范式的基礎(chǔ)上，當(dāng)表中的屬性不依賴除主鍵外的其他屬性，即為滿足第三范式。表1-3中，來源名稱是不滿足第三范式的，因?yàn)閬碓疵Q依賴于來源ID，所以需要將來源ID刪除。表1-3經(jīng)過規(guī)范化之后的合格數(shù)據(jù)表應(yīng)該是如表1-4、表1-5所示。

▼表1-4 合格的用戶標(biāo)簽表

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

4、第零范式

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

二、規(guī)范化的意義

一般要求在設(shè)計(jì)業(yè)務(wù)數(shù)據(jù)表時(shí)，需要至少設(shè)計(jì)到第三范式，避免出現(xiàn)數(shù)據(jù)冗余。從表1-3中不難發(fā)現(xiàn)出現(xiàn)了標(biāo)簽名稱和來源名稱的冗余。冗余不僅增加了數(shù)據(jù)大小，更重要的是，冗余的存在會(huì)影響數(shù)據(jù)庫事務(wù)，降低數(shù)據(jù)庫事務(wù)性能。

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

▼表1-6 影響事務(wù)性能的表結(jié)構(gòu)

數(shù)據(jù)庫規(guī)范化的意義在于通過規(guī)范化降低冗余，提高數(shù)據(jù)庫事務(wù)性能。正是基于這個(gè)考慮，在數(shù)據(jù)庫表設(shè)計(jì)中，會(huì)要求將對(duì)數(shù)據(jù)表進(jìn)行規(guī)范化。

三、規(guī)范化的局限

任何架構(gòu)在有優(yōu)勢的情況下，一定也會(huì)有其局限。對(duì)于規(guī)范化的數(shù)據(jù)表，這句話也同樣適用。規(guī)范化的數(shù)據(jù)表能夠降低冗余，進(jìn)而提高事務(wù)性能。同時(shí)，規(guī)范化的數(shù)據(jù)表無法支撐分析。

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

四、數(shù)倉建模的本質(zhì)

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

在實(shí)際建模過程中，數(shù)倉經(jīng)常提到的寬表本質(zhì)上就是一個(gè)低范式的表。寬表將所有相關(guān)聯(lián)的列全部都整合到一張表中，用于未來的分析，這樣做的好處就是所有相關(guān)信息都在這張寬表中，理論上在進(jìn)行分析時(shí)就不需要進(jìn)行任何join操作了，因?yàn)榭梢灾苯舆M(jìn)行相關(guān)的分析，所以提高了分析速度。這樣做的缺點(diǎn)就是數(shù)據(jù)冗余，從而難以支持事務(wù)能力。

大部分?jǐn)?shù)據(jù)倉庫都是基于低范式數(shù)據(jù)集進(jìn)行優(yōu)化的，讀者在使用OLAP引擎時(shí)一定要時(shí)刻記住這一點(diǎn)，避免將OLTP數(shù)據(jù)庫中的原始高范式數(shù)據(jù)直接用于OLAP分析，否則分析效果可能會(huì)差強(qiáng)人意。而應(yīng)該通過逆規(guī)范化的過程將高范式數(shù)據(jù)集還原為低范式數(shù)據(jù)集，再由OLAP進(jìn)行分析。

五、OLTP和OLAP的底層數(shù)據(jù)模型

OLAP和OLTP的本質(zhì)區(qū)別在于底層數(shù)據(jù)模型的不同。OLAP更適合使用低范式的數(shù)據(jù)表，而OLTP則更適合使用高范式的數(shù)據(jù)表。無論它們之間的功能是否越來越相似，只要其底層數(shù)據(jù)模型不同，那么它們之間的區(qū)別就永遠(yuǎn)存在，結(jié)構(gòu)決定功能。

ClickHouse是一個(gè)面向OLAP的數(shù)倉，很多的優(yōu)化都是面向低范式數(shù)據(jù)模型的，并沒有對(duì)高范式數(shù)據(jù)模型進(jìn)行很好的優(yōu)化。甚至在有些場景下，ClickHouse的join能力會(huì)成為整個(gè)系統(tǒng)的瓶頸。

ClickHouse更適合處理低范式數(shù)據(jù)集，特別是第零范式的數(shù)據(jù)集。ClickHouse對(duì)第零范式的數(shù)據(jù)集進(jìn)行了比較多的優(yōu)化。

六、維度建模

在使用OLAP進(jìn)行數(shù)據(jù)分析時(shí)，需要對(duì)原始數(shù)據(jù)進(jìn)行維度建模，之后再進(jìn)行分析。維度建模理論中，基于事實(shí)表和維度表構(gòu)建數(shù)據(jù)倉庫。在實(shí)際操作中，一般會(huì)使用ODS（Operational Data Store，運(yùn)營數(shù)據(jù)存儲(chǔ)）層、DW（Data Warehouse，數(shù)據(jù)倉庫）層、ADS（Application Data Service，應(yīng)用數(shù)據(jù)服務(wù)）層三級(jí)結(jié)構(gòu)。

1、ODS層

ODS層一般作為業(yè)務(wù)數(shù)據(jù)庫的鏡像。在項(xiàng)目中，數(shù)倉工程師通常通過數(shù)據(jù)抽取工具（例如Sqoop、DataX等）將業(yè)務(wù)庫的數(shù)據(jù)復(fù)制到數(shù)倉的ODS層，供后續(xù)建模使用。ODS層的數(shù)據(jù)結(jié)構(gòu)和業(yè)務(wù)數(shù)據(jù)庫保持一致，建立ODS的原因在于，通過復(fù)制一份數(shù)據(jù)到ODS層，可以避免建模過程直接訪問業(yè)務(wù)數(shù)據(jù)庫，從而對(duì)業(yè)務(wù)數(shù)據(jù)庫帶來影響，避免影響線上業(yè)務(wù)。

2、 DW層

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

在逆規(guī)范化時(shí)，可能會(huì)產(chǎn)生一些中間結(jié)果，這些中間結(jié)果也可以存儲(chǔ)于DW層中，因此在DW中有時(shí)會(huì)再次進(jìn)行細(xì)分，劃分成DWD（Data Warehouse Details，數(shù)據(jù)倉庫明細(xì)）層、DWM（Data Warehouse Middle，數(shù)據(jù)倉庫中間）層、DWS（Data Warehouse Service，數(shù)據(jù)倉庫服務(wù)）層三個(gè)更細(xì)分的層次。

ODS層的數(shù)據(jù)通過清洗后存儲(chǔ)到DWD層，DWD層本質(zhì)上是一個(gè)去除了臟數(shù)據(jù)的高質(zhì)量的低范式的數(shù)據(jù)層。DWD層的數(shù)據(jù)通過聚合，形成寬表并保存到DWM層中。DWM層已經(jīng)是低范式的數(shù)據(jù)層了，可以用于OLAP分析。在某些場景中，可以對(duì)DWM層的數(shù)據(jù)進(jìn)行業(yè)務(wù)重新聚合，以支持更復(fù)雜的業(yè)務(wù)，此時(shí)需要生成的數(shù)據(jù)保存到DWS層中。

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

3、ADS層

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

ADS層數(shù)據(jù)本質(zhì)上面向業(yè)務(wù)的，高度業(yè)務(wù)化的數(shù)據(jù)?？梢哉J(rèn)為是基于DW層分析的結(jié)果，很多情況下是指標(biāo)、標(biāo)簽等計(jì)算結(jié)果。本書在后續(xù)內(nèi)容中使用ADS名詞時(shí)，如無特殊說明，均指基于DW層分析后的業(yè)務(wù)化的結(jié)果。

本文摘編自《ClickHouse性能之巔：從架構(gòu)設(shè)計(jì)解讀性能之謎》，經(jīng)出版方授權(quán)發(fā)布。

關(guān)于作者：陳峰，資深大數(shù)據(jù)專家和架構(gòu)師，ClickHouse技術(shù)專家，滴普科技（2B領(lǐng)域獨(dú)角獸）合伙人兼首席架構(gòu)師。