核算大數(shù)據(jù)真實(shí)成本

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

重新分配的預(yù)算

在如今的經(jīng)濟(jì)環(huán)境下，企業(yè)顯然不會投入新的預(yù)算給到大數(shù)據(jù)，最可能的方案，是將現(xiàn)有IT預(yù)算重新分配。比如將原先分配在傳統(tǒng)數(shù)據(jù)倉庫或者設(shè)備上的預(yù)算調(diào)配到成本更低、更易于擴(kuò)展的開源項(xiàng)目上，比如能夠?yàn)楣芾砗头治鰯?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儀表盤，分析和報(bào)告工具，那么你肯定不想打擾那些不僅擔(dān)心影響性能水平而且需要培訓(xùn)新工具培訓(xùn)的商業(yè)用戶。

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

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

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

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

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

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

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

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

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

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