建站
咨詢
售后
建站咨詢
新聞中心
01 先看來龍， 再談去脈
數(shù)據(jù)倉庫概念興起于上世紀(jì)90年代，隨著IT系統(tǒng)的大發(fā)展， 人們發(fā)現(xiàn)應(yīng)用系統(tǒng)越來越多， 但是對于經(jīng)營決策的問題， 反而越來越難以獲取準(zhǔn)確的決策信息。
創(chuàng)新互聯(lián)公司主要從事網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)古塔,10年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220
據(jù)說有個笑話， 發(fā)生在2000年前后，Oracle 總裁Larry 想知道Oracle 全球有多少人。但那時沒有人知道， 因為Oracle全球的業(yè)務(wù)系統(tǒng)分布在各個大洲/各個國家， 每個區(qū)域都有自己的應(yīng)用系統(tǒng)，但是沒有一個全球統(tǒng)一的中央系統(tǒng)， 從而發(fā)生了這么一個有趣的事。
這也促使Oracle 花費大量人力物力， 把分布在各個不同國家地區(qū)的系統(tǒng)統(tǒng)一上收， 做成全球系統(tǒng)?；谌蚪y(tǒng)一的數(shù)據(jù)進(jìn)行決策分析， 進(jìn)入了Oracle 高速發(fā)展的20年。
其實很多企業(yè)都會發(fā)現(xiàn)， 在經(jīng)過了IT系統(tǒng)大規(guī)模建設(shè)之后， 反而越來越難以獲得有效的決策信息，數(shù)據(jù)分散在多個業(yè)務(wù)系統(tǒng)中， 演變成有大量數(shù)據(jù)， 但是缺乏有效信息的尷尬局面。 一般而言， 有這樣的幾種情況：
? 決策信息分散在多個業(yè)務(wù)系統(tǒng)中；
? 數(shù)據(jù)的不一致性突出，多個信息提供者對信息都不具備嚴(yán)格的定義，不同的業(yè)務(wù)系統(tǒng)對同一信息數(shù)據(jù)的理解和定義不同，甚至許多相同命名的數(shù)據(jù)所指代的業(yè)務(wù)信息并不相同；
? 缺乏歷史數(shù)據(jù)；
? 業(yè)務(wù)系統(tǒng)的數(shù)據(jù)模型，是針對事務(wù)處理設(shè)計的，不適合做分析；
? 在業(yè)務(wù)系統(tǒng)上做信息查詢，會影響現(xiàn)有系統(tǒng)的運行；
? 太多的數(shù)據(jù)，太少的信息。
為了走出重重困境， 數(shù)據(jù)倉庫就自然成了企業(yè)家關(guān)注的焦點，經(jīng)過各行各業(yè)的業(yè)務(wù)實踐， 雖然也有很多種變種， 但是大體上是個這樣的結(jié)構(gòu)。
02 數(shù)據(jù)倉庫給企業(yè)帶來了發(fā)展的機遇， 也帶來了挑戰(zhàn)
數(shù)據(jù)倉庫進(jìn)入中國市場之后， 經(jīng)歷了飛速發(fā)展的十年。在這十年里， 多少IT屆的仁人志士都在這個賽道上奮斗過， 有很多成功的經(jīng)驗， 也有不少失敗的案例。
這里簡單分享一個小故事，首先是中國移動的經(jīng)營分析系統(tǒng)， 經(jīng)過10多年的發(fā)展， 變成支撐企業(yè)績效考評和市場運營的重要工具。 我個人的觀點，中國移動能夠后來者居上，力壓其他兩家，和經(jīng)營分析的有力支撐，有著千絲萬縷的關(guān)系。
2015年之后， 中國移動基本就沒有再大規(guī)模地推出過經(jīng)營分析建設(shè)規(guī)范， 但是直到如今， 中國移動的一級經(jīng)營分析系統(tǒng)的各省數(shù)據(jù)上收， 還是各省公司考核的重要指標(biāo)。
隨著智能手機和各種智能終端的快速發(fā)展， 中國移動也推出各種新的業(yè)務(wù)和新的模式。這個時候， 如何更好地了解客戶，了解客戶的行為習(xí)慣和消費模式， 從而有針對性地推出新業(yè)務(wù)，自然就是市場部門的重要訴求。
手機用戶在手機上交友、瀏覽、購物， 娛樂都會產(chǎn)生大量的日志數(shù)據(jù)， 另外手機基本上和人是一一綁定的， 那么手機的定位系統(tǒng)自然也可以了解到用戶的出行情況。但是這些數(shù)據(jù)對于現(xiàn)有的數(shù)據(jù)倉庫來說， 體量太大了， 要想很好地收集處理， 需要耗費巨量的資源。?
舉個例子，移動交換機每15分鐘會把當(dāng)前用戶的位置信息吐出， 交給后臺處理， 這個數(shù)據(jù)基本上是PB級的。
另外還有用戶上網(wǎng)日志， 包括網(wǎng)址信息，這些都是非結(jié)構(gòu)化的信息， 也很難納入到當(dāng)前的倉庫模型當(dāng)中， 所以必須使用大數(shù)據(jù)技術(shù)。
談到大數(shù)據(jù)技術(shù)， 那肯定就是Hadoop，但是怎么更好地使用Hadoop技術(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還不夠成熟和普及， 對于數(shù)據(jù)倉庫的adhoc查詢和分析， 不可能奢望每個分析人員都會coding。而是應(yīng)該發(fā)揮Hadoop大數(shù)據(jù)并行處理的優(yōu)勢， 對于數(shù)據(jù)進(jìn)行預(yù)處理之后， 再去把結(jié)果導(dǎo)入到數(shù)據(jù)倉庫中。
經(jīng)過一段時間的沉淀和磨合，現(xiàn)在大家基本上更加認(rèn)可第二種方式。
對于處理完的海量數(shù)據(jù)，怎么處理呢？
這就是個兩難選擇， 因為存儲需要成本， 如果存儲數(shù)據(jù)帶來的收益不能cover 存儲成本的話， 那存儲數(shù)據(jù)就不合算。
但是如果覺得數(shù)據(jù)還是很有價值， 可能有一些目前沒有發(fā)現(xiàn)的價值，將來還有其他的分析角度和分析需求的時候， 那么就只有存儲起來。這個時候就是數(shù)據(jù)湖（Data lake）了。
03 湖倉一體的主要目標(biāo)就是打破壁壘， 實現(xiàn)湖倉聯(lián)動
Data lake 的主要定位，就是一個可以持續(xù)擴(kuò)充的海量數(shù)據(jù)存儲， 容量更大， 單位成本更低， 主要用于對于這些海量數(shù)據(jù)的深度開采， 另外也保存下來以備將來可用。
這個時候就有一些問題了。第一個需求，比如用戶行為分析， 因為用戶行為分析和用戶本身的屬性是高度關(guān)聯(lián)的。但是用戶的所有屬性都是在CRM系統(tǒng)中管理和存儲， 每當(dāng)用戶的屬性發(fā)生變化， 那么如何快速傳遞到數(shù)據(jù)湖， 以免數(shù)據(jù)挖掘系統(tǒng)使用后不準(zhǔn)確的數(shù)據(jù)， 產(chǎn)生不準(zhǔn)確的結(jié)果。?
第二個需求， 比如， 經(jīng)過數(shù)據(jù)湖中的數(shù)據(jù)挖掘， 對于現(xiàn)有的數(shù)據(jù)分類、標(biāo)簽等操作， 但是這些比如用戶流失風(fēng)險評估， 用戶近期喜好等特性， 最好還是通過統(tǒng)一的用戶界面與用戶進(jìn)行交互。
那么就自然需要把這些數(shù)據(jù)湖中的挖掘結(jié)果，盡快同步到電子渠道系統(tǒng)當(dāng)中去， 這樣才能通過各種渠道媒介與客戶互動，避免發(fā)生短信轟炸。
第三個需求， 就是SQL on hadoop， 這個是很自然的需求。因為無論如何， 懂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ù)據(jù)的價值，并通過技術(shù)手段實現(xiàn)各層次之間聯(lián)動：
高價值、高使用頻度的數(shù)據(jù)， 放在關(guān)系型數(shù)據(jù)庫中， 有條件可以上全閃或者數(shù)據(jù)庫一體機， 加快用戶分析效率。
中等價值的數(shù)據(jù)， 可以考慮多種存儲模式， 或者傳統(tǒng)關(guān)系型， 或者是使用MPP。 更有甚者， 考慮目前市面上的分布式數(shù)據(jù)庫， 都可以做一個性價比上的一個平衡。
當(dāng)然巨量數(shù)據(jù)， 還是優(yōu)先推薦存放在Hadoop， 甚至可以是云空間的對象存儲上。因為不少Big SQL 的外延， 已經(jīng)可以擴(kuò)展到S3之類的對象存儲上了。這樣就可以把歷史數(shù)據(jù)的存儲成本降到更低。
04 流批一體的目標(biāo)，是進(jìn)一步提高數(shù)據(jù)驅(qū)動能力
傳統(tǒng)的數(shù)據(jù)倉庫， 一般都是T+1的數(shù)據(jù)采集模式。因為一般而言需要頭天做了數(shù)據(jù)關(guān)賬， 才能給后臺提供比較準(zhǔn)確的財務(wù)數(shù)據(jù)， 后來隨著CDC技術(shù)的發(fā)展， 現(xiàn)在業(yè)務(wù)系統(tǒng)的數(shù)據(jù)變化可以準(zhǔn)實時進(jìn)入到數(shù)據(jù)倉庫中。?
但是我們要知道， 數(shù)據(jù)準(zhǔn)實時同步， 不一定代表分析數(shù)據(jù)準(zhǔn)實時， 因為多個系統(tǒng)之間，可能同步周期不一定相同。
另外，數(shù)據(jù)進(jìn)入數(shù)據(jù)倉庫，還有一個清晰度和匯總的過程， 如果數(shù)據(jù)倉庫隨時進(jìn)行海量數(shù)據(jù)的匯總和計算， 那么計算量就太大了， 得不償失。對于大多數(shù)業(yè)務(wù)而言， 數(shù)據(jù)粒度到前一天就夠了。
但萬事總有特例， 對于一些實時營銷的需求， 那么數(shù)據(jù)粒度到前一天就不一定夠了。
典型的，就像需要LBS（Location Based Services） 信息的分析要求， 就需要知道您現(xiàn)在到哪里了？比如您現(xiàn)在在高速上開車， 那么需要知道的前方道路上的信息， 事故或者堵車的情況， 那么這些分析結(jié)果嘛， 就需要利用流處理的方式，進(jìn)行實時處理。
在流處理中， 使用比較多的技術(shù)還是事件驅(qū)動（Event Drive）， 通過對于預(yù)先設(shè)定的一些事件 進(jìn)行預(yù)定義相關(guān)的操作。當(dāng)數(shù)據(jù)流快速通過的時候， 捕獲事件模式， 出現(xiàn)模式匹配的時候， 去觸發(fā)預(yù)定義的一些動作。
不過流處理的缺點在于， 需要事先配置事件， 如果沒有配置相關(guān)事件， 那么數(shù)據(jù)就自然而然的被忽視了。
流批一體的的常用模式就是， 數(shù)據(jù)進(jìn)來之后， 分雙路進(jìn)行處理， 一路是傳統(tǒng)的數(shù)據(jù)倉庫的ETL， 目標(biāo)是進(jìn)入數(shù)倉；而另一路數(shù)據(jù)就會通過流處理引擎， 在流處理引擎中會對數(shù)據(jù)進(jìn)行及時響應(yīng)。
比如在滴滴出租車運營過程中， 那么就需要結(jié)合流處理和批處理的數(shù)據(jù)，對于運營過程中出現(xiàn)的安全事件，進(jìn)行預(yù)測分析及主動干預(yù)。
05 實時數(shù)倉的重點還是在實時
對于一些時效性比較強的行業(yè)， 傳統(tǒng)的數(shù)據(jù)倉庫可以解決財務(wù)分析的難題， 但是不能對全流程進(jìn)行實時監(jiān)控，
比如外賣平臺， 需要準(zhǔn)確知道目前的訂單進(jìn)行到了哪一步？目前整個路程中的瓶頸在什么地方？
比如出租車行業(yè)， 需要知道目前周圍有沒有出租車， 預(yù)定的出租車什么時候能到？還需要多久能夠到達(dá)目的地？
這些需求都需要對當(dāng)前的實時信息進(jìn)行獲取之后， 再進(jìn)一步通過AI算法來進(jìn)行預(yù)測之后， 才能進(jìn)行準(zhǔn)確地回答，所以這些行業(yè)是實時數(shù)倉的主要目標(biāo)客戶群。
實時數(shù)倉從整個數(shù)據(jù)處理的流程上來看， 主要涉及幾個環(huán)節(jié)，實時數(shù)據(jù)采集， 實時數(shù)據(jù)運算，報表實時輸出。下面分別來看看幾個環(huán)節(jié)的使用場景和相關(guān)技術(shù)：
實時數(shù)據(jù)采集， 主要是采用一些變化數(shù)據(jù)捕獲機制，來接入來自各個不同渠道的實時數(shù)據(jù)變化， 對于關(guān)系型數(shù)據(jù)庫，有Golden Gate 或者直接Binlog 解析的方式，直接獲取變化數(shù)據(jù)。另外也有使用Kafka隊列， 來實現(xiàn)前端系統(tǒng)的變化數(shù)據(jù)直接投遞的。
實時數(shù)據(jù)運算， 則是對于最近進(jìn)來的數(shù)據(jù)， 馬上加入運算引擎進(jìn)行分析和處理， 比如幾乎所有的出行行業(yè)，都需要對用戶在出行過程中的狀態(tài)和安全態(tài)勢 進(jìn)行分析和研判， 以便于提供及時主動的安全干預(yù)。這個需要考慮的是實時數(shù)據(jù)運算的規(guī)模和粒度， 過大過小都不能達(dá)到最好效果。需要根據(jù)實際場景來具體決定。
實時數(shù)據(jù)報表， 這個對于很多營銷行為就很重要， 比如春晚紅包， 那么就需要隨時在大屏幕上，展示目前營銷活動各個環(huán)節(jié)的情況， 以便于對策略進(jìn)行及時的調(diào)整。
另外在一些大型調(diào)度業(yè)務(wù)場景， 也需要對海量數(shù)據(jù)進(jìn)行分析之后，快速輸出分析圖表進(jìn)行大屏展示。
06 結(jié)語
IT 行業(yè)瞬息萬變，各種新的技術(shù)和新的詞匯令人無所適從，但是萬變不離其宗， 抓住業(yè)務(wù)場景來去理解業(yè)務(wù)的痛點， 進(jìn)而才能有效把握新技術(shù)的賣點。
以上我對幾個目前流行的技術(shù)詞匯，進(jìn)行了簡單的剖析和舉例，每個行業(yè)使用場景不同， 需求也自然不同， 采用的技術(shù)路線也會各有千秋。一千個人心中有一千個哈姆雷特， 對于這些場景，您有什么不同的見解， 歡迎拍磚。
文章標(biāo)題：實時數(shù)倉、湖倉一體、流批一體，它們都在說什么
分享URL：http://m.fisionsoft.com.cn/article/coojhjs.html
