Загружались ли данные с фреймов искры лениво? - PullRequest
Новая
       13

Загружались ли данные с фреймов искры лениво?

0 голосов
/ 17 мая 2018

Я хочу запустить sql для своих данных паркета в spark, используя следующий код, 

val parquetDF = spark.read.parquet(path)
parquetDF.createOrReplaceTempView("table_name")
val df = spark.sql("select column_1, column_4, column 10 from table_name");
println(df.count())

Мой вопрос: Этот код считывает только необходимые столбцы с диска?

Теоретически ответ должен быть Да. Но мне нужно мнение эксперта, потому что в случае запросов Jdbc (Mysql), Этап чтения (spark.read) занимает больше времени по сравнению с действиями (может быть связан с подключением, но не уверен). Код Jdbc следует, 

spark.read.format("jdbc").jdbc(jdbcUrl, query, props).createOrReplaceTempView(table_name)
spark.sql("select column_1, column_4, column 10 from table_name");
df.show()
println(df.count())

Если кто-то может объяснить структуру потока в обоих случаях, это будет очень полезно.

Spark версия 2.3.0

Версия Scala 2.11.11

1 Ответ

0 голосов
/ 17 мая 2018

В обоих случаях Spark сделает все возможное (точное поведение зависит от формата и версии. В зависимости от контекста некоторые оптимизации могут не применяться, обычно с глубоко вложенными данными), чтобы ограничить трафик только необходимыми данными.На самом деле spark.sql("select ...) часть даже не релевантна, так как фактический запрос должен быть ограничен чем-то эквивалентным SELECT 1 FROM table для данного формата.

Это остается верным, если вы не используете cache / persist.Если вы это сделаете, все оптимизации пропадут, и Spark с нетерпением загрузит все данные (см. Мой ответ на Есть ли проблемы с производительностью, которые заставляют стремиться к оценке с использованием счетчика в spark? и Кэширование фреймов данных при сохранении разделов Также вот пример как план выполнения изменяется при использовании кэша.).

...