У меня есть запрос, который я выполнял в экономном порядке, который занимает очень много времени. Я запускаю его на одном разделе таблицы, в котором есть 500 тыс. Строк.
запрос выглядит так:
select col0 from <table> where partition=<partition> and <col1>=<val>
Я сделал это так col1 != val, поэтому запрос возвращает 0 строк.
Этот запрос занимает около 30 секунд (минута, если я использую select *).
Когда я запускаю точно такой же запрос, но с select count(col0), это занимает 2 секунды.
Что может заставить запросы занимать много времени с select col, но не с select count(col)?
Вот объясненные вопросы
explain select col0 from table where `partition` = partition and col=val;
* Проект [col0 # 607]
+ - * Фильтр (isnotnull (col1 # 607) && (col1 # 607 = aaaa))
+ - * FileScan parquet
таблица [col1 # 607, раздел # 611]
Пакетная: правда,
Формат: Паркет
Расположение: PrunedInMemoryFileIndex [...,
PartitionCount: 23,
PartitionFilters: [isnotnull (раздел # 611),
(приведение (раздел # 611 как int) = имя_раздела)],
PressedFilters: [IsNotNull (col1),
EqualTo (col1, аааа)]
ReadSchema: struct
explain select count(col0) from table where `partition` = partition and col=val;
* HashAggregate (keys = [], functions = [count (col0 # 625)])
+ - Обмен SinglePartition
+ - * HashAggregate (keys = [], functions = [частичный_чет (col0 # 625)])
+ - * Проект [col0 # 625]
+ - * Фильтр (isnotnull (col1 # 625) && (col1 # 625 = aaaa))
+ - * FileScan parquet
таблица [col1 # 625, раздел # 629]
Пакетная: правда,
Формат: Паркет,
Расположение: PrunedInMemoryFileIndex [...,
PartitionCount: 23,
PartitionFilters: [isnotnull (раздел # 629),
(приведение (раздел # 629 как int) = имя_раздела)],
PhedFilters: [IsNotNull (col1),
EqualTo (col1, аааа)]
ReadSchema: struct
Насколько я могу судить, процесс точно такой же, только у запроса count больше шагов. Так почему же это в 15 раз быстрее?
Редактировать
Я нашел этот интересный самородок в логах:
с количеством :
18/06/28 11:42:55 INFO TaskSetManager: запуск задачи 0.0 на этапе 2509.0 (TID 8092, ip-123456, исполнитель 36, раздел 0, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 ИНФОРМАЦИЯ TaskSetManager: запуск задачи 1.0 на этапе 2509.0 (TID 8093, ip-123456, исполнитель 35, раздел 1, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 ИНФОРМАЦИЯ TaskSetManager: запуск задачи 2.0 на этапе 2509.0 (TID 8094, ip-123456, исполнитель 36, раздел 2, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 ИНФОРМАЦИЯ TaskSetManager: запуск задачи 3.0 на этапе 2509.0 (TID 8095, ip-123456, исполнитель 35, раздел 3, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 ИНФОРМАЦИЯ TaskSetManager: запуск задачи 4.0 на этапе 2509.0 (TID 8096, ip-123456, исполнитель 36, раздел 4, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 ИНФОРМАЦИЯ TaskSetManager: запуск задачи 5.0 на этапе 2509.0 (TID 8097, ip-123456, исполнитель 35, раздел 5, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 INFO TaskSetManager: запуск задачи 6.0 на этапе 2509.0 (TID 8098, ip-123456, исполнитель 36, раздел 6, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 INFO TaskSetManager: запуск задачи 7.0 на этапе 2509.0 (TID 8099, ip-123456, исполнитель 35, раздел 7, RACK_LOCAL, 5521 байт)
18/06/28 11:42:55 ИНФОРМАЦИЯ TaskSetManager: запуск задачи 8.0 на этапе 2509.0 (TID 8100, ip-123456, исполнитель 36, раздел 8, RACK_LOCAL, 5521 байт)
18.0628 11:42:55 INFO TaskSetManager: запуск задачи 9.0 на этапе 2509.0 (TID 8101, ip-123456, исполнитель 35, раздел 9, RACK_LOCAL, 5521 байт)
18/06/28 11:45:32 INFO TaskSetManager: Запуск задачи 0.0 на этапе 2512.0 (TID 8136, ip-10-117-49-97.eu-west-1.compute. внутренний, исполнитель 37, раздел 1, RACK_LOCAL, 5532 байта)
18/06/28 11:45:32 ИНФОРМАЦИЯ BlockManagerInfo: Добавлено broadcast_2352_piece0 в памяти на ip-10-117-49-97.eu-west-1.compute.internal: 40489 (размер: 12,6 КБ, бесплатно: 11,6 ГБ)
18/06/28 11:45:32 ИНФОРМАЦИЯ TaskSetManager: Выполнено задание 0.0 на этапе 2512.0 (TID 8136) за 667 мс на ip-10-117-49-97.eu-west-1.compute.internal (исполнитель 37) (1/1)
18/06/28 11:45:32 ИНФОРМАЦИЯ YarnScheduler: Удален TaskSet 2512.0, все задачи которого выполнены, из пула
18/06/28 11:45:32 INFO DAGScheduler: ResultStage 2512 (getNextRowSet в OperationManager.java:220) завершен через 0,668 с
18/06/28 11:45:32 ИНФОРМАЦИЯ DAGScheduler: задание 2293 выполнено: getNextRowSet в OperationManager.java:220, заняло 0,671740 с
18/06/28 11:45:32 ИНФОРМАЦИЯ SparkContext: запуск задания: getNextRowSet at OperationManager.java:220
18/06/28 11:45:32 INFO DAGScheduler: получил задание 2294 (getNextRowSet в OperationManager.java:220) с 1 выходным разделом
18/06/28 11:45:32 ИНФОРМАЦИЯ DAGScheduler: Финальный этап: ResultStage 2513 (getNextRowSet в OperationManager.java:220)
18/06/28 11:45:32 ИНФОРМАЦИЯ DAGScheduler: Родители финальной стадии: Список ()
18/06/28 11:45:32 ИНФОРМАЦИЯ DAGScheduler: Пропавшие родители: Список ()
18/06/28 11:45:32 ИНФОРМАЦИЯ DAGScheduler: отправка ResultStage 2513 (MapPartitionsRDD [312] при запуске в AccessController.java:0), в котором нет отсутствующих родителей
18/06/28 11:45:32 INFO MemoryStore: блокировать трансляцию_2353, сохраненную в виде значений в памяти (приблизительный размер 66,6 КБ, бесплатно 12,1 ГБ)
18/06/28 11:45:32 INFO MemoryStore: блокировать трансляцию_2353_piece0 в виде байтов в памяти (примерный размер 12,6 КБ, бесплатно 12,1 ГБ)
18.0628 11:45:32 ИНФОРМАЦИЯ BlockManagerInfo: Добавлено широковещательное_2353_piece0 в памяти 10.117.48.68:41493 (размер: 12,6 КБ, бесплатно: 12,1 ГБ)
18/06/28 11:45:32 ИНФОРМАЦИЯ SparkContext: Создана трансляция 2353 из трансляции на DAGScheduler.scala: 1047
18/06/28 11:45:32 INFO DAGScheduler: отправка 1 отсутствующих задач из ResultStage 2513 (MapPartitionsRDD [312] при запуске в AccessController.java:0) (первые 15 задач предназначены для разделов
Vector (2))
18/06/28 11:45:32 ИНФОРМАЦИЯ YarnScheduler: Добавление набора задач 2513.0 с 1 задачей
18/06/28 11:45:32 ИНФОРМАЦИЯ TaskSetManager: Запуск задачи 0.0 на этапе 2513.0 (TID 8137, ip-10-117-49-97.eu-west-1.compute.internal, executor 37, раздел 2, RACK_LOCAL, 5532 байта)
18/06/28 11:45:33 ИНФОРМАЦИЯ BlockManagerInfo: добавлено broadcast_2353_piece0 в памяти на ip-10-117-49-97.eu-west-1.compute.internal: 40489 (размер: 12,6 КБ, бесплатно: 11,6 ГБ)
18/06/28 11:45:38 ИНФОРМАЦИЯ TaskSetManager: Выполнено задание 0.0 на этапе 2513.0 (TID 8137) за 5238 мс на ip-10-117-49-97.eu-west-1.compute.internal (исполнитель 37) (1/1)
18/06/28 11:45:38 ИНФОРМАЦИЯ YarnScheduler: удален набор задач 2513.0, задачи которого выполнены, из пула
18/06/28 11:45:38 ИНФОРМАЦИЯ DAGScheduler: ResultStage 2513 (getNextRowSet в OperationManager.java:220) завершена за 5,238 с
18/06/28 11:45:38 ИНФОРМАЦИЯ DAGScheduler: задание 2294 выполнено: getNextRowSet в OperationManager.java:220, заняло 5,242084 с
18/06/28 11:45:38 ИНФОРМАЦИЯ SparkContext: запуск задания: getNextRowSet at OperationManager.java:220
18/06/28 11:45:38 INFO DAGScheduler: получено задание 2295 (getNextRowSet в OperationManager.java:220) с 1 выходным разделом
18/06/28 11:45:38 INFO DAGScheduler: Финальный этап: ResultStage 2514 (getNextRowSet в OperationManager.java:220)
18/06/28 11:45:38 ИНФОРМАЦИЯ DAGScheduler: Родители финальной стадии: Список ()
18/06/28 11:45:38 ИНФОРМАЦИЯ DAGScheduler: Пропавшие родители: Список ()
18/06/28 11:45:38 ИНФОРМАЦИЯ DAGScheduler: отправка ResultStage 2514 (MapPartitionsRDD [312] при запуске в AccessController.java:0), в котором нет отсутствующих родителей
18/06/28 11:45:38 INFO MemoryStore: блокировать широковещательную передачу_2354 в виде значений в памяти (расчетный размер 66,6 КБ, свободных 12,1 ГБ)
18/06/28 11:45:38 INFO MemoryStore: блокировать трансляцию_2354_piece0 в виде байтов в памяти (примерный размер 12,6 КБ, бесплатно 12,1 ГБ)
18.0628 11:45:38 ИНФОРМАЦИЯ BlockManagerInfo: Добавлено широковещательное сообщение_2354_piece0 в памяти 10.117.48.68:41493 (размер: 12,6 КБ, бесплатно: 12,1 ГБ)
18/06/28 11:45:38 ИНФОРМАЦИЯ SparkContext: Создана трансляция 2354 из трансляции на DAGScheduler.scala: 1047
18/06/28 11:45:38 ИНФОРМАЦИЯ DAGScheduler: отправка 1 отсутствующих задач из ResultStage 2514 (MapPartitionsRDD [312] при запуске в AccessController.java:0) (первые 15 задач предназначены для разделов Vector (3))
(т.е. он повторяет этот блок, похоже, что он выполняет задачи последовательно, а не параллельно, как в случае подсчета)
Я также попытался выполнить команду "упорядочить по", и это фактически заставило запрос выполняться в 2 раза быстрее
Выполнение одного и того же запроса к тем же данным с использованием spark вместо thrift было намного быстрее.
Я запускаю thrift на aws emr-5.11.1
Улей 2.3.2
Искра 2.2.1
Экономия 0.11.0