Предположим, у меня есть Таблица1 и Таблица2, каждый с одинаковыми 3 столбцами: Месяц, День и Значение. Месяц и день - это разделенные столбцы, а значение - нет.
Я использую этот запрос:
select count(*) from
(
select * from Table1
)t1
left join
(
select * from Table2
left join
)t2
on(t1.month=T2.month and t1.day=t2.day and t1.value=t2.value)
Распределение данных является ключевым для этого примера, поэтому предположим, что разделы распределены следующим образом:
Table | Partition-set | Node location
-------------------------------------------
Table 1 May-12 Node 1
Table 1 May-13 Node 1
Table 1 May-14 Node 1
Table 1 May-15 Node 1
Table 1 May-16 Node 1
Table 1 May-17 Node 2
Table 1 May-18 Node 2
Table 2 May-09 Node 1
Table 2 May-10 Node 1
Table 2 May-11 Node 1
Table 2 May-12 Node 1
Table 2 May-13 Node 1
Table 2 May-14 Node 2
Table 2 May-17 Node 2
Я хотел бы знать, как менеджер Cloudera будет выполнять эту работу.
Я разделю процесс объединения на 2 части:
1-) Как данные распределяются по каждому узлу, так что соединение возможно:
Посмотрев здесь:
https://www.cloudera.com/documentation/enterprise/5-9-x/topics/impala_hints.html
Я видел 2 способа вовлечения разделов в объединение:
[Broadcast]: заставляет присоединяющуюся операцию использовать метод "broadcast", который отправляет все содержимое правой таблицы всем узлам, участвующим в обработке объединения.
Я понимаю, что это означает, что если оба узла будут выбраны для участия в соединении, им будет отправлено содержимое всех узлов. Таблица на этом первом шаге будет выглядеть следующим образом:
Table | Partition-set | Node location | Node origin
--------------------------------------------------------------
-- Added info ( Both nodes are choosen to host the join, so that we put all missing info in both)
Table 1 May-17 Node 1 Node 2
Table 1 May-18 Node 1 Node 2
Table 2 May-14 Node 1 Node 2
Table 2 May-17 Node 1 Node 2
Table 1 May-12 Node 2 Node 1
Table 1 May-13 Node 2 Node 1
Table 1 May-14 Node 2 Node 1
Table 1 May-15 Node 2 Node 1
Table 1 May-16 Node 2 Node 1
Table 2 May-09 Node 2 Node 1
Table 2 May-10 Node 2 Node 1
Table 2 May-11 Node 2 Node 1
Table 2 May-12 Node 2 Node 1
Table 2 May-13 Node 2 Node 1
[SHUFFLE]: заставляет присоединяющуюся операцию использовать технику «секционирования», которая разделяет соответствующие строки из обеих таблиц с использованием алгоритма хеширования, отправляя подмножества строк другим узлам для обработки.
Table | Partition-set | Node location | Node origin
--------------------------------------------------------------
Added info ( the only coincidence of partitions which are in different nodes is this one)
Table 2 May-14 Node 1 Node 2
2-) После того, как у нас есть вся необходимая информация в соответствующих узлах, теперь мы можем присоединиться к ней.
Но как нам это сделать? Например, узел 1 имеет набор разделов May-14 для таблицы 1 и таблицы 2. Действует ли эта вновь полученная информация как разделенная информация для? Есть разные возможности. Среди них:
2.1) Для каждого фактического значения Узла в Таблице 1 {посмотрите всю информацию Таблицы 2, которую мы должны увидеть, совпадают ли значения}
2.2) Для каждого фактического значения узла в таблице 1 {посмотрите только на часть с таким же значением раздела в таблице 2 и посмотрите, совпадают ли значения}
Если мы используем объяснение в запросе, результат будет следующим:
| 05:EXCHANGE [UNPARTITIONED] |
| | |
| 02:HASH JOIN [LEFT OUTER JOIN, PARTITIONED] |
| | hash predicates: value = value, year = year, month = month |
| | |
| |--04:EXCHANGE [HASH(value,month,year)] |
| | | |
| | 01:SCAN HDFS [Table2] |
| | partitions=69/69 files=2168 size=24.15GB |
| | |
| 03:EXCHANGE [HASH(value,month,year)] |
| | |
| 00:SCAN HDFS [Table1] |
| partitions=44/44 files=44 size=1.14GB
Что заставляет меня предположить, что мы используем преимущества только для разделов на первом шаге [если мы используем shuffle], а не на втором.
Итак, для этого я бы сказал:
Шаг 1) Мы используем преимущества в распределении информации между узлами.
Шаг 2) Мы не используем преимущества разделов, когда у нас есть информация в узлах. Как будто новая информация потеряла свойства раздела.
Это заставило бы меня предположить, что использование [shuffle] должно улучшить объединение (по крайней мере) аспектов памяти, поскольку индексация разделов для их распределения может иногда занимать больше времени, чем слепая широковещательная рассылка.
После этого я провел некоторые исследования с использованием диспетчера облачности, касающиеся использования памяти, времени и времени работы процессора:
Когда я использую [shuffle] или [широковещательный]: -память памяти одинаково, а также пик памяти -ЦПУ время почти одинаково
Время, затрачиваемое на получение результата, намного меньше для случайного воспроизведения, чем для широковещательной передачи, но я не уверен, почему они потребляют одинаковую память и ресурсы.
Может ли кто-нибудь объяснить процесс?