Movatterモバイル変換


[0]ホーム

URL:


Cloudera Enterprise 5.11.x |Other versions

Cloudera AdministrationPerformanceManagement

Tuning Hive Performance on the Amazon S3 Filesystem

Some of the default behaviors of Apache Hive might degrade performance when reading and writing data to tables stored on Amazon S3. Cloudera has introduced the following enhancementsthat make using Hive with S3 more efficient.

Tuning Hive Write Performance on S3

In releases lower than CDH 5.10, creating or writing Hive tables or partitions to S3 caused performance issues due to the differences between the HDFS and S3 file systems. This occurredbecause parallel writes to S3 were not supported, and the S3 file system lacks an efficient move operation. In CDH 5.10, these issues are resolved. For details, seeHIVE-14269.

These optimizations enable the final job in the query plan to write data efficiently in parallel to the S3 file system. HiveServer2 then uses a thread pool of workers to transfer thedata to the final table location on S3. The default values of these parameters yield good performance for a wide range of workloads. However, you can further tune the parameters to optimize forspecific workloads.

Hive S3 Write Performance Tuning Parameters

To improve write performance for Hive tables stored on S3, use Cloudera Manager to set the parameters listed below. SeeSetting Parameters as Service-Wide Defaults with Cloudera Manager.

Parameter NameDescriptionSettingsDefault
hive.mv.files.threadsImportant: Only tune this parameter when you have confirmed that thread pool parallelism is impacting performance. Before making any changes,contact Cloudera Support for guidance.

Sets the number of threads used to move files in a move task. Increasing the value of this parameter increases the number of parallel copies that can run on S3.

A separate thread pool is used for each Hive query. When running only a few queries in parallel, you can increase this parameter for greater per-query write throughput. However, when yourun a large number of queries in parallel, decrease this parameter to avoid thread exhaustion.

To disable multi-threaded file moves, set this parameter to0. This can prevent thread contention on HiveServer2.

This parameter also controls renames on HDFS, so increasing this value increases the number of threads responsible for renaming files on HDFS.

Range between:0 and4015
hive.blobstore.use.blobstore. as.scratchdir

When set totrue, this parameter enables the use of scratch directories directly on S3.

Important: Enabling this parameter might degrade performance slightly, but is useful if the HDFS cluster is not large enough to hold theintermediate data from a Hive query.
true |falsefalse

Setting Parameters on a Per-Query Basis with the HiveSET Command

Optimize on a per-query basis by setting these parameters in the query code with the HiveSET command.

For example, to set the thread pool to 20 threads and enable scratch directories on S3:

set hive.mv.files.threads=20set hive.blobstore.use.blobstore.as.scratchdir=true

Setting Parameters as Service-Wide Defaults with Cloudera Manager

Use Cloudera Manager to sethive.mv.files.threads andhive.blobstore.use.blobstore.as.scratchdir as service-widedefaults:

  1. In the Cloudera Manager Admin Console, go to the Hive service.
  2. In the Hive service page, click theConfiguration tab.
  3. On the Configuration page, click theHiveServer2 scope.
  4. Click thePerformance category.
  5. Search for each parameter to set them.
  6. ClickSave Changes.

Tuning the S3A Connector to Improve Hive Write Performance on S3

Thefs.s3a parameters are used to tune theS3A Connector inside theHadoop code base. The S3A Connector configurations control the number of threads used to issue concurrent upload and copy requests. A single instance of the S3A Connector is used with a HiveServer2instance, so different Hive queries can share the same connector instance. The same thread pool is used to issue upload and copy requests. This means that thefs.s3aparameters cannot be set on a per-query basis. Instead, set them for each HiveServer2 instance. In contrast, the thread pool controlled byhive.mv.files.thread iscreated for each query separately.

Parameter NameHow To Tune
fs.s3a.threads.coreIncrease the value to increase the number of core threads in the thread pool used to run any data uploads or copies.
fs.s3a.threads.maxIncrease the value to increase the maximum number of concurrent active partition uploads and copies, which each use a thread from thethread pool.
fs.s3a.max.total.tasksIncrease the value to increase the number of partition uploads and copies allowed to the queue before rejecting additionaluploads.
fs.s3a.connection.maximum

Increase the value to increase the maximum number of simultaneous connections to S3. Cloudera recommends setting this value to1500.

Setting S3A Connector Parameters as Service-Wide Defaults

