Cloudera Impala 常見問題(翻譯)

Cloudera Impala 常見問題

Trying Impala

如何實驗 Cloudera Impala?

想要試試 Impala 的核心特性和功能,最簡便的實驗 Impala 的方法就是下載 Cloudera QuickStart VM 並經過 Cloudera Manager 啓動 Impala 服務,而後在終端窗口使用 impala-shell,或者在Hue web 接口中使用  Impala Query UI。 git

想要在集羣中測試 Impala 的性能並實驗管理特性,你須要超越 QuickStart VM 和它的虛擬化的單節點環境。理想狀況下,下載 Cloudera Manager 軟件來設置集羣,而後經過 Cloudera Manager 安裝 Impala。 github

Cloudera 是否提供演示 Impala 的 VM 環境?

Cloudera 提供演示 VM 環境 QuickStart VM,包含 VMWare, VirtualBox, KVM 三種格式。更多信息,參見 the Cloudera QuickStart VM。啓動 QuickStart VM 後,其中許多服務默認是關閉的;在自動出現的 Cloudera Manager UI 中,啓用 Impala 和其餘你想要實驗的組件 web

在哪裏能夠找到 Impala 文檔

參見 Impala Documentation 瞭解 Impala 版本說明、關於 Impala 安裝更新配置、以及 Impala 查詢語言的信息。 sql

在哪裏能夠了解到更多的 Impala 的信息?

這裏有更多 Impala 產品的信息: shell

在 Cloudera Announcements 論壇查看最新的 Impala 公告。 數據庫

在哪裏提問和提交 Impala 的反饋?

在哪裏能夠下載樣例數據進行測試?

你能夠在 this Github repository 得到生成數據文件並設置 TPC-DS 類型基準測試環境的腳本。除了能夠用於性能試驗外,這些表也適用於測試 Impala SQL 的許多方面:他們包含了各類數據類型、數據分佈、分區、以及適合鏈接查詢的關係數據。 apache

Impala System Requirements

運行 Impala 有什麼軟硬件方面的需求?

關於 Impala 的需求,參見 Cloudera Impala Requirements。須要注意的是,對於給定版本的 Impala,一般有一個最小支持的 Clouder Manager 版本。 緩存

須要多少內存?

儘管 Impala 不是內存數據庫,當處理大的表和大的結果集時,你應當期待爲 impalad 守護進程分配大量的物理內存(you should expect to dedicate a substantial portion of physical memory for the impalad daemon)。推薦 Impala 節點具備至少 128 GB 內存。Impala 操做所需的內存依賴於幾個因素:

  • 表的文件格式。相同的數據,採用不一樣的文件格式,數據文件個數也不一樣。爲了分析數據,根據每一個文件所採用的壓縮和編碼格式的不一樣,可能須要不一樣數據量的臨時內存來進行解壓(The compression and encoding for each file format might require a different amount of temporary memory to decompress the data for analysis)
  • 是否爲 SELECT 或 INSERT 操做。例如,查詢 Parquet 表時須要相對較少的內存,由於 Impala 以 8MB /塊來進行讀取和解壓縮數據。而向 Parquet 表插入數據則是內存密集型操做,由於每個數據文件(最大大小爲 1GB)的數據被放在內存中,直到編碼、壓縮並寫入硬盤
  • 表是否爲分區表,而且針對分區表的查詢是否能夠從分區修剪(partition pruning)中受益
  • 最終的結果集是否使用 ORDER BY 子句來排序。請記住,Impala 要求全部包含的 ORDER BY 子句的查詢同時包含 LIMIT 子句,或者在語句中直接包含,或者隱式的經過 DEFAULT_ORDER_BY_LIMIT 查詢選項設置來實現。每個 Impala 節點掃描並過濾總數據的一部分,而且對他們本身那部分數據應用 LIMIT。中間結果集 (包含最大 LIMIT 行記錄)都發送回協調節點,在上面執行最終的排序並對最終結果集應用 LIMIT 子句。例如,假如你執行查詢:
    select * from giant_table order by some_column limit 1000;
    而且你的集羣有 50 個節點,而後這 50 個節點每一個節點將傳遞最多 1000 行記錄給協調節點。協調節點須要足夠的內存進行排序(LIMIT *集羣節點數) ,儘管這時最終的結果集最多返回 1000 行。
  • 結果集的大小。當中間結果集在節點之間傳輸時,傳輸數據的數量依賴於查詢返回列的數量。例如,在結果集中只返回實際所需列的查詢比老是使用 SELECT * 的查詢消耗更少的內存
  • 鏈接查詢工做如何拆分的機制

如何 Impala 節點在處理中間結果集時超出了預留給 Impala 內存的限制,目前 Impala 不支持"溢出的硬盤(spill to disk)"。假如這對你的狀況來講是個問題(例如鏈接兩個很是大的表時),更多內存是有益的。

參見 Hardware Requirements 瞭解更詳細的信息以及 Impala 硬件方面的先決條件。

Cloudera 推薦哪一種處理器?

