對于圍繞云計算的所有應用來說，目前公共云服務中的應用只代表了IT總支出的一小部分。除非主流的、占企業預算大頭的關鍵任務應用能夠遷往公共云，否則這一態勢將不會發生變化。

公共云應用的***瓶頸似乎是高昂的云計算存儲成本。與Web相關的云應用可能會存儲數以百兆的數據，而關鍵任務應用則可能會存儲TB級的數據，按目前的價格來看，其存儲成本是大部分用戶所難以承受的。但是值得慶幸的是，我們有兩種策略可以來解決這一云存儲成本問題：數據抽象和分布查詢式數據訪問。

將數據抽象方法用于商業智能和成本分析應用

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

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

BI和真實數據分析降低云存儲成本

我們在醫療行業中的某一個客戶說，通過診斷代碼、治療代碼以及年齡/性別的形式，創建一組患者信息摘要數據庫，將減少三百倍以上的信息量，這意味著其云數據存儲和訪問成本僅為未經數據抽象處理的三百分之一。

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

對非結構化數據使用分布查詢式訪問方法

數據抽象方法適用于對具有少量重要變量參數結構化交易數據的分析應用。但它不適用于非結構化格式的傳統大數據，這是因為非結構化數據的抽象比較難以實現。有些公司在創建電子郵件特定單詞或單詞組合高識別率數據庫的應用中有過不少成功案例，但是其前提條件是這樣的關鍵詞/詞組合是可以預先知道的。對于大多數應用來說，還是需要有一個更為通用的方法的。這個方法就是我們所提出的第二個數據成本管理策略——分布查詢式數據訪問方法。

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

針對這類功能劃分對應用程序進行結構設計是相對簡單的，事實上，正有越來越多的廠商提供了包含存儲/查詢功能的DBMS引擎或設備。但是，構建針對應用程序的檢查以防止有問題的查詢結構提供所有的數據信息是非常必要的措施。在這里，試點測試是不夠的;在交付前，查詢邏輯應當測試結果的大小。

認識到分布式查詢處理的問題

大數據的一個特殊狀況是，有可能出現信息不是存儲在一個地方的情況。電子郵件、即時通信以及協作信息通常都被保存在它產生的地方，因此企業可能會擁有數十個或數百個網站。這就產生了分布式查詢處理的問題，它通常被稱為MapReduce的解決方案架構或最常用的開源實施Hadoop。

但結構化數據能夠解決分布式查詢;一家金融公司報告說，它的客戶借用了從位于主要大城市區域三十多個數據庫抽取數據而得到的經驗分析結果。對于結構化的DBMS分析，即便查詢命令被發送至每個站點以便于單獨運行，也可使用SQL/DBMS命令來“綜合”來自于多個站點的結果。這樣一來，問題就轉變成為要確保在每個地方查詢命令都要被細分以便于完全運行;否則，運行每個命令就都要求訪問其它地方的數據，其成本就會變得相當高。

雖然很多人都在關注如何創建混合云，但是對于未來云中關鍵任務應用程序來說，創建“混合數據”將是更為重要的任務。如果缺少一種***化使用物美價廉本地存儲資源和高度靈活云計算處理的方法，那么用戶們可能會發現他們的大型數據將迫使他們保持傳統的IT架構。這不僅會讓云失去與關鍵任務應用程序相關的收入，而且也讓云計算失去了對企業的吸引力。