隨著互聯(lián)網(wǎng)的發(fā)展進(jìn)入下半場(chǎng)，數(shù)據(jù)的時(shí)效性對(duì)企業(yè)的精細(xì)化運(yùn)營(yíng)越來(lái)越重要，商場(chǎng)如戰(zhàn)場(chǎng)，在每天產(chǎn)生的海量數(shù)據(jù)中，如何能實(shí)時(shí)有效的挖掘出有價(jià)值的信息， 對(duì)企業(yè)的決策運(yùn)營(yíng)策略調(diào)整有很大幫助。

其次從智能商業(yè)的角度來(lái)講，數(shù)據(jù)的結(jié)果代表了用戶(hù)的反饋，獲取結(jié)果的及時(shí)性就顯得尤為重要，快速的獲取數(shù)據(jù)反饋能夠幫助公司更快的做出決策，更好的進(jìn)行產(chǎn)品迭代，實(shí)時(shí)數(shù)倉(cāng)在這一過(guò)程中起到了不可替代的作用。

?從數(shù)據(jù)架構(gòu)圖來(lái)看，順風(fēng)車(chē)實(shí)時(shí)數(shù)倉(cāng)和對(duì)應(yīng)的離線(xiàn)數(shù)倉(cāng)有很多類(lèi)似的地方。例如分層結(jié)構(gòu)；比如ODS層，明細(xì)層，匯總層，乃至應(yīng)用層，他們命名的模式可能都是一樣的。但仔細(xì)比較不難發(fā)現(xiàn)，兩者有很多區(qū)別：

• 與離線(xiàn)數(shù)倉(cāng)相比，實(shí)時(shí)數(shù)倉(cāng)的層次更少一些

• 從目前建設(shè)離線(xiàn)數(shù)倉(cāng)的經(jīng)驗(yàn)來(lái)看，數(shù)倉(cāng)的數(shù)據(jù)明細(xì)層內(nèi)容會(huì)非常豐富，處理明細(xì)數(shù)據(jù)外一般還會(huì)包含輕度匯總層的概念，另外離線(xiàn)數(shù)倉(cāng)中應(yīng)用層數(shù)據(jù)在數(shù)倉(cāng)內(nèi)部，但實(shí)時(shí)數(shù)倉(cāng)中，app應(yīng)用層數(shù)據(jù)已經(jīng)落入應(yīng)用系統(tǒng)的存儲(chǔ)介質(zhì)中，可以把該層與數(shù)倉(cāng)的表分離。

• 應(yīng)用層少建設(shè)的好處：實(shí)時(shí)處理數(shù)據(jù)的時(shí)候，每建一個(gè)層次，數(shù)據(jù)必然會(huì)產(chǎn)生一定的延遲。

• 匯總層少建的好處：在匯總統(tǒng)計(jì)的時(shí)候，往往為了容忍一部分?jǐn)?shù)據(jù)的延遲，可能會(huì)人為的制造一些延遲來(lái)保證數(shù)據(jù)的準(zhǔn)確。舉例，在統(tǒng)計(jì)跨天相關(guān)的訂單事件中的數(shù)據(jù)時(shí)，可能會(huì)等到 00:00:05 或者 00:00:10再統(tǒng)計(jì)，確保 00:00 前的數(shù)據(jù)已經(jīng)全部接受到位了，再進(jìn)行統(tǒng)計(jì)。所以，匯總層的層次太多的話(huà)，就會(huì)更大的加重人為造成的數(shù)據(jù)延遲。

• 與離線(xiàn)數(shù)倉(cāng)相比，實(shí)時(shí)數(shù)倉(cāng)的數(shù)據(jù)源存儲(chǔ)不同

• 在建設(shè)離線(xiàn)數(shù)倉(cāng)的時(shí)候，目前滴滴內(nèi)部整個(gè)離線(xiàn)數(shù)倉(cāng)都是建立在 Hive 表之上。但是，在建設(shè)實(shí)時(shí)數(shù)倉(cāng)的時(shí)候，同一份表，會(huì)使用不同的方式進(jìn)行存儲(chǔ)。比如常見(jiàn)的情況下，明細(xì)數(shù)據(jù)或者匯總數(shù)據(jù)都會(huì)存在 Kafka 里面，但是像城市、渠道等維度信息需要借助Hbase，mysql或者其他KV存儲(chǔ)等數(shù)據(jù)庫(kù)來(lái)進(jìn)行存儲(chǔ)。

