4fceef0159
### What changes were proposed in this pull request? The changes being proposed are to increase the accuracy of JDBCRelation's stride calculation, as outlined in: https://issues.apache.org/jira/browse/SPARK-34843 In summary: Currently, in JDBCRelation (line 123), the stride size is calculated as follows: val stride: Long = upperBound / numPartitions - lowerBound / numPartitions Due to truncation happening on both divisions, the stride size can fall short of what it should be. This can lead to a big difference between the provided upper bound and the actual start of the last partition. I'm proposing a different formula that doesn't truncate to early, and also maintains accuracy using fixed-point decimals. This helps tremendously with the size of the last partition, which can be even more amplified if there is data skew in that direction. In a real-life test, I've seen a 27% increase in performance with this more proper stride alignment. The reason for fixed-point decimals instead of floating-point decimals is because inaccuracy due to limitation of what the float can represent. This may seem small, but could shift the midpoint a bit, and depending on how granular the data is, that could translate to quite a difference. It's also just inaccurate, and I'm striving to make the partitioning as accurate as possible, within reason. Lastly, since the last partition's predicate is determined by how the strides align starting from the lower bound (plus one stride), there can be skew introduced creating a larger last partition compared to the first partition. Therefore, after calculating a more precise stride size, I've also introduced logic to move the first partition's predicate (which is an offset from the lower bound) to a position that closely matches the offset of the last partition's predicate (in relation to the upper bound). This makes the first and last partition more evenly distributed compared to each other, and helps with the last task being the largest (reducing its size). ### Why are the changes needed? The current implementation is inaccurate and can lead to the last task/partition running much longer than previous tasks. Therefore, you can end up with a single node/core running for an extended period while other nodes/cores are sitting idle. ### Does this PR introduce _any_ user-facing change? No. I would suspect some users will just get a good performance increase. As stated above, if we were to run our code on Spark that has this change implemented, we would have all of the sudden got a 27% increase in performance. ### How was this patch tested? I've added two new unit tests. I did need to update one unit test, but when you look at the comparison of the before and after, you'll see better alignment of the partitioning with the new implementation. Given that the lower partition's predicate is exclusive and the upper's is inclusive, the offset of the lower was 3 days, and the offset of the upper was 6 days... that's potentially twice the amount of data in that upper partition (could be much more depending on how the user's data is distributed). Other unit tests that utilize timestamps and two partitions have maintained their midpoint. ### Examples I've added results with and without the realignment logic to better highlight both improvements this PR brings. **Example 1:** Given the following partition config: "lowerBound" -> "1930-01-01" "upperBound" -> "2020-12-31" "numPartitions" -> 1000 _Old method (exactly what it would be BEFORE this PR):_ First partition: "PartitionColumn" < '1930-02-02' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2017-07-11' _Old method, but with new realingment logic of first partition:_ First partition: "PartitionColumn" < '1931-10-14' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2019-03-22' _New method:_ First partition: "PartitionColumn" < '1930-02-03' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2020-04-05' _New with new realingment logic of first partition (exactly what it would be AFTER this PR):_ First partition: "PartitionColumn" < '1930-06-02' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2020-08-02' **Example 2:** Given the following partition config: "lowerBound" -> "1927-04-05", "upperBound" -> "2020-10-16" "numPartitions" -> 2000 _Old method (exactly what it would be BEFORE this PR):_ First partition: "PartitionColumn" < '1927-04-21' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2014-10-29' _Old method, but with new realingment logic of first partition::_ First partition: "PartitionColumn" < '1930-04-07' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2017-10-15' _New method:_ First partition: "PartitionColumn" < '1927-04-22' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2020-04-19' _New method with new realingment logic of first partition (exactly what it would be AFTER this PR):_ First partition: "PartitionColumn" < '1927-07-13' or "PartitionColumn" is null Last partition: "PartitionColumn" >= '2020-07-10' Closes #31965 from hanover-fiste/SPARK-34843. Authored-by: hanover-fiste <jyarbrough.git@gmail.com> Signed-off-by: Sean Owen <srowen@gmail.com> |
||
|---|---|---|
| .. | ||
| catalyst | ||
| core | ||
| hive | ||
| hive-thriftserver | ||
| create-docs.sh | ||
| gen-sql-api-docs.py | ||
| gen-sql-config-docs.py | ||
| gen-sql-functions-docs.py | ||
| mkdocs.yml | ||
| README.md | ||
Spark SQL
This module provides support for executing relational queries expressed in either SQL or the DataFrame/Dataset API.
Spark SQL is broken up into four subprojects:
- Catalyst (sql/catalyst) - An implementation-agnostic framework for manipulating trees of relational operators and expressions.
- Execution (sql/core) - A query planner / execution engine for translating Catalyst's logical query plans into Spark RDDs. This component also includes a new public interface, SQLContext, that allows users to execute SQL or LINQ statements against existing RDDs and Parquet files.
- Hive Support (sql/hive) - Includes extensions that allow users to write queries using a subset of HiveQL and access data from a Hive Metastore using Hive SerDes. There are also wrappers that allow users to run queries that include Hive UDFs, UDAFs, and UDTFs.
- HiveServer and CLI support (sql/hive-thriftserver) - Includes support for the SQL CLI (bin/spark-sql) and a HiveServer2 (for JDBC/ODBC) compatible server.
Running ./sql/create-docs.sh generates SQL documentation for built-in functions under sql/site, and SQL configuration documentation that gets included as part of configuration.md in the main docs directory.