大資料環境下Hadoop基礎架構有多重要？

Hadoop和大資料在同一時段開始流行起來，因而成了同義字。 但是，二者並不是一回事兒。 Hadoop是在集成處理器集群上實施的一種並行程式設計模式，主要用於資料密集型HTTP://www.aliyun.com/zixun/aggregation/13506.html">分散式應用。 Hadoop的作用就在於此。 早在對大資料的熱衷之前，Hadoop就已經存在。 但後來Hadoop的意義變了，被當作一種結構用以建立大資料基礎架構。

Hadoop以谷歌的MapReduce演算法為基礎，該演算法是在集群中分配應用的一種方法。 谷歌的檔案系統、運行系統、MapReduce應用以及分散式檔案系統（HDFS）幾乎都以JAVA為基礎，從而引發了一系列問題。 Hadoop也需要通過節點間的容錯移轉來提供彈性。 在眾多集群中，當一個節點失效了，應該能及時進行故障處理並轉移到下一個集群中去。

在以後，我並不確定有了Hadoop就可以高枕無憂了。 事實上關於Hadoop已有了普遍的共識：為企業所用還需要Hadoop基礎架構的許多方面起作用才行。 首先，Hadoop的核心是NameNodes，儲存了與Hadoop集群相關的中繼資料（集群中的每台設備、每台設備的容量、設備的用途及其能承受的工作負載量）。 這類資訊並非隨處可複製，而只存在於一個地方，因而成了Hadoop基礎架構中的單點故障。 如果Hadoop集群上正進行著重要的程式處理的話，那一定要解決這類資訊。 其次是JobTracker。 JobTracker是管理MapReduce任務和為不同伺服器安排工作負載的這樣一個組成部分，換種說法，JobTracker更接近以專門方法分析的資料。 需要強調的是，JobTracker也是一個單點故障，並且只存在於急群眾的一台伺服器上。 這些也只是有關當下的Hadoop架構最明顯的問題。

Hadoop技術本身並不簡單。 如果打算部署Hadoop，需要足夠的程式。 這些程式得能夠勝任工具箱裡單一程式無法做到的各種事情、得知道Pig是Pig Latin的縮寫、與Hadoop運行環境息息相關。 當然，這些程式也得知道JAVA、JavaScript的目標符號語言Jaql。 現如今找到能勝任PHP的程式已經不是什麼難事兒了，只需找一些跨度極大的組合即可。

因此首先是會有一些單點故障。 其次，Hadoop需要一些在技術市場上沒有的專項技能。 再次，會產生性能問題。 每個已部署Hadoop的公司都已經有了Hadoop操作方面的性能問題，因而關於其的大資料分析會一直存在。 雖然一些問題與糟糕的寫入應用代碼有關，但更多的是與其架構本身有關。 很多公司在額外的伺服器集群、直連存儲和額外的軟體工具上下了很大功夫，都只為改善Hadoop基礎架構的速度和進給量。

當然，基礎架構的管理也讓人頭疼。 一些人試圖以ZooKeeper技術來處理Hadoop基礎架構管理，而很多廠商則力圖以他們提供的定制產品來處理。 問題是目前還是沒有一個很好的Hadoop管理范式，似乎也沒什麼指望。

前不久，福布斯的一篇文章表達了我要分享的另一個重要的關注點：Hadoop等同于承擔大資料項目目的基礎架構。 現在，商人們並不明白這一過程，也不介意如何處理大資料。 他們只是想要業務利潤，要它快一點兒。 文章的作者正確地觀察到Hadoop也許非常適合處理規模資料（其文章觀點所在），但絕對算不上迅速而專業的分析或即時分析學。 因此，該文章也不能用於業務處理，只是起到了其下的某些價值作用，並且只是掌控資料的一種方式。

那指向了問題的核心，最終的真正問題是：我們將大資料用於何處？ 很多人沒有認識到這一問題，除了市場上那些想要使用大資料的商家們，他們的目的是使其產品和服務面向特定客戶群體時能更為專業化。