接下來(lái)，根據(jù)順風(fēng)車(chē)實(shí)時(shí)數(shù)倉(cāng)架構(gòu)圖，對(duì)每一層建設(shè)做具體展開(kāi)：

▍2.1?ODS 貼源層建設(shè)

根據(jù)順風(fēng)車(chē)具體場(chǎng)景，目前順風(fēng)車(chē)數(shù)據(jù)源主要包括訂單相關(guān)的binlog日志，冒泡和安全相關(guān)的public日志，流量相關(guān)的埋點(diǎn)日志等。這些數(shù)據(jù)部分已采集寫(xiě)入kafka或ddmq等數(shù)據(jù)通道中，部分?jǐn)?shù)據(jù)需要借助內(nèi)部自研同步工具完成采集，最終基于順風(fēng)車(chē)數(shù)倉(cāng)ods層建設(shè)規(guī)范分主題統(tǒng)一寫(xiě)入kafka存儲(chǔ)介質(zhì)中。

命名規(guī)范：ODS層實(shí)時(shí)數(shù)據(jù)源主要包括兩種。

• 一種是在離線(xiàn)采集時(shí)已經(jīng)自動(dòng)生產(chǎn)的DDMQ或者是Kafka topic，這類(lèi)型的數(shù)據(jù)命名方式為采集系統(tǒng)自動(dòng)生成規(guī)范為：cn-binlog-數(shù)據(jù)庫(kù)名-數(shù)據(jù)庫(kù)名 eg：cn-binlog-ihap_fangyuan-ihap_fangyuan

• 一種是需要自己進(jìn)行采集同步到kafka topic中，生產(chǎn)的topic命名規(guī)范同離線(xiàn)類(lèi)似：ODS層采用：realtime_ods_binlog_{源系統(tǒng)庫(kù)/表名}/ods_log_{日志名} eg: realtime_ods_binlog_ihap_fangyuan

▍2.2 DWD 明細(xì)層建設(shè)

根據(jù)順風(fēng)車(chē)業(yè)務(wù)過(guò)程作為建模驅(qū)動(dòng)，基于每個(gè)具體的業(yè)務(wù)過(guò)程特點(diǎn)，構(gòu)建最細(xì)粒度的明細(xì)層事實(shí)表；結(jié)合順風(fēng)車(chē)分析師在離線(xiàn)側(cè)的數(shù)據(jù)使用特點(diǎn)，將明細(xì)事實(shí)表的某些重要維度屬性字段做適當(dāng)冗余，完成寬表化處理，之后基于當(dāng)前順風(fēng)車(chē)業(yè)務(wù)方對(duì)實(shí)時(shí)數(shù)據(jù)的需求重點(diǎn)，重點(diǎn)建設(shè)交易、財(cái)務(wù)、體驗(yàn)、安全、流量等幾大模塊；該層的數(shù)據(jù)來(lái)源于ODS層，通過(guò)大數(shù)據(jù)架構(gòu)提供的Stream SQL完成ETL工作，對(duì)于binlog日志的處理主要進(jìn)行簡(jiǎn)單的數(shù)據(jù)清洗、處理數(shù)據(jù)漂移和數(shù)據(jù)亂序，以及可能對(duì)多個(gè)ODS表進(jìn)行Stream Join，對(duì)于流量日志主要是做通用的ETL處理和針對(duì)順風(fēng)車(chē)場(chǎng)景的數(shù)據(jù)過(guò)濾，完成非結(jié)構(gòu)化數(shù)據(jù)的結(jié)構(gòu)化處理和數(shù)據(jù)的分流；該層的數(shù)據(jù)除了存儲(chǔ)在消息隊(duì)列Kafka中，通常也會(huì)把數(shù)據(jù)實(shí)時(shí)寫(xiě)入Druid數(shù)據(jù)庫(kù)中，供查詢(xún)明細(xì)數(shù)據(jù)和作為簡(jiǎn)單匯總數(shù)據(jù)的加工數(shù)據(jù)源。