Impala 使用 SSE4.2 指令。對應 Intel 的 Nehalem+ 芯片和 AMD 的 Bulldozer+ 芯片。Impala 能夠在較老的機器上正常運行,但沒法達到最佳性能。

Supported and Unsupported Functionality In Impala

Impala 支持下列功能:

  • SQL 和 HiveQL 命令的一個大的子集,包括 SELECT 、 INSERT 、joins。更多信息,參見 Impala SQL Language Reference.
  • 使用 Cloudera Manager 管理 Impala。請使用 Cloudera Manager 4.6 及以上版本,你能夠部署和管理你的 Impala 服務。在集羣中使用 Impala ,使用 Cloudera Manager 是最佳入門方式。 更多信息,參見 Cloudera Manager Installation Guide 中使用 Cloudera Manager 安裝 Impala 的主題
  • 使用 Hue 進行查詢
  • 經過 INSERT 語句向表中追加和插入數據。參見 How Impala Works with Hadoop File Formats 瞭解關於哪一種文件格式的哪些操做能夠支持的詳細信息
  • ODBC: Impala 是認證支持 MicroStrategy 和 Tableau的,可是有一些限制更多信息,參見 Configuring Impala to Work with ODBC.
  • 在單個查詢中同時查詢 HDFS 和 HBase 中的數據。參見 Using Impala to Query HBase Tables 瞭解詳細信息
  • 併發客戶端請求。每個 Impala 守護進程能夠處理多併發客戶端請求。對性能的影響依賴於你特定的硬件和負載
  • Kerberos 認證。更多信息參見 Impala Security.
  • 分區。在 Impala SQL 中,你可使用 CREATE TABLE 語句建立分區表,使用 ALTER TABLE 語句添加、刪除分區。Impala 一樣會從以前 Hive 中的分區表。參見 Partitioning 瞭解詳細信息

Impala 不支持下列功能:

  • 流數據查詢(Querying streaming data)
  • 刪除個別行。你能夠經過覆蓋整個表或分區、或刪除表來批量刪除數據
  • 索引(暫不支持)。像 Using LZO-Compressed Text Files 中描述的那樣,LZO 壓縮文本文件能夠在 Impala 以外進行索引
  • 文本字段的全文檢索。這時候請使用 Cloudera Search 產品
  • 自定義 Hive 序列化/反序列化(Serializer/Deserializer) 類(SerDes)。Impala 支持一組通用的本地文件格式,在 CDH 中有對應的內置的 SerDes。參見 How Impala Works with Hadoop File Formats 瞭解詳細信息
  • 運行中查詢的故障轉移。假如運行查詢的任意主機失敗,目前來講 Impala 是取消所運行的查詢。當一個或多個主機下線,Impala 會從新路由以後的查詢並只使用可用的主機,當主機從新上線時 Impala 能夠檢測到,並從新使用它們。由於查詢能夠經過任意 Impala 節點提交,因此不會出現單點故障。未來咱們會爲 Impala 添加額外的工做分配功能,這樣即便出現主機失敗也會完成整個查詢
  • Impala 守護進程之間的加密數據傳輸
  • 窗口函數(Window functions)
  • Hive 索引
  • 非 Hadoop 數據源,如關係數據庫

關於更詳細的不支持的 HiveQL 特性列表,參見 SQL Differences Between Impala and Hive

Impala 是否支持通用 JDBC?

Impala 支持 HiveServer2 JDBC 驅動。

是否支持 Avro?

是的,支持 Avro。Impala 能夠查詢 Avro 表。但目前你必須在 Hive 中建立表並加載數據。參見 Using the Avro File Format with Impala Tables 瞭解詳細信息。

What's next for Cloudera Impala?

How do I?

如何避免用戶看到 SQL 查詢的內容?

關於如何設置 Impala 日誌對未受權的用戶不可讀的介紹,參見 Securing Impala Data and Log Files.

關於web 接口對 Impala 日誌文件和其餘內部服務器信息的密碼保護(For instructions on password-protecting the web interface to the Impala log files and other internal server information),參見 Securing the Impala Web User Interface

如何知道集羣中有多少 Impala 節點?

Impala statestore 會跟蹤當前有多少 impalad 節點可用。你能夠經過 statestore 的 web 接口看到這些信息。例如,在 http://statestore_host:25010/metrics 你能夠看到相似下面的行:

statestore.live-backends:3
statestore.live-backends.list:[host1:22000,host1:26000,host2:22000]

其中 impalad 節點的個數是列出的對象中使用 22000 端口的對象的個數,這裏是 2 個(一般這個數值比 statestore.live-backends 報告的數值少一)。假如一個 impalad 不可用,通過停機後恢復正常,那本頁報告的信息會對應的修改。

Impala Performance

查詢結果是一可用就返回仍是等查詢完成後一次所有返回?

Impala 儘量的一有結果就輸出來。特定的 SQL 操做(聚合函數或排序操做) 須要全部的結果都準備好才能夠返回。

爲何個人查詢運行緩慢?

