[jira] [Commented] (KUDU-1802) Deserializing scan tokens should avoid round-trip to master

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KUDU-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148627#comment-17148627 ] 

ASF subversion and git services commented on KUDU-1802:
-------------------------------------------------------

Commit d23ee5d38ddc4317f431dd65df0c825c00cc968a in kudu's branch refs/heads/master from Grant Henke
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=d23ee5d ]

KUDU-1802: Avoid calls to master when using scan tokens

This patch adds new metadata to the scan token to allow it
to contain all of the metadata required to construct a KuduTable
and open a scanner in the clients. This means the GetTableSchema
and GetTableLocations RPC calls to the master are no longer required
when using the scan token.

New TableMetadataPB, TabletMetadataPB, and authorization token
fields were added as optional fields on the token. Additionally a
`projected_column_idx` field was added that can be used in place
of the `projected_columns`. This significantly reduces the size of
the scan token by not duplicating the ColumnSchemaPB that is
already in the TableMetadataPB.

Adding the table metadata to the scan token is enabled by
default given it’s more scalable and performant. However,
it can be disabled in rare cases where more resiliency to
column renaming is desired. One example where disabling the
table metadata is used is the backup job. Future work, tracked
by KUDU-3146, should allow for table metadata to be leveraged in
those cases as well.

This doesn’t avoid the need for a call to the master to get the
schema in the case of writing data to Kudu, that work is tracked
by KUDU-3135. I expect the TableMetadataPB message would
be used there as well.

I included the ability to disable this functionality in the
kudu-spark integration via `kudu.useDriverMetadata` just
in case there are any unforeseen issues or regressions with
this feature.

I added a test to compare the serialized size of the scan token with
and without the table and tablet metadata. The size results for a
100 column table are:
   no metadata: 2697 Bytes
   tablet metadata: 2805
   tablet, table, and authz metadata: 3258

Change-Id: I88c1b8392de37dd5e8b7bd8b78a21603ff8b1d1b
Reviewed-on: http://gerrit.cloudera.org:8080/16031
Reviewed-by: Grant Henke <gr...@apache.org>
Tested-by: Grant Henke <gr...@apache.org>


> Deserializing scan tokens should avoid round-trip to master
> -----------------------------------------------------------
>
>                 Key: KUDU-1802
>                 URL: https://issues.apache.org/jira/browse/KUDU-1802
>             Project: Kudu
>          Issue Type: Improvement
>          Components: client, perf
>    Affects Versions: 1.2.0
>            Reporter: Todd Lipcon
>            Assignee: Grant Henke
>            Priority: Major
>              Labels: impala, ramp-up
>
> 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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)