Use Cloudera Manager to set the S3A Connector parameters as service-wide defaults for Hive:

  1. In the Cloudera Manager Admin Console, go to the Hive service.
  2. In the Hive service page, click theConfiguration tab.
  3. On the Configuration page, click theHiveServer2 scope.
  4. Click theAdvanced category.
  5. Search for theHiveServer2 Advanced Configuration Snippet (Safety Valve) for hive-site.xml configuration setting and click the plus sign to addparameters.
  6. For eachfs.s3a parameter, type the parameter name into theName field and the value in theValue field.
  7. ClickSave Changes.

Known Limitations

  1. If you have a large number of concurrent Hive query operations running, a deadlock might occur in theS3AFileSystem class of the Hadoop platform. This iscaused by thread pool limits and causes HiveServer2 to freeze. If this occurs, you must restart HiveServer2. To work around the issue, increase the values offs.s3a.threads.core andfs.s3a.threads.max. SeeHADOOP-13826.

    This behavior might occur more frequently iffs.s3a.blocking.executor.enabled is set totrue. This parameter is turned offby default in CDH.

  2. S3 is an eventually consistent storage system. See theS3documentation. This eventual consistency affects Hive behavior on S3 and, in rare cases, can cause intermittent failures. Retrying the failed query usually works around the issue.

Tuning Hive Dynamic Partitioning Performance on S3

Dynamic partitioning is a Hive feature that enables dynamic insertions ofdata into partitions based on the value of a column in a record. It is useful for bulk creating or updating partitions. Prior to CDH 5.11, performance of Hive queries that performed dynamicpartitioning on S3 was diminished because partitions were loaded into the target table one at a time. CDH 5.11 optimizations change the underlying logic so that partitions are loaded in parallel.

Use the following parameter to tune performance on a wide range of workloads that use dynamic partitioning. This parameter can be set with Cloudera Manager at the service level or on aper-query basis using the HiveSET command. SeeSetting the Hive Dynamic Partition Loading Parameter as a Service-Wide Default with ClouderaManager.

Parameter NameDescriptionSettingsDefault
hive.load.dynamic.partitions.thread

Sets the number of threads used to load dynamically generated partitions.

Loading dynamically generated partitions requires renaming the files to their destination location and updating the new partition metadata.

Increasing the value set for this parameter can improve performance when you have several hundred dynamically generated partitions.

Range between:0 and2515

Tuning Tips

Increase the value set forhive.load.dynamic.partitions.thread to improve dynamic partitioning query performance on S3. However, do not set this parameterto values exceeding25 to avoid placing an excessive load on S3, which can lead to throttling issues.

Setting the Hive Dynamic Partition Loading Parameter on a Per-Query Basis

Optimize dynamic partitioning at the session level by using the HiveSET command in the query code.

For example, to set the thread pool to 25 threads:

set hive.load.dynamic.partitions.thread=25

Setting the Hive Dynamic Partition Loading Parameter as a Service-Wide Default with Cloudera Manager

Use Cloudera Manager to sethive.load.dynamic.partitions.thread as a service-wide default:

  1. In the Cloudera Manager Admin Console, go to the Hive service.
  2. In the Hive service page, click theConfiguration tab.
  3. On the Configuration page, click theHiveServer2 scope.
  4. Click thePerformance category.
  5. Search forLoad Dynamic Partitions Thread Count and enter the value you want to set as a service-wide default.
  6. ClickSave Changes.

Tuning Hive INSERT OVERWRITE Performance on S3

INSERT OVERWRITE queries write data to a specific table or partition, overwriting any existing data. When Hive detects existing data in the targetdirectory, it moves the existing data to theHDFS trash directory. Moving data to the trashdirectory can significantly degrade performance when it is run on S3. In CDH 5.11, an optimization is added to move data to the trash directory in parallel by using the following parameter. UseCloudera Manager to set this parameter as a service-wide default or use the HiveSET command to set the parameter on a per-query basis. SeeSetting the Hive INSERT OVERWRITE Performance Tuning Parameter as a Service-Wide Default withCloudera Manager.

Important: This optimization only applies toINSERT OVERWRITE queries that insert data into tables orpartitions where already there is existing data.
Parameter NameDescriptionSettingsDefault
hive.mv.files.thread

Set this parameter to control the number of threads used to delete existing data in the HDFS trash directory forINSERT OVERWRITE queries.

Important: Originally, this parameter only controlled the number of threads used by HiveServer2 to move data from the staging directory toanother location. This parameter can also be used to tune Hive write performance on S3 tables. SeeHive S3 WritePerformance Tuning Parameters.
Range between:0 and4015

