[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Release Note: (was: Fix FindBugs and CheckStyle Errors)
Status: Patch Available (was: Open)
Trying this again... patch didn't build but I also didn't change anything.
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch, HIVE-19847.6.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Open (was: Patch Available)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch, HIVE-19847.6.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Attachment: HIVE-19847.6.patch
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch, HIVE-19847.6.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Open (was: Patch Available)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Patch Available (was: Open)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Attachment: HIVE-19847.5.patch
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Attachment: HIVE-19847.4.patch
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Open (was: Patch Available)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Release Note: Fix FindBugs and CheckStyle Errors
Status: Patch Available (was: Open)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch, HIVE-19847.4.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Patch Available (was: Open)
There seems to be a lot of interest in multi-threading varying aspects of the
HiveServer2 application, but everyone seems to be doing it there own way.
I've put forward a patch that I hope can start the conversation on coming up
with a more holistic approach to tackling this.
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Attachment: HIVE-19847.3.patch
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Open (was: Patch Available)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch,
> HIVE-19847.3.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never performing tear down and setup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Description:
The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on a
life of its own. We should consider separating out the various components into
their own classes. For this ticket, I propose separating out the
{{getInputSummary}} functionality into its own class.
There are several issues with the current implementation:
# It is
[synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
Only one query can get file input summary at a time. For a query which deals
with a large data set with a large number of files, this can block other
queries for a long period of time. This is especially painful when most
queries use a small data set, but a large data set is submitted on occasion.
# For each query, time is spend setting up and tearing down a ThreadPool
# It uses deprecated code
I propose breaking it out into its own class and creating a single thread pool
that all queries pull from. In this way, the bottle neck will be one the
number of available threads, not on a single query and if a big query is
running and a small query is also submitted, the smaller query will be able to
proceed.
In regards to setup/teardown... if a query uses 15 threads to perform this
summary action, then finishes, it will tear down the threads, the next query
may immediate create 15 new threads for processing. With a single pool, those
threads are never performing tear down and setup.
was:
The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on a
life of its own. We should consider separating out the various components into
their own classes. For this ticket, I propose separating out the
{{getInputSummary}} functionality into its own class.
There are several issues with the current implementation:
# It is
[synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
Only one query can get file input summary at a time. For a query which deals
with a large data set with a large number of files, this can block other
queries for a long period of time. This is especially painful when most
queries use a small data set, but a large data set is submitted on occasion.
# For each query, time is spend setting up and tearing down a ThreadPool
# It uses deprecated code
I propose breaking it out into its own class and creating a single thread pool
that all queries pull from. In this way, the bottle neck will be one the
number of available threads, not on a single query and if a big query is
running and a small query is also submitted, the smaller query will be able to
proceed.
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
> In regards to setup/teardown... if a query uses 15 threads to perform this
> summary action, then finishes, it will tear down the threads, the next query
> may immediate create 15 new threads for processing. With a single pool,
> those threads are never
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Open (was: Patch Available)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Patch Available (was: Open)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Attachment: HIVE-19847.2.patch
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Attachment: HIVE-19847.1.patch
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[
https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated HIVE-19847:
---
Status: Patch Available (was: Open)
> Create Separate getInputSummary Service
> ---
>
> Key: HIVE-19847
> URL: https://issues.apache.org/jira/browse/HIVE-19847
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
>Affects Versions: 3.0.0, 4.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Major
> Attachments: HIVE-19847.1.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on
> a life of its own. We should consider separating out the various components
> into their own classes. For this ticket, I propose separating out the
> {{getInputSummary}} functionality into its own class.
> There are several issues with the current implementation:
> # It is
> [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
> Only one query can get file input summary at a time. For a query which
> deals with a large data set with a large number of files, this can block
> other queries for a long period of time. This is especially painful when
> most queries use a small data set, but a large data set is submitted on
> occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread
> pool that all queries pull from. In this way, the bottle neck will be one
> the number of available threads, not on a single query and if a big query is
> running and a small query is also submitted, the smaller query will be able
> to proceed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
