大數(shù)據(jù)時(shí)代：傳統(tǒng)BI還能走多遠(yuǎn)？

---

從事BI多年，經(jīng)歷了經(jīng)營(yíng)分析系統(tǒng)的大建設(shè)，大發(fā)展時(shí)期，也有幸處在大數(shù)據(jù)與傳統(tǒng)BI系統(tǒng)的交替之際，因此特別來(lái)談?wù)?，傳統(tǒng)BI還能走多遠(yuǎn)？

技術(shù)為業(yè)務(wù)服務(wù)，因此這里不談技術(shù)，更多從使用者的角度去闡述原因，理了八個(gè)方面，每個(gè)方面都是筆者親歷，當(dāng)然任何窮舉法都無(wú)法證明絕對(duì)正確，但希望能引起思考。

1、資源申請(qǐng)-從月到日，不可同日耳語(yǔ)

自從企業(yè)有了大數(shù)據(jù)MPP、HADOOP、流處理三個(gè)資源池，租戶(hù)生效基本都是所見(jiàn)即所得。公司甚至為了申請(qǐng)方便，搞了資源套餐，我們申請(qǐng)資源叫點(diǎn)套餐，這種資源申請(qǐng)模式為對(duì)外靈活開(kāi)放數(shù)據(jù)提供了基本保障，在半年時(shí)間內(nèi)，內(nèi)外部租戶(hù)已經(jīng)開(kāi)出了100多個(gè)(以前可能叫數(shù)據(jù)集市)，現(xiàn)在回想起來(lái)，如果沒(méi)有這個(gè)能力，公司的對(duì)外變現(xiàn)基本不可能。

無(wú)論是阿里云還是AWS，都是這個(gè)套路，但為什么企業(yè)要自己做，因?yàn)檩^大的企業(yè)本身內(nèi)部就是個(gè)巨大的市場(chǎng)，有各類(lèi)的應(yīng)用要求，從數(shù)據(jù)、安全、接口、技術(shù)等各個(gè)方面講，都不適合放到外部平臺(tái)。

傳統(tǒng)BI的小型機(jī)階段，沒(méi)有資源池概念，資源申報(bào)按硬件臺(tái)數(shù)算，需要提前申請(qǐng)預(yù)算，即使硬件到位，集成時(shí)間也過(guò)于漫長(zhǎng)，記得以前為11個(gè)地市規(guī)劃11個(gè)數(shù)據(jù)集市，采用四臺(tái)570劃分12個(gè)分區(qū)，搞了1個(gè)多月，效率不可同日而語(yǔ)。

大數(shù)據(jù)系統(tǒng)在資源粒度、申請(qǐng)速度、資源動(dòng)態(tài)擴(kuò)展等各個(gè)方面都完爆傳統(tǒng)BI，在業(yè)務(wù)快速部署上具有無(wú)法比擬的優(yōu)勢(shì)，為業(yè)務(wù)創(chuàng)新奠定了很好的基礎(chǔ)。如果你做過(guò)DB2的項(xiàng)目集成啥的，每一次都涉及規(guī)劃、劃盤(pán)、分區(qū)、安裝等等，就知道啥叫等待。

2、數(shù)據(jù)采集-多樣性才能創(chuàng)造更多應(yīng)用場(chǎng)景

傳統(tǒng)ETL的基本套路都是從源數(shù)據(jù)庫(kù)導(dǎo)出成文本，然后通過(guò)客戶(hù)端工具導(dǎo)入到目的數(shù)據(jù)庫(kù)，導(dǎo)出用EXPORT，傳輸用FTP，導(dǎo)入用IMPORT，當(dāng)然，同種類(lèi)型的數(shù)據(jù)庫(kù)可能用DBLINK等這種快捷方式，程序中采用ODBC啥的連接數(shù)據(jù)庫(kù)來(lái)進(jìn)行操作。很多公司專(zhuān)門(mén)開(kāi)發(fā)了一些多庫(kù)之間互導(dǎo)數(shù)據(jù)的工具，當(dāng)然一般企業(yè)級(jí)的平臺(tái)不用，可擴(kuò)展性、靈活性太差。傳統(tǒng)ETL的技術(shù)非常適應(yīng)以天或月為分析周期的靜態(tài)應(yīng)用要求。