命名規(guī)范：DWD層的表命名使用英文小寫(xiě)字母，單詞之間用下劃線(xiàn)分開(kāi)，總長(zhǎng)度不能超過(guò)40個(gè)字符，并且應(yīng)遵循下述規(guī)則：realtime_dwd_{業(yè)務(wù)/pub}_{數(shù)據(jù)域縮寫(xiě)}_[{業(yè)務(wù)過(guò)程縮寫(xiě)}]_[{自定義表命名標(biāo)簽縮寫(xiě)}]

• {業(yè)務(wù)/pub}：參考業(yè)務(wù)命名

• {數(shù)據(jù)域縮寫(xiě)}：參考數(shù)據(jù)域劃分部分

• {自定義表命名標(biāo)簽縮寫(xiě)}：實(shí)體名稱(chēng)可以根據(jù)數(shù)據(jù)倉(cāng)庫(kù)轉(zhuǎn)換整合后做一定的業(yè)務(wù)抽象的名稱(chēng)，該名稱(chēng)應(yīng)該準(zhǔn)確表述實(shí)體所代表的業(yè)務(wù)含義
  樣例：realtime_dwd_trip_trd_order_base??

▍2.3 DIM 層

• 公共維度層，基于維度建模理念思想，建立整個(gè)業(yè)務(wù)過(guò)程的一致性維度，降低數(shù)據(jù)計(jì)算口徑和算法不統(tǒng)一風(fēng)險(xiǎn)；

• DIM 層數(shù)據(jù)來(lái)源于兩部分：一部分是Flink程序?qū)崟r(shí)處理ODS層數(shù)據(jù)得到，另外一部分是通過(guò)離線(xiàn)任務(wù)出倉(cāng)得到；

• DIM 層維度數(shù)據(jù)主要使用 MySQL、Hbase、fusion(滴滴自研KV存儲(chǔ))?三種存儲(chǔ)引擎，對(duì)于維表數(shù)據(jù)比較少的情況可以使用 MySQL，對(duì)于單條數(shù)據(jù)大小比較小，查詢(xún) QPS 比較高的情況，可以使用 fusion 存儲(chǔ)，降低機(jī)器內(nèi)存資源占用，對(duì)于數(shù)據(jù)量比較大，對(duì)維表數(shù)據(jù)變化不是特別敏感的場(chǎng)景，可以使用HBase 存儲(chǔ)。

命名規(guī)范：DIM層的表命名使用英文小寫(xiě)字母，單詞之間用下劃線(xiàn)分開(kāi)，總長(zhǎng)度不能超過(guò)30個(gè)字符，并且應(yīng)遵循下述規(guī)則：dim_{業(yè)務(wù)/pub}_{維度定義}[_{自定義命名標(biāo)簽}]：

• {業(yè)務(wù)/pub}：參考業(yè)務(wù)命名

• {維度定義}：參考維度命名

• {自定義表命名標(biāo)簽縮寫(xiě)}：實(shí)體名稱(chēng)可以根據(jù)數(shù)據(jù)倉(cāng)庫(kù)轉(zhuǎn)換整合后做一定的業(yè)務(wù)抽象的名稱(chēng)，該名稱(chēng)應(yīng)該準(zhǔn)確表述實(shí)體所代表的業(yè)務(wù)含義
  樣例：dim_trip_dri_base

▍2.4?DWM 匯總層建設(shè)

在建設(shè)順風(fēng)車(chē)實(shí)時(shí)數(shù)倉(cāng)的匯總層的時(shí)候，跟順風(fēng)車(chē)離線(xiàn)數(shù)倉(cāng)有很多一樣的地方，但其具體技術(shù)實(shí)現(xiàn)會(huì)存在很大不同。

第一：對(duì)于一些共性指標(biāo)的加工，比如pv，uv，訂單業(yè)務(wù)過(guò)程指標(biāo)等，我們會(huì)在匯總層進(jìn)行統(tǒng)一的運(yùn)算，確保關(guān)于指標(biāo)的口徑是統(tǒng)一在一個(gè)固定的模型中完成。對(duì)于一些個(gè)性指標(biāo)，從指標(biāo)復(fù)用性的角度出發(fā)，確定唯一的時(shí)間字段，同時(shí)該字段盡可能與其他指標(biāo)在時(shí)間維度上完成拉齊，例如行中異常訂單數(shù)需要與交易域指標(biāo)在事件時(shí)間上做到拉齊。

