Adaptive query execution in Apache Spark - Mini Project: Build & Apply
sales_df with these exact rows: ("Store1", "2024-01-01", 100), ("Store2", "2024-01-01", 150), ("Store1", "2024-01-02", 200), ("Store2", "2024-01-02", 300). Use columns named store, date, and sales.Use spark.createDataFrame() with a list of tuples and specify the schema as a list of column names.
spark.sql.adaptive.enabled to true using spark.conf.set.Use spark.conf.set with the key "spark.sql.adaptive.enabled" and value "true" (string).
agg_df by grouping sales_df by store and summing the sales column using groupBy and sum.Use sales_df.groupBy("store").sum("sales") and assign it to agg_df.
agg_df using agg_df.explain() to verify Adaptive Query Execution is enabled.Use agg_df.explain() to print the physical plan. Look for AdaptiveSparkPlanExec in the output.
Practice
What is the main purpose of adaptive query execution in Apache Spark?
Solution
Step 1: Understand adaptive query execution concept
Adaptive query execution allows Spark to change the query plan dynamically while the query runs.Step 2: Identify the main benefit
This dynamic adjustment improves performance by optimizing joins and data shuffles based on actual data size.Final Answer:
To improve query performance by adjusting the execution plan during runtime -> Option AQuick Check:
Adaptive query execution = dynamic plan adjustment [OK]
- Confusing adaptive execution with static query compilation
- Believing it disables optimization
- Thinking it requires manual query rewriting
Which Spark configuration enables adaptive query execution?
?Solution
Step 1: Recall the exact configuration key
The correct key to enable adaptive query execution isspark.sql.adaptive.enabled.Step 2: Confirm the value to enable
Setting it totrueactivates adaptive query execution.Final Answer:
spark.sql.adaptive.enabled = true -> Option DQuick Check:
Enable adaptive query with spark.sql.adaptive.enabled [OK]
- Using incorrect config keys like spark.execution.adaptive
- Setting the value to false instead of true
- Mixing up config names with similar words
Given the following Spark SQL code with adaptive query execution enabled, what will be the effect on the join?
spark.conf.set("spark.sql.adaptive.enabled", "true")
val df1 = spark.range(1000)
val df2 = spark.range(10)
val joined = df1.join(df2, df1("id") === df2("id"))
joined.explain(true)What does adaptive query execution do here?
Solution
Step 1: Identify adaptive execution behavior on join
Adaptive query execution detects small tables and converts joins to broadcast joins to reduce shuffle.Step 2: Analyze data sizes in example
df2 has only 10 rows, which is small enough to broadcast.Final Answer:
It converts the join to a broadcast join because df2 is small -> Option AQuick Check:
Small table join = broadcast join [OK]
- Assuming adaptive disables optimization
- Thinking adaptive causes errors on joins
- Believing it caches dataframes automatically
Consider this Spark code snippet with adaptive query execution enabled:
spark.conf.set("spark.sql.adaptive.enabled", "true")
val df1 = spark.range(1000)
val df2 = spark.range(1000000)
val joined = df1.join(df2, df1("id") === df2("id"))
joined.show()The job runs very slowly. What is the likely cause?
Solution
Step 1: Understand adaptive join behavior with large tables
Adaptive query execution may try to broadcast a table if it thinks it's small enough.Step 2: Analyze table sizes
df2 has 1,000,000 rows, which is too large to broadcast efficiently, causing slow execution.Final Answer:
Adaptive query execution tries to broadcast df2, which is too large -> Option BQuick Check:
Broadcasting large tables causes slow jobs [OK]
- Assuming adaptive is disabled by default
- Thinking join condition is invalid
- Believing Spark caches large tables automatically
You have a Spark job joining three datasets of unknown sizes. How can adaptive query execution help optimize this multi-join query?
Solution
Step 1: Understand adaptive query execution with multiple joins
Adaptive query execution evaluates data sizes during runtime for each join.Step 2: Explain optimization choice
It chooses broadcast joins for small tables and shuffle joins for large tables automatically.Step 3: Apply to multi-join scenario
For three datasets, it optimizes each join individually based on actual data size.Final Answer:
It dynamically chooses broadcast or shuffle joins for each join based on runtime data size -> Option CQuick Check:
Adaptive = dynamic join strategy per join [OK]
- Thinking adaptive disables joins
- Assuming all joins become shuffle joins
- Believing manual hints are always required
Ready to prove it?
Pass the test and this pattern moves unknown
