個人匯總:
hadoop :Hadoop是一個能夠對大量資料進行分散式處理的軟體框架,它是一種技術的實現
大資料:
資料:
我們都聽過這個預測:到2020年,電子資料存儲量將在2009年的基礎上增加44倍,達到35萬億GB。 根據IDC資料顯示,截止到2010年,這個數位已經達到了120萬PB,或1.2ZB。 如果把所有這些資料都存入DVD光碟,光碟高度將等同于從地球到月球的一個來回也就是大約 480,000英里。
對於那些喜歡杞人憂天的人來說,這是資料存儲的末日即將到來的不祥預兆。 而對於機會主義者們而言,這就好比是個資訊金礦,隨著技術的進步,金礦開採會變得越來越容易。
走進大資料,一種新興的資料採礦技術,它正在讓資料處理和分析變得更便宜更快速。 大資料技術一旦進入超級計算時代,很快便可應用於普通企業,在遍地開花的過程中,它將改變許多行業業務經營的模式。
在電腦世界裡,大資料被定義為一種使用非傳統的資料過濾工具,對大量有序或無序資料集合進行的挖掘過程,它包括但不僅限於分散式運算(Hadoop)。
大資料已經站在了資料存儲宣傳的風口浪尖,也存在著大量不確定因素,這點上非常像「雲」。 我們請教了一些分析人士和大資料愛好者,請他們解釋一下大資料究竟是什麼,以及它對於未來資料存儲的意義。
大資料走進歷史舞臺
適用于企業的大資料已經出現,這在部分程度上要歸功於計算能耗的降低以及系統已具備執行多重處理的能力這樣一個事實。 而且隨著主儲存體成本的不斷下降,和過去相比,公司可以將更多的資料存到儲存體中。 並且,將多台電腦連到伺服器集群也變得更容易了。 這三個變化加在一起成就了大資料,IDC 資料庫管理分析師Carl Olofson如是說。
「我們不僅要把這些事情做好,還要能承受得起相應的開支」,他說。 「過去的某些超級電腦也具有執行系統多重處理的能力,(這些系統緊密相連,形成了一個集群)但因為要使用專門的硬體,它的成本高達幾十萬美元甚至更多。 」現在我們可以使用普通硬體完成相同的配置。 正因為這樣,我們能更快更省得處理更多資料。 "
大資料技術還沒有在有大型資料倉儲的公司中得到廣泛普及。 IDC認為,想讓大資料技術得到認可,首先技術本身一定要足夠便宜,然後,必須滿足IBM稱之為3V標準中的2V,即:類型(variety),量(volume)和速度(velocity)。
種類要求指的是待存儲資料的類型分為結構化資料和非結構化資料。 量是指存儲和分析的資料量可以很龐大。 「資料量不只是幾百TB,」
Olofson說: 「要視具體情況而定,因為速度和時間的關係,有時幾百GB可能就算很多了。 如果我現在一秒能完成過去要花一小時才能完成的300GB的資料分析,那結果將大為不同。 大資料就是這樣一種技術,它可以滿足這三個要求中的至少兩個,並且普通企業也能夠部署。 」
關於大資料的三大誤解
對於大資料是什麼以及大資料能幹什麼存在很多誤會。 下面就是有關大資料的三個誤解:
1、關係資料庫無法大幅增容,因此不能被認為是大資料技術(不對)
2、無需考慮工作負載或具體使用方式,Hadoop或以此類推的任何MapReduce都是大資料的最佳選擇。 (也不對)
3、圖解式管理系統時代已經結束。 圖解的發展只會成為大資料應用的攔路虎。 (可笑的錯誤)
大資料與開源的關係
「很多人認為Hadoop和大資料基本上是一個意思。 這是錯誤的,」Olofson說。 並解釋道: Teradata, MySQL和「智慧聚合技術」的某些安裝啟用都用不到Hadoop,但它們也可以被認為是大資料。
Hadoop是一種用於大資料的應用程式,因為它是建立在MapReduce基礎上的,所以引起了極大的關注。 (MapReduce是一種用於超級計算的普通方法,之後經過了主要由Google資助的一個專案的優化,因此被簡化並變得考究了。 ) Hadoop是幾個緊密關聯的Apache專案組成的混合體的主要安裝啟用程式,其中包括MapReduce環境中的HBase資料庫。
為了充分利用Hadoop和類似的先進技術,軟體發展商們絞盡腦汁研發出了各種各樣的技術,其中很多都是在開源社區裡開發出來的。
Olofson 說「他們已經開發出了大量的所謂noSQL資料庫,種類之多讓人眼花繚亂,其中大部分都是鍵值配對資料庫,能利用多種技術對性能或種類或容量進行優化。 」
開源技術還沒有得到商業支援。 「所以在這方面還需要經過一段時間的發展完善,這一過程可能需要幾年。 基於這個原因,大資料可能需要一些時日才能在市場上走向成熟」他補充道。
據IDC預計,年內至少有三家商業公司能以某種方式給予Hadoop支援。 同時,包括Datameer 在內的幾家企業將發佈配有Hadoop元件的分析工具,這種工具能説明企業開發自己的應用程式。 Cloudera和Tableau公司的產品清單裡已經出現了Hadoop。
來源:HTTP://os.51cto.com/art/201205/339932.htm