Impala介紹

Impala支持的文件格式

Impala可以對Hadoop中大多數(shù)格式的文件進(jìn)行查詢。它能通過create table和insert的方式將一部分格式的數(shù)據(jù)加載到table中，但值得注意的是，有一些格式的數(shù)據(jù)它是無法寫入的（write to）。對于Impala無法寫入的數(shù)據(jù)格式，我們只能通過Hive建表，通過Hive進(jìn)行數(shù)據(jù)的寫入，然后使用Impala來對這些保存好的數(shù)據(jù)執(zhí)行查詢操作。

文件類型	文件格式	壓縮編碼	能否CREATE ?	能否INSERT ?
Parquet	結(jié)構(gòu)化	Snappy GZIP	能	能
Text	非結(jié)構(gòu)化	LZO	能。 如果建表時(shí)沒有指定存儲類型，默認(rèn)采用未壓縮的text，字段由ASCII編碼的0x01字符串分割。	能。 如果使用了LZO壓縮，則只能通過Hive建表和插入數(shù)據(jù)。
Avro	結(jié)構(gòu)化	Snappy GZIP Deflate BZIP2	在Impala 1.4.0 或者更高的版本上支持，之前的版本只能通過Hive來建表。	不能。 只能通過LOAD DATA的方式將已經(jīng)轉(zhuǎn)換好格式的數(shù)據(jù)加載進(jìn)去，或者使用Hive來插入數(shù)據(jù)。
RCFile	結(jié)構(gòu)化	Snappy GZIP Deflate BZIP2	能	不能。 只能通過LOAD DATA的方式將已經(jīng)轉(zhuǎn)換好格式的數(shù)據(jù)加載進(jìn)去，或者使用Hive來插入數(shù)據(jù)。
SequenceFile	結(jié)構(gòu)化	Snappy GZIP deflate BZIP2	能	不能。 只能通過LOAD DATA的方式將已經(jīng)轉(zhuǎn)換好格式的數(shù)據(jù)加載進(jìn)去，或者使用Hive來插入數(shù)據(jù)。

?

Impala支持以下壓縮編碼：

• Snappy – 推薦的編碼，因?yàn)樗趬嚎s率和解壓速度之間有很好的平衡性，Snappy壓縮速度很快，但是不如GZIP那樣能節(jié)約更多的存儲空間。Impala不支持Snappy壓縮的text file。
• GZIP – 壓縮比很高能節(jié)約很多存儲空間，Impala不支持GZIP壓縮的text file。
• Deflate – Impala不支持GZIP壓縮的text file。
• BZIP2 - Impala不支持BZIP2壓縮的text file。
• LZO – 只用于text file，Impala可以查詢LZO壓縮的text格式數(shù)據(jù)表，但是不支持insert數(shù)據(jù)，只能通過Hive來完成數(shù)據(jù)的insert。

Impapla如何執(zhí)行查詢

下面這個(gè)圖表示了Impala在Hadoop集群中所處的位置：

Impala由以下的組件組成：

• Clients – Hue、ODBC clients、JDBC clients、和Impala Shell都可以與Impala進(jìn)行交互，這些接口都可以用在Impala的數(shù)據(jù)查詢以及對Impala的管理。
• Hive Metastore – 存儲Impala可訪問數(shù)據(jù)的元數(shù)據(jù)。例如，這些元數(shù)據(jù)可以讓Impala知道哪些數(shù)據(jù)庫以及數(shù)據(jù)庫的結(jié)構(gòu)是可以訪問的，當(dāng)你創(chuàng)建、刪除、修改數(shù)據(jù)庫對象或者加載數(shù)據(jù)到數(shù)據(jù)表里面，相關(guān)的元數(shù)據(jù)變化會自動通過廣播的形式通知所有的Impala節(jié)點(diǎn)，這個(gè)通知過程由catalog service完成。
• Cloudera Impala – Impala的進(jìn)程運(yùn)行在各個(gè)數(shù)據(jù)節(jié)點(diǎn)（Datanode）上面。每一個(gè)Impala的實(shí)例都可以從Impala client端接收查詢，進(jìn)而產(chǎn)生執(zhí)行計(jì)劃、協(xié)調(diào)執(zhí)行任務(wù)。數(shù)據(jù)查詢分布在各個(gè)Impala節(jié)點(diǎn)上，這些節(jié)點(diǎn)作為worker，并行執(zhí)行查詢。
• HBase和HDFS – 存儲用于查詢的數(shù)據(jù)。