第二：在順風(fēng)車(chē)匯總層建設(shè)中，需要進(jìn)行多維的主題匯總，因?yàn)閷?shí)時(shí)數(shù)倉(cāng)本身是面向主題的，可能每個(gè)主題會(huì)關(guān)心的維度都不一樣，所以需要在不同的主題下，按照這個(gè)主題關(guān)心的維度對(duì)數(shù)據(jù)進(jìn)行匯總，最后來(lái)算業(yè)務(wù)方需要的匯總指標(biāo)。在具體操作中，對(duì)于pv類(lèi)指標(biāo)使用Stream SQL實(shí)現(xiàn)1分鐘匯總指標(biāo)作為最小匯總單位指標(biāo)，在此基礎(chǔ)上進(jìn)行時(shí)間維度上的指標(biāo)累加；對(duì)于uv類(lèi)指標(biāo)直接使用druid數(shù)據(jù)庫(kù)作為指標(biāo)匯總?cè)萜?，根?jù)業(yè)務(wù)方對(duì)匯總指標(biāo)的及時(shí)性和準(zhǔn)確性的要求，實(shí)現(xiàn)相應(yīng)的精確去重和非精確去重。

第三：匯總層建設(shè)過(guò)程中，還會(huì)涉及到衍生維度的加工。在順風(fēng)車(chē)券相關(guān)的匯總指標(biāo)加工中我們使用Hbase的版本機(jī)制來(lái)構(gòu)建一個(gè)衍生維度的拉鏈表，通過(guò)事件流和Hbase維表關(guān)聯(lián)的方式得到實(shí)時(shí)數(shù)據(jù)當(dāng)時(shí)的準(zhǔn)確維度

命名規(guī)范：DWM層的表命名使用英文小寫(xiě)字母，單詞之間用下劃線(xiàn)分開(kāi)，總長(zhǎng)度不能超過(guò)40個(gè)字符，并且應(yīng)遵循下述規(guī)則：realtime_dwm_{業(yè)務(wù)/pub}_{數(shù)據(jù)域縮寫(xiě)}_{數(shù)據(jù)主粒度縮寫(xiě)}_[{自定義表命名標(biāo)簽縮寫(xiě)}]_{統(tǒng)計(jì)時(shí)間周期范圍縮寫(xiě)}：

• {業(yè)務(wù)/pub}：參考業(yè)務(wù)命名

• {數(shù)據(jù)域縮寫(xiě)}：參考數(shù)據(jù)域劃分部分

• {數(shù)據(jù)主粒度縮寫(xiě)}：指數(shù)據(jù)主要粒度或數(shù)據(jù)域的縮寫(xiě)，也是聯(lián)合主鍵中的主要維度

• {自定義表命名標(biāo)簽縮寫(xiě)}：實(shí)體名稱(chēng)可以根據(jù)數(shù)據(jù)倉(cāng)庫(kù)轉(zhuǎn)換整合后做一定的業(yè)務(wù)抽象的名稱(chēng)，該名稱(chēng)應(yīng)該準(zhǔn)確表述實(shí)體所代表的業(yè)務(wù)含義

• {統(tǒng)計(jì)時(shí)間周期范圍縮寫(xiě)}：1d:天增量；td:天累計(jì)(全量)；1h:小時(shí)增量；th:小時(shí)累計(jì)(全量)；1min:分鐘增量；tmin:分鐘累計(jì)(全量)
  樣例：realtime_dwm_trip_trd_pas_bus_accum_1min

▍2.5 APP 應(yīng)用層

該層主要的工作是把實(shí)時(shí)匯總數(shù)據(jù)寫(xiě)入應(yīng)用系統(tǒng)的數(shù)據(jù)庫(kù)中，包括用于大屏顯示和實(shí)時(shí)OLAP的Druid數(shù)據(jù)庫(kù)(該數(shù)據(jù)庫(kù)除了寫(xiě)入應(yīng)用數(shù)據(jù)，也可以寫(xiě)入明細(xì)數(shù)據(jù)完成匯總指標(biāo)的計(jì)算)中，用于實(shí)時(shí)數(shù)據(jù)接口服務(wù)的Hbase數(shù)據(jù)庫(kù)，用于實(shí)時(shí)數(shù)據(jù)產(chǎn)品的mysql或者redis數(shù)據(jù)庫(kù)中。

命名規(guī)范：基于實(shí)時(shí)數(shù)倉(cāng)的特殊性不做硬性要求?