可喜的是，大數(shù)據(jù)的“4V”理念volume、variety、velocity(容量、類型和速度)、value(在前三者基礎(chǔ)上實現(xiàn)收集、存儲、管理、分析而產(chǎn)生的數(shù)據(jù)價值)已經(jīng)獲得市場認可，正在贏得更多的商業(yè)價值。但問題也隨之而生。如此廣泛的定義意味著不同的需求，不同參與者帶來的不同界定。比如，volume方面，不同的組織定義顯然不同。有些人認為，在相關(guān)BI環(huán)境中或其他系統(tǒng)中，超過10TB需要決策的數(shù)據(jù)就可以稱為大數(shù)據(jù)，而另一些人認為至少要到PB。velocity也是如此。數(shù)以億元的記錄流入到企業(yè)內(nèi)部和外部傳輸中。但是每個業(yè)務(wù)情況完全不同，不僅是規(guī)模和傳輸角度，還有商業(yè)用例和需求也不同。比如一個大銀行大數(shù)據(jù)的問題顯然與電商或航空公司完全不同。再如對比醫(yī)院試圖收集并分析所背有傳感器的病人的數(shù)據(jù)，顯然也與來自公共事業(yè)供應(yīng)商運行智能電網(wǎng)或電信運營商完全不同。是的，即使是被歸類于機器生成或者原始數(shù)據(jù)，但這些數(shù)據(jù)類型并不相同，更不用說數(shù)量或者增長速率。但是他們也有唯一的一個共同特點，在上述所有行業(yè)中每個人的數(shù)據(jù)都需要長期保存，即使是最為細節(jié)數(shù)據(jù)也不能隨意丟棄。

重新分配的預(yù)算

在如今的經(jīng)濟環(huán)境下，企業(yè)顯然不會投入新的預(yù)算給到大數(shù)據(jù)，最可能的方案，是將現(xiàn)有IT預(yù)算重新分配。比如將原先分配在傳統(tǒng)數(shù)據(jù)倉庫或者設(shè)備上的預(yù)算調(diào)配到成本更低、更易于擴展的開源項目上，比如能夠為管理和分析數(shù)據(jù)集提供最優(yōu)方案的Hadoop架構(gòu)等。而這樣帶來的問題是如何將新的Hadoop系統(tǒng)與舊有的更受喜愛和支持的BI或DW環(huán)境相整合或者并存?

新舊系統(tǒng)兼容并不容易

假設(shè)下你已經(jīng)有了一個數(shù)據(jù)倉庫或者數(shù)據(jù)集市，并已經(jīng)開始使用各種ETL或數(shù)據(jù)移動工具及BI儀表盤，分析和報告工具，那么你肯定不想打擾那些不僅擔心影響性能水平而且需要培訓新工具培訓的商業(yè)用戶。

但事實是，針對各類商業(yè)報告和KPI，長期以來你已經(jīng)習慣依賴于嚴格的SLA。但是，在同一時間，業(yè)務(wù)需要獲得新的數(shù)據(jù)集，以便獲得更好的分析，無論是直接數(shù)據(jù)源還是混合現(xiàn)有的客戶數(shù)據(jù)。也許是來自各種互動網(wǎng)站的網(wǎng)絡(luò)日志，點擊流數(shù)據(jù)或社會媒體的數(shù)據(jù)被利用并且用來追蹤。事實上，在追求利潤和競爭優(yōu)勢的環(huán)境中，這樣的數(shù)據(jù)競爭是無法避免的。

我們都知道，傳統(tǒng)的關(guān)系型或柱狀數(shù)據(jù)庫不能處理非結(jié)構(gòu)數(shù)據(jù)庫類型，所以需要不同的解決方案來滿足這方面的業(yè)務(wù)需求。也許有多種形式，但是在開始的時候，更多還是選擇Hdoop架構(gòu)，NoSQL或NewSQL數(shù)據(jù)庫，以及除了MapReduce之外的一些查詢工具。這不是很容易的事情，因為市場上現(xiàn)在有相對多的技術(shù)方案。這些方案往往聲稱可以在Hadoop中運行或提供類似MapReduce或者SQL-like的能力的來管理大量非結(jié)構(gòu)化數(shù)據(jù)。有些是比較成熟的，但是也有些并非所標榜的低成本。開源表面上看成本較低，但是往往需要一定程度的支持，這也是為什么商業(yè)環(huán)境很重要的原因，而這些投入顯然需要預(yù)算。大數(shù)據(jù)并非一個項目，其包含為了滿足業(yè)務(wù)需求而正確部署大數(shù)據(jù)的所有組件。就像其他IT換將中所包含的一樣：軟件許可和支持、硬件資源、專業(yè)技能、專業(yè)服務(wù)以及培訓和特定時間段企業(yè)用戶對于輸入關(guān)鍵要求如指定類型的報告、查詢、分析等在不同時間內(nèi)的需求的變換。

