遭遇雲計算 大資料架構對系統提出挑戰

大資料將挑戰企業的存儲架構及資料中心基礎設施等，也會引發雲計算、資料倉儲、資料採礦、商業智慧等應用的連鎖反應。 2011年企業會將更多的多 TB（1TB=1000GB）資料集用於商務智慧和商務分析；到2020年，全球資料使用量預計暴增44倍，達到35.2ZB（1ZB=10億TB）。

大資料面臨的挑戰

對於海量的資料資訊，如何對這些資料進行複雜的應用成了現今資料倉儲、商業智慧和資料分析技術的研究熱點。 資料採礦就是從大量的資料中發現隱含的規 律性的內容，解決資料的應用品質問題。 充分利用有用的資料，廢棄虛偽無用的資料，是資料採礦技術的最重要的應用。 傳統的資料庫中的資料結構性很強，即其中 的資料為完全結構化的資料，而目前資料最大特點就是半結構化，因此此類資料採礦比面向單個資料倉儲的資料採礦要複雜得多。

談到傳統資料倉儲的時候，大家不免就會買存放裝置，選伺服器，不管是IBMPower或者是Oracle架構的，這些其實都是在傳統時代非常有名的資料庫品牌，把它構建在一起，構成資料倉儲，微軟、COCNOS等都提供解決方案。

對企業業務來說，不光要有高擴充性，而且是動態的需求，能夠讓設備自由擴充，不用去管資料倉儲、應用具體運行在這些機器的哪一臺上，這些計算能力的耗費完全是根據業務的伸縮而來的。

傳統的架構做這類的專案十年到二十年的時間，它們有一個特點，資料倉儲的訪問和傳統的不同，所謂的不同就是查詢特別大，查詢的語句特別長、特別複 雜，不像去銀行的存提款只是在眾多的記錄中查詢一兩條，它符合大資料查詢的特徵， 傳統的查詢索引作用非常有限。 在資料庫中涉及多張表的連接，同時還有匯 總、算標準差等複雜的運算。 但是相反它的併發請求不是很多，一個企業就是人再多，不會同時超過一千個業務分析員在分析資料。

因此，在資料倉儲誕生的第一天，系統一直就有一個瓶頸，要把大查詢分解成小任務，這些小任務由並行的伺服器來完成，我們強調小的機器要多，而不要大的機器CPU數少。 因此，資料倉儲天生就是MPP、開放架構的CPU加上並行擴展橫向擴展數量。

當大資料遭遇雲計算

雲計算為什麼能盛行呢？ 在互聯網領域應用系統的構建：客戶群體是不確定的、系統規模不確定、系統投資不固定、業務應用有很清晰的並行分割特徵、資料 倉庫系統的構建、資料倉儲規模可估算、資料倉儲的系統投資與業務分析的價值和回報相關、 商業智慧應用屬於整體應用、Saas模式構建資料倉儲系統。

大資料管理，分散式進行檔案系統，如Hadoop、Mapreduce資料分割與訪問執行；同時SQL支援，以Hive+HADOOP為代表的SQL介面支援，在大資料技術上用雲計算構建下一代資料倉儲成為熱門話題。 從系統需求來看，大資料架構對系統提出了新的挑戰：

1、集成度更高。 一個標準主機殼最大限度完成特定任務。

2、配置更合理、速度更快。 存儲、控制器、I/O通道、記憶體、CPU、網路均衡設計，針對資料倉儲訪問最優設計，比傳統類似平臺高出一個數量級以上。

3、整體能耗更低。 同等計算任務，能耗最低。

4、系統更加穩定可靠。 能夠消除各種單點故障環節，統一一個部件、器件的品質和標準。

5、管理維護費用低。 資料藏的常規管理全部集成。

6、可規劃和預見的系統擴容、升級路線圖。

雲計算環境作為大資料處理平臺

1.雲計算環境中基本計算單元的分化

企業雲計算平臺上雖然有多個平行計算的CPU，但並沒有創造出具有超強資料處理能力的超級CPU，因此雲計算平臺需要的是有並行運算能力的軟體系統。 同時，當所有使用者的資料全部放在雲端時，雖然存儲容量可以很方便地擴充，但面對大量使用者同時發起的海量資料處理請求，簡單的資料處理邏輯已經無法滿足需要。

可以看到，國內有相當多的電商企業，用小型機和Oracle扛了好幾年，並請了全國最牛的Oracle的專家不停優化他的Oracle和小型機，初期發展可能很快，但是後來由於資料量激增，業務開始受到嚴重影響， 最典型的例子無疑是京東商城前段時間發生的大規模訪問請求宕機事件，因此他們開始逐漸放棄了Oracle或者MS-SQL，並逐漸轉向MySQL+X86的分散式架構。

目前的基本計算單元常常是普通的X86伺服器，它們組成了一個大的雲，而未來的雲計算單元裡有可能有存儲單元、計算單元、協調單元，總體的效率會更高。

2、對系統穩定性的需求

在應對大規模訪問的時候有一些系統穩定性的追求，來自很多方面，來自網路穩定性、資料庫穩定性。 對系統而言，需要把握一個大原則，需要消除任何單點故障。 不光是網路上單點故障，還有來自你話務中心裡的單點故障，只要有單點故障一定要消除掉。

因為對於電商行業而言，每一秒都是錢，電子商務業務如果宕機一個小時，損失多少是可以算出來的，電商行業需要非常全面的技術系統監控報警系統。 有時候你會發現你如果通過技術系統的監控去推匯出你的技術發生問題已經晚了。

(責任編輯：蒙遺善)