一個查詢運行的慢可能有許多緣由。使用下面的列表,診斷已有查詢性能問題,在寫新的查詢時避免出現這些問題,配置新的節點,建立新的表,或者加載數據。

  • 在查詢完成以後,在 impala-shell 中當即執行 PROFILE 命令。對於指定的節點,其中 BytesRead、BytesReadLocal、BytesReadShortCircuit 的值應當一致。例如:
    - BytesRead: 180.33 MB
    - BytesReadLocal: 180.33 MB
    - BytesReadShortCircuit: 180.33 MB
    假如 BytesReadLocal 低於 BytesRead,你集羣中的一些配置可能錯了, 例如 impalad 守護進程沒有在所有數據節點上都運行。假如 BytesReadShortCircuit 低於 BytesRead,這一節點上可能沒有啓用 short-circuit 讀;參見 Post-Installation Configuration for Impala 瞭解相關信息
  • 假如表剛剛建立,或者是在 INVALIDATE METADATA 語句以後或者 impalad 守護進程剛剛重啓以後第一次訪問這個表,當表元數據被加載和緩存時,可能有一些延遲。請檢查再次執行查詢時候放緩是否消失。在進行性能對比時,考慮先對每個表執行一個 DESCRIBE table_name 語句,以確保全部的計時都只記錄了實際的查詢時間而不是包含加載表元數據的一次性等待
  • 表數據使用的是未壓縮的文本格式?請使用 DESCRIBE FORMATTED table_name 語句檢查。文本文件表使用下面的語句標識:
    InputFormat: org.apache.hadoop.mapred.TextInputFormat
    儘管對於不包含 STORED AS 子句的 CREATE TABLE 語句,默認使用未壓縮的文本文件格式,但它是佔用硬盤空間最大的格式,因此也是查詢最慢的格式。對於查詢性能很關鍵的數據,特別是頻繁查詢的表,請考慮開始或轉換成緊湊的二進制文件格式,如Parquet 、Avro、RCFile、SequenceFile。詳細信息,參見 How Impala Works with Hadoop File Formats
  • 假如你的表有很是多的列,可是查詢僅涉及其中少許的列,請考慮使用 Parquet 文件格式。它的數據文件被組織成面向列(column-oriented)的佈局, 可讓檢索、過濾和彙總特定列的值的 I/O 需求量最小化。參見 Using the Parquet File Format with Impala Tables 瞭解詳細信息
  • 假如你的查詢涉及到不少鏈接,這些表是正確的順序嗎,以便返回最多行的表或子查詢放在最左側(If your query involves any joins, are the tables in the query ordered so that the tables or subqueries are ordered with the ones returning the largest number of rows on the left)? 這一順序容許 Impala 優化節點之間如何分佈工做,以及中間結果集如何從一個節點向另一個節點路由。例如,其餘部分都相同,下面鏈接順序的查詢是高效的查詢:
    select some_col from
        huge_table join big_table join medium_table join small_table
      where
        huge_table.id = big_table.id
        and big_table.id = medium_table.id
        and medium_table.id = small_table.id;
    參見 Performance Considerations for Join Queries 瞭解鏈接查詢的性能提示
  • 一樣對於鏈接查詢,在你的鏈接子句中使用的表、列是否都有統計信息?列統計信息讓 Impala 更好的選擇如何爲鏈接查詢的各個部分分配工做。參見 How Impala Uses Statistics for Query Optimization 瞭解採集統計信息的詳細信息
  • 你的表是否由大量的小數據文件組成?Impala 對大數據文件更高效(Impala works most efficiently with data files in the multi-megabyte range);Parquet 是一種專爲數據倉庫類的查詢優化的文件格式,採用 1GB 的文件和 1GB 塊大小。在 impala-shell 中使用 DESCRIBE FORMATTED table_name 語句來查看錶的數據位置,並使用 hadoop fs -ls 或 hdfs dfs -ls Unix 命令查看文件以及大小。假如你有成千上萬個小數據文件,這就是你應當合併成更少的大數據文件的信號。使用 INSERT ... SELECT 語句複製數據到新表,這一過程包含重組到新數據文件的部分。寧肯構建大的數據文件並經過 LOAD DATA 或 CREATE EXTERNAL TABLE 語句採用批量的方式導入,也不用採用 INSERT ... VALUES 語句的方式;每個 INSERT ... VALUES 語句建立一個單獨的極小的數據文件。假如你在同一個目錄下有成千上萬的數據文件,但每個有幾兆大(but each one is megabytes in size,), 考慮使用分區表,以便每個分區包含較少許的文件。請參閱下面更多的分區說明
  • 假如你的數據易於根據時間或地理位置分組,那麼你根據對應的列如年、月、和/或日分區了嗎?基於特定列的分區表容許查詢查詢根據這些列過濾,避免讀取無關年份、無關郵編等等的數據(不要分區成太細的粒度;分區構建成每一個分區下都有足夠的數據,以便從 multi-megabyte HDFS block size 中受益)。參見 Partitioning 瞭解詳細信息

爲何個人 SELECT 查詢會失敗?

