1、不要將數(shù)據(jù)提取出來，做成數(shù)據(jù)集市和數(shù)據(jù)立方，因為“提取”就意味著轉(zhuǎn)移。

2、記住了，安全即服務。

3、扁平化會毀掉原始結構中所表達的重要關系。

4、用戶希望和可視元素進行交互，得到他們正在尋找的答案，而不是對你已經(jīng)提供給他們的結果進行交叉過濾。

5、創(chuàng)造數(shù)據(jù)的人很多，但利用數(shù)據(jù)的人卻很少。

如今，各路企業(yè)和組織都不再使用上一代架構來存儲大數(shù)據(jù)。既然如此，為什么還要使用上一代商業(yè)智能（BI）工具來進行大數(shù)據(jù)分析呢？在為企業(yè)選擇BI工具時，應該遵守以下“十誡”。

第一誡：不要轉(zhuǎn)移大數(shù)據(jù)

轉(zhuǎn)移大數(shù)據(jù)代價高昂：畢竟，大數(shù)據(jù)很“大”，如果打包轉(zhuǎn)移，負擔太重。不要將數(shù)據(jù)提取出來，做成數(shù)據(jù)集市和數(shù)據(jù)立方，因為“提取”就意味著轉(zhuǎn)移，會在維護、網(wǎng)絡性能附加處理器方面造成紛亂龐雜的問題，出現(xiàn)兩個邏輯上相同的備份。讓BI深入更底層運行數(shù)據(jù)就是大數(shù)據(jù)萌發(fā)的最初動力。

第二誡：不要偷盜！或者說不要違反企業(yè)安全政策

安全并非可有可無。不幸的是，數(shù)據(jù)泄露事件頻繁發(fā)生，這表明實現(xiàn)安全并非易事。要選擇能夠利用現(xiàn)有安全模型的BI工具。依靠Ranger、Sentry、Knox等綜合性安全系統(tǒng)，大數(shù)據(jù)可以使實現(xiàn)數(shù)據(jù)安全變得更加容易，現(xiàn)在就連Mongo數(shù)據(jù)庫都有了令人驚嘆的安全架構。所有那些模型都允許你插入權限、將用戶信息一路傳播到應用層、實施可視化的授權和提供與該授權相關的數(shù)據(jù)志。記住了，安全即服務。

第三誡：不要按照用戶數(shù)和數(shù)據(jù)量付費

大數(shù)據(jù)的一個主要好處在于，如果做好了，它就能實現(xiàn)極高的性價比。把5PB數(shù)據(jù)存儲到Oracle可能會讓你傾家蕩產(chǎn)，但存儲到大數(shù)據(jù)系統(tǒng)則不會。盡管如此，在付錢購買之前，應該警惕某些價格陷阱。有些BI應用按照數(shù)據(jù)量或者索引數(shù)據(jù)量向用戶收費。千萬當心！數(shù)據(jù)量和大數(shù)據(jù)使用量出現(xiàn)指數(shù)式增長是再平常不過的事情，我們的客戶曾目睹其訪問量在短短幾個月時間里從數(shù)百億次猛增到數(shù)千億次，用戶數(shù)擴大50倍。這是大數(shù)據(jù)系統(tǒng)的另一個好處：漸進式可擴展性。不要被低價所迷惑，去購買一種會對企業(yè)增長征收“高稅”的BI工具。

第四誡：要貪大膽借鑒別人的可視圖

分享靜態(tài)圖表？這些我們已經(jīng)做過了，無論是PDF文檔、PNG圖片還是電郵附件里，到處都在傳播靜態(tài)圖表。但對于大數(shù)據(jù)和BI，靜態(tài)圖表還遠遠不夠：你擁有的一切無非都是些漂亮的圖片罷了。你應該讓任何人都能夠隨心所欲地與你的數(shù)據(jù)進行交互。應該把可視化看作是駕馭數(shù)據(jù)的交互式路線圖。為什么要閉門造車呢？將交互式可視化手段公之于眾只是第一步?？纯碐ithub的模式就知道。與其說“這是我的最終發(fā)布產(chǎn)品”，不如說“這是一幅可視圖，復制下來，分解它，我就是從中得到那些見解，看看它還能用于其他哪些領域”。這會其他人從你的見解中學到有用的東西。

第五誡：要分析天然形態(tài)的數(shù)據(jù)

大數(shù)據(jù)是“非結構化”的，這樣的說法我們已經(jīng)聽過太多太多。其實不然。財務和傳感器會產(chǎn)生大量的鍵值對。JSON（可能是當下最流行的數(shù)據(jù)格式）可以是半結構化、多結構化等等，Mongo數(shù)據(jù)庫對這種數(shù)據(jù)格式下了重注。JSON具有好處理和可規(guī)模化的優(yōu)點，但如果把它轉(zhuǎn)換成表格，表達力就會丟失。很多大數(shù)據(jù)仍然被制成表格，通常擁有數(shù)千欄。你不得不為所有的值尋找關系：“在那種情況下……從這里選擇這個”。扁平化會毀掉原始結構中所表達的重要關系。遠離那些對你說“請把數(shù)據(jù)轉(zhuǎn)換成表格，因為我們一直都這么干”的BI解決方案。

