為多租戶情境叢集配置Impala和Mapreduce

原文標題：Configuring Impala and MapReduce for Multi-tenant Performance(http://blog.cloudera.com/blog/2013/06/configuring-impala-and-mapreduce-for-multi-tenant-performance/)

為多租戶情境叢集配置Impala和Mapreduce

Cloudera
Impala包含很多令人驚喜的特性，但是其給人印象最深的應該是支援以多種格式分析HDFS和HBASE中資料的能力，並且不需要ETL。此外，使用者可以使用多個架構如mapreduce和impala來分析相同的資料。因此，Impala可以和mapreduce一起運行在相同的物理機器上，支援企業的關鍵業務。對那些多租戶（譯者註：這裡的多租戶指多計算架構，如叢集運行了Impala和Mapreduce）的叢集，儘管存在著可能的對叢集資源需求的潛在衝突，Impala和Mapreduce都需要營運好。

這篇文章，將分享作者在配置Impala和Mapreduce過程中認為最理想的多租戶營運環境的經驗。目標就是協助使用者理解怎樣去對多租戶叢集進行調優滿足產品的服務水準(SLOs)，並向社區貢獻一些有用的，事半功倍的測試方法和效能模型。

定義實用測試情境

Cloudera面對的是廣泛和多樣的客戶群體，所以這使得為現實世界的情境做測試是頭等大事。基於普通的使用案例的現實測試提供了有意義的指導，反之，人為地，不切實際地測試得出的結論在作用到實踐中時通常失敗。

對於Impala，主要的測試工作量就是直接複製Impala使用者的查詢，schema，以及資料選取。我們使用這個方法測試幾種不同類別的使用者案例的查詢和schema結構，通常會和客戶一起合作，對所有的cdh組件得到相似的實際測試情境。在對他們指定的使用案例獲得直接的效能結論過程中，客戶也一樣受益匪淺。

因為OLAP（online analytical processing）是使用者使用Impala案例中最多的一個，我們也運行TPC-H,一種在OLAP建立的基準測試，是對Impala的第二個工作。TPC-H提供了大量、公用的、已經被審核過結果的資源（這些結果是基於上世紀90年代的一次OLAP使用者調查得到的），所以現在我們啟動並執行這個TPC-H查詢的子集是最佳的用例。

對於MapReduce，使用各種基準測試來對不同資料格式，對MR計算管道不同階段不同壓力進行測試。比如TeraSort套件（包括TeraGen，TeraSort和TeraValidate），資料清洗作業，處理資料中隨機性不同量值。這些測試不同於其他的MR測試，比如使用類似SWIM的開源工具直接重現客戶的成千上萬道作業造成的工作負載。這些負載捕捉複雜並且多樣，將會在未來添加。與之相比，我們開展的多租戶測試，可以對測試進行精確控制，並容易重複進行。

多租戶測試包含Impala查詢、與MR並行基準測試等整套環節，並迴圈這個過程（每次，不同的impala查詢使用不同的mr作業）。再加上各種體積的資料，不同的資料格式，並行運行Impala查詢的不同，MR作業並行的不同，最後的結果會是一個百種參數設定的結果矩陣。這個測試矩陣給了我們信心，這樣出現的結果是有意義的，並且Impala可以和MR像期待的那樣一起在同一個叢集中共用。

多租戶效能期望建模

多租戶資源管理涉及到將不同的資源分派到不同的計算架構的作業中。為數百個測試案例的所有矩陣資料建模是難以實現的。不過，以簡單的方式，我們可以將資源分派簡化為一句話：“當叢集資源被爭用時，Impala獲得所有資源的x部分，而MR得到其餘的”。

如果Impala和MR資源共用和諧，其效能應隨著其佔有資源的比例下降而下降。也就是說，Impala的多租戶效能應不低於其獨佔所有資源時效能的比例值x部分，MR也不應低於其獨佔資源時效能的1-x部分。目標就是找到並驗證資源管理控制的一系列方法，儘可能的達到滿意的效能或者甚至超出期望。

這是理論上最簡單的模型也可能是更複雜的。例如如果MR作業已耗用時間比Impala查詢長，多租戶運行放緩只在兩者都運行時出現。那個Impala查詢將達到前面所說的x比例的效能。而那個MR作業在作業起始時獲得1-x比例的效能，而剩下的過程將擷取到所有資源時的效能。

這個模型的另外一個擴充是覆蓋不均勻的資源分派過程。例如大多數的Impala查詢需要大的記憶體需求，而MR作業需要較多得IO資源。如果分配給Impala 50%的CPU，60%的記憶體，40%的硬碟IO，所有資源變化可同時影響效能，並且我們期待整體上效能降低範圍在40-60%之間。這個比較複雜的伴隨著多維度資源分派模型在cdh是支援的，這裡暫時不講。

共用資源的控制

多租戶資源管理控制套件在另一篇文章裡" Setting
up a Multi-tenant Cluster for Impala and MapReduce"(包含在Cloudera Manager 安裝指導中)。套間裡包含了對每個啟動並執行計算架構的記憶體管理、CPU、IO管理等。文檔中含有幾個例子，和指導怎樣配置下面的資源：

• Memory. 包含Impala記憶體限制。直接對Impala可消耗記憶體、最大同時啟動並執行Map任務數、Reduce數設定。間接對MR記憶體控制。對於記憶體管理，主要關注點是防止記憶體的波動，作業或查詢失敗，或者任何架構對所有資源的獨佔導致的阻止其他架構運行程式。

為了設定總實體記憶體的比例x，設定Impala記憶體限制為（RAM/accounting factor）*x. 其中accounting factor是作業系統常駐記憶體中實際可用記憶體的參數常量，可用來調整伺服器負載。發現值為1.5是相對安全的值，而1.3則更理想但更危險。

對於Mapreduce，對map和reduce任務數的最大值應為預設值的1-x。例如假設給了Impala所有叢集資源的25%，則x=25%，那麼map和reduce最大鎖業數就為預設值的75%。如果並行map任務數最大預設值為16，reduce最大預設值是8，那麼新值就分別應該是12和6。當每個任務在其子jvm容器中運行通過map()和reduce()方法處理資料時，這樣可以有效地讓Mapreduce使用其餘剩餘的1-x部分叢集的記憶體資源。對應著這一變化，任何一個作業的調優與槽容量調優有關的都需要隨之做變化（因為槽資源減少了）。注意，在MR1中槽是最小的調優單元。對未來的CDH5和YARN來說，反而可能會指定具體的記憶體使用量量。YARN會對應用各主伺服器（他們中得一個要運行MR作業）進行資源分派。

• CPU. 我們通過Linux
  Control Groups（Cgroups）來控制CPU的使用。Cgroups是Linux kernel 提供的一個特性，使用者可以通過Cloudera Manager 4.5.x及以上版本配置。CGroup cpu共用給一個角色資源越多，其在資源競爭時共用的cpu資源就越大。例如，一個進程在4核cpu上運行佔有的cpu時間是在2核機器上的2倍。這個控制稱為soft limits（軟式節流），當伺服器上運行進程既有來自cloudera manager管理的角色，同時有其他系統進程時，那個設定就沒有效果了。

在多租戶環境中，所有的Impala和Mapreduce進程，包含Impala後台進程，DN、TT等，可能會同時搶佔cpu資源。設定cpu資源的x部分給Impala，每個節點上其餘的資源的一半給dn和tt，這樣即可達到將cpu的x部分給impala，mapreduce佔有其餘的資源。

這個對mapreduce來講是保守的設定，這裡假定dn和任務計算可以同時運行，最大化CPU的使用。如果你的mr負載遠遠低於叢集資源總量，這個設定就不那麼靠譜。例如，當你只有一個mr作業，通常作業輸入輸出使用的DN和TTcpu使用不會同時。只有當你有非常大的負載，那麼整體上可以說dn和tt使用是同時的。

• Disk. 磁碟IO資源也通過Cgroups來控制。角色被授予的Cgroup IO比重越大，其IO請求的優先順序就越高。這個和CPU管理效果幾乎一致。

我們選擇了一個比較保守的磁碟資源配置：Impala後台進程使用磁碟IO比重x的部分，其餘的（即1-x部分）中得一半給DN，另外的給TT。

多租戶效能資料

測試目標：

• 衡量未管控多租戶下叢集使用效果
• 衡量使用資源管控多租戶狀態下的效能
• 研究上面2種情況下的資源競爭
• 研究面向資源控制的獨立運行效能

測試叢集有64GB記憶體，12核 2.0GHz Intel Xeon， 12 * 2TB磁碟，10Gbps頻寬。

測試基準效能是在MapReduce和Impala均無資源控制情況，並且均獨立運行。我們稱為未管控獨立效能（uncontrolled, stand-alone performance）。這是非常好的基準效能，因為沒有資源控制，獨立安裝在研究Mapreduce或者Impala叢集都是公平的。

未管控叢集效能

如前所述，我們測試了多租戶無資源控制情況下叢集效能。測試中，MapReduce消耗了大部分叢集資源，大大影響了IMpala的效能。尤其是，沒有資源控制的Mapreduce效能是未資源控制獨立運行效能的90%，而Impala大概是獨立啟動並執行50%。

這些資料比預測的要高。原因是Impala和Mapredue資源需求並不是總是處於競爭狀態。以後的測試，我們也將研究如何控制Impala和Mapreduce 負載，以便讓其持續的存在資源競爭。

資源管理機制在未資源控制效能上有幾個方面的提升。首先 叢集資源很少會過度使用。資源控制使得記憶體更安全，耗記憶體的進程導致伺服器swap或者thrash的風險更低。例如如果未使用資源管理導致Impala效能低於生產的SLO（程式局部最佳化建議工具 Suggestions for Locality Optimizations），使用者可以調整資源控制並將資源從Mapreduce轉給Impala使得兩者都達到期望的SLO。

資源管理下叢集效能

資源管理控制運行使用者指定比重值x。我們測試使用參數有25-75，40-60，50-50，60-40，75-25。其中前面比值是分配給impala的，剩餘的資源給Mapreduce。測試結果顯示我們確實通過向某個計算架構分配資源多少控制了叢集效能。

顯示了Impala和Mapreduce叢集的效能。圖上每個資料點顯示了特定參數設定下的效能下降百分比，而豎線條顯示的是25到75的測試參數矩陣各情況下效能效果。

 

上面圖形顯示，Impala和Mapreduce多租戶效能都達到或者超過了預期模型。一些Impala查詢和Maprecuce作業的效能幾乎沒有收到影響（誤差線接近獨立運行時效能）。一些作業的效能受到的影響超過了之前的預期模型（誤差線低於預期模型線(Modeled line)）。絕大多數作業達到或者超過了預期。原因還是之前說的，Impala和Mapreduce資源競爭並不是一直存在。

驗證資源競爭

我們使用Cloudera Manager來檢測未資源控制和做了資源控制2種情況下測試中得實體資源使用方式。記憶體幾乎一直被打滿。CPU和磁碟負載只是一些時候出現飆升和競爭現象。這個行為解釋了我們測試結論：Impala和Mapreduce均超過了預期的效能。

資源管控下獨立運行效能

多租戶資源管控表現為軟式節流（soft limits）。換句話說，當只有一個架構處於活躍狀態時，就應該表現為其擁有整個叢集。上面說的CPU和磁碟控制均設計為軟式節流，而記憶體卻是硬限制（hard limits）。因此我們有必要測試資源管控下的獨立運行效能。注意，這不同於之前的未資源管控的獨立效能基準測試。

Impala的表現像極了其擁有整個叢集資源。這對於設定了記憶體限制的Impala也是預期就知道的。要麼查詢不受影響，要麼當查詢達到記憶體限制時，查詢被立即幹掉。

對Mapreduce而言，行為表現的稍顯複雜。將可用槽位設定到並行運行量的的上限。為適度降低槽位設定，仍然需要足夠的並行作業使資源達到滿負荷使用，這樣效能影響就很小。猛降槽位元，剩餘的槽位將不足以使資源得到有效利用，效能影響就非常大。

適度降低槽位還是猛降槽位依賴於叢集硬體。對於我們測試叢集，50%槽位的降低隻影響了15%的效能！然而減少槽位到25%得到的效能指標大致和多租戶效能類似。意味著可用槽位而不是資源競爭變成了Mapreduce的效能限制。因此，就像之前描述的那樣，根據叢集硬體資源，資源管控有一個調節設定的空間。

下一步計劃

大資料多租戶效能是一個非常重要的工程問題，因為其會立即影響到大量使用者。我們的測試方法、模型和結論高度依賴現實情境，並具有一定數學嚴謹性和實踐實驗性質。

下步馬上會做的就是去擴充測試情境，覆蓋Impala多查詢同時多MR作業運行時負載，impala和Mapreduce均設定一定的負載水平。

總之，我們希望這篇文章可以協助使用者調優多租戶叢集去達到生產環境的SLOs，並協助社區瞭解如何在共用的大資料平台上管理資源。