Можно ли уменьшить количество проверок MetaStore при запросе таблицы Hive с большим количеством столбцов? - PullRequest
Новая
       80

Можно ли уменьшить количество проверок MetaStore при запросе таблицы Hive с большим количеством столбцов?

2 голосов
/ 09 января 2020

Я использую spark sql на кирпичах данных, в которых используется метасторное хранилище Hive, и пытаюсь настроить задание / запрос, который использует довольно много столбцов (20+).

Время, необходимое для выполнения проверок проверки метастазов линейно масштабируется с количеством столбцов, включенных в мой запрос - есть ли способ пропустить этот шаг? Или предварительно рассчитать чеки? Или, по крайней мере, сделать так, чтобы метастроение проверяло только один раз для каждой таблицы, а не один раз для столбца?

Небольшой пример: когда я запускаю приведенное ниже, даже перед вызовом отображения или сбора, проверка метастазов происходит один раз: 

new_table = table.withColumn("new_col1", F.col("col1")

, и когда я запускаю нижеприведенное, проверка метастазов происходит несколько раз и, следовательно, занимает больше времени: 

new_table = (table
.withColumn("new_col1", F.col("col1")
.withColumn("new_col2", F.col("col2")
.withColumn("new_col3", F.col("col3")
.withColumn("new_col4", F.col("col4")
.withColumn("new_col5", F.col("col5")
)

Метастор проверяет, что в узле драйвера все выглядит так: 

20/01/09 11:29:24 INFO HiveMetaStore: 6: get_database: xxx
20/01/09 11:29:24 INFO audit: ugi=root    ip=unknown-ip-addr    cmd=get_database: xxx

Вид пользователя для блоков данных: 

Performing Hive catalog operation: databaseExists
Performing Hive catalog operation: tableExists
Performing Hive catalog operation: getRawTable
Running command...

Мне было бы интересно узнать, может ли кто-нибудь подтвердить, что это именно так, как работает (проверка метастазов в столбце) и если мне нужно просто спланировать накладные расходы на проверку метастазов.

1 Ответ

2 голосов
/ 21 января 2020

Меня удивляет такое поведение, поскольку оно не соответствует модели обработки Spark, и я не могу воспроизвести его в Scala. Вполне возможно, что он каким-то образом указан c для PySpark, но я сомневаюсь, что, поскольку PySpark - это просто API для создания планов Spark. проанализированы. Если план большой, это может занять некоторое время. Однако есть простая оптимизация. Замените несколько вызовов withColumn(...) для независимых столбцов на df.select(F.col("*"), F.col("col2").as("new_col2"), ...). В этом случае будет выполнен только один анализ.

В некоторых случаях очень больших планов мы сохранили 10+ минут анализа для одной ячейки ноутбука.

...