怎么通過準入控制馴服Apache Impala用戶

發布時間：2021-12-21 09:41:24 來源：億速云閱讀：209 作者：柒染欄目：大數據

怎么通過準入控制馴服Apache Impala用戶，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

介紹

Apache Impala遇到的一個常見問題是資源管理。每個人都想使用盡可能多的資源（即內存）來嘗試提高速度和/或隱藏查詢效率低下的情況。但是，這對其他人不公平，并且可能不利于支持重要業務流程的查詢。我們在許多客戶那里看到的是，在重新構建集群并開始使用初始用例時，會有大量資源。在繼續添加更多用例，數據科學家和運行即席查詢的業務部門之前，這些資源會消耗足夠的資源以防止那些原始用例按時完成，因此無需擔心資源。這會導致查詢失敗，這可能使用戶感到沮喪，并給現有使用案例帶來問題。

為了有效地管理Apache Impala的資源，我們建議使用準入控制功能。借助Admission Control，我們可以為Impala設置資源池。這意味著限制查詢的數量，內存的數量，并為資源池中的每個查詢強制設置。準入控制的設置很多，一開始可能令人生畏。我們將專注于內存設置，這些內存設置對于已經有數十個活動用戶和應用程序運行的集群而言至關重要。

步驟1：獲取內存統計信息

準入控制的第一個挑戰是手動收集有關單個用戶及其運行的查詢的指標，以嘗試定義資源池的內存設置。您可以在Cloudera Manager中手動使用Apache Impala查詢窗口和圖表構建器來遍歷每個用戶的查詢以收集一些統計信息，但是在以后進行重新評估非常耗時且乏味。為了對如何為各種用戶和應用程序分配資源做出明智而準確的決定，我們需要收集詳細的指標。我們已經編寫了Python腳本來簡化此過程。

該腳本可以在GitHub上找到：https://github.com/phdata/blog-2019-10-impala-admcontrol

該腳本會生成一個csv報告，并且不會進行任何更改。請查看Readme文件并在您的環境中運行腳本。

csv報告包含以下方面的總體統計信息和每個用戶的統計信息：

? （queries_count）–運行的查詢數

? （queries_count_missing_stats）–不帶統計信息運行的查詢數

? （aggregate_avg_gb）–節點間使用的平均內存

? （aggregate_99th_gb）–跨節點使用的最大內存為99％

? （aggregate_max_gb）–跨節點使用的最大內存

? （per_node_avg_gb）–每個節點使用的平均內存

? （per_node_99th_gb）–每個節點使用的最大內存為99％

? （per_node_max_gb）–每個節點使用的最大內存

? （duration_avg_minutes）–平均查詢持續時間（以分鐘為單位）

? （duration_99th_minutes）– 99％的查詢持續時間（以分鐘為單位）

? （duration_max_minutes）–最大查詢持續時間（以分鐘為單位）

步驟 2 ：立即采取的行動和關注的問題

每個集群上的每個工作負載都將有所不同，并且具有廣泛的要求。在瀏覽報告時，有一些高優先級項需要尋找。

首先，運行查詢的用戶是否缺少統計信息？

（ count_missing_stats 字段）如果您看到查詢在運行時沒有統計信息，建議您調查哪些表缺少統計信息，并確保計算統計信息是您環境中的標準過程。

其次，將最大值與第 99 列進行比較。

在第99列中，我們嘗試說明其大部分查詢（占99％）。如果最大列中的任何一個比第99個高出10-20％以上，這將使我們能夠解決錯誤或錯誤的查詢，調查用戶的最高查詢以查看它們是否為錯誤查詢，或者是否可以將這幾個查詢改進為更好地利用資源。

? aggregate_max到aggregate_99th

? per_node_max至per_node_99th

? duration_max至duration_99th

步驟 3 ： APACHE IMPALA 中的資源池設置

我們將基于此報告定義的設置為：

? 最大運行查詢/最大排隊查詢

? 默認查詢內存限制

? 最大內存

? 隊列超時

