雲上是時候丟掉Hadoop混合部署概念了

Hadoop體系裡面，有個非常讓其擁躉津津樂道的概念，混合部署。其基本含義就是將多個應用和元件部署在一個叢集，共享一套資源，以獲取資源的高效利用。物理機環境沒有彈性的能力，這個混合部署概念彌補了部分彈性的需求。

先來看下產生的歷史，Hadoop 1.0時代只有MapReduce/hdfs/zookeeper三大件，1.0時代只有MapReduce一種服務，沒有共享的必要。Hadoop 2.0 YARN橫空出世，主要概念來源於伯克利的mesos的思路，期望用同一個資源管理器管理所有資源共享給所有服務。YARN最主要作用就是將物理機環境的所有資源全部管理起來；各種該服務的資源由YARN統一分配和管理。隨著資源管理器的發展的同時，2.0時代應用繁榮起來MapReduce/Hive/Spark/Hue/HBase，中間為了解決長期執行資源服務管理問題，還有一個專門的slider元件。Mesos出來也更早，相當長一段時間mesos和yarn還競爭了一把；最後mesos拗不過社群的力量改道搞應用部署，又去和K8S PK上了。

總的來說，在物理機環境中，這個思路還是非常先進的，但是今天演進到雲環境是否還適用值得商榷一下，為什麼這麼說：

• 雲時代，資源都是雲平臺統一管理。首先分配的粒度本身就很細，可以支援到0.5個cpu。需要多少，向雲平臺申請，用多少付費多少，非常彈性；可以如果還是老思路，提前固定申請一批，再分配給各個應用。完全沒有享受雲彈性的能力。
• 其次可以根據不同的應用需求，還可以靈活申請不同的規格，更好的匹配應用特點和充分利用資源。比如有些應用需要cpu多，有些應用需要IO強；YARN只能統一管理同規格伺服器，很難照顧到每個應用的不同需求，非常容易申請過多，造成資源浪費。
• YARN概念非常先進，但是實際上管的好還是MapReduce，YARN一直沒有很好的解決應用之間的資源爭搶問題，尤其是不同特點的應用。例如HBase這種常駐型服務，機制上為了保證實時性，會盡量去佔用所有的記憶體，HBase跑的好，其他服務就跑不好；其他服務跑好了，HBase基本也跑不好。類似問題spark，storm等都有。

所以雲上最合理的是每個服務跟進自己的特點和需求，單獨申請資源，自行管理。是時候丟掉在物理機時髦的混合部署的概念了。要充分去利用雲平臺本身的彈效能力。當能大部分公司，最簡單的方法就是直接申請對應的雲服務，將這些複雜的資源管理和運維的工作讓雲服務廠商負責，從而專注自己的業務。