让我们假设我有Table1和Table2，每个都有相同的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 manager如何做这项工作。
我将加入过程分为两部分：
1-）数据如何分配到每个节点以便可以加入：
在这里查看之后：
https://www.cloudera.com/documentation/enterprise/5-9-x/topics/impala_hints.html
我看到了在联接中涉及分区的两种方法：
[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例如具有表1和表2的分区集May-14。此新接收的信息是否像分区信息那样起作用？有不同的可能性。其中：
2.1）对于表1的每个实际Node值{查看所有表2信息，我们必须查看值是否匹配}
2.2）对于表1的每个实际Node值{仅查看具有与表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
这让我假设我们仅在第一步（如果使用随机播放）中利用分区，而在第二步中则没有。
因此，我会说：
第1步）我们在节点之间的信息分配中利用分区。
第2步）当节点中有信息时，我们不会利用分区。好像新信息丢失了分区属性。
这使我认为使用[shuffle]至少可以改善内存方面的连接，因为索引分区以分配分区有时可能要比盲目广播更长。
然后，我使用clouder管理器对内存使用，所需时间和cpu工作时间进行了一些研究：
当我使用[shuffle]或[broadcast]时：-内存使用率相同，并且内存峰值-CPU时间几乎相同
获得结果所需的时间比随机播放要少得多，但是我不确定为什么它们会占用相同的内存和资源。
有人可以解释这个过程吗？