我通常看到Dataset.count在 3 个场景中的整个代码库：
- logging
log.info("this ds has ${dataset.count} rows")
- 分枝
if (dataset.count > 0) do x else do y
- 强制缓存
dataset.persist.count
它是否会通过强制查询优化器在任何这些场景中过早地急切来阻止查询优化器创建最有效的 dag？
TL;DR1) 和 2) 通常可以避免，但不会对您造成伤害（忽略评估成本），3) 通常是有害的货物崇拜编程 https://en.wikipedia.org/wiki/Cargo_cult_programming实践。
Without cache
Calling count独自一人大多是浪费。虽然并不总是那么简单，但可以用从侦听器检索的信息来替换日志记录（这是 RDD 的示例 https://stackoverflow.com/q/37496650/9613318），并且控制流要求通常（并非总是）可以通过更好的管道设计来调节。
单独它不会对执行计划产生任何影响（计数的执行计划通常与父级的执行计划不同。一般来说，Spark 会做尽可能少的工作，因此它会删除部分执行计划，这不需要计算计数）。
With cache:
count with cache是从 RDD API 使用的模式中天真复制的糟糕做法。已经有争议了RDDs，但与DataFrame can 打破了很多内部优化 https://stackoverflow.com/q/49798098/9613318（选择和谓词下推）从技术上讲，甚至不能保证工作 http://apache-spark-developers-list.1001551.n3.nabble.com/Will-count-always-trigger-an-evaluation-of-each-row-tp21018p21024.html.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
