01 先看來龍， 再談去脈

數(shù)據(jù)倉庫概念興起于上世紀(jì)90年代，隨著IT系統(tǒng)的大發(fā)展， 人們發(fā)現(xiàn)應(yīng)用系統(tǒng)越來越多， 但是對(duì)于經(jīng)營決策的問題， 反而越來越難以獲取準(zhǔn)確的決策信息。

據(jù)說有個(gè)笑話， 發(fā)生在2000年前后，Oracle 總裁Larry 想知道Oracle 全球有多少人。但那時(shí)沒有人知道， 因?yàn)镺racle全球的業(yè)務(wù)系統(tǒng)分布在各個(gè)大洲/各個(gè)國家， 每個(gè)區(qū)域都有自己的應(yīng)用系統(tǒng)，但是沒有一個(gè)全球統(tǒng)一的中央系統(tǒng)， 從而發(fā)生了這么一個(gè)有趣的事。

這也促使Oracle 花費(fèi)大量人力物力， 把分布在各個(gè)不同國家地區(qū)的系統(tǒng)統(tǒng)一上收， 做成全球系統(tǒng)?；谌蚪y(tǒng)一的數(shù)據(jù)進(jìn)行決策分析， 進(jìn)入了Oracle 高速發(fā)展的20年。

其實(shí)很多企業(yè)都會(huì)發(fā)現(xiàn)， 在經(jīng)過了IT系統(tǒng)大規(guī)模建設(shè)之后， 反而越來越難以獲得有效的決策信息，數(shù)據(jù)分散在多個(gè)業(yè)務(wù)系統(tǒng)中， 演變成有大量數(shù)據(jù)， 但是缺乏有效信息的尷尬局面。 一般而言， 有這樣的幾種情況：

? 決策信息分散在多個(gè)業(yè)務(wù)系統(tǒng)中；

? 數(shù)據(jù)的不一致性突出，多個(gè)信息提供者對(duì)信息都不具備嚴(yán)格的定義，不同的業(yè)務(wù)系統(tǒng)對(duì)同一信息數(shù)據(jù)的理解和定義不同，甚至許多相同命名的數(shù)據(jù)所指代的業(yè)務(wù)信息并不相同；

? 缺乏歷史數(shù)據(jù)；

? 業(yè)務(wù)系統(tǒng)的數(shù)據(jù)模型，是針對(duì)事務(wù)處理設(shè)計(jì)的，不適合做分析；

? 在業(yè)務(wù)系統(tǒng)上做信息查詢，會(huì)影響現(xiàn)有系統(tǒng)的運(yùn)行；

? 太多的數(shù)據(jù)，太少的信息。

為了走出重重困境， 數(shù)據(jù)倉庫就自然成了企業(yè)家關(guān)注的焦點(diǎn)，經(jīng)過各行各業(yè)的業(yè)務(wù)實(shí)踐， 雖然也有很多種變種， 但是大體上是個(gè)這樣的結(jié)構(gòu)。

02 數(shù)據(jù)倉庫給企業(yè)帶來了發(fā)展的機(jī)遇， 也帶來了挑戰(zhàn)

數(shù)據(jù)倉庫進(jìn)入中國市場(chǎng)之后， 經(jīng)歷了飛速發(fā)展的十年。在這十年里， 多少IT屆的仁人志士都在這個(gè)賽道上奮斗過， 有很多成功的經(jīng)驗(yàn)， 也有不少失敗的案例。

這里簡(jiǎn)單分享一個(gè)小故事，首先是中國移動(dòng)的經(jīng)營分析系統(tǒng)， 經(jīng)過10多年的發(fā)展， 變成支撐企業(yè)績(jī)效考評(píng)和市場(chǎng)運(yùn)營的重要工具。 我個(gè)人的觀點(diǎn)，中國移動(dòng)能夠后來者居上，力壓其他兩家，和經(jīng)營分析的有力支撐，有著千絲萬縷的關(guān)系。

2015年之后， 中國移動(dòng)基本就沒有再大規(guī)模地推出過經(jīng)營分析建設(shè)規(guī)范， 但是直到如今， 中國移動(dòng)的一級(jí)經(jīng)營分析系統(tǒng)的各省數(shù)據(jù)上收， 還是各省公司考核的重要指標(biāo)。

隨著智能手機(jī)和各種智能終端的快速發(fā)展， 中國移動(dòng)也推出各種新的業(yè)務(wù)和新的模式。這個(gè)時(shí)候， 如何更好地了解客戶，了解客戶的行為習(xí)慣和消費(fèi)模式， 從而有針對(duì)性地推出新業(yè)務(wù)，自然就是市場(chǎng)部門的重要訴求。

