下面是 Clouder Impala 產品常見問題的目錄。 html
繼續閱讀: node
想要試試 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 提供演示 VM 環境 QuickStart VM,包含 VMWare, VirtualBox, KVM 三種格式。更多信息,參見 the Cloudera QuickStart VM。啓動 QuickStart VM 後,其中許多服務默認是關閉的;在自動出現的 Cloudera Manager UI 中,啓用 Impala 和其餘你想要實驗的組件 web
這裏有更多 Impala 產品的信息: shell
在 Cloudera Announcements 論壇查看最新的 Impala 公告。 數據庫
你能夠在 this Github repository 得到生成數據文件並設置 TPC-DS 類型基準測試環境的腳本。除了能夠用於性能試驗外,這些表也適用於測試 Impala SQL 的許多方面:他們包含了各類數據類型、數據分佈、分區、以及適合鏈接查詢的關係數據。 apache
關於 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 操做所需的內存依賴於幾個因素:
select * from giant_table order by some_column limit 1000;而且你的集羣有 50 個節點,而後這 50 個節點每一個節點將傳遞最多 1000 行記錄給協調節點。協調節點須要足夠的內存進行排序(LIMIT *集羣節點數) ,儘管這時最終的結果集最多返回 1000 行。
如何 Impala 節點在處理中間結果集時超出了預留給 Impala 內存的限制,目前 Impala 不支持"溢出的硬盤(spill to disk)"。假如這對你的狀況來講是個問題(例如鏈接兩個很是大的表時),更多內存是有益的。
參見 Hardware Requirements 瞭解更詳細的信息以及 Impala 硬件方面的先決條件。
Impala 使用 SSE4.2 指令。對應 Intel 的 Nehalem+ 芯片和 AMD 的 Bulldozer+ 芯片。Impala 能夠在較老的機器上正常運行,但沒法達到最佳性能。
關於更詳細的不支持的 HiveQL 特性列表,參見 SQL Differences Between Impala and Hive。
Impala 支持 HiveServer2 JDBC 驅動。
是的,支持 Avro。Impala 能夠查詢 Avro 表。但目前你必須在 Hive 中建立表並加載數據。參見 Using the Avro File Format with Impala Tables 瞭解詳細信息。
關於如何設置 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 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 儘量的一有結果就輸出來。特定的 SQL 操做(聚合函數或排序操做) 須要全部的結果都準備好才能夠返回。
一個查詢運行的慢可能有許多緣由。使用下面的列表,診斷已有查詢性能問題,在寫新的查詢時避免出現這些問題,配置新的節點,建立新的表,或者加載數據。
- BytesRead: 180.33 MB - BytesReadLocal: 180.33 MB - BytesReadShortCircuit: 180.33 MB假如 BytesReadLocal 低於 BytesRead,你集羣中的一些配置可能錯了, 例如 impalad 守護進程沒有在所有數據節點上都運行。假如 BytesReadShortCircuit 低於 BytesRead,這一節點上可能沒有啓用 short-circuit 讀;參見 Post-Installation Configuration for Impala 瞭解相關信息
InputFormat: org.apache.hadoop.mapred.TextInputFormat儘管對於不包含 STORED AS 子句的 CREATE TABLE 語句,默認使用未壓縮的文本文件格式,但它是佔用硬盤空間最大的格式,因此也是查詢最慢的格式。對於查詢性能很關鍵的數據,特別是頻繁查詢的表,請考慮開始或轉換成緊湊的二進制文件格式,如Parquet 、Avro、RCFile、SequenceFile。詳細信息,參見 How Impala Works with Hadoop File Formats
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 瞭解鏈接查詢的性能提示
當一個 SELECT 語句失敗了,緣由一般是如下類別之一:
當 INSERT 語句失敗時,一般是由於超出 Hadoop 組件的一些限制,特別是 HDFS。
是的。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 系列中,已經添加了更多性能特性。
不會。Impala 不會對 HDFS 或 HBase 數據集作任何修改。
默認的 Parquet 塊大小已經至關的大(1GB),而且在建立 Parquet 文件時使用 PARQUET_FILE_SIZE 查詢選項能夠控制塊大小。
Impala 不會緩存數據,但它緩存一些表和文件的元數據。儘管由於數據集被緩存到 OS 的緩衝區中,接下來的重複查詢可能運行的更快,Impala 不會明確的控制這些。
Impala 很是適合在大的數據集上,爲交互式探索分析執行 SQL。Hive 和 MapReduce 則適合長時間運行的、批處理的任務,例如 ETL。
Impala 根本用不到 MapReduce。
例如,在工業環境中,許多客戶端可能產生大量的數據。Impala 是否可用與分析這些數據,發現環境中顯著的變化?
復瑣事件處理(Complex Event Processing,CEP) 一般使用專門的流處理系統處理。Impala 不是流處理系統,它其實更像關係數據庫。
即席查詢(Ad-hoc)是 Impala 的主要使用狀況。咱們估計它會在許多須要低延遲的環境中使用。Impala 是否適合某個特定的狀況依賴於此時的負載、數據大小和查詢次數。參見 Impala Benefits 瞭解使用 Impala 能夠得到的主要益處。
Impala 與 Hive 和 Pig 不一樣,由於它使用本身的守護進程,跨集羣分佈式進行查詢。由於 Impala 不依賴於 MapReduce,它避免了 MapReduce 做業的啓動開銷,讓 Impala 能實時返回結果。
Impala 1.2 開始支持 UDFs。你可使用 C++ 寫你本身的函數,或者重用已有的基於 Java 的 Hive UDFs。支持的 UDF 包括標量函數和用戶定義聚合函數(UDAs)。目前不支持用戶定義表函數(UDTFs)。
Impala 目前不支持擴展序列號-反序列化(serialization-deserialization)框架(SerDes),所以爲 Impala 添加擴展功能不像 Hive 或 Pig 那麼簡單。
是的。儘管在一些查詢如何處理方面有細微的差異,可是 Impala 查詢也能夠在 Hive 中完成。Impala SQL 是 HiveQL 的子集,有一些功能限制如變換(transforms)。關於具體的 Impala SQL 方言,參見 SQL Statements。關於 Impala 內置函數,參見 Built-in Functions。關於不支持的 HiveQL 特性,參見 SQL Differences Between Impala and Hive。
容許 Impala 查詢 Hive 管理的表,無論它是存放在 HDFS 仍是 HBase中,都不須要額外的步驟。請確保已經正確的配置 Impala 訪問 Hive metastore,而且你準備好了。請記住,默認的 impalad 使用 impala 用戶運行,因此你可能須要調整一些文件的權限,這取決於你目前權限多麼嚴格。
參見 Using Impala to Query HBase Tables 瞭解查詢 HBase 中數據的詳細信息。
Hive metastore 服務是必需的。Impala 與 Hive 共享同一個 metastore 數據庫,透明的容許 Impala 和 Hive 訪問相同的表。
Hive 自己是可選的,而且不須要跟 Impala 安裝在同一個節點上。相比目前 Impala 支持的寫(插入)操做(的文件格式),Impala 支持更多類型的讀取(查詢)操做;對於使用的特定的文件格式,你應當使用 Hive 向表裏插入數據。參見 How Impala Works with Hadoop File Formats 瞭解詳細信息。
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 服務器來回的請求,以實現負載均衡和高可用性。參見 Using Impala through a Proxy for High Availability 瞭解詳細信息。
你能夠爲 Hive metastore 啓用 HDFS HA。參見 CDH4 High Availability Guide 瞭解詳細信息。
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)服務,稱做 statestore 和 catalog 服務,僅僅在一臺主機上運行。假如 statestore 主機下線,Impala 會繼續執行查詢,但不會得到狀態更新。例如,若是在 statestore 主機下線期間向集羣添加了一臺主機,運行在其餘主機上的已有的 impalad 實例將不會發現這臺新的主機。一當 statestore 進程重啓後,全部它提供的信息會根據全部運行的 Impala 守護進程自動重建。
沒有限制。一些用戶已經使用 Impala 查詢包含上萬億記錄的表。
是的。參見 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
爲了更佳的性能,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 1.2.2 纔開始具備的新特性)。使用 COMPUTE STATS 語句採集的每個表的統計信息是高效鏈接的關鍵。Impala 鏈接查詢在兩種鏈接技術之間進行選擇,分別是 "廣播鏈接(broadcast joins)" 和 "分割鏈接(partitioned joins)"。參見 Joins 瞭解語法詳情,參見 Performance Considerations for Join Queries 瞭解性能注意事項。
Impala 採用多種策略,容許不一樣大小的表和結果集進行鏈接。當一個大表與一個小錶鏈接時,小表中的全部數據會傳輸到每一節點上以進行中間處理。當鏈接兩個大表時,其中一個表的數據被拆分紅多塊,每個節點只處理其中選中的塊。參見 Joins 瞭解鏈接處理的詳細信息,Performance Considerations for Join Queries 瞭解性能注意事項,Hints 瞭解如何微調鏈接策略。
Impala 目前僅支持內存中的哈希聚合(hash aggregation)。
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 語句的需求。
Impala 產生的負載與 MapReduce 產生的很是相似。Impala 在規劃階段鏈接 NameNode 以得到文件元數據(僅在接收到查詢的主機上執行)。每個 impalad 將讀取文件做爲查詢正常處理的一部分(Every impalad will read files as part of normal processing of the query)。
這是 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 經過利用最新機器和技術(modern hardware and technologies),採用了一種更高效的執行引擎(Impala uses a more efficient execution engine by taking advantage of modern hardware and technologies):
目前來講,假如在某一節點上處理中間結果集所需的內存超出了這一節點上 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)。一些特別內存密集型的查詢和表結構以下:
Impala 使用 tcmalloc 分配內存,一款專爲高併發優化的內存分頻器。一當 Impala 分配了內存,它保留這些內存用於未來的查詢。所以,空閒時顯示 Impala 有很高的內存使用是很正常的。假如 Impala 檢測到它將超過內存限制(經過 -mem_limit 啓動選項或 MEM_LIMIT 查詢選項定義),它將釋放當前查詢不須要的全部內存。
當經過 JDBC 或 ODBC 接口執行查詢,請確保在以後調用對應的關閉方法。不然,查詢關聯的一些內存不會釋放。
Impala 目前不支持 UPDATE 語句,它一般用於修改單行數據、一小組數據、或特定的列。一般 Impala 查詢使用的基於 HDFS 的文件針對一次超過許多M的批量操做(bulk operations)進行了優化,這使得傳統的 UPDATE 操做低效或不切實際。
你可使用下面的技術來達到與熟悉的 UPDATE 語句相同的目標,併爲以後的查詢保持高效的文件佈局:
Impala 1.2 及以上版本支持 UDFs 和 UDAs。你可使用 C++ 編寫本地 Impala UDFs 和 UDAs,或者重用以前用 Java 編寫的 Hive 中的 UDFs (但不支持 UDAs) 。參見 User-Defined Functions 瞭解詳細信息。
在 Impala 1.2 或更高版本中,大大減小了使用 REFRESH 和 INVALIDATE METADATA 語句的狀況:
當你對內部表而不是外部表執行 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
爲了向分區表裏加載數據文件,當數據文件包含相似 year,month, 等等對應着分區鍵的列時,使用兩步處理。首先,使用 LOAD DATA 或 CREATE EXTERNAL TABLE 語句加載數據到未分區的表裏。而後使用 INSERT ... SELECT 語句從未分區的表向分區表複製數據。在 INSERT 語句中包含 PARTITION 子句指定分區鍵列。對每個分區,這一 INSERT 操做把數據拆分紅單獨的數據文件。例如,參見 Partitioning 中的例子。關於如何把數據加載到分區 Parquet 表(大批量數據的熱門選擇)的詳細信息,參見 Loading Data into Parquet Tables。
當你使用 INSERT ... SELECT * 語法複製數據到分區表時,對應分區鍵的列必須出如今 SELECT * 所返回列的最後。你能夠把分區鍵定義放在最後來建立表。或者,你可使用 CREATE VIEW 語句建立一個記錄這些列:把分區鍵列放在最後,而後使用 INSERT ... SELECT * from the view。