Hadoop是大家廣泛接受的主流體系結構。其設計理念從硬體層面有兩個重要的哲學理念:
1) Share Nothing – 即每個硬體節點的完全獨立，CPU/記憶體/本地盤完全私有，以追求每個節點效率的最大化。
2) Data Exchange through distributed file system – 資料的共享通過分布式檔案系統來實作間接的遠程訪問（一個節點需要訪問遠程資料塊要通過DataNode代理實作）。
這個體系作業得不錯。最大的優點是“Scalability”幾乎可擴展到無窮大。
但在論壇上少有人提到Hadoop 之外的大資料分析的架構 --- 是否這是大資料分析的唯一架構選擇？無限的scalability是否是資料分析的最重要或唯一目標？
首先要問的是：你的大資料真的很大嗎？真的需要幾萬臺裝滿硬碟的服務器才能裝得下？
其次要問的是：你的大資料是否需要多次迭代分析逐步優化，每次迭代資料量是否在大大地精簡？
再次要問的是：你的大資料是否有實時性？處理節點之間要分析的資料是否很少量，還是要大量地進行交換？
拋磚引玉，歡迎各位大拿一塊兒來聊聊。
uj5u.com熱心網友回復：
嗯，大資料的確在分析領域有很大優勢~uj5u.com熱心網友回復：
Microsoft, Yahoo的統計資料表明，他們的Hadoop機群平均的輸入資料只有14GB。 Facebook公布的資料是90%的Hadoop任務在100GB以下。很多大資料分析的任務，資料在單個服務器記憶體中就能放下。 要是用上單個機架內全部服務器的記憶體，恐怕能覆寫決大多數的應用了。
因此，In Memory的大資料分析平臺成為了新的熱點哦。如UC Berkeley的Spark系統就是為這類資料分析優化的。
uj5u.com熱心網友回復：
同意樓主的觀點，大資料分析有著巨大的價值，這一點毋庸置疑。但是現在移動互聯網時代，各種應用場景，新的業務模式也是層出不窮。所以所需要的分析架構也很難做到一種通吃，所以，現在適合實時分析和迭代的Spark很火。uj5u.com熱心網友回復：
說說我的理解吧，還是比較淺顯的，一起討論。我認為Hadoop最大價值就是提供一個高可擴展性的分布式檔案存盤系統。當資料達到PB級別的時候，要想性能可用的話不做存盤結構的設計幾乎是不可能的，如果你不用Hadoop的或類似的解決方案你就必須自己設計這樣一個存盤結構，這可能要花費你大量時間，而你的經驗和知識也限制了是否真的能成功設計這樣的一個存盤結構，就想可以用現有關系型資料庫存盤但你也可以自己在設計一個資料庫為你自己的專案用，自己設計一個分布儲存架構難度不會比自己在設計一個關系型資料庫簡單多少。也想和樓主討論一下你提的幾個問題：
首先要問的是：你的大資料真的很大嗎？真的需要幾萬臺裝滿硬碟的服務器才能裝得下？
我想我們還要考慮一個問題，裝滿硬碟幾臺或十幾臺Hadoop服務器應該比實作同樣性能傳統架構設備便宜的多，所以也許幾臺或十幾臺規模的應用可能就值得用Hadoop，不用幾萬臺裝滿硬碟的服務器那么夸張。但也要考慮到另一個成本就是開發成本，開發基于Hadoop的應用還是比較困難的。
其次要問的是：你的大資料是否需要多次迭代分析逐步優化，每次迭代資料量是否在大大地精簡？
mapreduce效率確實是個問題，我想還是可以通過合理設計存盤結構和演算法來改善它。
再次要問的是：你的大資料是否有實時性？
資料實時確實也是問題，所以在一個大資料系統中可能應該包含關系型資料庫，hadoop等，各司其職相互配合。
處理節點之間要分析的資料是否很少量，還是要大量地進行交換？
這個也可以通過合理設計減少這種情況的發生，甚至可以不斷的調整資料結構和演算法改善類似的問題。
uj5u.com熱心網友回復：
我覺得歸根結底帶來的是機架硬體架構的變遷和更新， 計算存盤解耦合~~~uj5u.com熱心網友回復：
我覺得一種架構，必須要考慮很多方面。或許樓主問的，他們都考慮過，所以才出了hadoopuj5u.com熱心網友回復：
Hadoop這樣一個架構，雖然現在很成功，但是確實有很多改進的地方的。也不可能考慮全面。現在她還在發展中，比如前陣子 Hadoop V2出來了，加了很多靈活性。同時，像Spark這些演算法架構也在往Hadoop基礎框架上去集成。所以，發展/改進這個主旋律還是少不了的，我們在用她的同時，思考思考怎么改進，還是很有意思的。
uj5u.com熱心網友回復：
Hadoop作為一種主流的軟體構架，確實有其合理性和現實性的考慮。CMIC您的見解就包含了很多現實性的考慮，試著總結一下：1） 利用Hadoop 現成的存盤構架（HDFS）或其它成熟的資料庫或檔案系統構架對于開發應用的人而言是一種現實的選擇。
2） 即使在小規模機群上，Hadoop也提供了可行的并行處理構架，而且比傳統高性能服務器等單機設備要便宜。
3） Map reduce的效率、迭代引入的資料交換、以及實時性等Hadoop可能存在的性能效率的問題，可以通過資料結構和資料擺放調整等軟體優化手段來彌補，以達到實用的目的。
感覺CMIC是位經驗豐富的軟體架構師。從軟體架構師的視角來看，硬體是否是神圣而無法變更的呢？ 樓主對此很感興趣。是否在軟體工程師的世界里，OS/平臺都是既定的，而應用/演算法則是可變的，因此在出現問題時，會直接跳過硬體/OS/Hadoop，而著手于其上運行的應用，以求性能改善？如果跳出這個框架來思考，會不會有全然不同的答案？
uj5u.com熱心網友回復：
恕難茍同。是否“存在的就一定是合理的”？不可否認，Hadoop在其誕生的時期以及過去的幾年發展中，提供或者說充分實作了它設計的價值，但在當前飛速變化的大環境下，它的弊病也日益突出。樓主比較贊同cdb81關于處理模式不斷更新演進的觀點。cdb81提到的目前變得很火的Spark就是一例。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/108596.html
標籤：云存儲