從數(shù)據(jù)架構(gòu)圖來看，實時數(shù)倉的數(shù)據(jù)架構(gòu)會跟離線數(shù)倉有很多類似的地方。

比如分層結(jié)構(gòu)；比如說 ODS 、DWD、DWS、ADS，它們命名的模式可能都是一樣的。盡管如此，實時數(shù)倉和離線數(shù)倉還是有很多的區(qū)別的。

跟離線數(shù)倉主要不一樣的地方，就是實時數(shù)倉的層次更少一些。

DWD層

以我們目前建設(shè)離線數(shù)倉的經(jīng)驗來看，數(shù)倉的第二層遠遠不止這么簡單，一般都會有一些輕度匯總層這樣的概念，其實第二層會包含很多層。

ADS層

另外一個就是應(yīng)用層，以往建設(shè)數(shù)倉的時候，應(yīng)用層其實是在倉庫內(nèi)部的。在應(yīng)用層建設(shè)好后，會建同步任務(wù)，把數(shù)據(jù)同步到應(yīng)用系統(tǒng)的數(shù)據(jù)庫里。

在實時數(shù)倉里面，所謂 APP 層的應(yīng)用表，實際上就已經(jīng)在應(yīng)用系統(tǒng)的數(shù)據(jù)庫里了。上圖，雖然畫了 APP 層，但它其實并不算是數(shù)倉里的表，這些數(shù)據(jù)本質(zhì)上已經(jīng)存過去了。

為什么主題層次要少一些？

是因為在實時處理數(shù)據(jù)的時候，每建一個層次，數(shù)據(jù)必然會產(chǎn)生一定的延遲。

為什么匯總層也會盡量少建？

是因為在匯總統(tǒng)計的時候，往往為了容忍一部分數(shù)據(jù)的延遲，可能會人為的制造一些延遲來保證數(shù)據(jù)的準確。

舉例，統(tǒng)計事件中的數(shù)據(jù)時，可能會等到 10:00:05 或者 10:00:10再統(tǒng)計，確保 10:00 前的數(shù)據(jù)已經(jīng)全部接受到位了，再進行統(tǒng)計。所以，匯總層的層次太多的話，就會更大的加重人為造成的數(shù)據(jù)延遲。

建議盡量減少層次，特別是匯總層一定要減少，最好不要超過兩層。明細層可能多一點層次還好，會有這種系統(tǒng)明細的設(shè)計概念。

第二個比較大的不同點就是在于數(shù)據(jù)源的存儲。

在建設(shè)離線數(shù)倉的時候，可能整個數(shù)倉都全部是建立在 Hive 表上，都是跑在 Hadoop 上。

但是，在建設(shè)實時數(shù)倉的時候，同一份表，我們甚至可能會使用不同的方式進行存儲。比如常見的情況下，可能絕大多數(shù)的明細數(shù)據(jù)或者匯總數(shù)據(jù)都會存在 Kafka 里面，但是像維度數(shù)據(jù)，可能會存在像 Tair 或者 HBase 這樣的 kv 存儲的系統(tǒng)中，實際上可能匯總數(shù)據(jù)也會存進去