Skip to content

[SPARK-20515][SQL] Fix reading of HIVE ORC table with varchar/char columns in Spark SQL should not fail - #17791

Closed
umehrot2 wants to merge 1 commit into
apache:branch-2.0from
umehrot2:spark-hive-orc
Closed

[SPARK-20515][SQL] Fix reading of HIVE ORC table with varchar/char columns in Spark SQL should not fail#17791
umehrot2 wants to merge 1 commit into
apache:branch-2.0from
umehrot2:spark-hive-orc

Conversation

@umehrot2

Copy link
Copy Markdown

What changes were proposed in this pull request?

Reading from a Hive ORC table containing char/varchar columns fails in Spark SQL. This is caused by the fact that Spark SQL internally replaces the char/varchar columns with String data type. So, while reading from the table created in Hive which has varchar/char columns, it ends up using the wrong reader and causes a ClassCastException.

This patch allows Spark SQL to interpret varchar/char columns correctly, and store them as varchar/char type instead of internally converting to string columns.

How was this patch tested?

-> Added Unit tests
-> Manually tested on AWS EMR cluster

Step 1:
Created a table using hive (having varchar/char columns), and inserted some data:

CREATE EXTERNAL TABLE IF NOT EXISTS hive_orc_test (
a VARCHAR(10),
b CHAR(10),
c BIGINT)
STORED AS ORC
LOCATION 's3://xxxx';

INSERT INTO TABLE hive_orc_test VALUES ('abc', 'A', 101), ('abc1', 'B', 102), ('abc3', 'C', 103);

Step 2:
Created an external table in Spark SQL using the same source location, and run a select query on that.

CREATE EXTERNAL TABLE IF NOT EXISTS spark_orc_test (
a VARCHAR(10),
b CHAR(10),
c BIGINT)
STORED AS ORC
LOCATION 's3://xxxx';

SELECT * form spark_orc_test;

Result:
17/02/24 23:22:57 INFO DAGScheduler: Job 1 finished: processCmd at CliDriver.java:376, took 2.673360 s
abc A 101
abc1 B 102
abc3 C 103
Time taken: 4.327 seconds, Fetched 3 row(s)

@umehrot2umehrot2 changed the title Fix reading of HIVE ORC table with varchar/char columns in Spark SQL should not fail[SPARK-20515][SQL] Fix reading of HIVE ORC table with varchar/char columns in Spark SQL should not failApr 27, 2017
@AmplabJenkins

Copy link
Copy Markdown

Can one of the admins verify this patch?

@mridulm

Copy link
Copy Markdown
Contributor

+CC @dongjoon-hyun - since you were looking at ORC.

@hvanhovell

hvanhovell commented Apr 27, 2017

Copy link
Copy Markdown
Contributor

This is very similar to #16804 however that approach is like this one is slightly broken (because it does not support nested char/varchar columns), can you just backport #17030 which is an improved version.

@dongjoon-hyun

Copy link
Copy Markdown
Member

Thank you for pining me, @mridulm . :)

@gatorsmile

Copy link
Copy Markdown
Member

BTW, please add [BACKPORT-2.0] in your PR title.

@HyukjinKwon

Copy link
Copy Markdown
Member

ping @umehrot2

@HyukjinKwonHyukjinKwon mentioned this pull request Jun 7, 2017
@asfgitasfgit closed this in b771fedJun 8, 2017
zifeif2 pushed a commit to zifeif2/spark that referenced this pull request Nov 22, 2025
# What changes were proposed in this pull request?
This PR proposes to close stale PRs, mostly the same instances with apache#18017Closesapache#11459Closesapache#13833Closesapache#13720Closesapache#12506Closesapache#12456Closesapache#12252Closesapache#17689Closesapache#17791Closesapache#18163Closesapache#17640Closesapache#17926Closesapache#18163Closesapache#12506Closesapache#18044Closesapache#14036Closesapache#15831Closesapache#14461Closesapache#17638Closesapache#18222
Added:
Closesapache#18045Closesapache#18061Closesapache#18010Closesapache#18041Closesapache#18124Closesapache#18130Closesapache#12217
Added:
Closesapache#16291Closesapache#17480Closesapache#14995
Added:
Closesapache#12835Closesapache#17141
## How was this patch tested?
N/A
Author: hyukjinkwon <gurwls223@gmail.com>
Closesapache#18223 from HyukjinKwon/close-stale-prs.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@umehrot2@AmplabJenkins@mridulm@hvanhovell@dongjoon-hyun@gatorsmile@HyukjinKwon