我想大多數(shù)企業(yè)，BI的數(shù)據(jù)分析現(xiàn)在周期基本還是天，筆者做了10年BI，記得企業(yè)很長(zhǎng)一段時(shí)間，是以月為單位ETL數(shù)據(jù)的，當(dāng)然，從業(yè)務(wù)的角度講，夠用即可，有人會(huì)問(wèn)，數(shù)據(jù)的周期減少到小時(shí)、分鐘、秒以致實(shí)時(shí)，到底有多大現(xiàn)實(shí)意義?但真的業(yè)務(wù)上不需要更短周期的分析嗎?是因?yàn)榇蠹褺I分析的套路習(xí)慣使然還是能力不夠使然?

從取數(shù)的角度講，業(yè)務(wù)人員永遠(yuǎn)希望你取得數(shù)據(jù)越快越及時(shí)越好，我們?cè)瓉?lái)只出月報(bào)，后來(lái)性能上去了，復(fù)雜的日?qǐng)?bào)也能出了，日?qǐng)?bào)變成了標(biāo)配，日?qǐng)?bào)之后呢，實(shí)時(shí)是否應(yīng)該成為未來(lái)的標(biāo)配?

從應(yīng)用的角度講，企業(yè)除了一堆運(yùn)營(yíng)指標(biāo)報(bào)表，一般有營(yíng)銷(xiāo)和風(fēng)控兩個(gè)角度有數(shù)據(jù)的現(xiàn)實(shí)需求，實(shí)時(shí)營(yíng)銷(xiāo)顯然比靜態(tài)營(yíng)銷(xiāo)效果更好一點(diǎn)，BAT如果不搞實(shí)時(shí)營(yíng)銷(xiāo)基本就沒(méi)法活，實(shí)時(shí)風(fēng)控顯然比離線(xiàn)風(fēng)控效果更好有一點(diǎn)，比如反欺詐系統(tǒng)，如果不是實(shí)時(shí)的監(jiān)聽(tīng)，如何在詐騙的事中介入?

從趨勢(shì)的角度講，如果你認(rèn)同未來(lái)的世界是滿(mǎn)足個(gè)性化的世界，那么，只有實(shí)時(shí)的數(shù)據(jù)才能蘊(yùn)含更多的信息，才能給你更為個(gè)性化的服務(wù)，你會(huì)想到太多的場(chǎng)景需要實(shí)時(shí)化采集。

即使你沒(méi)有以上提的任何需求，但技術(shù)和業(yè)務(wù)永遠(yuǎn)是互動(dòng)的，你具備了按小時(shí)提供的能力，人家就會(huì)創(chuàng)造按小時(shí)的業(yè)務(wù)場(chǎng)景，你具備了實(shí)時(shí)的提供能力，人家就會(huì)創(chuàng)造實(shí)時(shí)的業(yè)務(wù)場(chǎng)景。誰(shuí)是蛋誰(shuí)是雞說(shuō)不清楚，但如果你想服務(wù)的更好，就應(yīng)該在技術(shù)層面更前瞻性一點(diǎn)。

但傳統(tǒng)BI能支撐嗎?傳統(tǒng)企業(yè)的BI不實(shí)時(shí)，本質(zhì)不是沒(méi)有需求，也許是能力不夠所致，我記得以前CRM上線(xiàn)要搞個(gè)實(shí)時(shí)放號(hào)指標(biāo)監(jiān)控，也是蠻困難的事情，以前出賬只有月報(bào)啊，現(xiàn)在，沒(méi)有日?qǐng)?bào)，還能活? 我記得很多年前第一份日賬報(bào)表是IT人員自己提的，因?yàn)槟芰Φ搅恕?那未來(lái)10年呢?