Impala執(zhí)行的查詢有以下幾個(gè)步驟：

客戶端通過ODBC、JDBC、或者Impala shell向Impala集群中的任意節(jié)點(diǎn)發(fā)送SQL語句，這個(gè)節(jié)點(diǎn)的impalad實(shí)例作為這個(gè)查詢的協(xié)調(diào)器（coordinator）。

Impala解析和分析這個(gè)查詢語句來決定集群中的哪個(gè)impalad實(shí)例來執(zhí)行某個(gè)任務(wù)。

HDFS和HBase給本地的impalad實(shí)例提供數(shù)據(jù)訪問。

各個(gè)impalad向協(xié)調(diào)器impalad返回?cái)?shù)據(jù)，然后由協(xié)調(diào)器impalad向client發(fā)送結(jié)果集。

Impala為什么比Hive速度快

Impala自稱數(shù)據(jù)查詢效率比Hive快幾倍甚至數(shù)十倍，它之所以這么快的原因大致有以下幾點(diǎn)：

• 真正的MPP查詢引擎。
• 使用C++開發(fā)而不是Java，降低運(yùn)行負(fù)荷。
• 運(yùn)行時(shí)代碼生成（LLVM IR），提高效率。

• 全新的執(zhí)行引擎（不是Mapreduce）。
• 在執(zhí)行SQL語句的時(shí)候，Impala不會把中間數(shù)據(jù)寫入到磁盤，而是在內(nèi)存中完成了所有的處理。
• 使用Impala的時(shí)候，查詢?nèi)蝿?wù)會馬上執(zhí)行而不是生產(chǎn)Mapreduce任務(wù)，這會節(jié)約大量的初始化時(shí)間。
• Impala查詢計(jì)劃解析器使用更智能的算法在多節(jié)點(diǎn)上分布式執(zhí)行各個(gè)查詢步驟，同時(shí)避免了sorting和shuffle這兩個(gè)非常耗時(shí)的階段，這兩個(gè)階段往往是不需要的。
• Impala擁有HDFS上面各個(gè)data block的信息，當(dāng)它處理查詢的時(shí)候能夠在各個(gè)datanode上面更均衡的分發(fā)查詢。
• 另外一個(gè)關(guān)鍵原因是，Impala為每個(gè)查詢產(chǎn)生匯編級的代碼，當(dāng)Impala在本地內(nèi)存中運(yùn)行的時(shí)候，這些匯編代碼執(zhí)行效率比其它任何代碼框架都更快，因?yàn)榇a框架會增加額外的延遲。

Impala核心組件

Impala Daemon

Impala的核心組件是運(yùn)行在各個(gè)節(jié)點(diǎn)上面的impalad這個(gè)守護(hù)進(jìn)程（Impala daemon），它負(fù)責(zé)讀寫數(shù)據(jù)文件，接收從impala-shell、Hue、JDBC、ODBC等接口發(fā)送的查詢語句，并行化查詢語句和分發(fā)工作任務(wù)到Impala集群的各個(gè)節(jié)點(diǎn)上，同時(shí)負(fù)責(zé)將本地計(jì)算好的查詢結(jié)果發(fā)送給協(xié)調(diào)器節(jié)點(diǎn)（coordinator node）。

你可以向運(yùn)行在任意節(jié)點(diǎn)的Impala daemon提交查詢，這個(gè)節(jié)點(diǎn)將會作為這個(gè)查詢的協(xié)調(diào)器（coordinator node），其他節(jié)點(diǎn)將會傳輸部分結(jié)果集給這個(gè)協(xié)調(diào)器節(jié)點(diǎn)。由這個(gè)協(xié)調(diào)器節(jié)點(diǎn)構(gòu)建最終的結(jié)果集。在做實(shí)驗(yàn)或者測試的時(shí)候?yàn)榱朔奖?#xff0c;我們往往連接到同一個(gè)Impala daemon來執(zhí)行查詢，但是在生產(chǎn)環(huán)境運(yùn)行產(chǎn)品級的應(yīng)用時(shí)，我們應(yīng)該循環(huán)（按順序）的在不同節(jié)點(diǎn)上面提交查詢，這樣才能使得集群的負(fù)載達(dá)到均衡。

