Autoscaling EMR-是否需要？我應該只使用EC2嗎？我應該只使用Qubole嗎？

Question

爲了減少配置時間，我們決定繼續使用5個實例的專用EMR集羣（我們預計需要大約5個實例）。如果我們需要更多，我們認爲我們需要實施某種自動縮放。

我對EMR並不陌生，它支持自動縮放嗎？我在文檔中找到了這個：http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-manage-resize.html

這是尋找自動縮放的正確位置，還是我誤解了「調整大小」的含義？我讀過EMR的一個好處是「按需處理」，我認爲它會分割ec2實例之間的負載，而不用指定多少實例，所以這給我的印象是它自己對ec2實例進行縮放，這意味着我們不需要自行擴展自己。我誤解了「按需處理」是什麼意思？

如果我提供的調整大小鏈接適合我正在嘗試做的事情，有沒有人有經驗確定時要調整大小？該文檔僅描述瞭如何但不是，例如，如何警報何時調整大小。我使用了他們的常規自動縮放服務，它允許您根據特定的條件調整大小，但我在這裏沒有看到它。我還不確定自動縮放EMR是否是一個壞主意 - 它是否涉及太多（因爲像Qubole這樣的整個公司都提供這種功能），或者可能不是很有用，因爲EMR已經使用了它需要的任何計算能力？我對EMR實際提供的東西不太瞭解，所以也許這就是我困惑的原因。

Answer 1

您鏈接的頁面顯示了手動或以編程方式增加羣集中節點的方式。我找不到有關EMR自動縮放的其他內容。

除非我們錯過了一些事實，否則你仍然必須想出自己的縮放算法和過程。如果您考慮了諸如工作積壓，付款時間單位，使用價格較低的「現貨」實例，多個集羣等因素，這可能不是一件簡單的事情。

除了增加羣集的大小，還有縮小規模。 EMR允許這些（手動或編程）用於任務節點，但它們聲明它們不適用於核心節點。您必須通過AWS功能終止核心節點，否則可能會丟失數據。如果您的工作負載隨着時間的推移而增加和減少，那麼核心節點縮小規模對於降低成本很有價值。

Qubole自動處理所有這些開箱即用的東西。您可以通過UI或API運行您的作業，並啓動，調整大小或調整羣集大小。完成後，它會縮小或終止羣集。它還允許您一次運行最少數量的節點。我也聽說Qubole節點的啓動時間比EMR快得多。

希望這可以幫助你。

Answer 2

AWS目前（截至2016年底）不支持作爲EMR一部分的開箱即用型自動縮放。但是，EMR API提供了所有必要的組件，以1）收集監視數據，2）以編程方式向上和向下縮放羣集。

基本上，存在實現自動縮放爲EMR簇的兩個主要的選項：

1. 自動配置功能環路：這是一個服務器上運行，並且連續的方法，監視其當前負載羣集。性能指標（內存，CPU，I/O等）可以定期收集並存儲在數據庫中。根據性能指標評估自動縮放規則，並根據需要放大或縮小羣集的任務節點。
2. 基於事件的自動配置功能：使用CloudWatch的指標（例如，metrics for EMR，或metrics for EC2），可以通過編程定義被在特定條件下執行的觸發器（例如，如果所有的節點的平均CPU利用率超過80％時添加節點）。

這兩個選項都有其優點和缺點。選項2的優點是它是無服務器方式（不需要運行自己的服務器）。缺點是CloudWatch指標是批量收集的（通常是5分鐘的時間間隔），因此數據可能稍微延遲或不準確。而且，基於事件的方法可能不會提供檢查羣集縮放的當前和歷史狀態所需的工具。另一方面，選項1的確需要服務器，但是因此具有更多的控制來定製您的縮放規則的邏輯。此外，它允許保留縮放決定歷史的可搜索記錄。

你可以看看Themis，這是一個在Atlassian開發的EMR自動縮放框架。 Themis按照上面的選項1所述實現自動調節循環。目前的功能包括主動式和反應式自動縮放，它帶有一個Web UI，並且該工具非常易於配置。