Uh oh!
There was an error while loading. Please reload this page.
[SPARK-18413][SQL][FOLLOW-UP] Use numPartitions instead of maxConnections - #15966
[SPARK-18413][SQL][FOLLOW-UP] Use numPartitions instead of maxConnections#15966dongjoon-hyun wants to merge 7 commits into
numPartitions instead of maxConnections#15966Conversation
…ections` JDBCOption
| <td><code>numPartitions</code></td> | ||
| <td> | ||
| The number of partitions that can be used, if set. It works by limiting both read and write | ||
| operations' parallelism. If the number of partitions to write exceeds this limit, the |
There was a problem hiding this comment.
Could you also document the impact on the number of JDBC connections here?
There was a problem hiding this comment.
Sure. I'll add that, too.
| <td><code>numPartitions</code></td> | ||
| <td> | ||
| The number of partitions that can be used, if set. It works by limiting both read and write | ||
| operations' parallelism. If the number of partitions to write exceeds this limit, the |
There was a problem hiding this comment.
fewer partitions is obscure. : )
There was a problem hiding this comment.
Thank you for review again. Yep. I'll revise it. :)
There was a problem hiding this comment.
How about this?
The number of partitions that can be used, if set. It works by limiting both read and write operations' parallelism. If the number of partitions to write exceeds this limit, the operation will coalesce the data set with this value before writing. In other words, this determines the maximum number of concurrent JDBC connections.
There was a problem hiding this comment.
In the read path, we might not generate the exact number of partitions.
Found a bug in the read path in #15499.
There was a problem hiding this comment.
Oh really? The number of JDBCPartition is different?
There was a problem hiding this comment.
Conceptually, if the column values are exactly identical, only one partition will be generated.
The bug in #15499 is not related the above fact.
There was a problem hiding this comment.
Ya. Actually, the above statement is describing coalesce and its parameter. So, shall we keep this?
There was a problem hiding this comment.
Maybe we need to rephrase it and document both behaviors (read and write paths). Also emphasize this is the max number.
There was a problem hiding this comment.
Like this?
The number of partitions that can be used, if set. It works by limiting both read and write operations' parallelism. In other words, this determines the maximum number of concurrent JDBC connections. For reading, it will make partitions less than or equal to this maximum. For writing, if the number of partitions to write exceeds this limit, the operation will coalesce the data set with this maximum before writing.
There was a problem hiding this comment.
(I am sorry I goofed in the PR.)
| </tr> | ||
| <tr> | ||
| <td><code>partitionColumn, lowerBound, upperBound, numPartitions</code></td> |
There was a problem hiding this comment.
We should revert it back. These four parameters are related.
These options must all be specified if any of them is specified
There was a problem hiding this comment.
That is incorrect now. numPartitions can be used alone. Those three are read-only optional parameters and numPartitions are general optional parameter.
There was a problem hiding this comment.
For that, I'll add some other description mentioning the relations.
SparkQA
commented
Nov 21, 2016
Test build #68951 has finished for PR 15966 at commit
|
| (lowerBound != null && upperBound != null && numPartitions != null), | ||
| (lowerBound != null && upperBound != null && numPartitions.isDefined), | ||
| s"If '$JDBC_PARTITION_COLUMN' is specified then '$JDBC_LOWER_BOUND', '$JDBC_UPPER_BOUND'," + | ||
| s" and '$JDBC_NUM_PARTITIONS' are required.") |
There was a problem hiding this comment.
We need to update this error message too.
There was a problem hiding this comment.
Ur, for me, this error message looks correct. JDBC_NUM_PARTITION is indenpendent of the others, but JDBC_PARTITION_COLUMN requires the others (including JDBC_NUM_PARTITION), isn't it?
There was a problem hiding this comment.
I did not try it. What happened if we input JDBC_PARTITION_COLUMN when writing the JDBC tables?
There was a problem hiding this comment.
It will raise exception due to the Ah, let me check.require. I think it's the correct previous behavior.
There was a problem hiding this comment.
Since it's used in declaration of view, users cannot go to writing path.
CREATE OR REPLACE TEMPORARY VIEW t1 USING org.apache.spark.sql.jdbc OPTIONS (url 'jdbc:mysql://localhost:3306/t', dbtable 't1', user 'root', password '', maxConnections '2', partitionColumn 'value')
java.lang.IllegalArgumentException: requirement failed: If 'partitionColumn' is specified then 'lowerBound', 'upperBound', and'numPartitions' are required.There was a problem hiding this comment.
Have you tried the DataFrameWriter's JDBC/write() APIs?
dongjoon-hyun
commented
Nov 21, 2016
To further review, I updated the doc. We can proceed on the updated content. |
SparkQA
commented
Nov 22, 2016
Test build #68955 has finished for PR 15966 at commit
|
cloud-fan
commented
Nov 22, 2016
Is it possible that users read a table through JDBC and then write data to a table through JDBC and want the read and write have different parallelism? |
SparkQA
commented
Nov 22, 2016
Test build #68963 has finished for PR 15966 at commit
|
Thank you for review, @cloud-fan . With the same parameter name To use different parallelisms for read/write, we are able to do that with different view names. In the following example, t1 is sql("CREATE OR REPLACE TEMPORARY VIEW data USING org.apache.spark.sql.jdbc OPTIONS (url 'jdbc:mysql://localhost:3306/t', dbtable 'data', user 'root', password '')")
sql("CREATE OR REPLACE TEMPORARY VIEW t1 USING org.apache.spark.sql.jdbc OPTIONS (url 'jdbc:mysql://localhost:3306/t', dbtable 't1', user 'root', password '', numPartitions '1')")
sql("CREATE OR REPLACE TEMPORARY VIEW t2 USING org.apache.spark.sql.jdbc OPTIONS (url 'jdbc:mysql://localhost:3306/t', dbtable 't1', user 'root', password '', numPartitions '2')")
sql("INSERT OVERWRITE TABLE t1 SELECT a FROM data GROUP BY a")
sql("INSERT OVERWRITE TABLE t2 SELECT a FROM data GROUP BY a") |
gatorsmile
commented
Nov 22, 2016
I found a way to verify the coalesce logics of JDBC writing. See my PR: #15975 It added With minor code changes, you can see the adjusted sql("INSERT INTO TABLE PEOPLE1 SELECT * FROM PEOPLE").explain(true) |
| The number of partitions that can be used, if set. It works by limiting both read and write | ||
| operations' parallelism. In other words, this determines the maximum number of concurrent | ||
| JDBC connections. For reading, it will make partitions less than or equal to this maximum. | ||
| For writing, if the number of partitions to write exceeds this limit, the operation will |
There was a problem hiding this comment.
Note, I am not good at writing tech document. Below is my revision.
The maximum number of partitions that can be used for parallelism in table reading and writing. This also determines the maximum number of concurrent JDBC connections. If the number of partitions to write exceeds this limit, we decrease it to this limit by calling
coalesce(numPartitions)before writing.
dongjoon-hyun
commented
Nov 22, 2016
Great! Thank you for #15975. |
gatorsmile
commented
Nov 22, 2016
LGTM pending test. Also cc @rxin |
| } else { | ||
| JDBCPartitioningInfo( | ||
| partitionColumn, lowerBound.toLong, upperBound.toLong, numPartitions.toInt) | ||
| partitionColumn, lowerBound.toLong, upperBound.toLong, numPartitions.get) |
There was a problem hiding this comment.
is this safe to call get on? calling get on an option is always dangerous and not future proof, especially when there is no if (x.isDefined) check surrounding this.
There was a problem hiding this comment.
Thank you for review, @rxin . Yes. It implicitly depends on that partitionColumn requires all others columns before.
I'll change here like this. Is it better?
- val partitionInfo = if (partitionColumn == null) {
+ val partitionInfo = if (partitionColumn == null || lowerBound == null || upperBound == null ||
+ numPartitions.isEmpty) {
There was a problem hiding this comment.
If you are doing this, how about changing partitionColumn, lowerBound, upperBound to Option types as well?
There was a problem hiding this comment.
Sure! No problem. I'll update them tonight.
SparkQA
commented
Nov 22, 2016
Test build #69019 has finished for PR 15966 at commit
|
dongjoon-hyun
commented
Nov 22, 2016
The only one failure seems to be irrelevant to this. |
SparkQA
commented
Nov 22, 2016
Test build #69024 has finished for PR 15966 at commit
|
dongjoon-hyun
commented
Nov 22, 2016
Hi, @rxin . |
dongjoon-hyun
commented
Nov 24, 2016
Hi, @rxin , @cloud-fan , @gatorsmile . |
SparkQA
commented
Nov 24, 2016
Test build #69104 has finished for PR 15966 at commit
|
dongjoon-hyun
commented
Nov 24, 2016
The only one failure is irrelevant to this PR. |
dongjoon-hyun
commented
Nov 24, 2016
Retest this please. |
SparkQA
commented
Nov 24, 2016
Test build #69112 has started for PR 15966 at commit |
dongjoon-hyun
commented
Nov 24, 2016
Maybe something internal errors. |
dongjoon-hyun
commented
Nov 24, 2016
Retest this please. |
SparkQA
commented
Nov 24, 2016
Test build #69125 has finished for PR 15966 at commit
|
SparkQA
commented
Nov 24, 2016
Test build #69126 has finished for PR 15966 at commit
|
cloud-fan
commented
Nov 24, 2016
LGTM |
dongjoon-hyun
commented
Nov 24, 2016
Thank you, @cloud-fan ! |
| val numPartitions = jdbcOptions.numPartitions | ||
| val partitionInfo = if (partitionColumn == null) { | ||
| val partitionInfo = if (partitionColumn.isEmpty || lowerBound.isEmpty || upperBound.isEmpty || |
There was a problem hiding this comment.
I'd change this to
if (partitionColumn == null) {
assert(lowerBound.isEmpty && upperBound.isEmpty && numPartitions.isEmpty)
null
} else {
...
}
to be future proof.
There was a problem hiding this comment.
Thanks. I'll update soon.
There was a problem hiding this comment.
I assumed the following.
if (partitionColumn.isEmpty) {
assert(lowerBound.isEmpty && upperBound.isEmpty && numPartitions.isEmpty)
null
} else {
...
}There was a problem hiding this comment.
Ur, @rxin .
We are using numPartitions for both writing and reading, and numPartitions can be used alone.
There was a problem hiding this comment.
I'll use the following.
valpartitionInfo=if (partitionColumn.isEmpty) {
assert(lowerBound.isEmpty && upperBound.isEmpty)
null
} else {
assert(lowerBound.nonEmpty && upperBound.nonEmpty && numPartitions.nonEmpty)
JDBCPartitioningInfo(
partitionColumn.get, lowerBound.get, upperBound.get, numPartitions.get)
}rxin
commented
Nov 25, 2016
LGTM other than that one change. |
SparkQA
commented
Nov 25, 2016
Test build #69143 has finished for PR 15966 at commit
|
rxin
commented
Nov 25, 2016
Thanks - merging in master. |
dongjoon-hyun
commented
Nov 25, 2016
Thank you for review and merging, @rxin , @gatorsmile , @cloud-fan ! |
…ections` ## What changes were proposed in this pull request? This is a follow-up PR of apache#15868 to merge `maxConnections` option into `numPartitions` options. ## How was this patch tested? Pass the existing tests. Author: Dongjoon Hyun <dongjoon@apache.org> Closesapache#15966 from dongjoon-hyun/SPARK-18413-2.
…ections` ## What changes were proposed in this pull request? This is a follow-up PR of apache#15868 to merge `maxConnections` option into `numPartitions` options. ## How was this patch tested? Pass the existing tests. Author: Dongjoon Hyun <dongjoon@apache.org> Closesapache#15966 from dongjoon-hyun/SPARK-18413-2.
What changes were proposed in this pull request?
This is a follow-up PR of #15868 to merge
maxConnectionsoption intonumPartitionsoptions.How was this patch tested?
Pass the existing tests.