Impala daemon不間斷的跟statestore進(jìn)行通信交流，從而確認(rèn)哪個(gè)節(jié)點(diǎn)是健康的能接收新的工作任務(wù)。它同時(shí)接收catalogd daemon（從Impala 1.2之后支持）傳來的廣播消息來更新元數(shù)據(jù)信息，當(dāng)集群中的任意節(jié)點(diǎn)create、alter、drop任意對象、或者執(zhí)行INSERT、LOAD DATA的時(shí)候觸發(fā)廣播消息。

Impala Statestore

Impala Statestore檢查集群各個(gè)節(jié)點(diǎn)上Impala daemon的健康狀態(tài)，同時(shí)不間斷地將結(jié)果反饋給各個(gè)Impala daemon。這個(gè)服務(wù)的物理進(jìn)程名稱是statestored，在整個(gè)集群中我們僅需要一個(gè)這樣的進(jìn)程即可。如果某個(gè)Impala節(jié)點(diǎn)由于硬件錯(cuò)誤、軟件錯(cuò)誤或者其他原因?qū)е码x線，statestore就會通知其他的節(jié)點(diǎn)，避免其他節(jié)點(diǎn)再向這個(gè)離線的節(jié)點(diǎn)發(fā)送請求。

由于statestore是當(dāng)集群節(jié)點(diǎn)有問題的時(shí)候起通知作用，所以它對Impala集群并不是有關(guān)鍵影響的。如果statestore沒有運(yùn)行或者運(yùn)行失敗，其他節(jié)點(diǎn)和分布式任務(wù)會照常運(yùn)行，只是說當(dāng)節(jié)點(diǎn)掉線的時(shí)候集群會變得沒那么健壯。當(dāng)statestore恢復(fù)正常運(yùn)行時(shí)，它就又開始與其他節(jié)點(diǎn)通信并進(jìn)行監(jiān)控。

Impala Catalog

Imppalla catalog服務(wù)將SQL語句做出的元數(shù)據(jù)變化通知給集群的各個(gè)節(jié)點(diǎn)，catalog服務(wù)的物理進(jìn)程名稱是catalogd，在整個(gè)集群中僅需要一個(gè)這樣的進(jìn)程。由于它的請求會跟statestore daemon交互，所以最好讓statestored和catalogd這兩個(gè)進(jìn)程在同一節(jié)點(diǎn)上。

Impala 1.2中加入的catalog服務(wù)減少了REFRESH和INVALIDATE METADATA語句的使用。在之前的版本中，當(dāng)在某個(gè)節(jié)點(diǎn)上執(zhí)行了CREATE DATABASE、DROP DATABASE、CREATE TABLE、ALTER TABLE、或者DROP TABLE語句之后，需要在其它的各個(gè)節(jié)點(diǎn)上執(zhí)行命令I(lǐng)NVALIDATE METADATA來確保元數(shù)據(jù)信息的更新。同樣的，當(dāng)你在某個(gè)節(jié)點(diǎn)上執(zhí)行了INSERT語句，在其它節(jié)點(diǎn)上執(zhí)行查詢時(shí)就得先執(zhí)行REFRESH table_name這個(gè)操作，這樣才能識別到新增的數(shù)據(jù)文件。需要注意的是，通過Impala執(zhí)行的操作帶來的元數(shù)據(jù)變化，有了catalog就不需要再執(zhí)行REFRESH和INVALIDATE METADATA，但如果是通過Hive進(jìn)行的建表、加載數(shù)據(jù)，則仍然需要執(zhí)行REFRESH和INVALIDATE METADATA來通知Impala更新元數(shù)據(jù)信息。

Impala與同類工具的性能對比

以下測試環(huán)境以及測試數(shù)據(jù)來自Impala官方博客。

環(huán)境配置

集群環(huán)境

所有的測試都在同一個(gè)集群上面運(yùn)行，保證硬件環(huán)境的一致性。集群有21個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)的配置都一樣：

• 2個(gè)處理器、12核心、Intel Xeon CPU E5-2630L 0 2.00GHz
• 12塊磁盤932GB（一個(gè)磁盤用于操作系統(tǒng)，其余的用于HDFS）
• 384GB內(nèi)存

對比環(huán)境

• Impala 1.3.0
• Hive-on-Tez: The final phase of the 18-month Stinger initiative (aka Hive 0.13)
• Shark 0.9.2: A port of Hive from UC Berkeley AMPLab that is architecturally similar to Hive-on-Tez, but based on Spark instead of Tez. Shark testing was done on a native in-memory dataset (RDD) as well as HDFS.
• Presto 0.60: Facebook’s query engine project

