tag | 82337125e5296e4ee6fb3b00e2f1b2242a55d883 | |
---|---|---|
tagger | Taras Bobrovytsky <tbobrovytsky@cloudera.com> | Thu Jun 15 18:09:09 2017 -0700 |
object | b8558506957dbf44b8ceb29c8b7382bfd8180e05 |
2.9.0 release
commit | b8558506957dbf44b8ceb29c8b7382bfd8180e05 | [log] [tgz] |
---|---|---|
author | Sailesh Mukil <sailesh@cloudera.com> | Tue May 30 19:50:13 2017 +0000 |
committer | Taras Bobrovytsky <tbobrovytsky@cloudera.com> | Thu Jun 01 17:52:18 2017 -0700 |
tree | 93a1ac914dab21c4e08c630178aa6f8235f2d6f6 | |
parent | 117fc388bff2a754be081eae7667627f84f1b33c [diff] |
IMPALA-5378: Disk IO manager needs to understand ADLS The Disk IO Manager had customized support for S3 and remote HDFS that allows for these to use a separate queue and have a customized number of IO threads. ADLS did not have this support. Based on the code in DiskIoMgr::Init and DiskIoMgr::AssignQueue, IOs for ADLS were previously put in local disk queues. Since local disks are considered rotational unless we can confirm otherwise by looking at the /sys filesystem, this means that THREADS_PER_ROTATIONAL_DISK=1 was being applied as the thread count. This patch adds customized support for ADLS, similar to how it was done for S3. We set 16 threads as the default number of IO threads for ADLS. For smaller clusters, setting a higher number like 64 would work better. We keep the thread count to a lower default of 16 since there is an undocumented concurrency limit for clusters, which is around 500-700 connections, which means we would hurt node level parallelism if we have higher thread level parallelism, for larger clusters. We also set the default maximum chunk size for ADLS as 128k. This is due to the fact that direct reads aren't supported for ADLS, which means that the JNI array allocation and the memcpy adds significant overhead for larger buffers. 128k was chosen emperically for S3 for the same reason. Since this reason also holds for ADLS, we keep the same value. A new flag called FLAGS_adls_read_chunk_size is used to control this value. TODO: Settle on a buffer size with the most optimal buffer size emperically. Change-Id: I067f053fec941e3631610c5cc89a384f257ba906 Reviewed-on: http://gerrit.cloudera.org:8080/7033 Reviewed-by: Sailesh Mukil <sailesh@cloudera.com> Tested-by: Impala Public Jenkins
Lightning-fast, distributed SQL queries for petabytes of data stored in Apache Hadoop clusters.
Impala is a modern, massively-distributed, massively-parallel, C++ query engine that lets you analyze, transform and combine data from a variety of data sources:
To learn more about Impala as a business user, or to try Impala live or in a VM, please visit the Impala homepage.
If you are interested in contributing to Impala as a developer, or learning more about Impala's internals and architecture, visit the Impala wiki.
Impala only supports Linux at the moment.
See bin/bootstrap_build.sh.
This distribution uses cryptographic software and may be subject to export controls. Please refer to EXPORT_CONTROL.md for more information.