apache spark - ¿Algún problema de rendimiento que obligue a una evaluación entusiasta usando count in spark?

apache-spark

Question

Comúnmente veo Dataset.count largo de las bases de código en 3 escenarios:

1. logging log.info("this ds has ${dataset.count} rows")
2. ramificación if (dataset.count > 0) do x else do y
3. forzar un caché dataset.persist.count

¿Evita que el optimizador de consultas cree el dag más eficiente al forzarlo a ser prematuro en cualquiera de esos escenarios?

Answer 1

TL; DR 1) y 2) por lo general pueden evitarse pero no deberían dañarlo (ignorando el costo de la evaluación), 3) es una práctica dañina de programación de culto de Cargo .

Sin cache

Llamar a count solo es en su mayor parte un desperdicio. Si bien no siempre es sencillo, el registro se puede reemplazar con la información recuperada de los oyentes ( aquí hay un ejemplo de RDD ), y los requisitos de flujo de control generalmente (no siempre) están mediados por un mejor diseño de canalización.

Solo no tendrá ningún impacto en el plan de ejecución (el plan de ejecución para el conteo, normalmente es diferente del plan de ejecución del padre. En general, Spark hace el menor trabajo posible, por lo que eliminará partes del plan de ejecución, que no están obligados a calcular la cuenta).

Con cache :

count con cache es una mala práctica copiada ingenuamente de patrones utilizados con la API de RDD. Ya es discutible con los RDDs , pero con DataFrame puede romper muchas optimizaciones internas (selección y empuje de predicados) y técnicamente hablando, ni siquiera se garantiza que funcione .