5. 根据执行计划进行性能优化及最佳实践
5.1. 使用解释计划进行性能调整
解释语句为您提供了一个查询将执行的逻辑步骤的概要，例如，如何将工作分配在节点之间，以及如何将中间结果合并到生成最终结果集。在实际运行查询之前，您可以看到这些详细信息。您可以使用此信息来检查查询将不会在一些非常意想不到的或低效的方式操作。
[impalad-host:21000]> explain select count(*) from customer_address;
+----------------------------------------------------------+
| ExplainString|
+----------------------------------------------------------+
| EstimatedPer-Host Requirements: Memory=42.00MB VCores=1 |
| |
|03:AGGREGATE [MERGE FINALIZE]|
| | output: sum(count(*)) |
| | |
|02:EXCHANGE [PARTITION=UNPARTITIONED] |
| | |
|01:AGGREGATE |
| | output: count(*) |
| | |
| 00:SCANHDFS [default.customer_address] |
| partitions=1/1 size=5.25MB|
+----------------------------------------------------------+
从下到上阅读解释计划：
该计划的最后一部分显示了低级别的细节，如预期的数据量，将被读取，在那里你可以判断你的分区策略的有效性，并估计将需要多长时间扫描一个表的基础上总的数据大小和大小的集群。
然后你看到的操作，将每个节点执行并行的impala。
在更高的层次，您可以看到当中间结果集合并和从一个节点发送到另一个节点时，数据流如何。
看到关于explain_level查询选项的详细信息explain_level查询选项，它允许您自定义显示解释计划取决于你正在做的高级或低级调谐多少细节，处理查询的逻辑或物理方面。
解释计划还打印在使用性能调整的查询配置文件中所描述的查询配置文件的开始处，以便于检查并排的查询的逻辑和物理方面的便利性。
在解释输出的explain_level查询选项控制显示细节的数量。你通常会增加这个设置从正常的冗长（或从0到1）时，仔细检查表和列数据时性能调优，或当估计查询资源使用与CDH 5资源管理功能的结合。
1.2. 使用性能调整的总结报告
在impala-shell解释器摘要命令给你一个容易消化的时间概述用于查询执行的不同阶段。像解释计划一样，很容易看到潜在的性能瓶颈。像配置文件输出，它是可用的查询后运行，所以显示实际的时间数。
摘要报告还打印在使用性能调整的查询配置文件中所描述的查询概要报告的开始处，以便于检查并排的查询的高级和低级方面的问题。
例如，这里是一个包含聚合函数的查询，在一个单一的节点上的虚拟机。的查询和他们的时间的不同阶段表现（卷起所有节点），以及估计值与实际值用于规划查询。在这种情况下，该avg()功能为每个节点上的数据的一个子集计算（01级）然后汇总结果，从所有节点结合在年底（03期）。你可以看到哪个阶段花了最多的时间，以及是否有任何估计值与实际的数据分布有明显的不同。（在检查的时间值，可以考虑后缀如我们毫秒、微秒和毫秒而不是寻找最大的数字。）
[localhost:21000] > select avg(ss_sales_price) from store_sales wheress_coupon_amt = 0;
+---------------------+
|avg(ss_sales_price) |
+---------------------+
|37.80770926328327 |
+---------------------+
[localhost:21000]> summary;
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
|Operator | #Hosts | Avg Time | MaxTime | #Rows | Est. #Rows | Peak Mem | Est. Peak Mem | Detail |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
|03:AGGREGATE | 1 | 1.03ms | 1.03ms | 1 | 1 | 48.00 KB | -1 B | MERGE FINALIZE |
|02:EXCHANGE | 1 | 0ns | 0ns | 1 | 1 | 0 B | -1 B | UNPARTITIONED |
|01:AGGREGATE | 1 | 30.79ms | 30.79ms | 1 | 1 | 80.00 KB | 10.00 MB | |
| 00:SCANHDFS | 1 | 5.45s | 5.45s | 2.21M | -1 | 64.05 MB |432.00 MB | tpc.store_sales |
+--------------+--------+----------+----------+-------+------------+----------+---------------+-----------------+
请注意查询最长的初始相位的测量单位是秒（s），而后期工作在较小的中间结果进行测量毫秒（ms）甚至纳秒（ns）。
这里有一个例子，从一个更复杂的查询，因为它会出现在配置文件输出：
Operator#Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail
------------------------------------------------------------------------------------------------------------------------
09:MERGING-EXCHANGE 1 79.738us 79.738us 5 5 0 -1.00 B UNPARTITIONED
05:TOP-N 3 84.693us 88.810us 5 5 12.00 KB120.00 B
04:AGGREGATE 3 5.263ms 6.432ms 5 5 44.00 KB10.00 MB MERGE FINALIZE
08:AGGREGATE 3 16.659ms 27.444ms 52.52K 600.12K 3.20 MB15.11 MB MERGE
07:EXCHANGE 3 2.644ms 5.1ms 52.52K 600.12K 00 HASH(o_orderpriority)
03:AGGREGATE 3 342.913ms 966.291ms 52.52K 600.12K 10.80 MB15.11 MB
02:HASHJOIN 3 2s165ms 2s171ms 144.87K 600.12K 13.63 MB 941.01 KB INNER JOIN, BROADCAST
|--06:EXCHANGE 3 8.296ms 8.692ms 57.22K 15.00K 00 BROADCAST
| 01:SCAN HDFS 2 1s412ms 1s978ms 57.22K 15.00K 24.21 MB 176.00 MB tpch.orders o
00:SCANHDFS 3 8s032ms 8s558ms 3.79M 600.12K 32.29 MB 264.00 MB tpch.lineitem l
5.3. 使用性能调整的查询配置文件
profile语句，在impala-shell解释器，产生一个详细的报告显示低水平的最新查询被执行。不同于使用解释计划进行性能调整的解释计划，此信息仅在查询完成后才可用。它显示物理细节，如读取字节数、最大内存使用量等每个节点的物理细节。您可以使用此信息来确定如果查询是I/O密集型或CPU绑定的，是否有网络条件实施的瓶颈，是否放缓是影响而不是其他的一些节点，并检查推荐配置设置，如短路本地读取效果。
默认情况下，配置文件输出的时间值反映了操作所采取的墙上时钟时间。指示系统的时间或用户的时间值，测量单位是反映在指标的名字，如scannerthreadssystime或scannerthreadsusertime。例如，一个多线程的I / O操作可能会显示一个小的数字墙上的时钟时间，而相应的系统时间是较大的，代表的总和所采取的每一个线程的*处理器时间。或是一个墙时钟的时间可能会更大，因为它计算时间等待时间，而相应的系统和用户的时间数字只测量时间，而操作正在积极使用的处理器周期。
该解释计划也打印在查询简要表报告的开始处，以便于检查并排的查询的逻辑和物理方面的便利性。的explain_level查询选项的解释也控制输出的打印命令的详细资料。
这里是一个查询配置文件的例子，从一个相对简单的查询一个单一的节点的伪分布式集群保持输出相对较短。
[localhost:21000]> profile;
QueryRuntime Profile:
Query(id=6540a03d4bee0691:4963d6269b210ebd):
Summary:
Session ID:ea4a197f1c7bf858:c74e66f72e3a33ba
Session Type: BEESWAX
Start Time: 2013-12-02 17:10:30.263067000
End Time: 2013-12-02 17:10:50.932044000
Query Type: QUERY
Query State: FINISHED
Query Status: OK
Impala Version: impalad version 1.2.1RELEASE (build edb5af1bcad63d410bc5d47cc203df3a880e9324)
User: cloudera
Network Address: 127.0.0.1:49161
Default Db: stats_testing
Sql Statement: select t1.s, t2.s from t1join t2 on (t1.id = t2.parent)
Plan:
----------------
EstimatedPer-Host Requirements: Memory=2.09GB VCores=2
PLANFRAGMENT 0
PARTITION: UNPARTITIONED
4:EXCHANGE
cardinality: unavailable
per-host memory: unavailable
tuple ids: 0 1
PLANFRAGMENT 1
PARTITION: RANDOM
STREAM DATA SINK
EXCHANGE ID: 4
UNPARTITIONED
2:HASH JOIN
| joinop: INNER JOIN (BROADCAST)
| hashpredicates:
| t1.id = t2.parent
| cardinality: unavailable
| per-host memory: 2.00GB
| tuple ids: 0 1
|
|----3:EXCHANGE
| cardinality: unavailable
| per-host memory: 0B
| tuple ids: 1
|
0:SCAN HDFS
table=stats_testing.t1 #partitions=1/1size=33B
table stats: unavailable
column stats: unavailable
cardinality: unavailable
per-host memory: 32.00MB
tuple ids: 0
PLANFRAGMENT 2
PARTITION: RANDOM
STREAM DATA SINK
EXCHANGE ID: 3
UNPARTITIONED
1:SCAN HDFS
table=stats_testing.t2 #partitions=1/1size=960.00KB
table stats: unavailable
column stats: unavailable
cardinality: unavailable
per-host memory: 96.00MB
tuple ids: 1
----------------
Query Timeline: 20s670ms
- Start execution: 2.559ms (2.559ms)
- Planning finished: 23.587ms (21.27ms)
- Rows available: 666.199ms (642.612ms)
- First row fetched: 668.919ms (2.719ms)
- Unregister query: 20s668ms (20s000ms)
ImpalaServer:
- ClientFetchWaitTimer: 19s637ms
- RowMaterializationTimer: 167.121ms
Execution Profile6540a03d4bee0691:4963d6269b210ebd:(Active: 837.815ms, % non-child: 0.00%)
Per Node Peak Memory Usage: impala-1.example.com:22000(7.42MB)
- FinalizationTimer: 0ns
Coordinator Fragment:(Active: 195.198ms, %non-child: 0.00%)
MemoryUsage(500.0ms): 16.00 KB, 7.42 MB,7.33 MB, 7.10 MB, 6.94 MB, 6.71 MB, 6.56 MB, 6.40 MB, 6.17 MB, 6.02 MB, 5.79MB, 5.63 MB, 5.48 MB, 5.25 MB, 5.09 MB, 4.86 MB, 4.71 MB, 4.47 MB, 4.32 MB,4.09 MB, 3.93 MB, 3.78 MB, 3.55 MB, 3.39 MB, 3.16 MB, 3.01 MB, 2.78 MB, 2.62MB, 2.39 MB, 2.24 MB, 2.08 MB, 1.85 MB, 1.70 MB, 1.54 MB, 1.31 MB, 1.16 MB,948.00 KB, 790.00 KB, 553.00 KB, 395.00 KB, 237.00 KB
ThreadUsage(500.0ms): 1
- AverageThreadTokens: 1.00
- PeakMemoryUsage: 7.42 MB
-PrepareTime: 36.144us
- RowsProduced: 98.30K (98304)
- TotalCpuTime: 20s449ms
- TotalNetworkWaitTime: 191.630ms
- TotalStorageWaitTime: 0ns
CodeGen:(Active: 150.679ms, % non-child:77.19%)
- CodegenTime: 0ns
- CompileTime: 139.503ms
- LoadTime: 10.7ms
- ModuleFileSize: 95.27 KB
EXCHANGE_NODE (id=4):(Active: 194.858ms,% non-child: 99.83%)
- BytesReceived: 2.33 MB
- ConvertRowBatchTime: 2.732ms
- DataArrivalWaitTime: 191.118ms
- DeserializeRowBatchTimer: 14.943ms
- FirstBatchArrivalWaitTime: 191.117ms
- PeakMemoryUsage: 7.41 MB
- RowsReturned: 98.30K (98304)
- RowsReturnedRate: 504.49 K/sec
- SendersBlockedTimer: 0ns
- SendersBlockedTotalTimer(*): 0ns
Averaged Fragment 1:(Active: 442.360ms, %non-child: 0.00%)
split sizes: min: 33.00 B, max: 33.00 B, avg: 33.00 B,stddev: 0.00
completion times: min:443.720ms max:443.720ms mean: 443.720ms stddev:0ns
execution rates: min:74.00 B/sec max:74.00 B/sec mean:74.00 B/sec stddev:0.00 /sec
num instances: 1
- AverageThreadTokens: 1.00
- PeakMemoryUsage: 6.06 MB
- PrepareTime: 7.291ms
- RowsProduced: 98.30K (98304)
- TotalCpuTime: 784.259ms
- TotalNetworkWaitTime: 388.818ms
- TotalStorageWaitTime: 3.934ms
CodeGen:(Active: 312.862ms, % non-child:70.73%)
- CodegenTime: 2.669ms
- CompileTime: 302.467ms
- LoadTime: 9.231ms
- ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=4):(Active:80.63ms, % non-child: 18.10%)
- BytesSent: 2.33 MB
- NetworkThroughput(*): 35.89 MB/sec
- OverallThroughput: 29.06 MB/sec
- PeakMemoryUsage: 5.33 KB
- SerializeBatchTime: 26.487ms
- ThriftTransmitTime(*): 64.814ms
- UncompressedRowBatchSize: 6.66 MB
HASH_JOIN_NODE (id=2):(Active: 362.25ms,% non-child: 3.92%)
- BuildBuckets: 1.02K (1024)
- BuildRows: 98.30K (98304)
- BuildTime: 12.622ms
- LoadFactor: 0.00
- PeakMemoryUsage: 6.02 MB
- ProbeRows: 3
- ProbeTime: 3.579ms
- RowsReturned: 98.30K (98304)
- RowsReturnedRate: 271.54 K/sec
EXCHANGE_NODE (id=3):(Active:344.680ms, % non-child: 77.92%)
- BytesReceived: 1.15 MB
- ConvertRowBatchTime: 2.792ms
- DataArrivalWaitTime: 339.936ms
- DeserializeRowBatchTimer: 9.910ms
- FirstBatchArrivalWaitTime:199.474ms
- PeakMemoryUsage: 156.00 KB
- RowsReturned: 98.30K (98304)
- RowsReturnedRate: 285.20 K/sec
- SendersBlockedTimer: 0ns
- SendersBlockedTotalTimer(*): 0ns
HDFS_SCAN_NODE (id=0):(Active: 13.616us,% non-child: 0.00%)
- AverageHdfsReadThreadConcurrency:0.00
- AverageScannerThreadConcurrency:0.00
- BytesRead: 33.00 B
- BytesReadLocal: 33.00 B
- BytesReadShortCircuit: 33.00 B
- NumDisksAccessed: 1
- NumScannerThreadsStarted: 1
- PeakMemoryUsage: 46.00 KB
- PerReadThreadRawHdfsThroughput:287.52 KB/sec
- RowsRead: 3
- RowsReturned: 3
- RowsReturnedRate: 220.33 K/sec
- ScanRangesComplete: 1
-ScannerThreadsInvoluntaryContextSwitches: 26
- ScannerThreadsTotalWallClockTime:55.199ms
- DelimiterParseTime: 2.463us
- MaterializeTupleTime(*): 1.226us
- ScannerThreadsSysTime: 0ns
- ScannerThreadsUserTime: 42.993ms
-ScannerThreadsVoluntaryContextSwitches: 1
- TotalRawHdfsReadTime(*): 112.86us
- TotalReadThroughput: 0.00 /sec
Averaged Fragment 2:(Active: 190.120ms, %non-child: 0.00%)
split sizes: min: 960.00 KB, max: 960.00 KB, avg: 960.00KB, stddev: 0.00
completion times: min:191.736ms max:191.736ms mean: 191.736ms stddev:0ns
execution rates: min:4.89 MB/sec max:4.89 MB/sec mean:4.89 MB/sec stddev:0.00 /sec
num instances: 1
- AverageThreadTokens: 0.00
- PeakMemoryUsage: 906.33 KB
- PrepareTime: 3.67ms
- RowsProduced: 98.30K (98304)
- TotalCpuTime: 403.351ms
- TotalNetworkWaitTime: 34.999ms
- TotalStorageWaitTime: 108.675ms
CodeGen:(Active: 162.57ms, % non-child:85.24%)
- CodegenTime: 3.133ms
- CompileTime: 148.316ms
- LoadTime: 12.317ms
- ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=3):(Active:70.620ms, % non-child: 37.14%)
- BytesSent: 1.15 MB
- NetworkThroughput(*): 23.30 MB/sec
- OverallThroughput: 16.23 MB/sec
- PeakMemoryUsage: 5.33 KB
- SerializeBatchTime: 22.69ms
- ThriftTransmitTime(*): 49.178ms
- UncompressedRowBatchSize: 3.28 MB
HDFS_SCAN_NODE (id=1):(Active: 118.839ms,% non-child: 62.51%)
- AverageHdfsReadThreadConcurrency:0.00
- AverageScannerThreadConcurrency:0.00
- BytesRead: 960.00 KB
- BytesReadLocal: 960.00 KB
- BytesReadShortCircuit: 960.00 KB
- NumDisksAccessed: 1
- NumScannerThreadsStarted: 1
- PeakMemoryUsage: 869.00 KB
- PerReadThreadRawHdfsThroughput:130.21 MB/sec
- RowsRead: 98.30K (98304)
- RowsReturned: 98.30K (98304)
- RowsReturnedRate: 827.20 K/sec
- ScanRangesComplete: 15
-ScannerThreadsInvoluntaryContextSwitches: 34
- ScannerThreadsTotalWallClockTime:189.774ms
- DelimiterParseTime: 15.703ms
- MaterializeTupleTime(*): 3.419ms
- ScannerThreadsSysTime: 1.999ms
- ScannerThreadsUserTime: 44.993ms
-ScannerThreadsVoluntaryContextSwitches: 118
- TotalRawHdfsReadTime(*): 7.199ms
- TotalReadThroughput: 0.00 /sec
Fragment 1:
Instance6540a03d4bee0691:4963d6269b210ebf (host=impala-1.example.com:22000):(Active:442.360ms, % non-child: 0.00%)
Hdfs split stats (<volumeid>:<# splits>/<split lengths>): 0:1/33.00 B
MemoryUsage(500.0ms): 69.33 KB
ThreadUsage(500.0ms): 1
- AverageThreadTokens: 1.00
- PeakMemoryUsage: 6.06 MB
- PrepareTime: 7.291ms
- RowsProduced: 98.30K (98304)
- TotalCpuTime: 784.259ms
- TotalNetworkWaitTime: 388.818ms
- TotalStorageWaitTime: 3.934ms
CodeGen:(Active: 312.862ms, %non-child: 70.73%)
- CodegenTime: 2.669ms
- CompileTime: 302.467ms
- LoadTime: 9.231ms
- ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=4):(Active:80.63ms, % non-child: 18.10%)
- BytesSent: 2.33 MB
- NetworkThroughput(*): 35.89 MB/sec
- OverallThroughput: 29.06 MB/sec
- PeakMemoryUsage: 5.33 KB
- SerializeBatchTime: 26.487ms
- ThriftTransmitTime(*): 64.814ms
- UncompressedRowBatchSize: 6.66 MB
HASH_JOIN_NODE (id=2):(Active:362.25ms, % non-child: 3.92%)
ExecOption: Build Side Codegen Enabled,Probe Side Codegen Enabled, Hash Table Built Asynchronously
- BuildBuckets: 1.02K (1024)
- BuildRows: 98.30K (98304)
- BuildTime: 12.622ms
- LoadFactor: 0.00
- PeakMemoryUsage: 6.02 MB
- ProbeRows: 3
- ProbeTime: 3.579ms
- RowsReturned: 98.30K (98304)
- RowsReturnedRate: 271.54 K/sec
EXCHANGE_NODE (id=3):(Active:344.680ms, % non-child: 77.92%)
- BytesReceived: 1.15 MB
- ConvertRowBatchTime: 2.792ms
- DataArrivalWaitTime: 339.936ms
- DeserializeRowBatchTimer:9.910ms
- FirstBatchArrivalWaitTime:199.474ms
- PeakMemoryUsage: 156.00 KB
- RowsReturned: 98.30K (98304)
- RowsReturnedRate: 285.20 K/sec
- SendersBlockedTimer: 0ns
- SendersBlockedTotalTimer(*): 0ns
HDFS_SCAN_NODE (id=0):(Active:13.616us, % non-child: 0.00%)
Hdfs split stats (<volumeid>:<# splits>/<split lengths>): 0:1/33.00 B
Hdfs Read Thread Concurrency Bucket:0:0% 1:0%
File Formats: TEXT/NONE:1
ExecOption: Codegen enabled: 1 out of1
- AverageHdfsReadThreadConcurrency:0.00
- AverageScannerThreadConcurrency: 0.00
- BytesRead: 33.00 B
- BytesReadLocal: 33.00 B
- BytesReadShortCircuit: 33.00 B
- NumDisksAccessed: 1
- NumScannerThreadsStarted: 1
- PeakMemoryUsage: 46.00 KB
- PerReadThreadRawHdfsThroughput:287.52 KB/sec
- RowsRead: 3
- RowsReturned: 3
- RowsReturnedRate: 220.33 K/sec
- ScanRangesComplete: 1
-ScannerThreadsInvoluntaryContextSwitches: 26
- ScannerThreadsTotalWallClockTime:55.199ms
- DelimiterParseTime: 2.463us
- MaterializeTupleTime(*): 1.226us
- ScannerThreadsSysTime: 0ns
- ScannerThreadsUserTime: 42.993ms
-ScannerThreadsVoluntaryContextSwitches: 1
- TotalRawHdfsReadTime(*): 112.86us
- TotalReadThroughput: 0.00 /sec
Fragment 2:
Instance6540a03d4bee0691:4963d6269b210ec0 (host=impala-1.example.com:22000):(Active: 190.120ms,% non-child: 0.00%)
Hdfs split stats (<volumeid>:<# splits>/<split lengths>): 0:15/960.00 KB
- AverageThreadTokens: 0.00
- PeakMemoryUsage: 906.33 KB
- PrepareTime: 3.67ms
- RowsProduced: 98.30K (98304)
- TotalCpuTime: 403.351ms
- TotalNetworkWaitTime: 34.999ms
- TotalStorageWaitTime: 108.675ms
CodeGen:(Active: 162.57ms, % non-child:85.24%)
- CodegenTime: 3.133ms
- CompileTime: 148.316ms
- LoadTime: 12.317ms
- ModuleFileSize: 95.27 KB
DataStreamSender (dst_id=3):(Active:70.620ms, % non-child: 37.14%)
- BytesSent: 1.15 MB
- NetworkThroughput(*): 23.30 MB/sec
- OverallThroughput: 16.23 MB/sec
- PeakMemoryUsage: 5.33 KB
- SerializeBatchTime: 22.69ms
- ThriftTransmitTime(*): 49.178ms
- UncompressedRowBatchSize: 3.28 MB
HDFS_SCAN_NODE (id=1):(Active:118.839ms, % non-child: 62.51%)
Hdfs split stats (<volumeid>:<# splits>/<split lengths>): 0:15/960.00 KB
Hdfs Read Thread Concurrency Bucket:0:0% 1:0%
File Formats: TEXT/NONE:15
ExecOption: Codegen enabled: 15 outof 15
- AverageHdfsReadThreadConcurrency:0.00
- AverageScannerThreadConcurrency:0.00
- BytesRead: 960.00 KB
- BytesReadLocal: 960.00 KB
- BytesReadShortCircuit: 960.00 KB
- NumDisksAccessed: 1
- NumScannerThreadsStarted: 1
- PeakMemoryUsage: 869.00 KB
- PerReadThreadRawHdfsThroughput:130.21 MB/sec
- RowsRead: 98.30K (98304)
- RowsReturned: 98.30K (98304)
- RowsReturnedRate: 827.20 K/sec
- ScanRangesComplete: 15
-ScannerThreadsInvoluntaryContextSwitches: 34
- ScannerThreadsTotalWallClockTime:189.774ms
- DelimiterParseTime: 15.703ms
- MaterializeTupleTime(*): 3.419ms
- ScannerThreadsSysTime: 1.999ms
- ScannerThreadsUserTime: 44.993ms
-ScannerThreadsVoluntaryContextSwitches: 118
- TotalRawHdfsReadTime(*): 7.199ms
- TotalReadThroughput: 0.00 /sec
6. 基准Impala查询最佳实践
Impala，像其他的Hadoop组件，目的是在分布式环境中处理大量的数据，进行性能测试，使用真实的数据和集群配置。使用一个多节点的集群，而不是一个单一的节点；对运行中包含数据而不是数十GB百万兆字节表查询。用Impala的并行处理技术是最适合的工作负载，超出单个服务器的能力。
当您运行查询返回大量的行时，该处理器的时间花费到漂亮的打印输出是实质性的，给一个不准确的测量的实际查询时间。考虑使用-B选项的Impala-shell命令关掉漂亮的打印输出，和任选的-o选项来存储查询结果文件中而不是打印到屏幕上。看到Impala-shell配置选项的详细信息。
7. 控制资源使用最佳实践
有时，平衡原始查询性能对可扩展性需要限制的资源量，如内存或*处理器，使用一个单一的查询或组查询。Impala可以使用多种机制，有助于消除负荷重的同时使用时，产生更快的整体查询时间和资源在Impala查询，MapReduce工作共享，以及其他在CDH集群工作负载：
Impala的接纳控制功能使用快速、分布式机制来阻止超过并行查询或使用的内存量的限制查询。查询是排队的，并执行其他查询完成和资源可用。您可以控制并发限制，并为不同的用户组指定不同的限制，根据不同类别的用户的优先级来划分群集资源。这个功能是新的Impala1.3，并与CDH 4和CDH5。查看接纳控制和查询队列的详细信息。
你可以限制内存Impala的储备量在查询执行过程中通过指定的impalad守护的mem_limit选项。看到修改细节Impala的启动选项。此限制仅适用于内存的查询直接引用；Impala储备额外的内存在启动时，例如举行缓存元数据。
生产部署，Cloudera的建议你实现资源隔离使用机制如C组，您可以使用Cloudera管理。详情在Cloudera管理文档查看静态资源池。
8. impala优化之HDFS缓存最佳实践
8.1. HDFS缓存的impala的概述
CDH 5.1高，Impala可以使用缓存功能更有效的利用内存的HDFS，这样反复查询可以利用数据“钉”在记忆中无论多少数据进行整体。HDFS的缓存功能允许您指定的一个子集的频繁访问的数据被永久的记忆，其余的在多个查询缓存不被驱逐。该技术适用于表或分区是经常访问的，小到可以完全在HDFS存储缓存。例如，您可以指定要在缓存中固定的几个维度表，以加快引用它们的许多不同的联接查询。或在一个分区表，你可能销分区保存数据，从最近一段时间因为数据将查询集中；然后下一组数据时，你可以脱离以前的分区和分区的新数据持销。
因为这辆车的性能特征依赖于HDFS的基础设施，它只适用于Impala表使用HDFS的数据文件。HDFS缓存Impala不适用于HBase表，S3表、Kudu表，或 Isilon 表。
8.2. 设置缓存为HDFS的Impala
使用HDFS的缓存与Impala，首先建立你的CDH聚类特征：
决定把每个主机上的HDFS的缓存内存的多少。请记住，可用的缓存数据的总内存是所有主机上的缓存大小的总和。默认情况下，任何数据块只缓存在一个主机上，虽然您可以通过增加复制因子来缓存一个跨多个主机的块。
问题cacheadmin HDFS命令来设置一个或多个缓冲池，由同一用户为impalad守护进程（通常是Impala）。例如:
hdfscacheadmin -addPool four_gig_pool -owner impala -limit 4000000000
关于HDFS cacheadmin命令的详细信息，参见CDH文档。
一旦HDFS启用高速缓存和一个或多个池，看到使HDFS的Impala表和分区缓存如何选择Impala的数据加载到HDFS的缓存。在Impala的一面，你指定的缓冲池的名字在Impala的DDL语句使HDFS为表或分区缓存HDFScacheadmin命令定义，如创建表…在池或更改表中缓存…集合缓存池。
8.3. 使用HDFS的Impala表和分区缓存
首先通过选择要缓存的表或分区。例如，这些可能是由许多不同的连接查询访问的查找表，或对应于由不同的报告或临时查询分析的最新的时间段的分区。
在你的SQL语句，您指定的逻辑分区如表和分区缓存。Impala将这些请求到HDFS级指令适用于特定的目录和文件。例如，给定一个分区键列的分区表普查，您可以选择缓存所有或部分数据如下：
在Impala 2.2 /CDH5.4高，可选复制条款创建表和修改表允许您指定一个复制因子，缓存相同的数据块上的主机的数量。当Impala过程缓存的数据块，其中缓存复制因子大于1，Impala随机选择一个主机，一个数据块的缓存副本。这种优化避免过多的在同一个主机上的多个处理器的使用，当相同的缓存数据块被处理的倍数。Cloudera建议指定一个值大于或等于HDFS块复制因子。
-- Cachethe entire table (all partitions).
alter tablecensus set cached in 'pool_name';
-- Removethe entire table from the cache.
alter tablecensus set uncached;
-- Cache aportion of the table (a single partition).
-- If thetable is partitioned by multiple columns (such as year, month, day),
-- theALTER TABLE command must specify values for all those columns.
alter tablecensus partition (year=1960) set cached in 'pool_name';
-- Cache the data from one partition on up to 4 hosts, tominimize CPU load on any
-- single host when the same data block is processedmultiple times.
alter table census partition (year=1970)
set cached in 'pool_name'with replication = 4;
-- At eachstage, check the volume of cached data.
-- Forlarge tables or partitions, the background loading might take some time,
-- so youmight have to wait and reissue the statement until all the data
-- hasfinished being loaded into the cache.
show tablestats census;
+-------+-------+--------+------+--------------+--------+
| year | #Rows | #Files | Size | Bytes Cached |Format |
+-------+-------+--------+------+--------------+--------+
| 1900 | -1 | 1 | 11B | NOT CACHED | TEXT |
| 1940 | -1 | 1 | 11B | NOT CACHED | TEXT |
| 1960 | -1 | 1 | 11B | 11B | TEXT |
| 1970 | -1 | 1 | 11B | NOT CACHED | TEXT |
| Total |-1 | 4 | 44B | 11B | |
+-------+-------+--------+------+--------------+--------+
创建表的考虑：
HDFS缓存功能影响Impala创建表的语句如下：
你可以把一个缓存的pool_name”条款和可选的复制= number_of_hosts条款在CREATE TABLE语句自动缓存表的全部内容，包括任何分区的后面添加。是的pool_name池以前设置了HDFS cacheadmin命令。
一旦一个表指定缓存通过HDFS创建表的语句，如果新分区添加后通过修改表…添加分区语句，将这些新分区中的数据自动缓存在同一个池中。
如果你想在从一个大的表格数据的子集进行重复查询，而不是对HDFS缓存指定整个表或特定的分区实用，你可以创建一个新的缓存表是数据的一个子集，利用创建表…缓存在pool_name”选择…哪里....当您完成从这个子集的数据生成报告，删除表和数据文件和缓存在内存中的数据被自动删除。
其他内存考虑：
某些DDL操作，如修改表…设置位置，而底层的HDFS的目录包含缓存文件受阻。你必须uncache文件第一，改变位置之前，删除表，等等。
当请求被固定在内存中时，该进程发生在后台，而不阻塞访问数据，而缓存正在进行中。从磁盘加载数据可能需要一段时间。ImpalaHDFS数据块从内存中读取每一个如果已经把已经，或从磁盘如果没有寄托呢。当文件被添加到一个表或分区的内容进行缓存，impala自动检测这些变化和执行自动刷新一次相关数据缓存。
你可以销每个节点通过缓存机制是受配额是由底层的HDFS服务执行HDFS的数据量。在请求一个内存中的impala表或分区销，检查它的大小不超过此限额。
注：由于HDFS缓存由组合的记忆从集群中所有的数据节点，缓存表或分区可以大于HDFS缓存在任何单一主机的数量。
8.4. 加载和HDFS启用缓存删除数据
当HDFS缓存启用，额外的处理发生在的背景，当你添加或删除数据通过报表，如插入和删除表。
插入或加载数据：
Impala执行表或分区缓存插入或加载数据表时，新的数据文件自动缓存和Impala自动承认事实。
如果你执行插入或加载数据通过hive，一如既往，Impala只承认新的数据文件后刷新在Impala table_name声明。
如果缓存池完全是满的，或已满之前，所有请求的数据可以缓存，Impala的DDL语句将返回一个错误。这是为了避免情况下，只有一些所请求的数据可以被缓存。
当HDFS缓存是一个表或分区启用，新的数据文件缓存时自动添加到HDFS相应的目录，无需刷新语句在Impala的需要。Impala自动执行刷新一次新的数据加载到HDFS的缓存。
丢弃表、分区或缓存池：
HDFS缓存功能的Impala表相互作用并改变表…删除分区语句如下：
当你发出了一个表，完全缓存表，或有一些分区缓存，删除表成功，所有的缓存指令提交表Impala从HDFS系统缓存删除。
同样适用于修改表…删除分区。操作成功，并删除任何缓存指令。
和总是一样，如果删除表是一个内部表，或者删除的分区在其内部表的默认位置，则删除基本的数据文件。如果删除表是一个外部表，或如果丢弃的分区在非默认位置，则单独留下数据文件。
如果你指定的数据文件缓存通过HDFS cacheadmin命令和数据文件在以前的项目描述留守，保持缓存数据文件。Impala只删除提交的Impala通过创建表的缓存指令或ALTER TABLE语句。可以有多个冗余的高速缓存指令属于同一个文件；指令都有独特的身份标识和所有者，使系统可以告诉他们分开。
如果你把一个HDFS的缓存池通过HDFScacheadmin命令，所有的Impala的数据文件保存，只是不再缓存。随后刷新后，显示表的统计报告0字节缓存每个相关的Impala表或分区。
将一个表或分区：
HDFS缓存功能与Impala的交互修改表…设置位置语句如下：
如果您指定了一个表或分区，通过创建表或更改表语句缓存，随后试图通过一个更改表重新定位表或分区…设置位置语句将失败。您必须发出一个更改表…设置被声明为表或分区第一。否则，会失去一些Impala缓存数据文件，没有办法uncache以后。
8.5. HDFS的缓存管理和Impala
HDFS的缓存管理和Impala
这是指导方针和步骤来检查或更改HDFS数据缓存状态的Impala：
HDFScacheadmin命令：
如果你把一个缓冲池与HDFS cacheadmin命令，对相关的数据文件的Impala查询仍然会工作，通过落回从磁盘中读取文件。执行刷新后放在桌上，Impala报道字节缓存0所有相关表和分区数。
你可以使用HDFS cacheadmin得到一个现有的缓存池，该池或详细信息，如下：
hdfscacheadmin -listDirectives #Basic info
Found 122entries
ID POOL REPL EXPIRY PATH
123 testPool 1 never /user/hive/warehouse/tpcds.store_sales
124 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-01-15
125 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-02-01
...
hdfscacheadmin -listDirectives -stats # Moredetails
Found 122entries
ID POOL REPL EXPIRY PATH BYTES_NEEDED BYTES_CACHED FILES_NEEDED FILES_CACHED
123 testPool 1 never /user/hive/warehouse/tpcds.store_sales 0 0 0 0
124 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-01-15 143169 143169 1 1
125 testPool 1 never /user/hive/warehouse/tpcds.store_sales/ss_date=1998-02-01 112447 112447 1 1
...
Impala SHOW 语句：
每个表或分区，显示表数据或显示分区表显示当前缓存的字节缓存功能的HDFS的数量。如果没有为该表或分区放置的缓存指令，则不会缓存结果集显示的结果集。一个值为0，或一个较小的数字比表或分区的整体大小，表明缓存请求已提交，但数据还没有完全加载到内存中。查看显示详细信息。
Cloudera管理：
您可以启用或禁用缓存通过HDFS Cloudera管理，使用配置设置最大内存用于HDFS的缓存服务。这种控制集dfs_datanode_max_locked_memoryHDFS配置参数，它指定缓存大小对HDFS的每个节点的上限。
所有的缓存设置HDFS的其他操作，如文件的缓存，通过命令行完成，无论是Impala的DDL语句或Linux HDFS cacheadmin命令。
Impala的内存限制：
Impala HDFS缓存功能与Impala的内存限制为相互作用如下：
每个HDFS的缓存池的最大大小是指定外部的Impala，通过HDFScacheadmin命令。
所有的内存用于缓存从HDFS impalad守护进程地址空间的分离与不计入的mem_limit启动选项的限制，mem_limit查询选项，或进一步限制通过纱线资源管理或Linux cgroups机制。
因为访问HDFS的缓存数据避免了内存到内存复制操作，包括缓存数据的查询需要在Impala边记忆比缓存数据的等效查询不。除了在一个单一的用户环境中的任何性能优势，减少内存有助于提高高并发工作负载下的可扩展性。
8.6. HDFS的缓存与Impala性能考虑
在 Impala 1.4.0及更高的版本， Impala 支持高效的读取，被固定在内存中缓存数据通过HDFS。 Impala 利用HDFS API和从存储器读取数据而不是从磁盘的数据文件是否在使用Impala DDL语句，或使用命令行机制您指定HDFS路径。
当你检查impala-shell 汇总命令的输出，或期待中的impalad守护进程的报告，你看到多少字节从HDFS缓存读取。例如，这是从查询资料说明，所有的数据读取一个特定的查询阶段来自HDFS的缓存，因为bytesread和bytesreaddatanodecache值是相同的。
HDFS_SCAN_NODE(id=0):(Total: 11s114ms, non-child: 11s114ms, % non-child: 100.00%)
- AverageHdfsReadThreadConcurrency:0.00
- AverageScannerThreadConcurrency:32.75
- BytesRead: 10.47 GB (11240756479)
- BytesReadDataNodeCache: 10.47 GB (11240756479)
- BytesReadLocal: 10.47 GB(11240756479)
- BytesReadShortCircuit: 10.47 GB(11240756479)
- DecompressionTime: 27s572ms
对于涉及较小的数据查询，或在单用户的工作负载，您可能没有注意到一个与或查询的响应时间差异没有HDFS缓存。即使HDFS缓存关闭，对于查询的数据可能仍然在Linux操作系统的缓存。的好处变得更清晰的数据量的增加，特别是随着系统处理更多的并发查询。HDFS的缓存可以提高整体系统的可扩展性。那就是，它可以防止查询性能下降时的工作量超过了Linux操作系统的缓存容量。
由于HDFS的局限，零拷贝读取不支持加密。不建议使用HDFS Cloudera在加密区Impala数据文件缓存。查询在查询执行过程中返回到正常的读取路径，这可能会导致一些性能开销。
选择的考虑：
ImpalaHDFS缓存功能与SELECT语句和查询性能如下：
Impala自动从内存读取任何数据，已被指定为缓存和实际加载到HDFS的缓存。（它可能需要一段时间后，初始请求完全填充缓存的表与大尺寸或多个分区）的加速比来自两个方面：从内存读取，而不是磁盘，并访问数据直接从高速缓存区，而不是从一个内存区复制到另一个。这第二个方面产生进一步的性能改进的标准的操作系统缓存机制，这仍然会导致内存复制缓存数据的内存。
对于少量的数据，查询加速可能不明显，在墙上的时钟时间。的性能可能与HDFS的缓存打开或关闭大致相同，由于最近使用的数据是在Linux操作系统的缓存举行。差异更为明显：
数据卷（对于同时运行的所有查询）超过了超高速缓存的大小。
一个繁忙的集群运行许多并发查询，其中在内存中的复制和整体内存使用的内存减少在查询结果中更大的可扩展性和吞吐量。
因此，要真正在开发环境中练习和基准此功能，您可能需要模拟现实的工作负载和与您的生产环境相匹配的并发查询。
在轻负载模拟系统的工作量的方法之一是冲洗操作系统缓冲区高速缓存（每个DataNode）对相同的表或分区之间的迭代查询：
$ sync
$ echo 1> /proc/sys/vm/drop_caches
Impala的查询利用HDFS的缓存数据无论是否缓存指令是由Impala或外部通过HDFS cacheadmin发出的命令，例如外部表的缓存数据文件可能是由几个不同的Hadoop组件访问。
如果您的查询返回一个大的结果集，则报告查询的时间可能会被打印在屏幕上的结果所需的时间所占。为了衡量标的查询时间，查询的结果集的count()大，不一样的处理只能打印一条直线到屏幕。