大數(shù)據(jù)成本快速轉(zhuǎn)變

從大數(shù)據(jù)集的硬件支出管理方面來看，最初可能只需要10節(jié)點的Hadoop集群，但是如果你對數(shù)據(jù)速度要求很高，那么這個集群會很快增加到100+節(jié)點。屆時，你需要面對的是大量的支出：額外的人員和技術(shù)資源用以管理整體環(huán)境，比如系統(tǒng)管理及監(jiān)控，通過不同業(yè)務(wù)系統(tǒng)而來的附加軟件，管理集群的工具等。但是如果需要對數(shù)據(jù)流進行實時分析，要檢測欺詐或有不同尋常的地方，則需要一個商業(yè)工具來提供前端GUI控制臺來跟蹤特殊的KPIs或者數(shù)據(jù)可視化工具。這樣商業(yè)用戶可以很快了解相關(guān)情況，將重點放到通過最新收集的數(shù)據(jù)帶來更多價值，減少非重點數(shù)據(jù)帶來的存儲硬件與軟件的成本。

不可否認，大數(shù)據(jù)帶來了新的機遇，這一點在一個量化的ROI中仍然是一個非常現(xiàn)實的挑戰(zhàn)。每個人都在談?wù)撊绾瓮ㄟ^大數(shù)據(jù)和創(chuàng)新技術(shù)來獲得成功，但是相關(guān)成功案例并不多見。也許大數(shù)據(jù)并不成熟，但是好消息是，其發(fā)展速度比IT歷史上的任何其他項目都快，這也受益于在過去的20年里，數(shù)據(jù)倉庫和BI已經(jīng)積累了足夠的經(jīng)驗和教訓。

以案例審核應(yīng)用

想要更仔細地審查大項目主要應(yīng)用領(lǐng)域，最好是通過特定的業(yè)務(wù)類型與案例。 以大型金融機構(gòu)為例，其已經(jīng)擁有了一批傳統(tǒng)的數(shù)據(jù)倉庫和BI系統(tǒng)，由于金融不能丟棄任何數(shù)據(jù)(法令法規(guī)對其的要求)，但現(xiàn)在企業(yè)希望對特定的數(shù)據(jù)集進行目前形勢下的趨勢分析。如審查問題，“在特定時間段內(nèi)，什么構(gòu)成了低風險客戶的消費模式(可參照消費者特征)”以幫助企業(yè)在細分市場獲得更好的業(yè)績。

顯然，IT預(yù)算不會隨著數(shù)據(jù)的增長而增長，相反，很大程度上需要降低成本，為此，很多企業(yè)選擇了擁有更低組建成本，并可深入了解客戶應(yīng)用模式，捕捉半結(jié)構(gòu)和非結(jié)構(gòu)數(shù)據(jù)的Hadoop平臺。前端數(shù)據(jù)倉庫采用專用的Hadoop集群是首選方案，但是很多商業(yè)用戶仍然希望能夠同時通過Hdaoop環(huán)境和現(xiàn)有的傳統(tǒng)數(shù)據(jù)倉庫環(huán)境來訪問。鑒于我們談?wù)摰氖墙鹑跈C構(gòu)，對有效性和安全性的要求都最高。要實現(xiàn)更多新需求，就需要更多技能和盡量避免重復(fù)工作。

下面是一個關(guān)于主要成本因素和評論集的快速表，可以幫助用戶降低成本：

大數(shù)據(jù)基本上是一個商業(yè)問題。在你開始思考“什么業(yè)務(wù)能幫助企業(yè)收集、存儲和分析新的數(shù)據(jù)集等”，就已經(jīng)踏上了應(yīng)用之路。無論你是否考慮主動引入外部顧問還是供應(yīng)商來做相關(guān)項目，都要面對與現(xiàn)有環(huán)境相融合等問題。此外，大部分方案商都愛承諾，但新的創(chuàng)新技術(shù)包括Hadoop和MapReduce是否能夠達到你的測試標準，是否可以與現(xiàn)有系統(tǒng)融合，都是問題。我們都知道，商業(yè)客戶購買僅代表了成功的一半，而另一半是部署。