手機(jī)用戶在手機(jī)上交友、瀏覽、購物， 娛樂都會(huì)產(chǎn)生大量的日志數(shù)據(jù)， 另外手機(jī)基本上和人是一一綁定的， 那么手機(jī)的定位系統(tǒng)自然也可以了解到用戶的出行情況。但是這些數(shù)據(jù)對(duì)于現(xiàn)有的數(shù)據(jù)倉庫來說， 體量太大了， 要想很好地收集處理， 需要耗費(fèi)巨量的資源。?

舉個(gè)例子，移動(dòng)交換機(jī)每15分鐘會(huì)把當(dāng)前用戶的位置信息吐出， 交給后臺(tái)處理， 這個(gè)數(shù)據(jù)基本上是PB級(jí)的。

另外還有用戶上網(wǎng)日志， 包括網(wǎng)址信息，這些都是非結(jié)構(gòu)化的信息， 也很難納入到當(dāng)前的倉庫模型當(dāng)中， 所以必須使用大數(shù)據(jù)技術(shù)。

談到大數(shù)據(jù)技術(shù)， 那肯定就是Hadoop，但是怎么更好地使用Hadoop技術(shù)， 這時(shí)候就產(chǎn)生一些分歧：

? 一部分人認(rèn)為， Hadoop是全新的技術(shù)， 是可以完全取代傳統(tǒng)數(shù)據(jù)庫進(jìn)行數(shù)據(jù)分析的技術(shù)， 傳統(tǒng)數(shù)據(jù)庫已經(jīng)落伍。

? 另外一部分人認(rèn)為，Hadoop還不夠成熟和普及， 對(duì)于數(shù)據(jù)倉庫的adhoc查詢和分析， 不可能奢望每個(gè)分析人員都會(huì)coding。而是應(yīng)該發(fā)揮Hadoop大數(shù)據(jù)并行處理的優(yōu)勢(shì)， 對(duì)于數(shù)據(jù)進(jìn)行預(yù)處理之后， 再去把結(jié)果導(dǎo)入到數(shù)據(jù)倉庫中。

經(jīng)過一段時(shí)間的沉淀和磨合，現(xiàn)在大家基本上更加認(rèn)可第二種方式。

對(duì)于處理完的海量數(shù)據(jù)，怎么處理呢？

這就是個(gè)兩難選擇， 因?yàn)榇鎯?chǔ)需要成本， 如果存儲(chǔ)數(shù)據(jù)帶來的收益不能cover 存儲(chǔ)成本的話， 那存儲(chǔ)數(shù)據(jù)就不合算。

但是如果覺得數(shù)據(jù)還是很有價(jià)值， 可能有一些目前沒有發(fā)現(xiàn)的價(jià)值，將來還有其他的分析角度和分析需求的時(shí)候， 那么就只有存儲(chǔ)起來。這個(gè)時(shí)候就是數(shù)據(jù)湖（Data lake）了。

03 湖倉一體的主要目標(biāo)就是打破壁壘， 實(shí)現(xiàn)湖倉聯(lián)動(dòng)

Data lake 的主要定位，就是一個(gè)可以持續(xù)擴(kuò)充的海量數(shù)據(jù)存儲(chǔ)， 容量更大， 單位成本更低， 主要用于對(duì)于這些海量數(shù)據(jù)的深度開采， 另外也保存下來以備將來可用。

這個(gè)時(shí)候就有一些問題了。第一個(gè)需求，比如用戶行為分析， 因?yàn)橛脩粜袨榉治龊陀脩舯旧淼膶傩允歉叨汝P(guān)聯(lián)的。但是用戶的所有屬性都是在CRM系統(tǒng)中管理和存儲(chǔ)， 每當(dāng)用戶的屬性發(fā)生變化， 那么如何快速傳遞到數(shù)據(jù)湖， 以免數(shù)據(jù)挖掘系統(tǒng)使用后不準(zhǔn)確的數(shù)據(jù)， 產(chǎn)生不準(zhǔn)確的結(jié)果。?

第二個(gè)需求， 比如， 經(jīng)過數(shù)據(jù)湖中的數(shù)據(jù)挖掘， 對(duì)于現(xiàn)有的數(shù)據(jù)分類、標(biāo)簽等操作， 但是這些比如用戶流失風(fēng)險(xiǎn)評(píng)估， 用戶近期喜好等特性， 最好還是通過統(tǒng)一的用戶界面與用戶進(jìn)行交互。

那么就自然需要把這些數(shù)據(jù)湖中的挖掘結(jié)果，盡快同步到電子渠道系統(tǒng)當(dāng)中去， 這樣才能通過各種渠道媒介與客戶互動(dòng)，避免發(fā)生短信轟炸。

