You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2020/04/02 13:42:00 UTC

[jira] [Commented] (IMPALA-9484) Milestone 1: properly scan files that has full ACID schema

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

ASF subversion and git services commented on IMPALA-9484:
---------------------------------------------------------

Commit 8aa0652871c64639a34e54a7339a1eff1d594b19 in impala's branch refs/heads/master from Zoltan Borok-Nagy
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=8aa0652 ]

IMPALA-9484: Full ACID Milestone 1: properly scan files that has full ACID schema

Full ACID row format looks like this:

{
  "operation": 0,
  "originalTransaction": 1,
  "bucket": 536870912,
  "rowId": 0,
  "currentTransaction": 1,
  "row": {"i": 1}
}

User columns are nested under "row". In the frontend we need to create
slot descriptors that correspond to the file schema. In the catalog we
could mimic the file schema but that would introduce several
complexities and corner cases in column resolution. Also in query
results the heading of the above user column would be "row.i". Star
expansion should also be modified, etc.

Because of that in the Catalog I create the exact opposite of the above
schema:

{
  "row__id":
  {
    "operation": 0,
    "originalTransaction": 1,
    "bucket": 536870912,
    "rowId": 0,
    "currentTransaction": 1
  }
  "i": 1
}

This way very little modification is needed in the frontend. And the
hidden columns can be easily retrieved via 'SELECT row__id.*' when we
need those for debugging/testing.

We only need to change Path.getAbsolutePath() to return a schema path
that corresponds to the file schema. Also in the backend we need some
extra juggling in OrcSchemaResolver::ResolveColumn() to retrieve the
table schema path from the file schema path.

Testing:
I changed data loading to load ORC files in full ACID format by default.
With this change we should be able to scan full ACID tables that are
not minor-compacted, don't have deleted rows, and don't have original
files.

Newly added Tests:
 * specific queries about hidden columns (full-acid-rowid.test)
 * SHOW CREATE TABLE (show-create-table-full-acid.test)
 * DESCRIBE [FORMATTED] TABLE (describe-path.test)
 * INSERT should be forbidden (acid-negative.test)
 * added tests for column masking (
   ranger_column_masking_complex_types.test)

Change-Id: Ic2e2afec00c9a5cf87f1d61b5fe52b0085844bcb
Reviewed-on: http://gerrit.cloudera.org:8080/15395
Reviewed-by: Impala Public Jenkins <im...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>


> Milestone 1: properly scan files that has full ACID schema
> ----------------------------------------------------------
>
>                 Key: IMPALA-9484
>                 URL: https://issues.apache.org/jira/browse/IMPALA-9484
>             Project: IMPALA
>          Issue Type: Sub-task
>            Reporter: Zoltán Borók-Nagy
>            Priority: Major
>              Labels: impala-acid
>
>  
> Full ACID row format looks like this:
> {
>  "operation": 0,
>  "originalTransaction": 1,
>  "bucket": 536870912,
>  "rowId": 0,
>  "currentTransaction": 1,
>  "row": \{"i": 1}
> }
> User columns are nested under "row". The frontend should create proper tuples and slot descriptors for the scan nodes to read the files correctly.
> We should be able to query the ACID columns, at least for debugging/testing. Hive uses the special “row__id” identifier for that.
> Impala should raise an error if there are delete deltas. Directory filtering should filter out minor compacted directories since the records from those need validation.
> Non-goals in this sub-task:
>  * row validation against validWriteIdList
>  * reading "original files" (files in non-ACID format)
>  * reading delete deltas



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org