引言

走過一些地方，發(fā)現(xiàn)各地都在建集中的大數(shù)據(jù)平臺，提供數(shù)據(jù)、服務、工具，面向各分支部門、各外圍合作伙伴，以“租戶”的形式接入應用，謂之能力開放，是當下極為流行的做法。講到開放，就要考慮考慮權(quán)限的控制、資源隔離，前者是安全控制，而后者技術(shù)性更強。當前常因為投資預算等客觀原因，所謂的“大”集群規(guī)模其實也是相對的，往往就是百十來臺，是否能夠在這樣一個單一的物理集群下承擔復雜多樣的應用呢?業(yè)界是沒有一個標準的計算公式，更多還需要具體情況具體分析。所以我又經(jīng)常碰到一些“重度使用”的集群環(huán)境，這是我們自己的一個說法，就是說集群的規(guī)模不是那么大，但上面跑的應用確是足夠多。促成這個困局的現(xiàn)實因素是，不單是因為有限的預算，有時是因為過于技術(shù)理想主義、過度的資源壓榨。講真，如果集群規(guī)模上去了，又沒幾個應用，好多問題就不是問題。

案例討論

以下給出一例：

上述集群規(guī)模在100臺左右，存量數(shù)據(jù)5PB，增量在10TB/日。機器屬于當前主流配置(256G內(nèi)存，32核CPU)已接入的租戶是30個左右，租戶基本是按照不同的項目或應用為單元，可能是不同的廠家。這些應用可以分為三類，一類是離線批處理類，主要使用MR,hive,Tez,Spark,Impala長作業(yè)之類的應用以及一些即席查詢，流計算實時批處理類作業(yè)主要是Spark Streaming類的作業(yè)，及基于Hbase之上的存儲和查詢類的業(yè)務，品種是非常齊全的。集群絕大部分時候運行良好，偶發(fā)性的性能問題有一些，主要是影響在線業(yè)務。

主機在某些時段，CPU消耗已出現(xiàn)繁忙

思考

提到資源的隔離，我們***時間想到的是Yarn，沒錯，當前集群也使用它來管理很大一部分(Mr on yarn,Spark on Yarn,Tez on Yarn)采用用戶級資源池公平調(diào)度，由于資源吃緊，***資源數(shù)留多出一部分作為自由搶占。

但細看有一部分的資源是存在管理盲區(qū)：

• Hbase資源隔離：只有一個全局的heapsize內(nèi)存控制，沒有做分用戶的資源隔離，盡管當前版本已經(jīng)具備單用戶請求數(shù)的隔離，但驗證發(fā)現(xiàn)對于一些scan操作結(jié)果詭異，與預期相去甚遠，甚至影響正常使用，姑且認為它還不夠健全而棄之。多說幾句，Hbase這個組件我向來認為并不是那么好駕馭，屬于上手很快、后期又容易出問題的一類東西，要求應用開發(fā)層面的考慮太多后臺服務優(yōu)化的點，處處充滿了不人性化的設(shè)計。你比如說：hbase本來是強項基于鍵值的小批量查詢的，偏偏也能通過hive外部表的方法來遍歷查詢或統(tǒng)計，完全當做一個關(guān)系型數(shù)據(jù)庫來干了，這個動作的影響之大開發(fā)人員并沒有想到，他們也無辜，問題在于hbase本身并未限制不能做這樣的操作，所謂的開發(fā)規(guī)范也僅僅是一個建議。另外關(guān)于分區(qū)、鍵值設(shè)計等，搞不好就會影響脆弱的RS，還是要去和開發(fā)逐一闡述清楚。所以，我現(xiàn)在比較推舉phoenix這種做了一層封裝的hbase服務。關(guān)于hbase的問題，說是組件不足也好，說是使用不當也罷，反正，問題就擺在這兒。
• Impala資源的隔離：有針對單個服務實例的內(nèi)存控制，也能控制到了用戶級隊列控制，也僅僅有內(nèi)存的限制，而CPU則是任由搶占，且目前資源并未交給Yarn集中托管。CPU搶占的結(jié)果是機器本身24核它可能搶去了20核，其它的服務怎么玩?需要補充說明的是，實際是存在Impala on Yarn技術(shù)：Llama，早期由于這個東西的版本一直處于測試階段，我們認為冒然去使用會增加問題定位的難度，因而生產(chǎn)應用擱淺上。
• IO的隔離：在用戶隊列層面，由于Yarn目前只做了CPU和核的控制，并未對IO做出控制，也就是放任搶占;當然，在服務進程層面，是可以通過cgroups做一些組件層面的限制。

