01 先看來龍， 再談去脈

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

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

這也促使Oracle 花費大量人力物力， 把分布在各個不同國家地區(qū)的系統(tǒng)統(tǒng)一上收， 做成全球系統(tǒng)。基于全球統(tǒng)一的數據進行決策分析， 進入了Oracle 高速發(fā)展的20年。

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

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

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

? 缺乏歷史數據；

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

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

? 太多的數據，太少的信息。

為了走出重重困境， 數據倉庫就自然成了企業(yè)家關注的焦點，經過各行各業(yè)的業(yè)務實踐， 雖然也有很多種變種， 但是大體上是個這樣的結構。

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

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

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

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

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

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

舉個例子，移動交換機每15分鐘會把當前用戶的位置信息吐出， 交給后臺處理， 這個數據基本上是PB級的。

另外還有用戶上網日志， 包括網址信息，這些都是非結構化的信息， 也很難納入到當前的倉庫模型當中， 所以必須使用大數據技術。

談到大數據技術， 那肯定就是Hadoop，但是怎么更好地使用Hadoop技術， 這時候就產生一些分歧：

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

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

經過一段時間的沉淀和磨合，現在大家基本上更加認可第二種方式。

對于處理完的海量數據，怎么處理呢？

這就是個兩難選擇， 因為存儲需要成本， 如果存儲數據帶來的收益不能cover 存儲成本的話， 那存儲數據就不合算。

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

03 湖倉一體的主要目標就是打破壁壘， 實現湖倉聯動

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

這個時候就有一些問題了。第一個需求，比如用戶行為分析， 因為用戶行為分析和用戶本身的屬性是高度關聯的。但是用戶的所有屬性都是在CRM系統(tǒng)中管理和存儲， 每當用戶的屬性發(fā)生變化， 那么如何快速傳遞到數據湖， 以免數據挖掘系統(tǒng)使用后不準確的數據， 產生不準確的結果。?

第二個需求， 比如， 經過數據湖中的數據挖掘， 對于現有的數據分類、標簽等操作， 但是這些比如用戶流失風險評估， 用戶近期喜好等特性， 最好還是通過統(tǒng)一的用戶界面與用戶進行交互。

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

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

所以目前大家所講的湖倉一體化， 歸根到底， 實際上是針對數據的價值，并通過技術手段實現各層次之間聯動：

高價值、高使用頻度的數據， 放在關系型數據庫中， 有條件可以上全閃或者數據庫一體機， 加快用戶分析效率。

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

當然巨量數據， 還是優(yōu)先推薦存放在Hadoop， 甚至可以是云空間的對象存儲上。因為不少Big SQL 的外延， 已經可以擴展到S3之類的對象存儲上了。這樣就可以把歷史數據的存儲成本降到更低。

04 流批一體的目標，是進一步提高數據驅動能力

傳統(tǒng)的數據倉庫， 一般都是T+1的數據采集模式。因為一般而言需要頭天做了數據關賬， 才能給后臺提供比較準確的財務數據， 后來隨著CDC技術的發(fā)展， 現在業(yè)務系統(tǒng)的數據變化可以準實時進入到數據倉庫中。?

但是我們要知道， 數據準實時同步， 不一定代表分析數據準實時， 因為多個系統(tǒng)之間，可能同步周期不一定相同。

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

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

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

在流處理中， 使用比較多的技術還是事件驅動（Event Drive）， 通過對于預先設定的一些事件 進行預定義相關的操作。當數據流快速通過的時候， 捕獲事件模式， 出現模式匹配的時候， 去觸發(fā)預定義的一些動作。

不過流處理的缺點在于， 需要事先配置事件， 如果沒有配置相關事件， 那么數據就自然而然的被忽視了。

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

比如在滴滴出租車運營過程中， 那么就需要結合流處理和批處理的數據，對于運營過程中出現的安全事件，進行預測分析及主動干預。

05 實時數倉的重點還是在實時

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

比如外賣平臺， 需要準確知道目前的訂單進行到了哪一步？目前整個路程中的瓶頸在什么地方？

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

這些需求都需要對當前的實時信息進行獲取之后， 再進一步通過AI算法來進行預測之后， 才能進行準確地回答，所以這些行業(yè)是實時數倉的主要目標客戶群。

實時數倉從整個數據處理的流程上來看， 主要涉及幾個環(huán)節(jié)，實時數據采集， 實時數據運算，報表實時輸出。下面分別來看看幾個環(huán)節(jié)的使用場景和相關技術：

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

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

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

另外在一些大型調度業(yè)務場景， 也需要對海量數據進行分析之后，快速輸出分析圖表進行大屏展示。

06 結語

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

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