當一個 SELECT 語句失敗了,緣由一般是如下類別之一:

  • 由於性能、容量、或網絡問題影響了特定的節點致使的超時
  • 鏈接查詢的過多內存數用,這一查詢的結果會自動取消
  • 處理查詢中特定的 WHERE 子句時,影響到每一節點上本地代碼如何生成的底層問題。例如,特定節點上可能會生成它的處理器不支持的機器指令。假如日誌中的錯誤信息猜想是無效指令(illegal instruction),考慮臨時關閉生成本地代碼,並重試這個查詢
  • 異常的輸入數據,例如包含一個巨大的長行的文本數據文件(a text data file with an enormously long line),或者使用了沒有在 CREATE TABLE 語句中 FIELDS TERMINATED BY 子句中設置的分隔符(or with a delimiter that does not match the character specified in the FIELDS TERMINATED BY clause of the CREATE TABLEstatement)

爲何個人 INSERT 查詢會失敗?

當 INSERT 語句失敗時,一般是由於超出 Hadoop 組件的一些限制,特別是 HDFS。

  • 因爲可能會在 HDFS 併發打開許多文件和關聯的進程,插入到分區表的操做是一個費力(strenuous)操做。Impala 1.1.1 包含了一些改進,以更有效的分發工做,這樣每一個分區使用一個節點寫入值,而不是沒一個節點一個單獨的數據文件
  • INSERT 語句中 SELECT 部分的特定表達式會產生複雜的執行計劃,並致使低效的 INSERT 操做。請儘可能使源表和目標表中列的數據類型匹配,例如,若是必要,在源表上執行 ALTER TABLE ... REPLACE COLUMNS 語句。請儘可能避免在 SELECT 位置使用 CASE 表達式,由於相比保持列不變或經過內置函數轉換列,CASE 會致使結果更難預測
  • 請作好準備提高你的 HDFS 配置設置中的一些限制,能夠臨時的在 INSERT 執行時,若是你頻繁運行這些 INSERT 語句做爲 ETL 管道的一部分,也能夠永久修改
  • 依賴於目標表的文件格式,INSERT 語句的資源使用可能會變化。插入到 Parquet 表是內存密集型操做,由於每個分區的數據會緩存到內存裏,直到它達到 1G,這時候數據文件才寫入到硬盤。當執行 INSERT 語句時候,若是查詢中源表的統計信息可用,Impala 能夠更高效的分佈工做。參見 How Impala Uses Statistics for Query Optimization 瞭解如何採集統計信息

當部署到集羣中更多主機上時, Impala 性能會提高嗎?就像 Hadoop 性能那樣?

是的。Impala 性能隨主機數而擴展(Impala scales with the number of hosts)。在集羣中全部數據節點上安裝 Impala 很重要,不然的話,一些節點必須進行遠程讀取以得到本地讀取沒法得到的數據。對於 Impala 性能來講,數據本地化(Data locality) 是一個重要的架構方面(architectural aspect)。參見 this Impala performance blog post 瞭解背景信息。請注意這些博客使用 Impala 1.1.1 進行的基準測試;在 Impala 1.2.x 系列中,已經添加了更多性能特性。

減小 HDFS 塊大小會實現更快的查詢結果嗎?

不會。Impala 不會對 HDFS 或 HBase 數據集作任何修改。

默認的 Parquet 塊大小已經至關的大(1GB),而且在建立 Parquet 文件時使用 PARQUET_FILE_SIZE 查詢選項能夠控制塊大小。

Impala 使用緩存嗎?

Impala 不會緩存數據,但它緩存一些表和文件的元數據。儘管由於數據集被緩存到 OS 的緩衝區中,接下來的重複查詢可能運行的更快,Impala 不會明確的控制這些。

Impala Use Cases

什麼狀況下適合使用 Impala 而不適合 Hive 和 MapReduce?

Impala 很是適合在大的數據集上,爲交互式探索分析執行 SQL。Hive 和 MapReduce 則適合長時間運行的、批處理的任務,例如 ETL。

Impala 是否須要 MapReduce ?若是 MapReduce 停了,Impala 是否能正常工做?

Impala 根本用不到 MapReduce。

Impala 是否能夠用於復瑣事件處理?

例如,在工業環境中,許多客戶端可能產生大量的數據。Impala 是否可用與分析這些數據,發現環境中顯著的變化?

復瑣事件處理(Complex Event Processing,CEP) 一般使用專門的流處理系統處理。Impala 不是流處理系統,它其實更像關係數據庫。

Is Impala intended to handle real time queries in low-latency applications or is it for ad hoc queries for the purpose of data exploration?

即席查詢(Ad-hoc)是 Impala 的主要使用狀況。咱們估計它會在許多須要低延遲的環境中使用。Impala 是否適合某個特定的狀況依賴於此時的負載、數據大小和查詢次數。參見 Impala Benefits 瞭解使用 Impala 能夠得到的主要益處。

Questions about Impala And Hive

Impala 與 Hive 和 Pig 有什麼異同?

