作者 |祁國輝

責編 |韓楠

資料倉儲概念興起於上世紀90年代，隨著IT系統的大發展，人們發現應用系統越來越多，但是對於經營決策的問題，反而越來越難以獲取準確的決策資訊。

據說有個笑話，發生在2000年前後，Oracle 總裁Larry 想知道Oracle 全球有多少人。但那時沒有人知道，因為Oracle全球的業務系統分佈在各個大洲/各個國家，每個區域都有自己的應用系統，但是沒有一個全球統一的中央系統，從而發生了這麼一個有趣的事。

這也促使Oracle 花費大量人力物力，把分佈在各個不同國家地區的系統統一上收，做成全球系統。基於全球統一的資料進行決策分析，進入了Oracle 高速發展的20年。

其實很多企業都會發現，在經過了IT系統大規模建設之後，反而越來越難以獲得有效的決策資訊，資料分散在多個業務系統中，演變成有大量資料，但是缺乏有效資訊的尷尬局面。一般而言，有這樣的幾種情況：

• 決策資訊分散在多個業務系統中；

• 資料的不一致性突出，多個資訊提供者對資訊都不具備嚴格的定義，不同的業務系統對同一資訊資料的理解和定義不同，甚至許多相同命名的資料所指代的業務資訊並不相同；

• 缺乏歷史資料；

• 業務系統的資料模型，是針對事務處理設計的，不適合做分析；

• 在業務系統上做資訊查詢，會影響現有系統的執行；

• 太多的資料，太少的資訊。

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

資料倉儲進入中國市場之後，經歷了飛速發展的十年。在這十年裡，多少IT屆的仁人志士都在這個賽道上奮鬥過，有很多成功的經驗，也有不少失敗的案例。

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

2015年之後，中國移動基本就沒有再大規模地推出過經營分析建設規範，但是直到如今，中國移動的一級經營分析系統的各省資料上收，還是各省公司考核的重要指標。

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

手機使用者在手機上交友、瀏覽、購物，娛樂都會產生大量的日誌資料，另外手機基本上和人是一一繫結的，那麼手機的定位系統自然也可以瞭解到使用者的出行情況。但是這些資料對於現有的資料倉儲來說，體量太大了，要想很好地收集處理，需要耗費巨量的資源。

舉個例子，移動交換機每15分鐘會把當前使用者的位置資訊吐出，交給後臺處理，這個資料基本上是PB級的。

另外還有使用者上網日誌，包括網址資訊，這些都是非結構化的資訊，也很難納入到當前的倉庫模型當中，所以必須使用大資料技術。

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

• 一部分人認為， Hadoop是全新的技術，是可以完全取代傳統資料庫進行資料分析的技術，傳統資料庫已經落伍。

• 另外一部分人認為，Hadoop還不夠成熟和普及，對於資料倉儲的adhoc查詢和分析，不可能奢望每個分析人員都會coding。而是應該發揮Hadoop大資料並行處理的優勢，對於資料進行預處理之後，再去把結果匯入到資料倉儲中。

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

對於處理完的海量資料，怎麼處理呢？

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

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

Data lake 的主要定位，就是一個可以持續擴充的海量資料儲存，容量更大，單位成本更低，主要用於對於這些海量資料的深度開採，另外也儲存下來以備將來可用。

這個時候就有一些問題了。 第一個需求，比如使用者行為分析，因為使用者行為分析和使用者本身的屬性是高度關聯的。但是使用者的所有屬性都是在CRM系統中管理和儲存，每當使用者的屬性發生變化，那麼如何快速傳遞到資料湖，以免資料探勘系統使用後不準確的資料，產生不準確的結果。

第二個需求， 比如，經過資料湖中的資料探勘，對於現有的資料分類、標籤等操作，但是這些比如使用者流失風險評估，使用者近期喜好等特性，最好還是透過統一的使用者介面與使用者進行互動。

那麼就自然需要把這些資料湖中的挖掘結果，儘快同步到電子渠道系統當中去，這樣才能透過各種渠道媒介與客戶互動，避免發生簡訊轟炸。

第三個需求， 就是SQL on hadoop，這個是很自然的需求。因為無論如何，懂SQL的人總是比懂Spark或者Flink的人多。而且絕大多數的業務系統，目前都是使用SQL 作為主要資料處理語言。那麼，如何把資料湖中的資料規範化之後，提供SQL 介面，讓業務系統能夠直接使用SQL訪問資料湖中的資料，這也便成了順理成章的需求了。

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

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

中等價值的資料 ，可以考慮多種儲存模式，或者傳統關係型，或者是使用MPP。更有甚者，考慮目前市面上的分散式資料庫，都可以做一個價效比上的一個平衡。

當然 巨量資料 ，還是優先推薦存放在Hadoop，甚至可以是雲空間的物件儲存上。因為不少Big SQL 的外延，已經可以擴充套件到S3之類的物件儲存上了。這樣就可以把歷史資料的儲存成本降到更低。

傳統的資料倉儲，一般都是T+1的資料採集模式。因為一般而言需要頭天做了資料關賬，才能給後臺提供比較準確的財務資料，後來隨著CDC技術的發展，現在業務系統的資料變化可以準實時進入到資料倉庫中。

但是我們要知道，資料準實時同步，不一定代表分析資料準實時，因為多個系統之間，可能同步週期不一定相同。

另外，資料進入資料倉儲，還有一個清晰度和彙總的過程，如果資料倉儲隨時進行海量資料的彙總和計算，那麼計算量就太大了，得不償失。對於大多數業務而言，資料粒度到前一天就夠了。

但萬事總有特例 ，對於一些實時營銷的需求，那麼資料粒度到前一天就不一定夠了。

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

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

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

流批一體的的常用模式就是，資料進來之後，分雙路進行處理，一路是傳統的資料倉儲的ETL，目標是進入數倉；而另一路資料就會透過流處理引擎，在流處理引擎中會對資料進行及時響應。

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

對於一些時效性比較強的行業，傳統的資料倉儲可以解決財務分析的難題，但是不能對全流程進行實時監控，

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

比如計程車行業，需要知道目前周圍有沒有計程車，預定的計程車什麼時候能到？還需要多久能夠到達目的地？

這些需求都需要對當前的實時資訊進行獲取之後，再進一步透過AI演算法來進行預測之後，才能進行準確地回答，所以這些行業是實時數倉的主要目標客戶群。

實時數倉從整個資料處理的流程上來看，主要涉及幾個環節，實時資料採集，實時資料運算，報表實時輸出。下面 分別來看看幾個環節的使用場景和相關技術：

實時資料採集，主要是採用一些變化資料捕獲機制，來接入來自各個不同渠道的實時資料變化，對於關係型資料庫，有Golden Gate 或者直接Binlog 解析的方式，直接獲取變化資料。另外也有使用Kafka佇列，來實現前端系統的變化資料直接投遞的。

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

實時資料包表，這個對於很多營銷行為就很重要，比如春晚紅包，那麼就需要隨時在大螢幕上，展示目前營銷活動各個環節的情況，以便於對策略進行及時的調整。

另外在一些大型排程業務場景，也需要對海量資料進行分析之後，快速輸出分析圖表進行大屏展示。

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

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

重新思考 | 實時數倉、湖倉一體、流批一體，它們都在說什麼

相關文章