ETL是傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)中的一個(gè)概念，我覺(jué)得該升級(jí)了，多樣化的采集方式是王道，這是大勢(shì)所趨，有三樣?xùn)|西是最重要的，一個(gè)是采集方式的百花齊放，即消息、數(shù)據(jù)流、爬蟲(chóng)、文件、日志增量都能支持，二是數(shù)據(jù)的流動(dòng)不是單向的，不僅僅是E，而且是X,即交換，這樣就極大衍生了ETL的內(nèi)涵，三是數(shù)據(jù)采集的分布式，可以并行動(dòng)態(tài)擴(kuò)展，ETL的讀寫(xiě)問(wèn)題能較好解決。這些恰是傳統(tǒng)BI做不到的。

3、計(jì)算性能-性?xún)r(jià)比是王道，更迭速度比想象的快

DB2、Teradata在數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域一直占據(jù)著巨大的份額，我們用GBASE+HADOOP花了半年時(shí)間把2臺(tái)P780替換掉了，綜合性能可以說(shuō)是原來(lái)的1.5倍，但投資只有幾分之一，雖然前期涉及一些調(diào)優(yōu)，對(duì)于代碼也有更高的要求，但性?xún)r(jià)比非常高，關(guān)鍵是能夠多租戶(hù)動(dòng)態(tài)擴(kuò)展，容災(zāi)能力也超DB2。記得以前DB2一旦節(jié)點(diǎn)出現(xiàn)問(wèn)題，雖然也能切換，但性能往往下降一半，極大影響業(yè)務(wù)。

傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)，對(duì)于不同的數(shù)據(jù)處理方式往往是一視同仁的，但事實(shí)上，不同數(shù)據(jù)處理階段，對(duì)于數(shù)據(jù)處理的要求存在結(jié)構(gòu)性的不同，一些簡(jiǎn)單的轉(zhuǎn)化和匯總，在庫(kù)外方式處理比庫(kù)內(nèi)處理合算，但傳統(tǒng)BI習(xí)慣于把數(shù)據(jù)全部導(dǎo)入到數(shù)據(jù)倉(cāng)庫(kù)中做，浪費(fèi)了珍貴的小型機(jī)系統(tǒng)資源，性?xún)r(jià)比很低。因此，當(dāng)前MPP+HADOOP混搭型數(shù)據(jù)倉(cāng)庫(kù)漸成趨勢(shì)，HADOOP擅長(zhǎng)海量簡(jiǎn)單的批量處理，MPP擅長(zhǎng)數(shù)據(jù)關(guān)聯(lián)分析，比如eBAY,中國(guó)移動(dòng)等都采用了類(lèi)似的方案。

從綜合的角度講，DB2等數(shù)據(jù)倉(cāng)庫(kù)當(dāng)然有它的優(yōu)勢(shì)，比如引以為豪的穩(wěn)定，但這些技術(shù)過(guò)于依賴(lài)國(guó)外，感覺(jué)運(yùn)維能力每況愈下，關(guān)鍵問(wèn)題的解決越來(lái)越力不從心，穩(wěn)定這個(gè)詞也要打上大大的問(wèn)號(hào)，不知道其他企業(yè)感覺(jué)如何。要相信筆者不是打國(guó)產(chǎn)GBASE廣告，坑很多，但值得擁有。

4、報(bào)表系統(tǒng)-審美疲勞不可避免，個(gè)性化是趨勢(shì)

用過(guò)很多商業(yè)化的報(bào)表系統(tǒng)，比如BRIO、BO、BIEE等等，系統(tǒng)都提供了較好的可視化界面，對(duì)于輕量級(jí)數(shù)據(jù)的展現(xiàn)也不錯(cuò)，但我覺(jué)得這個(gè)對(duì)于大型企業(yè)來(lái)講沒(méi)有吸引力。

