大數(shù)據(jù)時(shí)代：傳統(tǒng)BI還能走多遠(yuǎn)？-創(chuàng)新互聯(lián)

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

<img src="http://p1.pstatp.com/large/e4900012f674b176306" alt="傳統(tǒng)BI還能走多遠(yuǎn)？">

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

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

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

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

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

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

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

<img src="http://p3.pstatp.com/large/e490001300b29e6288d" alt="傳統(tǒng)BI還能走多遠(yuǎn)？">

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

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

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

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

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

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

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

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

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

<img src="http://p3.pstatp.com/large/e49000130d1245bcbf9" alt="傳統(tǒng)BI還能走多遠(yuǎn)？">

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

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

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

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

<img src="http://p5a.pstatp.com/large/e490001329b57616b71" alt="傳統(tǒng)BI還能走多遠(yuǎn)？">

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

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

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

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

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

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

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

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

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

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

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

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

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

<img src="http://p3.pstatp.com/large/e4e0001332a045c2d0b" alt="傳統(tǒng)BI還能走多遠(yuǎn)？">

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

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

即使如邏輯回歸、決策樹等傳統(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ù)管理類的系統(tǒng)很難建，因?yàn)闆]有你生產(chǎn)系統(tǒng)也不會(huì)死，有了也很難評(píng)估價(jià)值，且運(yùn)維的成本過高，一不小心就陷入了到底誰服務(wù)誰的問題。下載

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

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

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

二要能評(píng)估數(shù)據(jù)效益，通過一的手段，數(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à)值，自己的工作變得可有可無，我也不知道如何開展優(yōu)化，幾十萬張表爛在哪里，不敢去清理它們。

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

數(shù)據(jù)管理，最怕半拉子工程，要系統(tǒng)化，就要做徹底，否則，還不如文檔記錄算了，沒什么多大的區(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í)代到來，這種情況需要改變，該是重新審視自己的定位的時(shí)候了，報(bào)表取數(shù)的確是BI的基礎(chǔ)工作，但從事BI的人不應(yīng)該總是扮演拉磨的驢子的角色，應(yīng)該是最終掌舵的那個(gè)人，我可以拉一會(huì)，但我需要研究如何拉得更快，最后讓機(jī)器來代替我拉，或者讓拉磨的工作非常愉快，需要的人可以自己來拉。

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

“專業(yè)、務(wù)實(shí)、高效、創(chuàng)新、把客戶的事當(dāng)成自己的事”是我們每一個(gè)人一直以來堅(jiān)持追求的企業(yè)文化。 成都創(chuàng)新互聯(lián)公司是您可以信賴的網(wǎng)站建設(shè)服務(wù)商、專業(yè)的互聯(lián)網(wǎng)服務(wù)提供商! 專注于成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、軟件開發(fā)、設(shè)計(jì)服務(wù)業(yè)務(wù)。我們始終堅(jiān)持以客戶需求為導(dǎo)向，結(jié)合用戶體驗(yàn)與視覺傳達(dá)，提供有針對(duì)性的項(xiàng)目解決方案，提供專業(yè)性的建議，創(chuàng)新互聯(lián)建站將不斷地超越自我，追逐市場，引領(lǐng)市場！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

分享標(biāo)題：大數(shù)據(jù)時(shí)代：傳統(tǒng)BI還能走多遠(yuǎn)？-創(chuàng)新互聯(lián)
文章分享：http://bm7419.com/article30/ighpo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、服務(wù)器托管、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站策劃、用戶體驗(yàn)、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)