Impala 與 Hive 和 Pig 不一樣,由於它使用本身的守護進程,跨集羣分佈式進行查詢。由於 Impala 不依賴於 MapReduce,它避免了 MapReduce 做業的啓動開銷,讓 Impala 能實時返回結果。

我是否能夠改變或添加新功能(functionality)?

Impala 1.2 開始支持 UDFs。你可使用 C++ 寫你本身的函數,或者重用已有的基於 Java 的 Hive UDFs。支持的 UDF 包括標量函數和用戶定義聚合函數(UDAs)。目前不支持用戶定義表函數(UDTFs)。

Impala 目前不支持擴展序列號-反序列化(serialization-deserialization)框架(SerDes),所以爲 Impala 添加擴展功能不像 Hive 或 Pig 那麼簡單。

Impala 中的全部查詢均可以在 Hive 中執行嗎?

是的。儘管在一些查詢如何處理方面有細微的差異,可是 Impala 查詢也能夠在 Hive 中完成。Impala SQL 是 HiveQL 的子集,有一些功能限制如變換(transforms)。關於具體的 Impala SQL 方言,參見 SQL Statements。關於 Impala 內置函數,參見 Built-in Functions。關於不支持的 HiveQL 特性,參見 SQL Differences Between Impala and Hive

我能夠用 Impala 查詢已經在 Hive 和 HBase 加載的數據嗎?

容許 Impala 查詢 Hive 管理的表,無論它是存放在 HDFS 仍是 HBase中,都不須要額外的步驟。請確保已經正確的配置 Impala 訪問 Hive metastore,而且你準備好了。請記住,默認的 impalad 使用 impala 用戶運行,因此你可能須要調整一些文件的權限,這取決於你目前權限多麼嚴格。

參見 Using Impala to Query HBase Tables 瞭解查詢 HBase 中數據的詳細信息。

Impala 是否須要 Hive?

Hive metastore 服務是必需的。Impala 與 Hive 共享同一個 metastore 數據庫,透明的容許 Impala 和 Hive 訪問相同的表。

Hive 自己是可選的,而且不須要跟 Impala 安裝在同一個節點上。相比目前 Impala 支持的寫(插入)操做(的文件格式),Impala 支持更多類型的讀取(查詢)操做;對於使用的特定的文件格式,你應當使用 Hive 向表裏插入數據。參見 How Impala Works with Hadoop File Formats 瞭解詳細信息。

Impala Availability

Impala 能夠用於生產環境嗎?

Impala 已經完成了它的測試版本發佈週期,1.0 GA 版本已經爲生產環境作好準備。而 1.1.x 系列包括了受權這一新增的安全特性,這是許多組織使用產品的重要需求。一些 Cloudera 客戶已經爲大的負載使用 Impala。

Impala 1.2.0 版本目前是測試版,由於它使用了許多僅在 CDH 5.0 測試版中可用的特性。隨後的與 CDH 4 協同的 1.2.1 和 1.2.2,適用於生產環境 (相比 1.2.1,更推薦 1.2.2,由於 1.2.2 包含了許多針對鏈接查詢的性能優化)。

如何爲 Impala 配置 Hadoop 高可用性 (HA)?

你能夠設置代理服務器,轉發 Impala 服務器來回的請求,以實現負載均衡和高可用性。參見 Using Impala through a Proxy for High Availability 瞭解詳細信息。

你能夠爲 Hive metastore 啓用 HDFS HA。參見 CDH4 High Availability Guide 瞭解詳細信息。

Impala 出現錯誤時都發生了什麼?

Impala 中不會出現單點故障。全部的 Impala 守護進程全均可以處理所接受的查詢。假如一臺機器出現故障,在這臺機器上有查詢片斷(fragments)在上面運行的查詢都會失敗。由於查詢被指望快速返回的,當查詢失敗時你能夠從新運行失敗的查詢(Because queries are expected to return quickly, you can just rerun the query if there is a failure)。參見 Impala Concepts and Architecture 瞭解 Impala 架構的詳細信息。

完整回答:Impala 必須可以鏈接到 Hive metastore。Impala 積極緩存元數據,這樣 metastore 主機的負載很小。Impala 依賴於 HDFS NameNode,而且在 CDH 4中你能夠爲 HDFS 配置 HA。Impala 一樣有一個集中的軟件狀態(soft-state)服務,稱做 statestorecatalog 服務,僅僅在一臺主機上運行。假如 statestore 主機下線,Impala 會繼續執行查詢,但不會得到狀態更新。例如,若是在 statestore 主機下線期間向集羣添加了一臺主機,運行在其餘主機上的已有的 impalad 實例將不會發現這臺新的主機。一當 statestore 進程重啓後,全部它提供的信息會根據全部運行的 Impala 守護進程自動重建。

Impala 表中最多容許多少行?

沒有限制。一些用戶已經使用 Impala 查詢包含上萬億記錄的表。

Impala 和 MapReduce 做業能夠在相同集羣中運行而不會資源衝突嗎?

