Какие-то проблемы с производительностью заставляют стремиться к оценке с помощью счетчика в искре?

Question

Обычно я вижу Dataset.count в кодовых базах в 3 сценариях:

1. регистрация log.info("this ds has ${dataset.count} rows")
2. ветвление if (dataset.count > 0) do x else do y
3. форсировать кеш dataset.persist.count

Предотвращает ли это оптимизатор запросов от создания наиболее эффективного dag, заставляя его стремиться преждевременно в любом из этих сценариев?

Answer 1

TL; DR 1) и 2) обычно можно избежать, но не должно причинять вам вреда (игнорируя стоимость оценки), 3) обычно является вредным Программирование культа грузов практика.

Без cache

Вызов только count в большинстве случаев расточителен.Хотя регистрация не всегда проста, ее можно заменить информацией, полученной от слушателей (здесь приведен пример и пример для RDD ), а требования к потоку управления обычно (не всегда) опосредуются улучшенной схемой конвейера.

В одиночку это не окажет никакого влияния на план выполнения (план выполнения для count обычно в любом случае отличается от плана выполнения родительского элемента. Обычно Spark выполняет как можно меньше работы, поэтому он удаляет части выполненияплан, который не требуется для вычисления количества).

С cache:

count с cache - это плохая практика, наивно копируемая из шаблонов, используемых сRDD API.Это уже спорно с RDDs, но с DataFrame может сломать много внутренних оптимизаций (выбор и сказуемое Pushdown) и технически говоря, даже не гарантируется работа .