一是可替代性太強(qiáng)，現(xiàn)在開(kāi)源組件太多了，功能也雷同，為什么要用標(biāo)準(zhǔn)化被捆綁的東西，對(duì)于具有一定開(kāi)發(fā)能力的公司，似乎無(wú)此必要。

二是開(kāi)源性太差，企業(yè)有大量個(gè)性化的要求，比如安全控制等等，但這些產(chǎn)品的開(kāi)放性較差，很多時(shí)候滿(mǎn)足不了要求。

三是不靈活，再通用，能做得過(guò)EXCEL嗎，不要奢望從一個(gè)報(bào)表系統(tǒng)上能直接摘取一個(gè)報(bào)表粘貼到一個(gè)報(bào)告上，總是要二次加工，既然這樣，還不如數(shù)據(jù)直接灌入EXCEL簡(jiǎn)單。

四是速度太慢，當(dāng)前的報(bào)表已經(jīng)不是傳統(tǒng)BI意義的報(bào)表，因?yàn)榫S度和粒度要求很細(xì)，結(jié)果記錄數(shù)過(guò)億的也不在少數(shù)，比如我們的指標(biāo)庫(kù)一年記錄是百億條，傳統(tǒng)BI報(bào)表根本無(wú)法支撐，樣子好看是暫時(shí)的，業(yè)務(wù)人員最關(guān)注的始終是報(bào)表的速度。

當(dāng)然，對(duì)于小企業(yè)可能仍然具有一定吸引力，但這個(gè)開(kāi)放的時(shí)代，需求和新技術(shù)層出不窮，這類(lèi)標(biāo)準(zhǔn)化的產(chǎn)品能趕上變化嗎?如果你希望HBASE跟BIEE結(jié)合，怎么辦?是等著廠(chǎng)家慢慢推出版本，還是干脆自己干?

5、多維分析-適應(yīng)性較差，定制化才是方向

用過(guò)一些商業(yè)化的多維分析系統(tǒng)，也叫OLAP吧，比如IBM的ESSBASE。OLAP是幾十年前老外提出的概念，通過(guò)各維度分析快速得到所需的結(jié)果，但這個(gè)OLAP到底有多大的實(shí)用價(jià)值?

OLAP產(chǎn)品總是想通過(guò)通用化的手段解決一個(gè)專(zhuān)業(yè)性分析問(wèn)題，從誕生開(kāi)始就有硬傷，因?yàn)榉治鲎兓療o(wú)常，你是希望自己在后臺(tái)隨心所欲用SQL馳騁江湖還是面對(duì)一個(gè)呆板的界面進(jìn)行固定的復(fù)雜的多維操作?筆者作為技術(shù)人員不喜歡用它，但業(yè)務(wù)人員也不喜歡用它，操作門(mén)檻偏高。

在開(kāi)放性上，傳統(tǒng)OLAP的后臺(tái)引擎仍然是傳統(tǒng)數(shù)據(jù)庫(kù)，顯然不支持一些海量的大數(shù)據(jù)系統(tǒng);打CUBE是個(gè)設(shè)計(jì)活，非常耗時(shí)，每次更新數(shù)據(jù)要重打CUBE，總是讓筆者抓狂，不知道現(xiàn)在有啥改進(jìn);千萬(wàn)級(jí)數(shù)據(jù)量、10個(gè)維度估計(jì)也是它的性能極限了吧;最后，以前打的CUBE真的能解決你當(dāng)前的分析問(wèn)題?

淘寶的數(shù)據(jù)魔方一定程度說(shuō)明了OLAP的發(fā)展方向，針對(duì)特定的業(yè)務(wù)問(wèn)題，提供特定的多維數(shù)據(jù)解決方案，我們需要提供給用戶(hù)的是一個(gè)在體驗(yàn)、性能、速度上都OK的專(zhuān)業(yè)化系統(tǒng)。

