下面文字是來自天源迪科 大數據專家一篇純乾貨的實戰思考。這種經驗總結非常值得一看，真正的經驗來自不停踩坑之後的靈光一現，然後茅塞頓開。
強烈推薦！！！也希望更多的同學也來一起分享。
引言
走過一些地方，發現各地都在建集中的大數據平臺，提供數據、服務、工具，面向各分支部門、各外圍合作伙伴，以“租戶”的形式接入應用，謂之能力開放，是當下極為流行的做法。講到開放，就要考慮考慮權限的控制、資源隔離，前者是安全控制，而後者技術性更強。當前常因為投資預算等客觀原因，所謂的“大”集群規模其實也是相對的，往往就是百十來臺，是否能夠在這樣一個單一的物理集群下承擔複雜多樣的應用呢？業界是沒有一個標準的計算公式，更多還需要具體情況具體分析。所以我又經常碰到一些“重度使用”的集群環境，這是我們自己的一個說法，就是說集群的規模不是那麼大，但上面跑的應用確是足夠多。促成這個困局的現實因素是，不單是因為有限的預算，有時是因為過於技術理想主義、過度的資源壓榨。講真，如果集群規模上去了，又沒幾個應用，好多問題就不是問題。
案例討論
以下給出一例：
上述集群規模在100臺左右，存量數據5PB，增量在10TB/日。機器屬於當前主流配置（256G內存，32核CPU）已接入的租戶是30個左右，租戶基本是按照不同的項目或應用為單元，可能是不同的廠家。這些應用可以分為三類，一類是離線批處理類，主要使用MR,hive,Tez,Spark,Impala長作業之類的應用以及一些即席查詢，流計算實時批處理類作業主要是Spark Streaming類的作業，及基於Hbase之上的存儲和查詢類的業務，品種是非常齊全的。集群絕大部分時候運行良好，偶發性的性能問題有一些，主要是影響在線業務。
主機在某些時段，CPU消耗已出現繁忙
思考
提到資源的隔離，我們第一時間想到的是Yarn，沒錯，當前集群也使用它來管理很大一部分（Mr on yarn,Spark on Yarn,Tez on Yarn）採用用戶級資源池公平調度，由於資源吃緊，最大資源數留多出一部分作為自由搶佔。
但細看有一部分的資源是存在管理盲區：
Hbase資源隔離：只有一個全局的heapsize內存控制，沒有做分用戶的資源隔離，儘管當前版本已經具備單用戶請求數的隔離，但驗證發現對於一些scan操作結果詭異，與預期相去甚遠，甚至影響正常使用，姑且認為它還不夠健全而棄之。多說幾句，Hbase這個組件我向來認為並不是那麼好駕馭，屬於上手很快、後期又容易出問題的一類東西，要求應用開發層面的考慮太多後臺服務優化的點，處處充滿了不人性化的設計。你比如說：hbase本來是強項基於鍵值的小批量查詢的，偏偏也能通過hive外部表的方法來遍歷查詢或統計，完全當做一個關係型數據庫來幹了，這個動作的影響之大開發人員並沒有想到，他們也無辜，問題在於hbase本身並未限制不能做這樣的操作，所謂的開發規範也僅僅是一個建議。另外關於分區、鍵值設計等，搞不好就會影響脆弱的RS，還是要去和開發逐一闡述清楚。所以，我現在比較推舉phoenix這種做了一層封裝的hbase服務。關於hbase的問題，說是組件不足也好，說是使用不當也罷，反正，問題就擺在這兒。
Impala資源的隔離：有針對單個服務實例的內存控制，也能控制到了用戶級隊列控制，也僅僅有內存的限制，而CPU則是任由搶佔，且目前資源並未交給Yarn集中託管。CPU搶佔的結果是機器本身24核它可能搶去了20核，其它的服務怎麼玩？需要補充說明的是，實際是存在Impala on Yarn技術：Llama，早期由於這個東西的版本一直處於測試階段，我們認為冒然去使用會增加問題定位的難度，因而生產應用擱淺上。
IO的隔離：在用戶隊列層面，由於Yarn目前只做了CPU和核的控制，並未對IO做出控制，也就是放任搶佔；當然，在服務進程層面，是可以通過cgroups做一些組件層面的限制。
重度應用環境下，技術異構體現更明顯，有的是CPU密集型，有的是IO密集型，應用間的影響可能性加大，問題的定位變得更困難。例如：下圖顯示上面集群出現的一個問題，部分主機間歇性卡頓，top顯示不是用戶CPU消耗過高，而是的Sys消耗高。主機一卡頓，可能各種服務問題都會隨之而來。
Sys過高通常有swap使用、線程交換方面的問題，而I/O方面也是潛在的因素。
以上文字說明的是：大量I/O操作也可能觸發sys高負載，想想也是，所謂的sys不就是操作系統調用，當然與read，write有關的。通過比對相同時間點上的IO負載，發現確有此類問題。
而下面張圖則顯示的是在針對hbase做遍歷時，hbase集群層面的請求數陡增，由此引發的性能問題。
不可否認，當前技術發展的趨勢總體上朝著融合的方向走，通過多租戶隔離實現資源最大化的共享，大家在一個集中的平臺上轉。現實問題在於當前開源技術還不那麼成熟，更不要說生產版本還有一定滯後，直接導致資源的隔離不徹底，應用之間相互依舊有干擾。運營過程痛苦。
方案討論
鑑於上述情況，本人斗膽建議：針對小規模的集群（<200臺），現階段還是老老實實做一定的集群拆分，特別是生產級要求高的在線業務，通過簡單的分拆規避干擾。我下圖給出的是一個基於技術維度上的切分，也僅供參考。細分這些應用發現，還是有那麼一些應用是死不了人的，大不了可以重啟解決掉（開源的東西大家都能理解），有些則是真的有所要求的。這麼說可能不太嚴謹，但在當前過渡階段確是有效的辦法。
至於在技術演進方面，我們也不是無動於衷，以下是可以去做的：
Impala：如上文提到的，引入Llama組件，將Impala服務的資源交給Yarn集中管理。現階段看Yarn作為一個統一的資源管理入口，就比較可控了。而關於Impala的執行容錯性已經被一些案例中提及，我們也有有同類經歷，這會引起我們在選型中的嚴重關注
Hbase：針對資源的隔離方案也是有的，我們探究了三種：
方案1：邏輯隔離：HDFS共享一套，基於之上搭建多個Hbase集群（分在不同主機上），不需要額外遷移數據
方案2：物理隔離：完全獨立，包括HDFS也是分離的，隔離效果最優，但涉及數據在不同HDFS之間交互，很多人很忌諱做這個
方案3：Hbase on yarn：在Hbase2.0中得以支持。類似邏輯隔離，基於Yarn面向各個用戶提供單獨的Hbase集群實例，regionServer運行在YARN上
本文主要是結合實際經歷遇到的問題進行了一下思路總結，限於自己的眼界下給出的觀點，定有不妥之處，期待與你探討。
閱讀更多 大數據和雲計算技術 的文章