查詢環(huán)境

• 為了確保Hadoop每個(gè)節(jié)點(diǎn)具有代表性的真實(shí)負(fù)載，所有的查詢在20個(gè)節(jié)點(diǎn)上的15TB數(shù)據(jù)集上進(jìn)行。
• 我們針對不同的處理工具統(tǒng)一采用Snappy壓縮，不同的工具選用其性能最佳的數(shù)據(jù)文件格式，Impala用Apache Parquet、Hive-on-Tez用ORC、Presto用RCFile、Shark用ORC。
• 不同的處理工具都使用標(biāo)準(zhǔn)的測試技巧（多重運(yùn)行、調(diào)優(yōu)，等等）。

測試結(jié)果

單用戶場景

Impala on Parquet運(yùn)行效率最高，比其后的Shark 0.9.2平均快了5倍。

多用戶場景

我們同時(shí)測試了單用戶和10個(gè)用戶做對比，測試中Impala更好的體現(xiàn)了其性能優(yōu)勢，比其后的工具快了9.5倍。

吞吐量和硬件使用率

下面的CPU效率解釋了為什么Impala能夠做到低延遲和高吞吐量，絕大多數(shù)的性能和并發(fā)性都在于查詢引擎自身的CPU利用效率。

Impala調(diào)優(yōu)

表和字段的統(tǒng)計(jì)分析

當(dāng)數(shù)據(jù)表的統(tǒng)計(jì)信息可用的時(shí)候，Impala能夠更好的對查詢進(jìn)行優(yōu)化，通過統(tǒng)計(jì)信息它能更清楚的知道數(shù)據(jù)的分布情況，并有效地并行處理和分發(fā)工作任務(wù)。

在之前，Impala依賴于Hive的機(jī)制產(chǎn)生mapreduce任務(wù)來收集統(tǒng)計(jì)信息。為了更好的用戶體驗(yàn)和可靠性，Impala在1.2.2及其之后的版本中實(shí)現(xiàn)了自己的COMPUTE STATS語法來進(jìn)行信息統(tǒng)計(jì)，結(jié)合使用SHOW TABLE STATS和SHOW COLUMN STATS這兩種語法。

用Impala統(tǒng)計(jì)表和字段信息的例子如下：

[localhost:21000] > show table stats store; +-------+--------+--------+--------+ | #Rows | #Files | Size?? | Format | +-------+--------+--------+--------+ | -1??? | 1????? | 3.08KB | TEXT?? | +-------+--------+--------+--------+ Returned 1 row(s) in 0.03s [localhost:21000] > show column stats store; +--------------------+-----------+------------------+--------+----------+----------+ | Column???????????? | Type????? | #Distinct Values | #Nulls | Max Size | Avg Size | +--------------------+-----------+------------------+--------+----------+----------+ | s_store_sk???????? | INT?????? | -1?????????????? | -1? ???| 4??????? | 4??????? | | s_store_id???????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_rec_start_date?? | TIMESTAMP | -1?????????????? | -1???? | 16?????? | 16?????? | | s_rec_end_date???? | TIMESTAMP | -1?????????????? | -1?? ??| 16?????? | 16?????? | | s_closed_date_sk?? | INT?????? | -1?????????????? | -1???? | 4??????? | 4??????? | | s_store_name?????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_number_employees | INT?????? | -1?????????????? | -1??? ?| 4??????? | 4??????? | | s_floor_space????? | INT?????? | -1?????????????? | -1???? | 4??????? | 4??????? | | s_hours??????????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_manager????????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_market_id??????? | INT?????? | -1?????????????? | -1???? | 4??????? | 4??????? | | s_geography_class? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_market_desc????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_market_manager?? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_division_id????? | INT?????? | -1?????????????? | -1???? | 4??????? | 4??????? | | s_division_name??? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_company_id?????? | INT?????? | -1?????????????? | -1???? | 4??????? | 4??????? | | s_company_name???? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_street_number??? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_street_name????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_street_type????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_suite_number???? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_city???????????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_county?????????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_state??????????? | STRING??? | -1?????????????? | -1???? | -1 ??????| -1?????? | | s_zip????????????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_country????????? | STRING??? | -1?????????????? | -1???? | -1?????? | -1?????? | | s_gmt_offset?????? | FLOAT???? | -1?????????????? | -1???? | 4?? ?????| 4??????? | | s_tax_precentage?? | FLOAT???? | -1?????????????? | -1???? | 4??????? | 4??????? | +--------------------+-----------+------------------+--------+----------+----------+ Returned 29 row(s) in 0.04s