第三個(gè)需求， 就是SQL on hadoop， 這個(gè)是很自然的需求。因?yàn)闊o論如何， 懂SQL的人總是比懂Spark或者Flink的人多。而且絕大多數(shù)的業(yè)務(wù)系統(tǒng)， 目前都是使用SQL 作為主要數(shù)據(jù)處理語言。那么， 如何把數(shù)據(jù)湖中的數(shù)據(jù)規(guī)范化之后， 提供SQL 接口， 讓業(yè)務(wù)系統(tǒng)能夠直接使用SQL訪問數(shù)據(jù)湖中的數(shù)據(jù)， 這也便成了順理成章的需求了。?

所以目前大家所講的湖倉一體化， 歸根到底， 實(shí)際上是針對(duì)數(shù)據(jù)的價(jià)值，并通過技術(shù)手段實(shí)現(xiàn)各層次之間聯(lián)動(dòng)：

高價(jià)值、高使用頻度的數(shù)據(jù)， 放在關(guān)系型數(shù)據(jù)庫中， 有條件可以上全閃或者數(shù)據(jù)庫一體機(jī)， 加快用戶分析效率。

中等價(jià)值的數(shù)據(jù)， 可以考慮多種存儲(chǔ)模式， 或者傳統(tǒng)關(guān)系型， 或者是使用MPP。 更有甚者， 考慮目前市面上的分布式數(shù)據(jù)庫， 都可以做一個(gè)性價(jià)比上的一個(gè)平衡。

當(dāng)然巨量數(shù)據(jù)， 還是優(yōu)先推薦存放在Hadoop， 甚至可以是云空間的對(duì)象存儲(chǔ)上。因?yàn)椴簧貰ig SQL 的外延， 已經(jīng)可以擴(kuò)展到S3之類的對(duì)象存儲(chǔ)上了。這樣就可以把歷史數(shù)據(jù)的存儲(chǔ)成本降到更低。

04 流批一體的目標(biāo)，是進(jìn)一步提高數(shù)據(jù)驅(qū)動(dòng)能力

傳統(tǒng)的數(shù)據(jù)倉庫， 一般都是T+1的數(shù)據(jù)采集模式。因?yàn)橐话愣孕枰^天做了數(shù)據(jù)關(guān)賬， 才能給后臺(tái)提供比較準(zhǔn)確的財(cái)務(wù)數(shù)據(jù)， 后來隨著CDC技術(shù)的發(fā)展， 現(xiàn)在業(yè)務(wù)系統(tǒng)的數(shù)據(jù)變化可以準(zhǔn)實(shí)時(shí)進(jìn)入到數(shù)據(jù)倉庫中。?

但是我們要知道， 數(shù)據(jù)準(zhǔn)實(shí)時(shí)同步， 不一定代表分析數(shù)據(jù)準(zhǔn)實(shí)時(shí)， 因?yàn)槎鄠€(gè)系統(tǒng)之間，可能同步周期不一定相同。

另外，數(shù)據(jù)進(jìn)入數(shù)據(jù)倉庫，還有一個(gè)清晰度和匯總的過程， 如果數(shù)據(jù)倉庫隨時(shí)進(jìn)行海量數(shù)據(jù)的匯總和計(jì)算， 那么計(jì)算量就太大了， 得不償失。對(duì)于大多數(shù)業(yè)務(wù)而言， 數(shù)據(jù)粒度到前一天就夠了。

但萬事總有特例， 對(duì)于一些實(shí)時(shí)營銷的需求， 那么數(shù)據(jù)粒度到前一天就不一定夠了。

典型的，就像需要LBS（Location Based Services） 信息的分析要求， 就需要知道您現(xiàn)在到哪里了？比如您現(xiàn)在在高速上開車， 那么需要知道的前方道路上的信息， 事故或者堵車的情況， 那么這些分析結(jié)果嘛， 就需要利用流處理的方式，進(jìn)行實(shí)時(shí)處理。

在流處理中， 使用比較多的技術(shù)還是事件驅(qū)動(dòng)（Event Drive）， 通過對(duì)于預(yù)先設(shè)定的一些事件 進(jìn)行預(yù)定義相關(guān)的操作。當(dāng)數(shù)據(jù)流快速通過的時(shí)候， 捕獲事件模式， 出現(xiàn)模式匹配的時(shí)候， 去觸發(fā)預(yù)定義的一些動(dòng)作。

不過流處理的缺點(diǎn)在于， 需要事先配置事件， 如果沒有配置相關(guān)事件， 那么數(shù)據(jù)就自然而然的被忽視了。

流批一體的的常用模式就是， 數(shù)據(jù)進(jìn)來之后， 分雙路進(jìn)行處理， 一路是傳統(tǒng)的數(shù)據(jù)倉庫的ETL， 目標(biāo)是進(jìn)入數(shù)倉；而另一路數(shù)據(jù)就會(huì)通過流處理引擎， 在流處理引擎中會(huì)對(duì)數(shù)據(jù)進(jìn)行及時(shí)響應(yīng)。