Tuning Tips

Thehive.mv.files.thread parameter can be tuned forINSERT OVERWRITE performance in the same way it is tuned for writeperformance. SeeHive S3 Write Performance Tuning Parameters.

If setting the above parameter does not produce acceptable results, you can disable the HDFS trash feature by setting thefs.trash.interval to0 on the HDFS service. In Cloudera Manager, chooseHDFS > Configuration > NameNode > Main and setFilesystem Trash Interval to0.

Warning: Disabling the trash feature of HDFS causes permanent data deletions, making the deleted data unrecoverable.

Setting the Hive INSERT OVERWRITE Performance Tuning Parameter on a Per-Query Basis

Configure Hive to move data to the HDFS trash directory in parallel forINSERT OVERWRITE queries using the HiveSETcommand.

For example, to set the thread pool to use30 threads at a maximum:
set hive.mv.files.thread=30

Setting the Hive INSERT OVERWRITE Performance Tuning Parameter as a Service-Wide Default with Cloudera Manager

Use Cloudera Manager to sethive.mv.files.threads as a service-wide default:

  1. In the Cloudera Manager Admin Console, go to the Hive service.
  2. In the Hive service page, click theConfiguration tab.
  3. On the Configuration page, click theHiveServer2 scope.
  4. Click thePerformance category.
  5. Search forMove Files Thread Count and enter the value you want to set as a service-wide default.
  6. ClickSave Changes.

Tuning Hive Table Partition Read Performance on S3

Prior to CDH 5.11, Hive queries that read over 1,000 partitions stored on S3 experienced performance degradation because metadata operations against S3 are much slower than metadataoperations performed against HDFS. When Hive runs a query, it needs to collect metadata about the files and about the directory it is reading from. This metadata includes information such as numberof files or file sizes. To collect this metadata, Hive must make calls to S3. Before CDH 5.11, these metadata calls were issued serially (one at a time). In CDH 5.11, the metadata operations havebeen optimized so that the calls are now issued in parallel. This optimization delivers the most benefit for queries that read from multiple partitions. Benefits for queries that read fromnon-partitioned tables are less significant.

Use the following parameters to tune Hive table partition read performance on S3. The default values yield good performance gains for a wide range of workloads, but you can further tunethem to optimize for specific workloads. These parameters can be set with Cloudera Manager at the service level or on a per-query basis using the HiveSET command. SeeSetting Hive Table Partition Read Performance Tuning Parameters as Service-WideDefaults with Cloudera Manager.

Parameter NameDescriptionSettingsDefault
hive.exec.input.listing.max.threads

Sets the maximum number of threads that Hive uses to list input files. Increasing this value can improve performance when there are many partitions being read.

Range between:0 and5015
mapreduce.input.fileinputformat.list-status.num-threads

Sets the number of threads used by theFileInputFormat class when listing and fetching block locations for the specified input paths.

Range between:0 and501

Tuning Tips

If listing input files becomes a bottleneck for the Hive query, increase the values forhive.exec.input.listing.max.threads andmapreduce.input.fileinputformat.list-status.num-threads. This bottleneck might occur if the query takes a long time to list input directories or to run split calculations whenreading several thousand partitions. However, do not set these parameters to values over50 to avoid putting excessive load on S3, which might lead to throttlingissues.

Setting the Hive Table Partition Read Performance Tuning Parameters on a Per-Query Basis

Configure Hive to perform metadata collection in parallel when reading table partitions on S3 using the HiveSET command.

For example, to set the maximum number of threads that Hive uses to list input files to20 and the number of threads used by theFileInputFormat class when listing and fetching block locations for input to5:

set hive.exec.input.listing.max.threads=20set mapreduce.input.fileinputformat.list-status.num-threads=5

Setting Hive Table Partition Read Performance Tuning Parameters as Service-Wide Defaults with Cloudera Manager

Use Cloudera Manager to sethive.exec.input.listing.max.threads andmapreduce.input.fileinputformat.list-status.num-threadsas service-wide defaults.

To set hive.exec.input.listing.max.threads:

  1. In the Cloudera Manager Admin Console, go to the Hive service.
  2. In the Hive service page, click theConfiguration tab.
  3. On the Configuration page, click theHiveServer2 scope.
  4. Click thePerformance category.
  5. Search forInput Listing Max Threads and enter the value you want to set as a service-wide default.
  6. ClickSave Changes.