我們將逐步指導您如何確定必要資源池的每個設置。確定后，我們將使用CM中的“創建資源池”向導來創建每個池，如下圖所示。

最大正在運行/排隊查詢

為了真正衡量這一點，我們需要有一個單獨的報告，該報告記錄了查詢的開始時間和持續時間，以跟蹤每個用戶的平均、第99個百分位數和最大并發性。對于此設置，我們建議您根據用例將其保持在盡可能低的水平，因為它最終會影響您希望該用戶或一組用戶能夠使用的最大內存。為簡單起見，對于排隊查詢的數量，我們將其設置為為最大運行查詢設置的數量。

默認查詢內存限制

這是我們要為每個節點查詢的最大內存量。此設置最安全的輸入是我們報告中的per_node_max列。例外情況是，如果您調查了用戶的最高內存使用情況查詢，并發現per_node_99th可以更好地表示用戶的良好查詢，則請使用per_node_99th。

最大內存

這是根據（默認查詢內存限制* 20（Impala主機數）*最大運行查詢數）計算得出的。例如，如果我們希望資源池每個節點的查詢限制為最大4GiB，并且一次能夠運行5個查詢，那么最大內存為400GiB。

隊列超時

此設置由并發性，持續時間和查詢的SLA決定。如果查詢必須在30秒內運行，并且查詢已調整為在20秒內運行，則查詢在隊列中停留的時間超過10秒，將違反SLA。針對Apache Impala運行的第三方應用程序可能會有自己的查詢超時，這可能會干擾我們希望返回立即錯誤的情況。對于長期運行的ETL工作負載，這些工作負載可能最終導致數據偏斜增加查詢持續時間，您可以延長這些超時時間以確保所有查詢都已排隊并運行。

像Cloudera的“ 準入控制示例方案 ” 一樣，我們的集群有20個節點，每個節點上的Impala內存為128gb（Impala總計2560 GiB）。

馬上，我們可以看到需要跟進三個用戶（svc_account3，user1和user4），以查看他們的內存狀態是否可以通過計算狀態得到改善，或者他們的幾個查詢編寫得很差。我們還應該研究svc_account1，因為它們的_99th和_max數字相距甚遠。

用戶的默認資源池：這是我們的通用池，適用于平臺上沒有合理用例的其他資源的任何人。我們預留了25％的集群資源。

? 最大內存：640 GiB（集群的25％）

? 默認查詢內存限制：3 GiB

? 最高運行查詢：10

? 最大排隊查詢數：10

? 隊列超時：60秒

服務帳戶的默認資源池：這是用于由應用程序或計劃的進程生成的標準工作負載的常規資源池。

? 最大內存：1000 GiB

? 默認查詢內存限制：5 GiB

? 最高運行查詢：10

? 最大排隊查詢數：10

? 隊列超時：20分鐘

超級用戶資源池：這是需要更多資源的用戶的資源池。user3可能是唯一符合Power Users資源池條件的用戶。

? 最大內存：400 GiB

? 默認查詢內存限制：10 GiB

? 最大運行查詢數：2

? 最大排隊查詢數：2

? 隊列超時：60分鐘

svc_account2 資源池：在服務帳戶中，這是我們發現的唯一一個真正需要專用資源池的帳戶。

? 最大內存：240 GiB

? 默認查詢內存限制：12 GiB

? 最大運行查詢數：1

? 最大排隊查詢數：1

? 隊列超時：5分鐘

我們建議為每個服務帳戶創建專用的資源池，以確保資源受到保護，不會被標準用戶使用。

結論

實施準入控制的防護欄后，我們的客戶在工作負載中將具有更高的可靠性和一致性。但是，需要一些照顧和喂養。在某些情況下，新的用例會經歷一個過程，即需要請求并證明超出默認值之外的資源。提醒一下，每個集群上的每個工作負載都是唯一的，要完全實施準入控制，可能需要反復試驗。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。

向AI問一下細節

亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

怎么通過準入控制馴服Apache Impala用戶

猜你喜歡

亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

怎么通過準入控制馴服Apache Impala用戶

猜你喜歡

最新資訊

相關推薦

相關標簽