是的。參見 Controlling Resource Usage 瞭解如何使用 Linux cgroup 機制控制 Impala 使用的資源,以及 Using YARN Resource Management with Impala (CDH 5 Only) 瞭解如何使用 Impala 和 YARN 資源管理框架。Impala 被設計爲運行在 DataNode 主機上的。任何資源衝突都依賴於集羣的配置和負載。

關於詳細的如何配置集羣在 Impala 查詢和 MapReduce 做業之間共享資源的例子,參見 Setting up a Multi-tenant Cluster for Impala and MapReduce

Impala Internals

Impala 應當在哪些主機上運行?

爲了更佳的性能,Cloudera 強烈推薦在每一臺數據節點(DataNode)上都運行 impalad 守護進程。儘管這一拓撲結構不是硬性要求,假若有任意主機,上面包含了數據塊副本可是沒有 Impala 守護進程運行,那麼涉及到這些數據的查詢的效率將很是低下(if there are data blocks with no Impala daemons running on any of the hosts containing replicas of those blocks, queries involving that data could be very inefficient)。這時候,這些數據必須經過"遠程讀取"從一臺主機傳輸到另一臺主機以進行處理,這是 Impala 應儘可能避免的狀況。參見 Impala Concepts and Architecture 瞭解關於 Impala 架構的詳細信息。Impala 會盡量的調度查詢分片,以便能在存放對應數據的主機上執行查詢(Impala schedules query fragments on all hosts holding data relevant to the query, if possible)。

Impala 中鏈接如何執行?

默認的,Impala 使用基於成本的方法,根據表的總大小和行數,自動肯定最高效的錶鏈接順序(這是從 Impala 1.2.2 纔開始具備的新特性)。使用 COMPUTE STATS 語句採集的每個表的統計信息是高效鏈接的關鍵。Impala 鏈接查詢在兩種鏈接技術之間進行選擇,分別是 "廣播鏈接(broadcast joins)" 和 "分割鏈接(partitioned joins)"。參見 Joins 瞭解語法詳情,參見 Performance Considerations for Join Queries 瞭解性能注意事項。

Impala 如何處理大表的鏈接查詢?

Impala 採用多種策略,容許不一樣大小的表和結果集進行鏈接。當一個大表與一個小錶鏈接時,小表中的全部數據會傳輸到每一節點上以進行中間處理。當鏈接兩個大表時,其中一個表的數據被拆分紅多塊,每個節點只處理其中選中的塊。參見 Joins 瞭解鏈接處理的詳細信息,Performance Considerations for Join Queries 瞭解性能注意事項,Hints 瞭解如何微調鏈接策略。

Impala 的聚合策略是什麼?

Impala 目前僅支持內存中的哈希聚合(hash aggregation)。

Impala 元數據如何管理?

Impala 使用兩部分的元數據:Hive metastore 中的目錄信息和 NameNode 中的文件元數據。目前,當 impalad 須要元數據以產生查詢的執行計劃時才加載並緩存元數據(this metadata is lazily populated and cached when an impaladneeds it to plan a query)

當在 Hive 中加載新數據以後,使用 REFRESH 語句更新這個表的元數據。INVALIDATE METADATA Statement 語句刷新全部的元數據,以便 Impala 識別到 Hive 中建立的新表或其餘 DDL 、DML 的修改。

在 Impala 1.2 及以上版本中,有一個單獨的 catalogd 守護進程向全部節點廣播 Impala 中 DDL 或 DML 語句致使的元數據變化,減小或避免了使用 REFRESH 和 INVALIDATE METADATA 語句的需求。

併發查詢時 NameNode 負載如何?

Impala 產生的負載與 MapReduce 產生的很是相似。Impala 在規劃階段鏈接 NameNode 以得到文件元數據(僅在接收到查詢的主機上執行)。每個 impalad 將讀取文件做爲查詢正常處理的一部分(Every impalad will read files as part of normal processing of the query)。

爲什麼 Impala 能實現性能提高(How does Impala achieve its performance improvements)?

這是 Impala 與其餘 Hadoop 組件和相關技術在性能方面不一樣的主要緣由(These are the main factors in the performance of Impala versus that of other Hadoop components and related technologies)。

Impala 避免使用 MapReduce。儘管 MapReduce 是一種偉大的通用並行處理模型,具備許多優勢,可是它不是專爲執行 SQL 設計的。Impala 在這些方面避免了 MapReduce 的低效:

  • Impala 不會把中間結果存放到硬盤上。SQL 查詢一般映射成多個包含全部中間結果集都寫入到硬盤上的 MapReduce 做業(SQL queries often map to multiple MapReduce jobs with all intermediate data sets written to disk)
  • Impala 避免了 MapReduce 啓動時間的耗費。對於交互式查詢,MapReduce 啓動時間變得很是醒目。Impala 以服務方式運行,實際上沒有啓動時間
  • Impala 能夠更天然的分散查詢計劃,而不是不得不歸入 map 和 reduce 做業管道中。這使得 Impala 能夠並行處理查詢的多個步驟,並避免沒必要要的負載如排序和混洗(This enables Impala to parallelize multiple stages of a query and avoid overheads such as sort and shuffle when unnecessary)