業(yè)務(wù)導(dǎo)向+定制化的后臺(tái)數(shù)據(jù)解決方案(比如各類(lèi)大數(shù)據(jù)組件)是未來(lái)OLAP的方向。

6、挖掘平臺(tái)-從樣本到全量，需要全面升級(jí)裝備

SAS、SPSS都是傳統(tǒng)數(shù)據(jù)挖掘的利器，但他們大部分時(shí)候只能在PC上進(jìn)行抽樣分析，顯然，大數(shù)據(jù)的全量分析是其無(wú)法承擔(dān)的，比如社交網(wǎng)絡(luò)、時(shí)間序列等等。

傳統(tǒng)數(shù)據(jù)挖掘平臺(tái)似乎沒(méi)有拿得出手的東西，以前IBM DB2有個(gè)DATA MINER，后來(lái)放棄了，Teradata可以，有自己的算法庫(kù)，但面對(duì)海量數(shù)據(jù)其計(jì)算能力顯然也力不從心，跟大數(shù)據(jù)的SPARK等差了一個(gè)檔次，我們接觸的很多合作伙伴，大多開(kāi)始將SPARK做為大規(guī)模并行算法的標(biāo)準(zhǔn)套件了。

即使如邏輯回歸、決策樹(shù)等傳統(tǒng)算法， SPARK顯然能基于更多的樣本數(shù)據(jù)甚至全量數(shù)據(jù)進(jìn)行訓(xùn)練，比SPSS，SAS僅能在PC上搗鼓要好很多。

傳統(tǒng)BI的SAS和SPSS仍然有效，但基于大數(shù)據(jù)平臺(tái)的全量算法也應(yīng)該納入BI的視野。

7、數(shù)據(jù)管理-不與時(shí)俱進(jìn)，就是一個(gè)死

數(shù)據(jù)管理類(lèi)的系統(tǒng)很難建，因?yàn)闆](méi)有你生產(chǎn)系統(tǒng)也不會(huì)死，有了也很難評(píng)估價(jià)值，且運(yùn)維的成本過(guò)高，一不小心就陷入了到底誰(shuí)服務(wù)誰(shuí)的問(wèn)題。

最早接觸元數(shù)據(jù)管理系統(tǒng)是在2006-2007年吧，那個(gè)時(shí)候搞元數(shù)據(jù)還是蠻有前瞻性的，搞了很多年，卻明白一個(gè)道理，如果你把元數(shù)據(jù)當(dāng)成一個(gè)外掛，這個(gè)元數(shù)據(jù)系統(tǒng)沒(méi)有成功的可能，搞事后補(bǔ)錄這種看似可以的方法，無(wú)論制度如何完善，系統(tǒng)解析能力如何強(qiáng)大，也最終會(huì)走向源系統(tǒng)和元數(shù)據(jù)兩張皮的現(xiàn)象，失去應(yīng)有的價(jià)值。

只要不解決這個(gè)問(wèn)題，我嚴(yán)重懷疑傳統(tǒng)BI元數(shù)據(jù)管理真正成功的可能。大數(shù)據(jù)時(shí)代，隨著數(shù)據(jù)量、數(shù)據(jù)類(lèi)型、技術(shù)組件等的不斷豐富，搞事后元數(shù)據(jù)更是不可能的事情。

新時(shí)代的數(shù)據(jù)管理系統(tǒng)長(zhǎng)啥樣?一提倡生產(chǎn)即管理，也就是說(shuō)，元數(shù)據(jù)管理的規(guī)則是通過(guò)系統(tǒng)化的方式固話(huà)在系統(tǒng)生產(chǎn)流程中，我們提倡無(wú)文檔的數(shù)據(jù)開(kāi)發(fā)，因?yàn)槲臋n就是元數(shù)據(jù)，所有關(guān)于元數(shù)據(jù)的要求已經(jīng)梳理成規(guī)則并成為數(shù)據(jù)開(kāi)發(fā)環(huán)境的一部分。比如你建個(gè)表，在給你可視化開(kāi)發(fā)界面時(shí)，關(guān)于表的定義已經(jīng)強(qiáng)制要求在線(xiàn)輸入必須的說(shuō)明，你寫(xiě)的代碼也被規(guī)則化，以便于元數(shù)據(jù)自動(dòng)解析，成為數(shù)據(jù)質(zhì)量監(jiān)控的一部分。

