[jira] [Commented] (KUDU-3146) Consistent table metadata for scans

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

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

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

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>


> Consistent table metadata for scans
> -----------------------------------
>
>                 Key: KUDU-3146
>                 URL: https://issues.apache.org/jira/browse/KUDU-3146
>             Project: Kudu
>          Issue Type: Improvement
>    Affects Versions: 1.12.0
>            Reporter: Grant Henke
>            Priority: Major
>
> Currently there is a time between generating/deserializing a scan token and opening the scanner that can result in and invalid schema when scanning the table. This is especially the case when a column is renamed or dropped and then another column with the same name is created. 
> This has been somewhat worked around client side by leveraging column ids and mapping the scan token projection to the new schema based on the column ids. However, this doesn't work when the scan token sends it's own metadata (KUDU-1802). 
> We should provide a mechanism to allow the schema to be consistent and guaranteed to work from the point a scan token is generated to the time it is run/completed.
> A simple approach might be to allow column ids to be passed on the scan request. Instead of handling the mapping client side, this makes the column ids more of a server side concern again (which was the original intent). This is also how table renames are handled, by passing the table id. Of course this wouldn't support destructive changes such as dropping a column, but that would require a much larger change to keep the dropped column for a period of time and use the snapshot time to scan using the schema at the given snapshot time.
> The other open issue with column name changes in todays implementation is that predicates are by name only and the client can't map them the same way it does for the projection. Using column ids in the predicates would be required as well if that approach is taken. 



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