Impala 經過利用最新機器和技術(modern hardware and technologies),採用了一種更高效的執行引擎(Impala uses a more efficient execution engine by taking advantage of modern hardware and technologies):

  • Impala 生成運行時代碼。Impala 使用 LLVM 爲要執行的查詢生成彙編碼(assembly code)。個別查詢不須要爲運行在能夠支持各類查詢的系統而支付代價(Individual queries do not have to pay the overhead of running on a system that needs to be able to execute arbitrary queries)
  • Impala 儘量採用最新的硬件指令。Impala 使用最新的 SSE (SSE4.2) 指令集,某些狀況下能夠提供巨大的加速效果
  • Impala 採用更好的 I/O 調度。Impala 瞭解塊在硬盤上的位置,並能夠調度塊處理的順序,以便保證全部硬盤都繁忙
  • Impala 專爲性能設計。Impala 採起以性能爲導向的設計原則,爲此花費了大量的時間,例如緊密內部循環、內聯函數調用、最小分支、更好的緩存使用、以及最小內存使用等(A lot of time has been spent in designing Impala with sound performance-oriented fundamentals, such as tight inner loops, inlined function calls, minimal branching, better use of cache, and minimal memory usage)

當數據集超出可用內存時會發生什麼?

目前來講,假如在某一節點上處理中間結果集所需的內存超出了這一節點上 Impala 可用的內存,查詢會被取消。你能夠調整每一節點上 Impala 的可用內存,也能夠對你最大的查詢微調鏈接策略來減小內存需求。咱們計劃在未來支持外部鏈接和排序。

但請記住,使用內存的大小並非跟輸入數據集的大小直接相關。對於聚合來講,使用的內存跟分組後的行數有關。對於鏈接來講,使用的內存與除了最大的表以外其餘全部表的大小相關,而且 Impala 能夠採用在每一個節點之間拆分大的鏈接表而不是把整個表都傳輸到每一個節點的鏈接策略。

哪些是內存密集型操做?

假如查詢失敗,錯誤信息是 "memory limit exceeded",你可能懷疑有內存泄露(memory leak)。其實問題多是由於查詢構造的方式致使 Impala 分配超出你預期的內存,從而在某些節點上超出 Impala 分配的內存限制(The problem could actually be a query that is structured in a way that causes Impala to allocate more memory than you expect, exceeded the memory allocated for Impala on a particular node)。一些特別內存密集型的查詢和表結構以下:

  • 使用動態分區的 INSERT 語句,插入到包含許多分區的表中(特別是使用 Parquet 格式的表,這些表中每個分區的數據都保存到內存中,直到它達到 1 GB 並被寫入到硬盤裏)。考慮把這樣的操做分散成幾個不一樣的 INSERT 語句,例如一次只加載一年的數據而不是一次加載全部年份的數據
  • 在惟一或高基數(high-cardinality)列上的 GROUP BY 操做。Impala 爲 GROUP BY 查詢中每個不一樣的值分配一些處理結構(handler structures)。成千上萬不一樣的 GROUP BY 值可能超出內存限制
  • 查詢涉及到很是寬、包含上千個列的表,特別是包含許多 STRING 列的表。由於 Impala 容許 STRING 值最大不超過 32 KB,這些查詢的中間結果集可能須要大量的內存分配

什麼時候 Impala 分配(hold on to)或釋放(return)內存?

Impala 使用 tcmalloc 分配內存,一款專爲高併發優化的內存分頻器。一當 Impala 分配了內存,它保留這些內存用於未來的查詢。所以,空閒時顯示 Impala 有很高的內存使用是很正常的。假如 Impala 檢測到它將超過內存限制(經過 -mem_limit 啓動選項或 MEM_LIMIT 查詢選項定義),它將釋放當前查詢不須要的全部內存。

當經過 JDBC 或 ODBC 接口執行查詢,請確保在以後調用對應的關閉方法。不然,查詢關聯的一些內存不會釋放。

SQL

是否支持 UPDATE 語句?

Impala 目前不支持 UPDATE 語句,它一般用於修改單行數據、一小組數據、或特定的列。一般 Impala 查詢使用的基於 HDFS 的文件針對一次超過許多M的批量操做(bulk operations)進行了優化,這使得傳統的 UPDATE 操做低效或不切實際。

你可使用下面的技術來達到與熟悉的 UPDATE 語句相同的目標,併爲以後的查詢保持高效的文件佈局:

  • 使用你已經更新後並存放在其餘位置的數據替換掉表或分區的所有內容,或者使用 INSERT OVERWRITE, LOAD DATA, 或者使用手工 HDFS 文件操做以後對這個表執行 REFRESH 語句。可選的,你能夠在 INSERT 語句中使用內置函數和表達式來轉換複製的數據,就像你一般在 UPDATE 語句中所作的那樣,例如轉換一個混合大小寫的字符串爲所有大寫或所有小寫
  • 爲了更新單行數據,請使用 HBase 表,並使用與原來行相同的 key 執行 INSERT ... VALUES 語句。由於 HBase 經過只返回特定鍵值的最新的行來處理重複的鍵,新插入的行有效的隱藏了以前的

