從事BI多年,經歷了經營分析系統的大建設,大發展時期,也有幸處在大數據與傳統BI系統的交替之際,所以特別來談談,傳統BI還能走多遠?算法
技術爲業務服務,所以這裏不談技術,更多從使用者的角度去闡述緣由,理了八個方面,每一個方面都是筆者親歷,固然任何窮舉法都沒法證實絕對正確,但但願能引發思考。數據庫
一、資源申請-從月到日,不可同日耳語安全
自從企業有了大數據MPP、HADOOP、流處理三個資源池,租戶生效基本都是所見即所得。公司甚至爲了申請方便,搞了資源套餐,咱們申請資源叫點套餐,這種資源申請模式爲對外靈活開放數據提供了基本保障,在半年時間內,內外部租戶已經開出了100多個(之前可能叫數據集市),如今回想起來,若是沒有這個能力,公司的對外變現基本不可能。網絡
不管是阿里雲仍是AWS,都是這個套路,但爲何企業要本身作,由於較大的企業自己內部就是個巨大的市場,有各種的應用要求,從數據、安全、接口、技術等各個方面講,都不適合放到外部平臺。運維
傳統BI的小型機階段,沒有資源池概念,資源申報按硬件臺數算,須要提早申請預算,即便硬件到位,集成時間也過於漫長,記得之前爲11個地市規劃11個數據集市,採用四臺570劃分12個分區,搞了1個多月,效率不可同日而語。分佈式
大數據系統在資源粒度、申請速度、資源動態擴展等各個方面都完爆傳統BI,在業務快速部署上具備沒法比擬的優點,爲業務創新奠基了很好的基礎。若是你作過DB2的項目集成啥的,每一次都涉及規劃、劃盤、分區、安裝等等,就知道啥叫等待。工具
二、數據採集-多樣性才能創造更多應用場景性能
傳統ETL的基本套路都是從源數據庫導出成文本,而後經過客戶端工具導入到目的數據庫,導出用EXPORT,傳輸用FTP,導入用IMPORT,固然,同種類型的數據庫可能用DBLINK等這種快捷方式,程序中採用ODBC啥的鏈接數據庫來進行操做。不少公司專門開發了一些多庫之間互導數據的工具,固然通常企業級的平臺不用,可擴展性、靈活性太差。傳統ETL的技術很是適應以天或月爲分析週期的靜態應用要求。學習
我想大多數企業,BI的數據分析如今週期基本仍是天,筆者作了10年BI,記得企業很長一段時間,是以月爲單位ETL數據的,固然,從業務的角度講,夠用便可,有人會問,數據的週期減小到小時、分鐘、秒以至實時,到底有多大現實意義?但真的業務上不須要更短週期的分析嗎?是由於你們BI分析的套路習慣使然仍是能力不夠使然?大數據
從取數的角度講,業務人員永遠但願你取得數據越快越及時越好,咱們原來只出月報,後來性能上去了,複雜的日報也能出了,日報變成了標配,日報以後呢,實時是否應該成爲將來的標配?
從應用的角度講,企業除了一堆運營指標報表,通常有營銷和風控兩個角度有數據的現實需求,實時營銷顯然比靜態營銷效果更好一點,BAT若是不搞實時營銷基本就無法活,實時風控顯然比離線風控效果更好有一點,好比反欺詐系統,若是不是實時的監聽,如何在詐騙的事中介入?
從趨勢的角度講,若是你認同將來的世界是知足個性化的世界,那麼,只有實時的數據才能蘊含更多的信息,才能給你更爲個性化的服務,你會想到太多的場景須要實時化採集。
即便你沒有以上提的任何需求,但技術和業務永遠是互動的,你具有了按小時提供的能力,人家就會創造按小時的業務場景,你具有了實時的提供能力,人家就會創造實時的業務場景。誰是蛋誰是雞說不清楚,但若是你想服務的更好,就應該在技術層面更前瞻性一點。
但傳統BI能支撐嗎?傳統企業的BI不實時,本質不是沒有需求,也許是能力不夠所致,我記得之前CRM上線要搞個實時放號指標監控,也是蠻困難的事情,之前出帳只有月報啊,如今,沒有日報,還能活? 我記得不少年前第一份日帳報表是IT人員本身提的,由於能力到了。 那將來10年呢?
ETL是傳統數據倉庫中的一個概念,我以爲該升級了,多樣化的採集方式是王道,這是大勢所趨,有三樣東西是最重要的,一個是採集方式的百花齊放,即消息、數據流、爬蟲、文件、日誌增量都能支持,二是數據的流動不是單向的,不只僅是E,並且是X,即交換,這樣就極大衍生了ETL的內涵,三是數據採集的分佈式,能夠並行動態擴展,ETL的讀寫問題能較好解決。這些恰是傳統BI作不到的。
三、計算性能-性價比是王道,更迭速度比想象的快
DB二、Teradata在數據倉庫領域一直佔據着巨大的份額,咱們用GBASE+HADOOP花了半年時間把2臺P780替換掉了,綜合性能能夠說是原來的1.5倍,但投資只有幾分之一,雖然前期涉及一些調優,對於代碼也有更高的要求,但性價比很是高,關鍵是可以多租戶動態擴展,容災能力也超DB2。記得之前DB2一旦節點出現問題,雖然也能切換,但性能每每降低一半,極大影響業務。
傳統數據倉庫,對於不一樣的數據處理方式每每是一視同仁的,但事實上,不一樣數據處理階段,對於數據處理的要求存在結構性的不一樣,一些簡單的轉化和彙總,在庫外方式處理比庫內處理合算,但傳統BI習慣於把數據所有導入到數據倉庫中作,浪費了珍貴的小型機系統資源,性價比很低。所以,當前MPP+HADOOP混搭型數據倉庫漸成趨勢,HADOOP擅長海量簡單的批量處理,MPP擅長數據關聯分析,好比eBAY,中國移動等都採用了相似的方案。
從綜合的角度講,DB2等數據倉庫固然有它的優點,好比引覺得豪的穩定,但這些技術過於依賴國外,感受運維能力每況愈下,關鍵問題的解決愈來愈力不從心,穩定這個詞也要打上大大的問號,不知道其餘企業感受如何。要相信筆者不是打國產GBASE廣告,坑不少,但值得擁有。
四、報表系統-審美疲勞不可避免,個性化是趨勢
用過不少商業化的報表系統,好比BRIO、BO、BIEE等等,系統都提供了較好的可視化界面,對於輕量級數據的展示也不錯,但我以爲這個對於大型企業來說沒有吸引力。
一是可替代性太強,如今開源組件太多了,功能也雷同,爲何要用標準化被捆綁的東西,對於具備必定開發能力的公司,彷佛無此必要。
二是開源性太差,企業有大量個性化的要求,好比安全控制等等,但這些產品的開放性較差,不少時候知足不了要求。
三是不靈活,再通用,能作得過EXCEL嗎,不要奢望從一個報表系統上能直接摘取一個報表粘貼到一個報告上,老是要二次加工,既然這樣,還不如數據直接灌入EXCEL簡單。
四是速度太慢,當前的報表已經不是傳統BI意義的報表,由於維度和粒度要求很細,結果記錄數過億的也不在少數,好比咱們的指標庫一年記錄是百億條,傳統BI報表根本沒法支撐,樣子好看是暫時的,業務人員最關注的始終是報表的速度。
固然,對於小企業可能仍然具備必定吸引力,但這個開放的時代,需求和新技術層出不窮,這類標準化的產品能遇上變化嗎?若是你但願HBASE跟BIEE結合,怎麼辦?是等着廠家慢慢推出版本,仍是乾脆本身幹?
五、多維分析-適應性較差,定製化纔是方向
用過一些商業化的多維分析系統,也叫OLAP吧,好比IBM的ESSBASE。OLAP是幾十年前老外提出的概念,經過各維度分析快速獲得所需的結果,但這個OLAP到底有多大的實用價值?
OLAP產品老是想經過通用化的手段解決一個專業性分析問題,從誕生開始就有硬傷,由於分析變化無常,你是但願本身在後臺爲所欲爲用SQL馳騁江湖仍是面對一個呆板的界面進行固定的複雜的多維操做?筆者做爲技術人員不喜歡用它,但業務人員也不喜歡用它,操做門檻偏高。
在開放性上,傳統OLAP的後臺引擎仍然是傳統數據庫,顯然不支持一些海量的大數據系統;打CUBE是個設計活,很是耗時,每次更新數據要重打CUBE,老是讓筆者抓狂,不知道如今有啥改進;千萬級數據量、10個維度估計也是它的性能極限了吧;最後,之前打的CUBE真的能解決你當前的分析問題?
淘寶的數據魔方必定程度說明了OLAP的發展方向,針對特定的業務問題,提供特定的多維數據解決方案,咱們須要提供給用戶的是一個在體驗、性能、速度上都OK的專業化系統。
業務導向+定製化的後臺數據解決方案(好比各種大數據組件)是將來OLAP的方向。
六、挖掘平臺-從樣本到全量,須要全面升級裝備
SAS、SPSS都是傳統數據挖掘的利器,但他們大部分時候只能在PC上進行抽樣分析,顯然,大數據的全量分析是其沒法承擔的,好比社交網絡、時間序列等等。
傳統數據挖掘平臺彷佛沒有拿得出手的東西,之前IBM DB2有個DATA MINER,後來放棄了,Teradata能夠,有本身的算法庫,但面對海量數據其計算能力顯然也力不從心,跟大數據的SPARK等差了一個檔次,咱們接觸的不少合做夥伴,大多開始將SPARK作爲大規模並行算法的標準套件了。
即便如邏輯迴歸、決策樹等傳統算法, SPARK顯然能基於更多的樣本數據甚至全量數據進行訓練,比SPSS,SAS僅能在PC上搗鼓要好不少。
傳統BI的SAS和SPSS仍然有效,但基於大數據平臺的全量算法也應該歸入BI的視野。
七、數據管理-不與時俱進,就是一個死
數據管理類的系統很難建,由於沒有你生產系統也不會死,有了也很難評估價值,且運維的成本太高,一不當心就陷入了到底誰服務誰的問題。
最先接觸元數據管理系統是在2006-2007年吧,那個時候搞元數據仍是蠻有前瞻性的,搞了不少年,卻明白一個道理,若是你把元數據當成一個外掛,這個元數據系統沒有成功的可能,搞過後補錄這種看似能夠的方法,不管制度如何完善,系統解析能力如何強大,也最終會走向源系統和元數據兩張皮的現象,失去應有的價值。
只要不解決這個問題,我嚴重懷疑傳統BI元數據管理真正成功的可能。大數據時代,隨着數據量、數據類型、技術組件等的不斷豐富,搞過後元數據更是不可能的事情。
新時代的數據管理系統長啥樣?一提倡生產即管理,也就是說,元數據管理的規則是經過系統化的方式固話在系統生產流程中,咱們提倡無文檔的數據開發,由於文檔就是元數據,全部關於元數據的要求已經梳理成規則併成爲數據開發環境的一部分。好比你建個表,在給你可視化開發界面時,關於表的定義已經強制要求在線輸入必須的說明,你寫的代碼也被規則化,以便於元數據自動解析,成爲數據質量監控的一部分。
二要能評估數據效益,經過一的手段,數據跟應用能夠造成關聯,應用的價值能夠傳導爲數據的價值,爲數據的價值管理提供標準,作數據最鬱悶的是,我創造了一個模型,但不知道這個模型的價值,本身的工做變得無關緊要,我也不知道如何開展優化,幾十萬張表爛在哪裏,不敢去清理它們。
三是跨平臺管理,這麼多的技術組件,好比HADOOP、MPP、流處理等等,你的管理系統要能無縫銜接和透明訪問,每新增一類組件,都要能及時接入管理系統,不然,接入一個,該組件上的數據就成爲遊離以外的數據,數據管理無從談起。
數據管理,最怕半拉子工程,要系統化,就要作完全,不然,還不如文檔記錄算了,沒什麼多大的區別。
八、審視定位-BI幹BI的事情,各司其職
傳統BI,作報表取數的太多,研究平臺和算法的太少,重複勞動太多,創造性工做太少,隨着業務的發展,BI的人逐漸老去,但系統中留下的東西很少,很是遺憾。
大數據時代到來,這種狀況須要改變,該是從新審視本身的定位的時候了,報表取數的確是BI的基礎工做,但從事BI的人不該該老是扮演拉磨的驢子的角色,應該是最終掌舵的那我的,我能夠拉一會,但我須要研究如何拉得更快,最後讓機器來代替我拉,或者讓拉磨的工做很是愉快,須要的人能夠本身來拉。
BI的人有太多須要創新和學習的東西,若是有太多取數,搞個取數機器人,若是太多報表,搞個指標體系,若是太多需求,搞個自助工具或給個租戶環境,誘惑業務人員本身來作,需求永無止境,慾望永不知足,靠人肉填坑,永遠填不滿的,須要BI人的引導,授人予魚,不如授人予漁。
傳統BI還能走多遠?提了八點,對於處於不一樣階段的人,可能也有不一樣的理解,固然僅爲一家之言,但願有所啓示。