FAQ系列之Impala

語言: CN / TW / HK


我下載了一個配置檔案,裡面有一堆沒有單位的數字。那些是什麼?

那是納秒。 查詢計劃 GUI 的格式適合您,但下載的配置檔案只有基本資料。

當我使用 Hue 時,為什麼我的查詢長時間處於活動狀態?

Hue 保持查詢執行緒處於活動狀態,直到您關閉它。 有一種方法可以在 Hue 上設定超時。

Impala的查詢計劃是什麼樣子?

1. Exec Summary - 查詢片段執行時間的概述。 例如 這是一些處理偏差,因為片段 27 的平均時間為 17 分鐘,但最大時間為 4 小時。 由於某種原因,一個節點有太多的工作要做。


2. 查詢時間線 - 查詢時間線概覽。當 Rows 可用時,查詢結束。

有時,如果 Hue 保持開啟狀態,則在獲取完成後查詢會持續很長時間,然後它會保持執行緒處於活動狀態。

3. 查詢計劃 - 這會更詳細地介紹每個片段,告訴您發生了什麼以及處理或交換了多少資料。

如何獲取Impala的查詢計劃:

1. Impala Daemon WebUI - 我最喜歡這個

優點 - 給出了一個圖形化的計劃並有一個漂亮的網路介面

易於剪下和貼上格式良好的查詢配置檔案和計劃

缺點 - 很難知道哪個守護程序運行了查詢。

不讓你輕鬆下載文字查詢計劃——必須剪下和貼上

2. Cloudera Manager - Impala 程序

轉到查詢選項卡並選擇最右側的查詢詳細資訊。

優點 - 有一個下載文字配置檔案按鈕

有一個很好的格式佈局。

缺點 - 文字配置檔案下載始終更改為難以閱讀的納秒。

我寧願剪下和貼上格式化的時間。

以下是格式化查詢時間線與下載時間線的比較:

3. 在 Hue 中執行解釋

您可以在查詢前鍵入 Explain 以檢視查詢計劃。

優點- 容易做到。

缺點 - 你沒有得到查詢時間線或 exec 配置檔案。

如何獲取Impala的cookbook指南?

檢視 Impala Cookbook 以獲取端到端部署指南。地址:http://blog.cloudera.com/latest-impala-cookbook/

Impala的Schema設計建議是什麼?

  • 使用數字型別。儘可能避免字串型別,以避免每次讀取列值時的字串轉換成本、儲存字串的記憶體開銷以及不同的比較語義。對於記憶體利用率、併發性、效能和 CPU 效率,這個“瑣碎”點的重要性怎麼強調都不為過。您應該使用字串型別的情況:HBase 行鍵(為了效能)、Parquet 日期(為了 Hive 相容性)和顯然是真實的文字字串。

  • 儘可能避免 CHAR 和 VARCHAR。CHAR 和 VARCHAR 的效率明顯低於字串,只有在應用程式無法處理可變長度字串(例如 SAS)時才應使用。數字型別優先於字串以上。如果您必須使用其中之一,請使用 VARCHAR 而不要使用 CHAR。

  • 明智地選擇分割槽。一個好的分割槽計劃既可以從常見的查詢過濾器中消除資料,又可以為長順序讀取提供足夠的分割槽大小,從而提高 IO 吞吐量。遵循 Impala 分割槽策略工作表。

Impala推薦的檔案格式是什麼?

  • 總是喜歡 Parquet。Parquet 是一種列式格式,可提供其他列式資料儲存所證明的快速分析效能和最大儲存密度。使用 Parquet 可以最大限度地提高併發性、效能和 IO 效率。在轉換為 Parquet 之前,如果需要的話,可以使用 Avro 或可能的文字來攝取暫存。“在 Impala 表中使用 Parquet 檔案格式”

  • 避免除 Parquet、Avro 和 Text 之外的檔案格式。最佳模式是將資料攝取到 Avro 或文字中,因為它們的面向行的格式允許逐行寫入。然後將資料批量轉換為 Parquet,以利用列式效能和資料密度效率進行讀取。這些格式應涵蓋所有用例,並且是我們的工程工作最集中的地方(如果沒有,請聯絡 justin@)。Impala 將繼續為遺留資料開發其他檔案格式。注意上一點總是更喜歡 Parquet。

  • 遵循檔案和塊大小的最佳實踐。最佳做法是 256 MB Parquet 檔案,以提供足夠的大小以提高 IO 掃描效率(建議使用 Impala 建立 Parquet 檔案以避免當前 Parquet-MR/Hive 設定的複雜性)。如果在極少數情況下尋找 SLA < 5s,您可能會考慮根據 Advanced Block Sizing 自定義塊大小。

Impala查詢計劃的建議是什麼?

  • 始終在連線、聚合或建立/插入中涉及的所有表上計算統計資訊。這是在不耗盡記憶體的情況下處理更大的表連線所必需的。新增新的大型資料元素時重新整理統計資訊以避免過時的統計資訊。有關統計資料為何至關重要的更多詳細資訊。

  • 不要在列數非常多的表上使用增量統計。每個節點上每個分割槽的每列增量統計資料佔用 400 位元組。我們建議在可能的情況下將它用於具有較少列的較大表,並注意增量統計資料並不適合所有客戶。請參閱“增量統計概述”

  • 使用 EXPLAIN 按照查詢計劃驗證來驗證計劃是否合理。設定explain_level=2 以顯示掃描節點中統計資訊的可用性。“瞭解 Impala 查詢效能 - 解釋計劃和查詢配置檔案”

Impala的併發性和多租戶建議是什麼?

  • 使用 NLB(網路負載平衡器)來實現容錯和可擴充套件性。這是必要的,因此您可以在 ImpalaD 之間分散連線以避免單點故障並分散任何最終步驟和客戶端連線的負載。

  • 為 MR/YARN 設定 cgroup 資源限制併為 Impala 使用記憶體限制。如果您在同一叢集上同時執行批處理作業(例如 MR、Spark、Pig、Hive)和 Impala,您應該為 MR/YARN 設定 cgroup 限制,並使用 Impala 的記憶體限制來控制這些工作負載之間的資源分配。

  • 對併發使用准入控制和查詢佇列。如果您同時執行多個使用者,您可以使用准入控制來避免叢集過度飽和並支援多租戶。

Impala監控的方法有哪些?

  • 使用 CM 來監控查詢。

  • 使用 Impala Charts 下的 CM Best Practices 來確認上面的一些最佳實踐。




本文分享自微信公眾號 - 大資料雜貨鋪(bigdataGrocery)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。