Uh oh!
There was an error while loading. Please reload this page.
Spark 3.4: IcebergSource extends SessionConfigSupport - #7732
Conversation
dramaticlly
left a comment
There was a problem hiding this comment.
LGTM, excited to use SQL syntax to influence spark write options. I am curious to see if similar can be applied to DELETE and MERGE INTO which can only be achieved via SQL today in iceberg
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
pan3793
commented
Jun 1, 2023
@dramaticlly thanks, I refined the test code. |
pan3793
commented
Jun 6, 2023
Kindly ping @RussellSpitzer@aokolnychyi@rdblue |
This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions. |
This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time. |
szehon-ho
left a comment
There was a problem hiding this comment.
This looks good to me, small suggestion for the test, let me know what you think
| withSQLConf( | ||
| // set write option through session configuration | ||
| ImmutableMap.of("spark.datasource.iceberg.overwrite-mode", "dynamic"), |
There was a problem hiding this comment.
suggestion, wdyt to test with snapshot-property and assert that its set explicitly? It may make the test a bit more clear without needing to understand what overwrite-mode is?
There was a problem hiding this comment.
@szehon-ho Hmm.. sorry I don't get your point.
Let me explain my idea briefly, the test case should cover both the read and write paths:
- create a table, write some data into the table, and record the snapshot as
s1 - overwrite the table with dynamic overwrite mode (test setting write options through session conf) and check the current snapshot of the table
- read the table from the snapshot
s1(test setting read options through session conf) and check the data
There was a problem hiding this comment.
Yea sorry, i was not clear. Its just a suggestion.
I think, because the test is to test SessionConfigSupport functionality only, it may be more clear for the reader if the first check (on write part) is like:
'spark.datasource.iceberg.snapshot-property.foo=bar'
and then check if foo is set on latest snapshot summary?
Because i think the reader of the test need to know what is 'dynamic overwrite' mode to understand the assert (its not related to the feature), whereas the above is a bit more self-explanatory imo.
I think the read part is decently understandable without additional context.
There was a problem hiding this comment.
Thanks for the detailed description. I am educated because I didn't know that Iceberg can add custom snapshot properties through options. I update the test case to follow the suggestions.
75d88fa to
b21335aComparepan3793
commented
Nov 18, 2024
rebased on the latest main branch |
| withSQLConf( | ||
| // set write option through session configuration | ||
| ImmutableMap.of("spark.datasource.iceberg.overwrite-mode", "dynamic"), |
There was a problem hiding this comment.
Yea sorry, i was not clear. Its just a suggestion.
I think, because the test is to test SessionConfigSupport functionality only, it may be more clear for the reader if the first check (on write part) is like:
'spark.datasource.iceberg.snapshot-property.foo=bar'
and then check if foo is set on latest snapshot summary?
Because i think the reader of the test need to know what is 'dynamic overwrite' mode to understand the assert (its not related to the feature), whereas the above is a bit more self-explanatory imo.
I think the read part is decently understandable without additional context.
| * over any namespace resolution. | ||
| */ | ||
| public class IcebergSource implements DataSourceRegister, SupportsCatalogOptions { | ||
| public class IcebergSource |
There was a problem hiding this comment.
Another comment, is it now multiple ways to configure properties (including #4011), it may be confusing to user. Worth to add a documentation about it, listing the precedence, ie:
I guess using dataframe API (to be double-checked)
- explicit dataframe option
- dataframe session default
- if table exists, explicit table option
- if table exists, table default
There was a problem hiding this comment.
I updated the docs and hope it's clear now.
| ### Write options | ||
| Spark write options are passed when configuring the DataFrameWriter, like this: | ||
| Spark write options are passed when configuring the DataFrameWriterV2, like this: |
There was a problem hiding this comment.
I replaced the example with DataFrameWriterV2 because
iceberg/docs/docs/spark-writes.md
Line 264 in 319f29e
| | vectorization-enabled | As per table property | Overrides this table's read.parquet.vectorization.enabled | | ||
| | batch-size | As per table property | Overrides this table's read.parquet.vectorization.batch-size | | ||
| | stream-from-timestamp | (none) | A timestamp in milliseconds to stream from; if before the oldest known ancestor snapshot, the oldest will be used | | ||
| Iceberg 1.8.0 and later support setting read options by Spark session configuration `spark.datasource.iceberg.<key>=<value>` |
There was a problem hiding this comment.
I think this is good, but was also thinking of adding a section for priority as well as mentioned.
There was a problem hiding this comment.
This can be in its own section, like "session level configuration"?
| when using DataFrame to read Iceberg tables, for example: `spark.datasource.iceberg.split-size=512m`, it has lower priority | ||
| than options explicitly passed to DataFrameReader. | ||
| | Spark option | Default | Description | |
There was a problem hiding this comment.
I think we can revert change to this table?
There was a problem hiding this comment.
it was auto-formatted by IDEA, reverted
362ccac to
ea7a515Comparepan3793
commented
Nov 21, 2024
@szehon-ho WDYT of the current state? I keep the docs change minimally in this patch. |
| | vectorization-enabled | As per table property | Overrides this table's read.parquet.vectorization.enabled | | ||
| | batch-size | As per table property | Overrides this table's read.parquet.vectorization.batch-size | | ||
| | stream-from-timestamp | (none) | A timestamp in milliseconds to stream from; if before the oldest known ancestor snapshot, the oldest will be used | | ||
| Iceberg 1.8.0 and later support setting read options by Spark session configuration `spark.datasource.iceberg.<key>=<value>` |
There was a problem hiding this comment.
This can be in its own section, like "session level configuration"?
| .append() | ||
| ``` | ||
| Iceberg 1.8.0 and later support setting write options by Spark session configuration `spark.datasource.iceberg.<key>=<value>` |
There was a problem hiding this comment.
If we extract to its own section, no need to repeat it?
There was a problem hiding this comment.
I write it here because it's "Write options", actually, Spark has different concepts to allow the format/extensions to control the behavior, i.e. table properties, session configurations, options.
| .table("catalog.db.table") | ||
| ``` | ||
| Iceberg 1.8.0 and later support setting read options by Spark session configuration `spark.datasource.iceberg.<key>=<value>` |
There was a problem hiding this comment.
I still think we need new section like 'Configuration Priority' where we can explain the order of precedence:
DataFrame Writes:
- explicit dataframeWriter option
- dataframe session default
- if table exists, explicit table option
- if table exists, table default
DataFrame Reads:
- explicit dataFrameReader option
- dataframe session default
- if table exists, explicit table option
- if table exists, table default
(please double check)
There was a problem hiding this comment.
I hesitate to write such a section because the situation looks more complex, some configurations are allowed to be set by dedicated session configuration, for example
public boolean localityEnabled() {
boolean defaultValue = Util.mayHaveBlockLocations(table.io(), table.location());
return confParser
.booleanConf()
.option(SparkReadOptions.LOCALITY)
.sessionConf(SparkSQLProperties.LOCALITY)
.defaultValue(defaultValue)
.parse();
}
This reverts commit ea7a515.
This reverts commit d3b9f9d.
pan3793
commented
Nov 22, 2024
@szehon-ho I made a minor change on assertion statement after your approval, also create two backports PR for Spark 3.3 and 3.5, thanks for your detailed review. |
szehon-ho
commented
Nov 22, 2024
Sure, thanks its a good catch, assertThat is better. |
szehon-ho
commented
Nov 23, 2024
Merged, thanks @pan3793 |
This PR aims to make
IcebergSource extends SessionConfigSupportto improve the Spark DataSource v2 API coverage.It allows to set read/write options by setting Spark session configuration when using the DataFrame API to read/write tables. For examples,