You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@gobblin.apache.org by GitBox <gi...@apache.org> on 2020/04/23 21:11:06 UTC

[GitHub] [incubator-gobblin] autumnust opened a new pull request #2966: [GOBBLIN-1126] Make ORC compaction shuffle key configurable

autumnust opened a new pull request #2966:
URL: https://github.com/apache/incubator-gobblin/pull/2966

Dear Gobblin maintainers,

Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!

### JIRA
- https://issues.apache.org/jira/browse/GOBBLIN-1126

### Description
The contribution of this PR contains:
- Refactored `upConvertOrcStruct` which was used specifically for handling schema evolution. The downside of the original implementation is, it creates new OrcStruct for each map call which is usually considered as an anti-pattern in MR execution. The fix makes it possible to reuse the same `OrcStruct` object by making this method only generating side-effect but return void.
- The refactored `upConvertOrcStruct` can be reused in column projection of `OrcStruct` so that if we want to have an arbitrary subset of columns to form a shuffle key (we used to use the whole record for shuffle key which is unnecessarily burdensome and harm the performance).
- To accommodate with tests I created a bunch of tools in `OrcUtils`:
-- `orcStructFillerWithFixedValue`: Given a schema, generate a `OrcStruct` with some value. This would be useful to randomly generate some record in row-manner and we could write them into a ORC file easily.
-- `writableComparableTypeWidening`: The original `upConvertOrcStruct` cannot handle this. Added for correctness.
-- `createValueRecursively`: The ORC API to create a `OrcStruct`, `OrcStruct.createValue` has a problem: If there's nested type within a contain-type like List/MAP, `createValue` call doesn't create any instance within the container, so that any nested-type information within the container's element type is lost. It might be worthwhile to contribute this back to ORC upstream.

The test might be hard to read, but given all the tools mentioned above, what I really do is mostly following this sequence:

1. create a ORC schema by: `schema = TypeDescription.createFromString(schemaString);`
2. create a OrcStruct by `orcStruct = OrcUtils.createValueRecursively(schema)`.
3. Fill in the value by `OrcUtils.orcStructFillerWithFixedValue(orcStruct, schema, valueForDifferntTypes ...)`
4. Do this for two different schema: writer schema and reader schema with certain evolution.
5. `upConvertOrcStruct(recordInWriterSchema, recordInReaderSchema, readerSchema); `
6. Examine if `recordInReaderSchema`'s result is expected.

### Tests
- [ ] My PR adds the following unit tests __OR__ does not need testing for this extremely good reason:

### Commits
- [ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "[How to write a good git commit message](http://chris.beams.io/posts/git-commit/)":
1. Subject is separated from body by a blank line
2. Subject is limited to 50 characters
3. Subject does not end with a period
4. Subject uses the imperative mood ("add", not "adding")
5. Body wraps at 72 characters
6. Body explains "what" and "why", not "how"

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org