對(duì)于圍繞云計(jì)算的所有應(yīng)用來(lái)說(shuō)，目前公共云服務(wù)中的應(yīng)用只代表了IT總支出的一小部分。除非主流的、占企業(yè)預(yù)算大頭的關(guān)鍵任務(wù)應(yīng)用能夠遷往公共云，否則這一態(tài)勢(shì)將不會(huì)發(fā)生變化。

公共云應(yīng)用的***瓶頸似乎是高昂的云計(jì)算存儲(chǔ)成本。與Web相關(guān)的云應(yīng)用可能會(huì)存儲(chǔ)數(shù)以百兆的數(shù)據(jù)，而關(guān)鍵任務(wù)應(yīng)用則可能會(huì)存儲(chǔ)TB級(jí)的數(shù)據(jù)，按目前的價(jià)格來(lái)看，其存儲(chǔ)成本是大部分用戶所難以承受的。但是值得慶幸的是，我們有兩種策略可以來(lái)解決這一云存儲(chǔ)成本問(wèn)題：數(shù)據(jù)抽象和分布查詢式數(shù)據(jù)訪問(wèn)。

將數(shù)據(jù)抽象方法用于商業(yè)智能和成本分析應(yīng)用

商業(yè)智能(BI)與分析是云計(jì)算最有前途的兩個(gè)應(yīng)用。這些應(yīng)用都聚集在重要IT決策上，且遍布在規(guī)劃者和決策者中。這使得它們成為理想的云計(jì)算應(yīng)用，但是通常企業(yè)估計(jì)一個(gè)試運(yùn)行商業(yè)智能應(yīng)用的運(yùn)行成本至少為三萬(wàn)美元，這個(gè)價(jià)格相當(dāng)昂貴。

建立真實(shí)而不過(guò)分龐大的大數(shù)據(jù)是我們之前提出的兩個(gè)數(shù)據(jù)成本管理方法中***個(gè)，即數(shù)據(jù)抽象的一個(gè)具體實(shí)施。數(shù)據(jù)抽象是從原始公司信息中產(chǎn)生一個(gè)或多個(gè)摘要數(shù)據(jù)庫(kù)的機(jī)制，其數(shù)據(jù)庫(kù)規(guī)模應(yīng)確保它(們)能夠被經(jīng)濟(jì)地存儲(chǔ)在云計(jì)算中。

BI和真實(shí)數(shù)據(jù)分析降低云存儲(chǔ)成本

我們?cè)卺t(yī)療行業(yè)中的某一個(gè)客戶說(shuō)，通過(guò)診斷代碼、治療代碼以及年齡/性別的形式，創(chuàng)建一組患者信息摘要數(shù)據(jù)庫(kù)，將減少三百倍以上的信息量，這意味著其云數(shù)據(jù)存儲(chǔ)和訪問(wèn)成本僅為未經(jīng)數(shù)據(jù)抽象處理的三百分之一。

如果希望數(shù)據(jù)抽象方法成為一種高效的成本管理方法，那么就必須對(duì)如何進(jìn)行分析以及分析的對(duì)象進(jìn)行深入研究。大多數(shù)BI運(yùn)行的目的并不是為了發(fā)現(xiàn)細(xì)節(jié)信息;它們是為了尋找某種規(guī)律或某種發(fā)展趨勢(shì)。對(duì)于大多數(shù)的行業(yè)來(lái)說(shuō)，有明確的變量非常重要，例如醫(yī)療行業(yè)中的診斷和治療就是這樣。通過(guò)對(duì)這些變量創(chuàng)建摘要數(shù)據(jù)庫(kù)，能夠通過(guò)加快訪問(wèn)速度來(lái)降低成本支出，同時(shí)也不會(huì)影響分析工作本身。一旦定義好變量的特定組合，那么之后如有需要從未抽象的數(shù)據(jù)中提取該組合的詳細(xì)信息也是非常容易實(shí)現(xiàn)。這樣一來(lái)，基于數(shù)據(jù)抽象的分析就成為了一個(gè)云應(yīng)用，可以用于數(shù)據(jù)中心的詳細(xì)分析操作。

對(duì)非結(jié)構(gòu)化數(shù)據(jù)使用分布查詢式訪問(wèn)方法