Impala 能夠執行用戶定義函數(UDFs)嗎?

Impala 1.2 及以上版本支持 UDFs 和 UDAs。你可使用 C++ 編寫本地 Impala UDFs 和 UDAs,或者重用以前用 Java 編寫的 Hive 中的 UDFs (但不支持 UDAs) 。參見 User-Defined Functions 瞭解詳細信息。

爲何我必須使用 REFRESH 和 INVALIDATE METADATA,它們作了什麼?

在 Impala 1.2 或更高版本中,大大減小了使用 REFRESH 和 INVALIDATE METADATA 語句的狀況:

  • 新的 impala 目錄服務,即 catalogd 守護進程,向全部 Impala 節點廣播 Impala DDL 語句的結果。所以,假如你在一個 Impala 節點執行了 CREATE TABLE 語句,再經過其餘節點執行查詢時,再也不須要執行 INVALIDATE METADATA
  • 目錄服務只識別到經過 Impala 致使的變動,所以若是你經過 Hive,或者經過在 HDFS 中操做文件加載數據,仍然必須使用 REFRESH 語句,而且若是你在 Hive 中建立、修改表、添加或刪除分區、或執行其餘 DDL 操做後,必須執行 INVALIDATE METADATA 語句
  • 由於目錄服務向全部節點廣播 REFRESH 和 INVALIDATE METADATA 語句的結果,當你仍然須要執行這些語句的時候,你能夠只在其中一個節點上運行,而不是在全部節點上運行,而且這些變化會被整個集羣自動識別。這使得能夠經過任意 Impala 節點執行查詢而不是總使用同一個協調器節點,更方便負載均衡

爲何執行 DROP TABLE 以後空間不釋放?

當你對內部表而不是外部表執行 DROP TABLE 後,Impala 刪除對應的數據文件。默認的,CREATE TABLE 語句建立內部表,文件被 Impala 管理。外部表經過 CREATE EXTERNAL TABLE 語句建立,文件位置在 Impala 控制範圍以外。請執行 DESCRIBE FORMATTED 語句檢查表是內部表仍是外部表。關鍵字 MANAGED_TABLE 表示是內部表,Impala 能夠刪除這些數據文件。關鍵字 EXTERNAL_TABLE 表示這是外部表,當你刪除表時,Impala 將保持這些數據文件不變。

即便當你刪除一個內部表而且文件已經從原來的位置移除,你可能也不會馬上獲得空閒的硬盤空間。默認的,HDFS 中刪除的文件放到特定的回收站(trashcan)目錄,在那裏過一段時間(默認是 6 小時)後被清除。關於回收站機制的背景知識,請參見 http://archive.cloudera.com/cdh4/cdh/4/hadoop/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html。更多關於在回收站清除文件的信息,參見 http://archive.cloudera.com/cdh4/cdh/4/hadoop/hadoop-project-dist/hadoop-common/FileSystemShell.html

當 Impala 刪除文件,而且那些文件被移動到 HDFS 回收站,他們存放在屬於 impala 用戶的 HDFS 目錄中。假如 impala 用戶沒有 HDFS home 目錄,在這裏回收站會被建立,基於安全的考慮,這些文件不會被刪除和移動。假如你執行了 DROP TABLE 語句,而後發現表的數據文件仍然在原來的位置,請先建立 HDFS 目錄 /user/impala,屬於 impala 用戶,並可寫。例如,你可能發現 /user/impala 屬於 hdfs 用戶,這時你須要切換成 hdfs 用戶並執行相似的命令:

hdfs dfs -chown -R impala /user/impala

Partitioned Tables

我怎麼把一個大的 CSV 文件加載到分區表裏?

爲了向分區表裏加載數據文件,當數據文件包含相似 year,month, 等等對應着分區鍵的列時,使用兩步處理。首先,使用 LOAD DATA 或 CREATE EXTERNAL TABLE 語句加載數據到未分區的表裏。而後使用 INSERT ... SELECT 語句從未分區的表向分區表複製數據。在 INSERT 語句中包含 PARTITION 子句指定分區鍵列。對每個分區,這一 INSERT 操做把數據拆分紅單獨的數據文件。例如,參見 Partitioning 中的例子。關於如何把數據加載到分區 Parquet 表(大批量數據的熱門選擇)的詳細信息,參見 Loading Data into Parquet Tables

我能夠執行 INSERT ... SELECT *加載數據到分區表嗎?

當你使用 INSERT ... SELECT * 語法複製數據到分區表時,對應分區鍵的列必須出如今 SELECT * 所返回列的最後。你能夠把分區鍵定義放在最後來建立表。或者,你可使用 CREATE VIEW 語句建立一個記錄這些列:把分區鍵列放在最後,而後使用 INSERT ... SELECT * from the view。

相關文章
相關標籤/搜索