Почему секционированное соединение (перемешивание) не всегда лучше, чем широковещательное соединение?

Я провел глубокое исследование, но не нашел ничего достаточно подробного. Я прочитал это: 1) http://www.cloudera.com/content/www/en-us/documentation/enterprise/latest/PDF/cloudera-impala.pdf 2) http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper28.pdf

но ответа не нашел..

Может кто-нибудь объяснить мне, почему секционированное соединение не всегда лучше? Я имею в виду, если у нас есть две таблицы T1 (большая) и T2 (маленькая), если я использую стратегию разделения, обе они разделены, и у нас есть подмножество T1/n-1, отправленное на другие узлы, и то же самое для T2 . С другой стороны, если я выберу широковещательную передачу, одна Impala отправит T2 * n-1 данных другим.

Может быть, я не понял, как работают стратегии... если я ошибаюсь, может кто-нибудь объяснить мне, пожалуйста? может с простой ничьей? (Я уже искал изображения в Google ..)

заранее спасибо


person MrGoodKat    schedule 02.12.2015    source источник


Ответы (1)


Разбиение на разделы не является бесплатным, и обе стороны сборки и зонда (левая и правая) должны быть разделены, чтобы выполнить объединение разделов. Каждое разделение требует фрагмента плана обмена в качестве дочернего элемента, и каждое из них требует передачи по сети. Однако, если сторона сборки небольшая, то каждый узел может иметь ее копию (т. е. широковещательную рассылку), а затем проверять хэш-таблицу сборки с неразделенной левой стороной, не вводя дополнительный дочерний обмен в тесте. сторона. На самом деле обмены, необходимые для широковещательной передачи, особенно дороги, потому что каждый отправитель должен отправить N получателям.

Что такое «достаточно маленький» для выполнения широковещательного соединения? Это зависит от ряда факторов, но наиболее очевидным и важным является то, что хеш-таблица на стороне сборки должна помещаться в памяти.

Вот пример плана, в котором используется стратегия присоединения BROADCAST:

[localhost:21000] > explain select * from alltypes t1 join alltypessmall t2 on t1.id = t2.id;
Query: explain select * from alltypes t1 join alltypessmall t2 on t1.id = t2.id
+-----------------------------------------------------------+
| Explain String                                            |
+-----------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=160.01MB VCores=2 |
|                                                           |
| 04:EXCHANGE [UNPARTITIONED]                               |
| |                                                         |
| 02:HASH JOIN [INNER JOIN, BROADCAST]                      |
| |  hash predicates: t1.id = t2.id                         |
| |                                                         |
| |--03:EXCHANGE [BROADCAST]                                |
| |  |                                                      |
| |  01:SCAN HDFS [functional.alltypessmall t2]             |
| |     partitions=4/4 files=4 size=6.32KB                  |
| |                                                         |
| 00:SCAN HDFS [functional.alltypes t1]                     |
|    partitions=24/24 files=24 size=478.45KB                |
+-----------------------------------------------------------+

А вот пример, в котором стратегия объединения разделена:

Query: explain select * from tpch.lineitem t1 join tpch.lineitem t2 on t1.l_orderkey = t2.l_orderkey
+-----------------------------------------------------------+
| Explain String                                            |
+-----------------------------------------------------------+
| Estimated Per-Host Requirements: Memory=815.44MB VCores=2 |
|                                                           |
| 05:EXCHANGE [UNPARTITIONED]                               |
| |                                                         |
| 02:HASH JOIN [INNER JOIN, PARTITIONED]                    |
| |  hash predicates: t1.l_orderkey = t2.l_orderkey         |
| |                                                         |
| |--04:EXCHANGE [HASH(t2.l_orderkey)]                      |
| |  |                                                      |
| |  01:SCAN HDFS [tpch.lineitem t2]                        |
| |     partitions=1/1 files=1 size=718.94MB                |
| |                                                         |
| 03:EXCHANGE [HASH(t1.l_orderkey)]                         |
| |                                                         |
| 00:SCAN HDFS [tpch.lineitem t1]                           |
|    partitions=1/1 files=1 size=718.94MB                   |
+-----------------------------------------------------------+
Fetched 16 row(s) in 0.03s

Обратите внимание, что последний план имеет дополнительный обмен. Значит есть дополнительный фрагмент плана сканирования (id 00).

person Matt    schedule 02.12.2015