您的评论是正确的。你的问题有点含糊。但是,我同意你的观点,并且发现这些概念也很好,并且也受到这类问题的影响,所以你去吧。
所以,这现在可以用于 DataFrame API,而不是您所说的 DataSet 或 DSL。
SELECT A.dep_id,
A.employee_id,
A.age,
(SELECT MAX(age)
FROM employee B
WHERE A.dep_id = B.dep_id) max_age
FROM employee A
ORDER BY 1,2
一个例子——从互联网上借来的,清楚地显示了 DS 和 DF 之间的区别,这意味着 SPARK SQL 相关子查询(当然这里没有显示)也不会发生在 DataSet 上——通过推论:
sql("SELECT COUNT(*) FROM src").show()
val sqlDF = sql("SELECT key, value FROM src WHERE key < 10 ORDER BY key")
val stringsDS = sqlDF.map {case Row(key: Int, value: String) => s"Key: $key, Value: $value"}
stringsDS.show()
SQL 针对 Hive 或 Parquet 等源或针对 SPARK TempViews 运行,而不针对 DS。您可以从 DF 转到 DS,然后享受更多类型安全的方法,但只能使用有限的选择界面。我做了很好的搜索以找到反驳这一点的东西,但事实并非如此。正如我之前所说的那样,DS 和 DF 无论如何都是可以互换的。但是,我看你很彻底!
此外,至少有 2 种技术可以将 Nested-Correlated=Subqueries 转换为“正常”JOIN,这正是 SPARK 和其他优化器在后台执行的操作。例如。重写CorrelatedScalarSubquery 和PullupCorrelatedPredicate。
但是对于您提到的 DSL,您可以通过使用 JOIN、LEFT JOIN、OUTER JOIN 手动重新编写查询以实现相同的目的,无论情况如何。奇怪的是,这并不是那么明显。