比如在滴滴出租車運(yùn)營過程中， 那么就需要結(jié)合流處理和批處理的數(shù)據(jù)，對(duì)于運(yùn)營過程中出現(xiàn)的安全事件，進(jìn)行預(yù)測(cè)分析及主動(dòng)干預(yù)。

05 實(shí)時(shí)數(shù)倉的重點(diǎn)還是在實(shí)時(shí)

對(duì)于一些時(shí)效性比較強(qiáng)的行業(yè)， 傳統(tǒng)的數(shù)據(jù)倉庫可以解決財(cái)務(wù)分析的難題， 但是不能對(duì)全流程進(jìn)行實(shí)時(shí)監(jiān)控，

比如外賣平臺(tái)， 需要準(zhǔn)確知道目前的訂單進(jìn)行到了哪一步？目前整個(gè)路程中的瓶頸在什么地方？

比如出租車行業(yè)， 需要知道目前周圍有沒有出租車， 預(yù)定的出租車什么時(shí)候能到？還需要多久能夠到達(dá)目的地？

這些需求都需要對(duì)當(dāng)前的實(shí)時(shí)信息進(jìn)行獲取之后， 再進(jìn)一步通過AI算法來進(jìn)行預(yù)測(cè)之后， 才能進(jìn)行準(zhǔn)確地回答，所以這些行業(yè)是實(shí)時(shí)數(shù)倉的主要目標(biāo)客戶群。

實(shí)時(shí)數(shù)倉從整個(gè)數(shù)據(jù)處理的流程上來看， 主要涉及幾個(gè)環(huán)節(jié)，實(shí)時(shí)數(shù)據(jù)采集， 實(shí)時(shí)數(shù)據(jù)運(yùn)算，報(bào)表實(shí)時(shí)輸出。下面分別來看看幾個(gè)環(huán)節(jié)的使用場(chǎng)景和相關(guān)技術(shù)：

實(shí)時(shí)數(shù)據(jù)采集， 主要是采用一些變化數(shù)據(jù)捕獲機(jī)制，來接入來自各個(gè)不同渠道的實(shí)時(shí)數(shù)據(jù)變化， 對(duì)于關(guān)系型數(shù)據(jù)庫，有Golden Gate 或者直接Binlog 解析的方式，直接獲取變化數(shù)據(jù)。另外也有使用Kafka隊(duì)列， 來實(shí)現(xiàn)前端系統(tǒng)的變化數(shù)據(jù)直接投遞的。

實(shí)時(shí)數(shù)據(jù)運(yùn)算， 則是對(duì)于最近進(jìn)來的數(shù)據(jù)， 馬上加入運(yùn)算引擎進(jìn)行分析和處理， 比如幾乎所有的出行行業(yè)，都需要對(duì)用戶在出行過程中的狀態(tài)和安全態(tài)勢(shì) 進(jìn)行分析和研判， 以便于提供及時(shí)主動(dòng)的安全干預(yù)。這個(gè)需要考慮的是實(shí)時(shí)數(shù)據(jù)運(yùn)算的規(guī)模和粒度， 過大過小都不能達(dá)到最好效果。需要根據(jù)實(shí)際場(chǎng)景來具體決定。

實(shí)時(shí)數(shù)據(jù)報(bào)表， 這個(gè)對(duì)于很多營銷行為就很重要， 比如春晚紅包， 那么就需要隨時(shí)在大屏幕上，展示目前營銷活動(dòng)各個(gè)環(huán)節(jié)的情況， 以便于對(duì)策略進(jìn)行及時(shí)的調(diào)整。

另外在一些大型調(diào)度業(yè)務(wù)場(chǎng)景， 也需要對(duì)海量數(shù)據(jù)進(jìn)行分析之后，快速輸出分析圖表進(jìn)行大屏展示。

06 結(jié)語

IT 行業(yè)瞬息萬變，各種新的技術(shù)和新的詞匯令人無所適從，但是萬變不離其宗， 抓住業(yè)務(wù)場(chǎng)景來去理解業(yè)務(wù)的痛點(diǎn)， 進(jìn)而才能有效把握新技術(shù)的賣點(diǎn)。

以上我對(duì)幾個(gè)目前流行的技術(shù)詞匯，進(jìn)行了簡(jiǎn)單的剖析和舉例，每個(gè)行業(yè)使用場(chǎng)景不同， 需求也自然不同， 采用的技術(shù)路線也會(huì)各有千秋。一千個(gè)人心中有一千個(gè)哈姆雷特， 對(duì)于這些場(chǎng)景，您有什么不同的見解， 歡迎拍磚。