毋庸置疑，大數據時代已經來了。那麼，我們如何去應對這種局面呢？下面，我們聽聽擁有此方面經驗的專家是如何說的吧。
首先我們要知道，在成百上千TB的信息中，我們該如何充分利用大數據。這完全取決於個人的需求和偏好。Interclick廣告服務公司找到了一種在提供接近實時數據分析的同時，能提供更高效的解決方案。哈佛醫學院也瞭解到，在對病人數量和多年保持不變的數據研究的情況下，數據也會明顯增長。互聯網流量監測機構comSCore，擁有12年的利用列存儲數據庫壓縮數據的豐富經驗，事實上，它採用了排序技術來優化壓縮、減少處理需求。
目前，包括雅虎、Facebook、Twitter、NetFlix和eHarmony（美國在線約會網站）都認爲，Hadoop是一個理想化的低成本處理 非結構化數據平臺。它不僅能滿足互聯網巨頭需要，也能滿足包括摩根大通銀行和其他主流的傳統企業的需求。數據供應商InfoChimps同時發現，隨着越來越多的附加和輔助應用的提供，Hadoop將是提供部署支持的快速成熟方案。
大數據時代下的應用
當然，並非所有的大數據部署都是根據總規模來衡量。比如Linkshare只保留了幾個月但每天都需要加載和快速分析多達數十GB的數據，因此對於每天的這些數據規模來說它是一個比較大規模的部署。除此之外，我們還需要注意數據倉庫擴展性的六個維度。只有這樣，我們纔可以制定一個較爲準確的方案，從而滿足最爲苛刻的測試需求，並獲得技術投資滿足未來需要。
一、快速查詢確保高效和及時
大規模並行處理平臺、列存儲數據庫、數據庫內處理技術和內存計算技術，都可以大幅降低數據查詢時間，從數天、數小時縮減到幾分鐘甚至幾秒。但這並不夠。紐約廣告公司Interclick發現，快速分析帶來的最主要好處是高效。快速響應能爭取到更多時間進行更多、更深入的查詢工作。第二個好處則是，可以獲得幾近實時分析的結果，據此分析有助於提高決策反應水平和準確率。
Interclick所採用的大數據分析技術
通過快速響應，Interclick能夠在幾個小時甚至數分鐘內對網上衝浪者的行爲進行細分。它能夠對訪問旅遊站點、預訂酒店站點等的網名行爲信息，發送給相應的航空公司、連鎖酒店、汽車租賃公司等。Interclick採用的是ParAccel列存儲數據庫部署，內存集羣可以容納3.2TB容量的數據。
壓縮和削減存儲成本二、衡量數據增長時深知何爲貴
通過對長達20年的醫療記錄、研究各種藥物的療效和風險，哈佛醫學院吸取到了這樣一種教訓--在規劃數據倉儲投資時，不僅僅需要解諸如客戶、記錄和交易數量等簡單問題。雖然病人數量和時限仍然較爲穩定，但各種醫療記錄卻不斷豐富起來，因爲湧現出了很多新的健康監測技術指標。因此，事先了解所有的動態需求至關重要。
哈佛醫學院
三、數據壓縮和削減存儲成本
更好的數據壓縮可以節省每TB硬件成本。列存儲數據庫，比惠普的Vertica、Infobright、ParAccel和Sybase IQ，可以實現30:1或者40:1的壓縮比。而行存儲數據庫，比如EMC Greenplum、IBM Netezza和Teradata，平均4:1的壓縮比。這是因爲柱狀數據可以保持一致，包含郵編、採購訂單號碼等多種數據。而行狀數據，比如與客戶相關的屬性組合--名稱、地址、郵編、採購訂單號等等，則不具有這種優勢。Aster Data和甲骨文數據庫可以提供混合行/列存儲功能。甲骨文的Hybrid Columnar Compression可以提供10:1的壓縮比。
數據壓縮
壓縮比率不同很大程度上取決於數據本身，而且列存儲並不總是最好的選擇。如果在數據查詢的時候需要調用很大屬性，行存儲方案可能會表現出更好的性能。事實上，行存儲數據庫經常被企業應用在處理混合查詢的數據倉庫中，而列存儲數據庫更多的是集中在海量數據查詢中。
四、分類壓縮、減少處理時間
類似連續性的列數據有利於壓縮一樣，我們也可以通過數據加載之前進行分類從而提高壓縮比。在將數據裝載進Sybase IQ至 強，comSCore使用Syncsort DMExpress軟件對數據進行分類。該公司的CTO Michael Brown（圖示）表示，它可以將10字節的 數據壓縮成3、4個字節，而通過分類後的10個字節數據可被壓縮成1個字節。“這將給我們存儲海量數據提供了另外一種方式 。”
Michael Brown
此外，分類也可以提高數據處理效率。comScore對URL數據進行分類，從而將Web站點分類查詢工作量降到最低。無需加載40個網站頁面的URL地址從而在單個會話中進行訪問，而只需對它們進行分類就可以在Facebook上露出其中20個頁面，GMail上露出12個，其他的則可能會出現在NYTimes.com上面。
分類數據會觸發僅僅3個站點查詢，而未分類的數據則會引起多個毫不相關的數據查詢。“它有助於節約CPU大部分資源和時間，”Brown說到。完全可以藉助SQL語句和自編腳本對數據進行分類。不過，在IBM、甲骨文、SAP、SAS等數據集成軟件中，數據分類也是一個常見功能。事實上，Hadoop是一個真正意義上的大規模數據分類和處理的良好選擇。
速度勝於規模五、Hadoop的低成本非結構化數據處理
Apache Hadoop是成長速度最快的開源項目之一，它是用於處理分佈式數據尤其是大量非結構化數據的組件集合。而MapReduce是基於Hadoop的快速處理大量信息的編程模型。傳統的關係型數據庫，比如IBM Netezz、甲骨文、Teradata和MySQL不能處理這種數據，因爲它們不能適應整行或者整列數據的情形，即使它們能夠提供支持，其帶來的許可成本會令人望而卻步。因爲數據規模通常都是成百上千TB甚至PB級。Hadoop是一款免費軟件，可以運行在低成本的硬件平臺上（Hadoop部署需要日常維護，並不是免費的）。
Hadoop的特點
採用Hadoop的急先鋒包括有雅虎、eHarmony、Facebook、NetFlix和Twitter，而且也有越來越多的商業機構對Hadoop開始感興趣。
六、Hadoop減輕數據加載和處理煩惱
據預測，Hadoop市場規模將增長到數十億美元，而且相應配套和集成的產品也正在迅速成長。比如著名的數據集成廠商Informatica、Pervasive Software、SnapLogic和Syncsort，都宣佈了旨在幫助更快更容易的與新一代處理平臺協同的產品或者集成方案。
Pervasive Software公司Data Rush工具可以提供與Hadoop協同、並行處理的優化，數據服務商InfoChimps採用該工具與Hadoop實例運行在亞馬遜的EC2雲平臺上。該公司首席技術官Philip Kromer（圖示）表示，經過Data Rush對數百GB數據的測 試發現，其性能提升了2-4倍，由以往的16個小時降低到8小時，從而幫助InfoChimps降低計算成本，能夠從Twitter和其他非關係數據源獲取更多數據。
Philip Kromer
Informatica、SnapLogic、Syncsort和其他廠商，在跨傳統數據庫和Hadoop部署上使用單個工具，正使得數據加載、分類和彙總變成可能。某個單一和熟悉的方式和工具集，會讓管理數據的專業人員工作變得更加輕鬆。
七、速度勝於規模
在很多情況下，大數據中的“大”並不是每天加載和分析的信息數據庫規模，比如市場營銷人員，通常加載和分析大量數據以儘快洞察市場行情，從而做出快速反應，並重新細分市場，而不會浪費精力和金錢到無用的事情上去。
LinkShare數據分析服務
爲出版商、廣告商提供搜索、聯合營銷服務，廣告網絡公司Linkshare每天需要裝載和分析數百GB網絡點擊數據，但總的數據庫容量卻僅爲6TB。低延遲正越來越成爲該公司獲取競爭力的法寶之一，該公司首席運營官Jonathan Levine表示，“五年以前將昨天的數據信息提交給用戶還能滿足需要，但現在不能再拖延了。”
充分利用所熟知的領域八、充分利用所熟知的領域
傳統甲骨文、IBM DB2和微軟SQL Server部署之外，Netezza和Greenplum在2000年中期也進入了數據倉庫市場。轉眼間，甲骨文在2008年推出了Exadata，IBM於去年收購Netezza，而今年的早些時候微軟推出SQL Server 2008 PDW。IBM、微軟和甲骨文已經成爲當下主流的幾大供應商。比如DirectEdge證券交易所，一直以來都是使用微軟解決方案的客戶。該公司首席技術官Richard Hochron（圖示）表示，PDW成爲了“一個顯而易見的選擇”。
Richard Hochron
汽車數據提供商Polk公司是甲骨文的客戶，其數據庫開發和運營總監Doug Miller說，公司選擇Exadata的很大一部分原因，是工作人員對管理這一類型數據庫比較熟悉，他們正在等待着第二版的產品更新。
九、基於兼容性的應用
某些數據庫平臺提供有對上一代產品的兼容，而其他產品則要求用戶對數據進行遷移和產品更新。Teradata就是這種提供保持對以往產品兼容性的代表產品之一，用戶可以在新舊硬件的混合環境下提升整體規模。
除此之外，用戶仍需要注意數據庫版本和硬件廠商的特殊要求。在方案實施以前，需要仔細瞭解各供應商產品的兼容性，同時也需要着眼於未來的長久擴展。
沃爾瑪網上超市
零售業巨頭沃爾瑪應用Teradata已經超過了20年。作爲新協議的一部分，沃爾瑪的Teradata應用部署將繼續擴大和更新。一般來說，“服役期”滿的硬件通常都會爲升級提供很好的理由。相比上一代產品，最新的Teradata產品能夠減少50%的佔地面積，降低40%的能源消耗。
十、考慮擴展性的方方面面
數據庫專家Richard Winter建議，在進行數據倉庫平臺投資時，要考慮六個方面的擴展性，它們分別是：數據的大小、數據的複雜性、用戶數、查詢量、查詢的複雜性以及數據延遲要求。大量的併發用戶(1000名、10000名或者更多)，混合查詢以及複雜的分析，會受限於大規模數據。如果無法滿足以上這六個方面，那麼系統不堪重負的速度可能要比預期更快。
Richard Winter
最後，用最複雜的數據，以及最難的查詢需求去測試那些數據倉庫平臺，這是非常有必要的。同時，將併發用戶的工作量進行復制和混合查詢，從而進一步測試數據倉庫平臺。
http://www.china-cloud.com/yunjishu/shujuzhongxin/20111122_8087.html