數(shù)據(jù)抽象方法適用于對(duì)具有少量重要變量參數(shù)結(jié)構(gòu)化交易數(shù)據(jù)的分析應(yīng)用。但它不適用于非結(jié)構(gòu)化格式的傳統(tǒng)大數(shù)據(jù)，這是因?yàn)榉墙Y(jié)構(gòu)化數(shù)據(jù)的抽象比較難以實(shí)現(xiàn)。有些公司在創(chuàng)建電子郵件特定單詞或單詞組合高識(shí)別率數(shù)據(jù)庫(kù)的應(yīng)用中有過(guò)不少成功案例，但是其前提條件是這樣的關(guān)鍵詞/詞組合是可以預(yù)先知道的。對(duì)于大多數(shù)應(yīng)用來(lái)說(shuō)，還是需要有一個(gè)更為通用的方法的。這個(gè)方法就是我們所提出的第二個(gè)數(shù)據(jù)成本管理策略——分布查詢式數(shù)據(jù)訪問(wèn)方法。

通常來(lái)說(shuō)，數(shù)據(jù)處理任務(wù)可以分為三個(gè)部分：對(duì)數(shù)據(jù)的實(shí)際處理、用于定位數(shù)據(jù)位置的數(shù)據(jù)庫(kù)管理訪問(wèn)，以及從海量存儲(chǔ)設(shè)備中獲取信息的存儲(chǔ)訪問(wèn)。如果由于成本原因而無(wú)法把大量的信息遷往云，那么也就無(wú)法在云中實(shí)現(xiàn)信息的逐條訪問(wèn)。***的解決方法就是在云以外的某地托管數(shù)據(jù)和查詢邏輯，并發(fā)送數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS)查詢命令以提取數(shù)據(jù)的一個(gè)子集，從而實(shí)現(xiàn)在云中的數(shù)據(jù)處理。在企業(yè)內(nèi)部確保DBMS引擎功能并只把查詢和結(jié)果遷入/出云能夠顯著地降低數(shù)據(jù)存儲(chǔ)和訪問(wèn)成本。

針對(duì)這類功能劃分對(duì)應(yīng)用程序進(jìn)行結(jié)構(gòu)設(shè)計(jì)是相對(duì)簡(jiǎn)單的，事實(shí)上，正有越來(lái)越多的廠商提供了包含存儲(chǔ)/查詢功能的DBMS引擎或設(shè)備。但是，構(gòu)建針對(duì)應(yīng)用程序的檢查以防止有問(wèn)題的查詢結(jié)構(gòu)提供所有的數(shù)據(jù)信息是非常必要的措施。在這里，試點(diǎn)測(cè)試是不夠的;在交付前，查詢邏輯應(yīng)當(dāng)測(cè)試結(jié)果的大小。

認(rèn)識(shí)到分布式查詢處理的問(wèn)題

大數(shù)據(jù)的一個(gè)特殊狀況是，有可能出現(xiàn)信息不是存儲(chǔ)在一個(gè)地方的情況。電子郵件、即時(shí)通信以及協(xié)作信息通常都被保存在它產(chǎn)生的地方，因此企業(yè)可能會(huì)擁有數(shù)十個(gè)或數(shù)百個(gè)網(wǎng)站。這就產(chǎn)生了分布式查詢處理的問(wèn)題，它通常被稱為MapReduce的解決方案架構(gòu)或最常用的開(kāi)源實(shí)施Hadoop。

但結(jié)構(gòu)化數(shù)據(jù)能夠解決分布式查詢;一家金融公司報(bào)告說(shuō)，它的客戶借用了從位于主要大城市區(qū)域三十多個(gè)數(shù)據(jù)庫(kù)抽取數(shù)據(jù)而得到的經(jīng)驗(yàn)分析結(jié)果。對(duì)于結(jié)構(gòu)化的DBMS分析，即便查詢命令被發(fā)送至每個(gè)站點(diǎn)以便于單獨(dú)運(yùn)行，也可使用SQL/DBMS命令來(lái)“綜合”來(lái)自于多個(gè)站點(diǎn)的結(jié)果。這樣一來(lái)，問(wèn)題就轉(zhuǎn)變成為要確保在每個(gè)地方查詢命令都要被細(xì)分以便于完全運(yùn)行;否則，運(yùn)行每個(gè)命令就都要求訪問(wèn)其它地方的數(shù)據(jù)，其成本就會(huì)變得相當(dāng)高。

雖然很多人都在關(guān)注如何創(chuàng)建混合云，但是對(duì)于未來(lái)云中關(guān)鍵任務(wù)應(yīng)用程序來(lái)說(shuō)，創(chuàng)建“混合數(shù)據(jù)”將是更為重要的任務(wù)。如果缺少一種***化使用物美價(jià)廉本地存儲(chǔ)資源和高度靈活云計(jì)算處理的方法，那么用戶們可能會(huì)發(fā)現(xiàn)他們的大型數(shù)據(jù)將迫使他們保持傳統(tǒng)的IT架構(gòu)。這不僅會(huì)讓云失去與關(guān)鍵任務(wù)應(yīng)用程序相關(guān)的收入，而且也讓云計(jì)算失去了對(duì)企業(yè)的吸引力。