Details
Description
Currently, KuduScanToken::DeserializeIntoScanner calls KuduClient::OpenTable() which makes a GetTableSchema call to the master. This round trip is a bit expensive because it's always a "thundering herd" for an Impala query or Spark job – every host deserializes a bunch of scan tokens at the same time and ends up having to back off.
We should consider some ways to avoid this.
Attachments
Issue Links
- causes
-
KUDU-3254 Crash in Kudu C++ client when working with stale scan tokens containing tablet location info
- Resolved
-
KUDU-3349 Kudu java client failed to demote leader and caused a lot of deleting rows timeout
- Resolved
- is related to
-
KUDU-3115 Improve scalability of Kudu masters
- Open
-
KUDU-3135 Add Client Metadata Tokens
- Open
-
KUDU-3146 Consistent table metadata for scans
- Open
-
IMPALA-9903 Queries on a Kudu table call openTable multiple times
- Resolved