To set mapreduce.input.fileinputformat.list-status.num-threads:

  1. In the Cloudera Manager Admin Console, go to the MapReduce service.
  2. In the MapReduce service page, click theConfiguration tab.
  3. Search forMapReduce Service Advanced Configuration Snippet (Safety Valve) for mapred-site.xml and enter the parameter, value, and description:
    <property>   <name>mapreduce.input.fileinputformat.list-status.num-threads</name>   <value>number_of_threads</value>   <description>Number of threads used to list and fetch block locations for input paths   specified by FileInputFormat</description></property>
  4. ClickSave Changes.

Tuning Hive MSCK (Metastore Check) Performance on S3

Running theMSCK command with theREPAIR TABLE option is a simple way to bulk add partitions to Hive tables. See theApache Language Manual for detailsabout usingMSCK REPAIR TABLE.MSCK REPAIR TABLE scans the file system to look for directories that correspond to a partition and thenregisters them with the Hive metastore. Prior to CDH 5.11,MSCK performance was slower on S3 when compared to HDFS due to the overhead created by collecting metadata onS3. In CDH 5.11,MSCK metadata calls are now issued in parallel, which significantly improves performance.

Use the following parameters to tune HiveMSCK metadata call performance on S3. The default values yield good performance gains for a wide range ofworkloads, but you can further tune them to optimize for specific workloads. Thehive.metastore.fshandler.threads parameter can be set as a service-wide default withCloudera Manager, but cannot be set at the session level. Thehive.msck.repair.batch.size parameter can be set with Cloudera Manager at the service level or on aper-query basis using the HiveSET command. SeeSettingthe Hive MSCK REPAIR TABLE Tuning Parameters as Service-Wide Defaults with Cloudera Manager.

Parameter NameDescriptionSettingsDefault
hive.metastore.fshandler.threads

Sets the number of threads that the Hive metastore uses when adding partitions in bulk to the metastore. Each thread performs metadata operations for each partition added, such ascollecting statistics for the partition or checking if the partition directory exists.

This parameter is also used to control the size of the thread pool that is used byMSCK whe4n it scans the file system looking for directories thatcorrespond to table partitions. Each thread performs a list status on each possible partition directory.

Range between:0 and3015
hive.msck.repair.batch.size

Sets the number of partition objects sent per batch from the HiveServe2 service to the Hive metastore service with theMSCK REPAIR TABLE command. If thisparameter is set to a value higher than zero, new partition information is sent from HiveServer2 to the Hive metastore in batches. Sending this information in batches improves how memory is used inthe metastore, avoiding client read timeout exceptions. If this parameter is set to0, all partition information is sent at once in a single Thrift call.

Range between:0 and2,147,483,6470

Tuning Tips

Thehive.metastore.fshandler.threads parameter can be increased if theMSCK REPAIR TABLE command is taking excessive time toscan S3 for potential partitions to add. Do not set this parameter to a value higher than30 to avoid putting excessive load on S3, which can lead to throttlingissues.

Increase the value set for thehive.msck.repair.batch.size parameter if you receive the following exception:

SocketTimeoutException: Read timed out

This exception is thrown by HiveServer2 when a metastore operation takes longer to complete than the time specified for thehive.metastore.client.socket.timeout parameter. If you simply increase the timeout, it must be set across all metastore operations and requires restarting the metastore service. Itis preferable to increase the value set forhive.msck.repair.batch.size, which specifies the number of partition objects that are added to the metastore at one time.Increasinghive.msck.repair.batch.size to3000 can help mitigate timeout exceptions returned when runningMSCK commands. Set to a lower value if you have multipleMSCK commands running in parallel.

Setting hive.msck.repair.batch.size on a Per-Query Basis

Use the HiveSET command to specify how many partition objects are sent per batch from the HiveServer2 service to the Hive metastore service at the sessionlevel.

For example, to specify that batches containing 3,000 partition objects each are sent:

set hive.msck.repair.batch.size=3000

Setting the Hive MSCK REPAIR TABLE Tuning Parameters as Service-Wide Defaults with Cloudera Manager

Use Cloudera Manager to set thehive.metastore.fshandler.threads and thehive.msck.repair.batch.size parameters asservice-wide defaults:

  1. In the Cloudera Manager Admin Console, go to the Hive service.
  2. In the Hive service page, click theConfiguration tab.
  3. On the Configuration page, search for each parameter to set them.
  4. ClickSave Changes.

[8]ページ先頭

©2009-2025 Movatter.jp