[localhost:21000] > compute stats store;

+------------------------------------------+

| summary????????????????????????????????? |

+------------------------------------------+

| Updated 1 partition(s) and 29 column(s). |

+------------------------------------------+

Returned 1 row(s) in 1.88s

[localhost:21000] > show table stats store;

+-------+--------+--------+--------+

| #Rows | #Files | Size?? | Format |

+-------+--------+--------+--------+

| 12??? | 1????? | 3.08KB | TEXT?? |

+-------+--------+--------+--------+

Returned 1 row(s) in 0.02s

[localhost:21000] > show column stats store;

+--------------------+-----------+------------------+--------+----------+----------------+

| Column???????????? | Type????? | #Distinct Values | #Nulls | Max Size | Avg Size????????? |

+--------------------+-----------+------------------+--------+----------+----------------+

| s_store_sk???????? | INT?????? | 12?????????????? | -1???? | 4??????? | 4???????????????? |

| s_store_id???????? | STRING??? | 6??????????????? | -1???? | 16????? ?| 16??????????????? |

| s_rec_start_date?? | TIMESTAMP | 4??????????????? | -1???? | 16?????? | 16??????????????? |

| s_rec_end_date???? | TIMESTAMP | 3??????????????? | -1???? | 16?????? | 16??????????????? |

| s_closed_date_sk?? | INT?????? | 3???????? ???????| -1???? | 4??????? | 4???????????????? |

| s_store_name?????? | STRING??? | 8??????????????? | -1???? | 5??????? | 4.25????????????? |

| s_number_employees | INT?????? | 9??????????????? | -1???? | 4??????? | 4???????????????? |

| s_floor_space??? ??| INT?????? | 10?????????????? | -1???? | 4??????? | 4???????????????? |

| s_hours??????????? | STRING??? | 2??????????????? | -1?? ??| 8??????? | 7.08330011367797 |

| s_manager????????? | STRING??? | 7??????????????? | -1???? | 15?????? | 12??????????? ????|

| s_market_id??????? | INT?????? | 7??????????????? | -1???? | 4??????? | 4???????????????? |

| s_geography_class? | STRING??? | 1??????????????? | -1???? | 7??????? | 7???????????????? |

| s_market_desc????? | STRING??? | 10?????????????? | -1???? | 94?????? | 55.5????????????? |

| s_market_manager?? | STRING??? | 7??????????????? | -1???? | 16?????? | 14??????????????? |

| s_division_id????? | INT?????? | 1??????????????? | -1???? | 4??????? | 4???????????????? |

| s_division_name??? | STRING??? | 1??????????????? | -1???? | 7??????? | 7???????????????? |

| s_company_id?????? | INT?????? | 1??????????????? | -1???? | 4??????? | 4???????????????? |

| s_company_name???? | STRING??? | 1??????????????? | -1???? | 7??????? | 7???????????????? |

| s_street_number??? | STRING??? | 9??????????????? | -1?? ??| 3??????? | 2.83330011367797 |

| s_street_name????? | STRING??? | 12?????????????? | -1?? ??| 11?????? | 6.58330011367797 |

| s_street_type????? | STRING??? | 8??????????????? | -1?? ??| 9??????? | 4.83330011367797 |

| s_suite_number???? | STRING??? | 11?????????????? | -1???? | 9??????? | 8.25????????????? |

| s_city???????????? | STRING??? | 2??????????????? | -1???? | 8??????? | 6.5?????????????? |

| s_county?????????? | STRING??? | 1??????????????? | -1???? | 17?????? | 17??????????????? |

| s_state??????????? | STRING??? | 1??????????????? | -1???? | 2??????? | 2???????????????? |

| s_zip????????????? | STRING??? | 2??????????????? | -1???? | 5??????? | 5???????????????? |

| s_country????????? | STRING??? | 1??????????????? | -1???? | 13?????? | 13??????????????? |

| s_gmt_offset?????? | FLOAT???? | 1??????????????? | -1???? | 4??????? | 4???????????????? |

| s_tax_precentage?? | FLOAT???? | 5??????????????? | -1???? | 4??????? | 4???????????????? |

+--------------------+-----------+------------------+--------+----------+----------------