第六誡：不要無限期地等待結果

在2016年，我們預計數(shù)據(jù)處理速度將會變得快起來。一個典型方法是聯(lián)機分析處理（OLAP）立方，本質(zhì)上就是把數(shù)據(jù)轉(zhuǎn)移到預計算緩存，從而加快處理速度。問題在于，你必須提取和轉(zhuǎn)移數(shù)據(jù)（請看第一誡），以便建造數(shù)據(jù)立方，然后才能加快速度。現(xiàn)在，這種方法能夠在一定的數(shù)據(jù)規(guī)模下良好運轉(zhuǎn)，但如果臨時表格過于龐大，你的筆記本電腦在試圖將表格本地化的時候就會崩潰。當你提取新數(shù)據(jù)重建緩存時，新數(shù)據(jù)的分析就會中途停下來。此外還要注意樣本問題，你可能會得到一個看起來不錯、效果很好的可視圖，但最后卻發(fā)現(xiàn)全不對路，而問題就出在缺少大局觀。要選擇那些能便捷地不斷調(diào)整數(shù)據(jù)的BI工具。

第七誡：不要制作報告，而要打造應用

在很長一段時間里，“獲得數(shù)據(jù)”意味著獲得報告。在大數(shù)據(jù)時代，BI用戶希望從多個來源獲得異步數(shù)據(jù)，這樣他們就不需要刷新任何東西，就好像瀏覽器和移動設備上運行的其他各種東西。用戶希望和可視元素進行交互，得到他們正在尋找的答案，而不是對你已經(jīng)提供給他們的結果進行交叉過濾。Rails等框架使打造Web應用變得更加簡單。為什么不對BI應用做同樣的事情呢？沒理由不對這些應用、應用程序接口（API）、模板、可重用性等等采取類似的做法?，F(xiàn)在是時候通過現(xiàn)代Web應用開發(fā)的透鏡來看待BI。

第八誡：要利用智能工具

在提供基于數(shù)據(jù)的可視圖方面，BI工具已經(jīng)證明了自己的能力?，F(xiàn)在則輪到在模型和緩存的自動維護上下功夫，這樣一來，終端用戶就不必操這個心了。在龐大的數(shù)據(jù)規(guī)模下，自動維護幾乎是不可或缺的，我們可以從用戶和數(shù)據(jù)與可視圖的交互中獲得大量信息，現(xiàn)代工具應該使用這些信息來對數(shù)據(jù)網(wǎng)絡效應加以利用。另外，要選擇那些內(nèi)置全面搜索能力的工具，因為我曾見過有些客戶擁有成千上萬的可視圖。你需要一種迅速查找的方法，在網(wǎng)絡的長年熏陶之下，我們已經(jīng)習慣了搜索，而不是翻找菜單。

第九誡：要超越基本范疇

如今的大數(shù)據(jù)系統(tǒng)因為預測分析能力而著稱。相關性、預測和其他功能使企業(yè)用戶比以往任何時候都能更便捷地進行高級分析。不需要編程經(jīng)驗就能處理大數(shù)據(jù)的可視化技術讓分析師如有神助，超越了基本分析的范疇。為了實現(xiàn)其真正的潛力，大數(shù)據(jù)不應該依賴于每個人都變成R預言程序員。人類非常善于處理可視化信息，我們必須更加努力地將可視化信息呈現(xiàn)在人們眼前。

第十誡：不要只是站在數(shù)據(jù)湖邊，等著數(shù)據(jù)科學家來干活兒

不管你是把大數(shù)據(jù)當成數(shù)據(jù)湖還是企業(yè)數(shù)據(jù)中心，Hadoop已經(jīng)改變了數(shù)據(jù)的處理速度和存儲成本，我們每天都在創(chuàng)造更多的數(shù)據(jù)。但在真正利用大數(shù)據(jù)為企業(yè)用戶服務方面，常常存在一種“只寫系統(tǒng)”——創(chuàng)造數(shù)據(jù)的人很多，但利用數(shù)據(jù)的人卻很少。

其實，用Hadoop里的數(shù)據(jù)可以為企業(yè)用戶解答數(shù)不清的問題。BI講究的是打造數(shù)據(jù)可視化應用，為日常決策提供支持。企業(yè)里的每個人都希望做出數(shù)據(jù)驅(qū)動的決策。把大數(shù)據(jù)能夠解答的所有問題局限于需要數(shù)據(jù)科學家來處理的問題，這是奇恥大辱。

更多關于大數(shù)據(jù)和商業(yè)智能BI的話題，歡迎登陸慧都科技的官網(wǎng)//fc6vip.cn/tecserv/bigdata與我們溝通交流。