шаги в физическом плане искры не назначены шагу DAG - PullRequest
Новая
       106

шаги в физическом плане искры не назначены шагу DAG

1 голос
/ 10 февраля 2020

Я пытаюсь отладить простой запрос в spark SQL, который возвращает неверные данные.

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

вот пример запроса 

from pyspark_llap import HiveWarehouseSession
hive = HiveWarehouseSession.session(spark).build()

filter_1 = hive.executeQuery('select * from 03_score where scores = 5 or scores = 6')
filter_2 = hive.executeQuery('select * from 03_score where scores = 8')


joined_df = filter_1.alias('o').join(filter_2.alias('po'), filter_1.encntr_id == filter_2.encntr_id, how='inner')
joined_df.count() ### shows incorrect value ### 
joined_df.explain(True)

пример физического плана, возвращаемого искрой 

== Physical Plan ==
 SortMergeJoin [encntr_id#0], [encntr_id#12], Inner
:- *(2) Sort [encntr_id#0 ASC NULLS FIRST], false, 0
:  +- Exchange hashpartitioning(encntr_id#0, 200)
:     +- *(1) Filter isnotnull(encntr_id#0)
:        +- *(1) DataSourceV2Scan [encntr_id#0, scores_datetime#1, scores#2], com.hortonworks.spark.sql.hive.llap.HiveWarehouseDataSourceReader@a6df563
+-  Sort [encntr_id#12 ASC NULLS FIRST], false, 0
   +- Exchange hashpartitioning(encntr_id#12, 200)
      +-  Filter isnotnull(encntr_id#12)
         +- DataSourceV2Scan [encntr_id#12, dateofbirth#13, postcode#14, event_desc#15, event_performed_dt_tm#16], com.hortonworks.spark.sql.hive.llap.HiveWarehouseDataSourceReader@60dd22d9

Обратите внимание, что сканирование всех источников данных, обмен фильтрами и сортировке с правой стороны объединения не был присвоен идентификатор заказа.

Может кто-нибудь пролить свет на этот вопрос для меня .. Почему физическому плану, который выглядит правильно, не будет присвоен идентификатор заказа на оценку ?

1 Ответ

0 голосов
/ 12 февраля 2020

понял это внутренне.

Оказывается, что на процедуру оптимизации зажигания может влиять параметр конфигурации

spark. sql .codegen.Maxfields

, который может повлиять на оптимизацию искры. чтение из «толстых» таблиц.

В моем случае настройка была установлена ​​на низкое значение, что означает, что этапы DAG чтения с правой стороны объединения («толстая» таблица) выполнялись без назначения на целую стадию codegen.

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

...