Uh oh!
There was an error while loading. Please reload this page.
[SPARK-20682][SPARK-15474][SPARK-21791] Add new ORCFileFormat based on ORC 1.4.1 - #19651
[SPARK-20682][SPARK-15474][SPARK-21791] Add new ORCFileFormat based on ORC 1.4.1#19651dongjoon-hyun wants to merge 22 commits into
Conversation
SparkQA
commented
Nov 3, 2017
Test build #83382 has finished for PR 19651 at commit
|
HyukjinKwon
commented
Nov 3, 2017
retest this please |
SparkQA
commented
Nov 3, 2017
Test build #83407 has started for PR 19651 at commit |
dongjoon-hyun
commented
Nov 3, 2017
Thank you, @HyukjinKwon ! |
SparkQA
commented
Nov 4, 2017
Test build #83431 has finished for PR 19651 at commit
|
dongjoon-hyun
commented
Nov 4, 2017
Retest this please |
SparkQA
commented
Nov 4, 2017
Test build #83433 has finished for PR 19651 at commit
|
dongjoon-hyun
commented
Nov 4, 2017
Hi, @cloud-fan and @gatorsmile . |
There was a problem hiding this comment.
This is moved from object ORCFileFormat in sql/hive.
There was a problem hiding this comment.
This is moved from object ORCFileFormat inside sql/hive.
There was a problem hiding this comment.
sparkSession.sessionState.newHadoopConf
There was a problem hiding this comment.
shouldn't we do schema merging?
There was a problem hiding this comment.
Later, I will implement schema merging in a parallel manner like Parquet.
There was a problem hiding this comment.
we should override buildReader and return GenericInternalRow here. Then the parent class will merge the partition values and output UnsafeRow. This is what the current OrcFileFormat does and let's keep it first.
There was a problem hiding this comment.
Yep. I see. It was because I preferred to be consistent with ParquetFileFormat here.
There was a problem hiding this comment.
why call this function inside a loop? Can we put it at the beginning?
There was a problem hiding this comment.
This is a two-step approach which validates each individual filter is convertible.
I'll add the comment of SPARK-12218.
There was a problem hiding this comment.
this doesn't belong to OrcOptions, maybe OrcUtils?
There was a problem hiding this comment.
ideally we should make it into a function a use it in write, like the old OrcOutputWriter did.
There was a problem hiding this comment.
shall we merge this class to OrcUtils?
There was a problem hiding this comment.
OrcFileOperator defines functions depending on Hive. We cannot merge these functions into sql/core.
import org.apache.hadoop.hive.ql.io.orc.{OrcFile, Reader}
import org.apache.hadoop.hive.serde2.objectinspector.StructObjectInspector
There was a problem hiding this comment.
like the old orc format, can we create a OrcSerializer to capsulate these serializing logic?
dongjoon-hyun
commented
Nov 6, 2017
Thank you so much for review, @cloud-fan . I'll try to update the PR tonight. |
@dongjoon-hyun, btw, if I understood correctly,
we don't necessarily remove the old (I said this because I'd like to keep the blame easy to track if possible). |
dongjoon-hyun
commented
Nov 7, 2017
Right. @HyukjinKwon . I'll follow the final decision on this PR. |
SparkQA
commented
Nov 7, 2017
Test build #83543 has finished for PR 19651 at commit
|
dongjoon-hyun
commented
Nov 7, 2017
The PR is updated according to your advice. Thank you again, @cloud-fan ! |
dongjoon-hyun
commented
Nov 9, 2017
Hi, @cloud-fan and @gatorsmile . |
dongjoon-hyun
commented
Nov 10, 2017
Retest this please. |
SparkQA
commented
Nov 10, 2017
Test build #83669 has finished for PR 19651 at commit
|
dongjoon-hyun
commented
Nov 10, 2017
Retest this please. |
There was a problem hiding this comment.
can you follow the code style in OrcFileFormat.unwrapOrcStructs? Basically create an unwrapper for each field, and unwrapper is a (Any, InternalRow, Int) => Unit
There was a problem hiding this comment.
your implementation here doesn't consider boxing for primitive types at all.
There was a problem hiding this comment.
We use valueWrapper for each field here. Do you mean changing name?
There was a problem hiding this comment.
Your wrapper returns a value, while the old implementation's wrapper set value to InternalRow, which avoids boxing.
There was a problem hiding this comment.
nit: we can use sparkSession.sessionState.conf.isCaseSensitive here, as it's much cheaper than serializing a function.
There was a problem hiding this comment.
do you mean, even if each individual filter is convertible, the final filter(combine filters by And) may be un-convertible?
There was a problem hiding this comment.
Your previous question was about line 40.
why call this function inside a loop? Can we put it at the beginning?
+ val convertibleFilters = for {
+ filter <- filters
+ _ <- buildSearchArgument(dataTypeMap, filter, SearchArgumentFactory.newBuilder())
Here. It seems you are asking another one.
There was a problem hiding this comment.
ah you are just following the previous code:
// First, tries to convert each filter individually to see whether it's convertible, and then
// collect all convertible ones to build the final `SearchArgument`.
val convertibleFilters = for {
filter <- filters
_ <- buildSearchArgument(dataTypeMap, filter, SearchArgumentFactory.newBuilder())
} yield filter
for {
// Combines all convertible filters using `And` to produce a single conjunction
conjunction <- convertibleFilters.reduceOption(And)
// Then tries to build a single ORC `SearchArgument` for the conjunction predicate
builder <- buildSearchArgument(dataTypeMap, conjunction, SearchArgumentFactory.newBuilder())
} yield builder.build()
can you add back those comments?
dongjoon-hyun
commented
Dec 1, 2017
Thank you so much, @cloud-fan . |
| * builder methods mentioned above can only be found in test code, where all tested filters are | ||
| * known to be convertible. | ||
| */ | ||
| private[orc] object OrcFilters { |
There was a problem hiding this comment.
I didn't review it carefully, just assume it's same with the old version, with API update.
There was a problem hiding this comment.
Yes. It's logically the same with old version. Only API usage is updated here.
SparkQA
commented
Dec 1, 2017
Test build #84378 has finished for PR 19651 at commit
|
SparkQA
commented
Dec 2, 2017
Test build #84393 has finished for PR 19651 at commit
|
cloud-fan
commented
Dec 3, 2017
great, all tests pass! Let's restore to old ORC implementation and merge it. |
dongjoon-hyun
commented
Dec 3, 2017
Sure, @cloud-fan . |
dongjoon-hyun
commented
Dec 3, 2017
Now, this PR has only new OrcFileFormat-related addition: 1009 insertions(+), 2 deletions(-) |
SparkQA
commented
Dec 3, 2017
Test build #84396 has finished for PR 19651 at commit
|
dongjoon-hyun
commented
Dec 3, 2017
@cloud-fan . It pass the Jenkins again. Could you take a look again? |
| val paths = SparkHadoopUtil.get.listLeafStatuses(fs, origPath) | ||
| .filterNot(_.isDirectory) | ||
| .map(_.getPath) | ||
| .filterNot(_.getName.startsWith("_")) |
There was a problem hiding this comment.
nit: How about combining two filterNot into one filterNot by creating one condition with two startsWith?
There was a problem hiding this comment.
@kiszk . This comes from the existing code, OrcFileOperator.scala. This PR keeps the original function because I don't want to make a possibility of difference. We had better do those kind of improvement later in a separate PR.
There was a problem hiding this comment.
Thank you for your explanation, got it.
cloud-fan
commented
Dec 3, 2017
thanks, merging to master! followups:
|
dongjoon-hyun
commented
Dec 3, 2017
Thank you so much for making ORC move forward, @cloud-fan ! |
…a sources ## What changes were proposed in this pull request? After [SPARK-20682](apache#19651), Apache Spark 2.3 is able to read ORC files with Unicode schema. Previously, it raises `org.apache.spark.sql.catalyst.parser.ParseException`. This PR adds a Unicode schema test for CSV/JSON/ORC/Parquet file-based data sources. Note that TEXT data source only has [a single column with a fixed name 'value'](https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/text/TextFileFormat.scala#L71). ## How was this patch tested? Pass the newly added test case. Author: Dongjoon Hyun <dongjoon@apache.org> Closesapache#20266 from dongjoon-hyun/SPARK-23072.
…a sources ## What changes were proposed in this pull request? After [SPARK-20682](#19651), Apache Spark 2.3 is able to read ORC files with Unicode schema. Previously, it raises `org.apache.spark.sql.catalyst.parser.ParseException`. This PR adds a Unicode schema test for CSV/JSON/ORC/Parquet file-based data sources. Note that TEXT data source only has [a single column with a fixed name 'value'](https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/text/TextFileFormat.scala#L71). ## How was this patch tested? Pass the newly added test case. Author: Dongjoon Hyun <dongjoon@apache.org> Closes#20266 from dongjoon-hyun/SPARK-23072. (cherry picked from commit a0aedb0) Signed-off-by: Wenchen Fan <wenchen@databricks.com>
What changes were proposed in this pull request?
Since SPARK-2883, Apache Spark supports Apache ORC inside
sql/hivemodule with Hive dependency. This PR aims to add a new ORC data source insidesql/coreand to replace the old ORC data source eventually. This PR resolves the following three issues.How was this patch tested?
Pass the Jenkins with the existing all tests and new tests for SPARK-15474 and SPARK-21791.