二要能評(píng)估數(shù)據(jù)效益，通過(guò)一的手段，數(shù)據(jù)跟應(yīng)用可以形成關(guān)聯(lián)，應(yīng)用的價(jià)值可以傳導(dǎo)為數(shù)據(jù)的價(jià)值，為數(shù)據(jù)的價(jià)值管理提供標(biāo)準(zhǔn)，做數(shù)據(jù)最郁悶的是，我創(chuàng)造了一個(gè)模型，但不知道這個(gè)模型的價(jià)值，自己的工作變得可有可無(wú)，我也不知道如何開(kāi)展優(yōu)化，幾十萬(wàn)張表爛在哪里，不敢去清理它們。

三是跨平臺(tái)管理，這么多的技術(shù)組件，比如HADOOP、MPP、流處理等等，你的管理系統(tǒng)要能無(wú)縫銜接和透明訪(fǎng)問(wèn)，每新增一類(lèi)組件，都要能及時(shí)接入管理系統(tǒng)，否則，接入一個(gè)，該組件上的數(shù)據(jù)就成為游離之外的數(shù)據(jù)，數(shù)據(jù)管理無(wú)從談起。

數(shù)據(jù)管理，最怕半拉子工程，要系統(tǒng)化，就要做徹底，否則，還不如文檔記錄算了，沒(méi)什么多大的區(qū)別。

8、審視定位-BI干BI的事情，各司其職

傳統(tǒng)BI，做報(bào)表取數(shù)的太多，研究平臺(tái)和算法的太少，重復(fù)勞動(dòng)太多，創(chuàng)造性工作太少，隨著業(yè)務(wù)的發(fā)展，BI的人逐漸老去，但系統(tǒng)中留下的東西不多，非常遺憾。

大數(shù)據(jù)時(shí)代到來(lái)，這種情況需要改變，該是重新審視自己的定位的時(shí)候了，報(bào)表取數(shù)的確是BI的基礎(chǔ)工作，但從事BI的人不應(yīng)該總是扮演拉磨的驢子的角色，應(yīng)該是最終掌舵的那個(gè)人，我可以拉一會(huì)，但我需要研究如何拉得更快，最后讓機(jī)器來(lái)代替我拉，或者讓拉磨的工作非常愉快，需要的人可以自己來(lái)拉。

BI的人有太多需要?jiǎng)?chuàng)新和學(xué)習(xí)的東西，如果有太多取數(shù)，搞個(gè)取數(shù)機(jī)器人，如果太多報(bào)表，搞個(gè)指標(biāo)體系，如果太多需求，搞個(gè)自助工具或給個(gè)租戶(hù)環(huán)境，誘惑業(yè)務(wù)人員自己來(lái)做，需求永無(wú)止境，欲望永不滿(mǎn)足，靠人肉填坑，永遠(yuǎn)填不滿(mǎn)的，需要BI人的引導(dǎo)，授人予魚(yú)，不如授人予漁。

傳統(tǒng)BI還能走多遠(yuǎn)？提了八點(diǎn)，對(duì)于處于不同階段的人，可能也有不同的理解，當(dāng)然僅為一家之言，希望有所啟示。

更多大數(shù)據(jù)與分析相關(guān)行業(yè)資訊、解決方案、案例、教程等請(qǐng)點(diǎn)擊查看>>>

詳情請(qǐng)咨詢(xún)在線(xiàn)客服！

客服熱線(xiàn)：023-66090381