Returned 29 row(s) in 0.04s?

啟用block location跟蹤

當(dāng)在Impala上執(zhí)行查詢的時(shí)候，會多個(gè)datanode上分布式地讀取block數(shù)據(jù)，如果Impala擁有更多的block信息，將會更高效的獲取數(shù)據(jù)并處理。可以通過以下步驟來啟用block location跟蹤：

修改hdfs-site.xml文件添加以下內(nèi)容： <property><name>dfs.datanode.hdfs-blocks-metadata.enabled</name><value>true</value> </property>

拷貝Hadoop集群的hdfs-site.xml和core-site.xml文件到各個(gè)Impala節(jié)點(diǎn)的配置目錄/etc/impala/conf中。

重啟Hadoop集群中的所有datanode。

啟用native checksumming

對大量數(shù)據(jù)計(jì)算校驗(yàn)和（checksum）會帶來巨大的時(shí)間損耗，因此用本地庫（native library）來執(zhí)行校驗(yàn)和會帶來性能上的提升。在Impala中可以采用以下方式來啟用本地校驗(yàn)：

• 如果Impala是用Cloudera Manager部署的，默認(rèn)已經(jīng)開啟了本地校驗(yàn)。
• 如果是手動安裝的Impala，你必須手動安裝Hadoop本地庫libhadoop.so，如果這個(gè)本地庫找不到，你會在Impala日志中看到這樣的信息："Unable to load native-hadoop library for your platform... using built-in-java classes where applicable"。

允許Impala執(zhí)行short-circuit read

Short-circuit read意味著會從datanode的本地文件系統(tǒng)直接讀取數(shù)據(jù)，而不用首先與datanode進(jìn)行通信，這肯定會提高性能。你必須使用Cloudera CDH 4.2或更高的版本來達(dá)到快速的short-circuit讀取數(shù)據(jù)。可以通過以下步驟來進(jìn)行設(shè)置：

修改各個(gè)Impala節(jié)點(diǎn)上的hdfs-site.xml文件： <property><name>dfs.client.read.shortcircuit</name><value>true</value> </property> <property><name>dfs.domain.socket.path</name><value>/var/run/hadoop-hdfs/dn._PORT</value> </property> <property><name>dfs.client.file-block-storage-locations.timeout</name><value>3000</value> </property>

確保/var/run/hadoop-hdfs/目錄對用戶是可寫入的。

拷貝Hadoop集群的hdfs-site.xml和core-site.xml文件到各個(gè)Impala節(jié)點(diǎn)的配置目錄/etc/impala/conf中。

重啟Hadoop集群中的所有datanode。

增加更多的Impala節(jié)點(diǎn)

事實(shí)證明更多的Impala節(jié)點(diǎn)會顯著地提高性能，這跟Hadoop使用更多的datanode提高性能是一樣的。擁有更多的節(jié)點(diǎn)會讓數(shù)據(jù)分散到更多的節(jié)點(diǎn)上，在執(zhí)行查詢的時(shí)候能夠分發(fā)更多的任務(wù)并行執(zhí)行，從而提高整體執(zhí)行性能。

執(zhí)行查詢時(shí)優(yōu)化內(nèi)存的使用

在啟動Impala守護(hù)進(jìn)程的時(shí)候可以使用-mem_limits參數(shù)來限制內(nèi)存消耗，這個(gè)參數(shù)只對查詢（query）進(jìn)行內(nèi)存限制。

查詢的執(zhí)行依賴于內(nèi)存

如果數(shù)據(jù)集太大以至于超出了機(jī)器的可用內(nèi)存，這個(gè)查詢將會失敗。Impala對內(nèi)存的使用并不直接根據(jù)數(shù)據(jù)集的大小決定，它是根據(jù)查詢的類型而變化的。聚合查詢需要的內(nèi)存跟group之后的數(shù)據(jù)量一樣，連接查詢（join）需要的內(nèi)存量等價(jià)于除開最大表之外的所有表的總大小。

采用資源隔離

如果你使用的是Cloudera Manager，可以使用Cloudera Manager的設(shè)備控制器（cgroups）機(jī)制來實(shí)現(xiàn)資源隔離（resource isolation）。更多信息請閱讀Cloudera Manager文檔中對resource isolation的描述。

?

----end

轉(zhuǎn)載于:https://www.cnblogs.com/jamesf/p/4751468.html

總結(jié)

以上是生活随笔為你收集整理的Impala介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。