重度應用環(huán)境下，技術(shù)異構(gòu)體現(xiàn)更明顯，有的是CPU密集型，有的是IO密集型，應用間的影響可能性加大，問題的定位變得更困難。例如：下圖顯示上面集群出現(xiàn)的一個問題，部分主機間歇性卡頓，top顯示不是用戶CPU消耗過高，而是的Sys消耗高。主機一卡頓，可能各種服務問題都會隨之而來。

Sys過高通常有swap使用、線程交換方面的問題，而I/O方面也是潛在的因素。

以上文字說明的是：大量I/O操作也可能觸發(fā)sys高負載，想想也是，所謂的sys不就是操作系統(tǒng)調(diào)用，當然與read，write有關(guān)的。通過比對相同時間點上的IO負載，發(fā)現(xiàn)確有此類問題。

而下面張圖則顯示的是在針對hbase做遍歷時，hbase集群層面的請求數(shù)陡增，由此引發(fā)的性能問題。

不可否認，當前技術(shù)發(fā)展的趨勢總體上朝著融合的方向走，通過多租戶隔離實現(xiàn)資源***化的共享，大家在一個集中的平臺上轉(zhuǎn)?，F(xiàn)實問題在于當前開源技術(shù)還不那么成熟，更不要說生產(chǎn)版本還有一定滯后，直接導致資源的隔離不徹底，應用之間相互依舊有干擾。運營過程痛苦。

方案討論

鑒于上述情況，本人斗膽建議：針對小規(guī)模的集群(<200臺)，現(xiàn)階段還是老老實實做一定的集群拆分，特別是生產(chǎn)級要求高的在線業(yè)務，通過簡單的分拆規(guī)避干擾。我下圖給出的是一個基于技術(shù)維度上的切分，也僅供參考。細分這些應用發(fā)現(xiàn)，還是有那么一些應用是死不了人的，大不了可以重啟解決掉(開源的東西大家都能理解)，有些則是真的有所要求的。這么說可能不太嚴謹，但在當前過渡階段確是有效的辦法。

至于在技術(shù)演進方面，我們也不是無動于衷，以下是可以去做的：

1. Impala：如上文提到的，引入Llama組件，將Impala服務的資源交給Yarn集中管理。現(xiàn)階段看Yarn作為一個統(tǒng)一的資源管理入口，就比較可控了。而關(guān)于Impala的執(zhí)行容錯性已經(jīng)被一些案例中提及，我們也有有同類經(jīng)歷，這會引起我們在選型中的嚴重關(guān)注

2. Hbase：針對資源的隔離方案也是有的，我們探究了三種：

• 方案1：邏輯隔離：HDFS共享一套，基于之上搭建多個Hbase集群(分在不同主機上)，不需要額外遷移數(shù)據(jù)
• 方案2：物理隔離：完全獨立，包括HDFS也是分離的，隔離效果***，但涉及數(shù)據(jù)在不同HDFS之間交互，很多人很忌諱做這個
• 方案3：Hbase on yarn：在Hbase2.0中得以支持。類似邏輯隔離，基于Yarn面向各個用戶提供單獨的Hbase集群實例，regionServer運行在YARN上

本文主要是結(jié)合實際經(jīng)歷遇到的問題進行了一下思路總結(jié)，限于自己的眼界下給出的觀點，定有不妥之處，期待與你探討。

【本文為51CTO專欄作者“大數(shù)據(jù)和云計算”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號獲取聯(lián)系和授權(quán)】

戳這里，看該作者更多好文