嗨，无聊么
我们在使用git进行项目版本控制的时候，经常会创建多个分支，其中一个分支作为项目的最新、最全的版本来用于项目的发布迭代更新，而其它版本只是在某个需求阶段会用作临时的部分代码更新。
有些情况下，比如我们长时间没有用git来管理代码，而忘记哪个版本的代码是最新的了，只是印象里记得有一个功能是最后一次更新的。而且只是小范围的更新也不记得最后的而差异有哪些了？这个时候就需要我们来比较一个各个分支的内容有什么不同，来找寻最后的代码更新的影子。
git diff 分支1 分支2 --stat // （加上 --stat 是显示文件列表, 默认是文件内容diff）
git diff branch1 branch2 --stat //显示出所有有差异的文件列表
git diff branch1 branch2 具体文件路径 //显示指定文件的详细差异
git diff branch1 branch2 //显示出所有有差异的文件的详细差异
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。不夸张的说，Git是目前世界上最先进的分布式版本控制系统。
Git 完整命令手册地址：http://git-scm.com/docs
PDF 版命令手册：github-git-cheat-sheet.pdf
我们在之前的文章中介绍了hive的sort by , distribute by 等操作和相关使用技巧，除了之前说的这些常用函数外，我们在查询的时候还会用到分组、去重、关联等操作。
Join查找操作的基本原则：应该将条目少的表/子查询放在 Join 操作符的左边。
原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出错误的几率。
1、Join查找操作中如果存在多个join，且所有参与join的表中其参与join的key都相同，则会将所有的join合并到一个mapred程序中。
hive > SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)
# 在一个mapre程序中执行join
hive > SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)
# 在两个mapred程序中执行join
2、Map join的关键在于join操作中的某个表的数据量很小。
Mapjoin 的限制是无法执行a FULL/RIGHT OUTER JOIN b，和map join相关的hive参数：hive.join.emit.interval hive.mapjoin.size.key hive.mapjoin.cache.numrows
hive> SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM a join b on a.key = b.key
3、由于join操作是在where操作之前执行，所以当你在执行join时，where条件并不能起到减少join数据的作用
hive > SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key)
WHERE a.ds='2009-07-07' AND b.ds='2009-07-07'
hive > SELECT a.val, b.val FROM a LEFT OUTER JOIN b
ON (a.key=b.key AND b.ds='2009-07-07' AND a.ds='2009-07-07')
# 优化修改后的where条件
4、在join操作的每一个mapred程序中，hive都会把出现在join语句中相对靠后的表的数据stream化，相对靠前的变的数据缓存在内存中。当然，也可以手动指定stream化的表。
hive > SELECT /*+ STREAMTABLE(a) */ a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)
Map端聚合，首先在map端进行初步聚合，最后在reduce端得出最终结果，相关参数：· hive.map.aggr = true是否在 Map 端进行聚合，默认为 True· hive.groupby.mapaggr.checkinterval = 100000在 Map 端进行聚合操作的条目数目数据倾斜聚合优化，设置参数hive.groupby.skewindata = true，当选项设定为 true，生成的查询计划会有两个 MR Job。
第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；
第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。
通过left outer join进行查询,（假设B表中包含另外的一个字段 key1
hive > select a.key from a left outer join b on a.key=b.key where b.key1 is null
通过left semi join 实现 in;Left semi join 的限制：join条件中右边的表只能出现在join条件中。
hive> SELECT a.key, a.val FROM a LEFT SEMI JOIN b on (a.key = b.key)
文件数目过多，会给 HDFS 带来压力，并且会影响处理效率，可以通过合并 Map 和 Reduce 的结果文件来消除这样的影响：
Hive中的每个分区都对应hdfs上的一个目录，分区列也不是表中的一个实际的字段，而是一个或者多个伪列，在表的数据文件中实际上并不保存分区列的信息与数据。
Partition关键字中排在前面的为主分区（只有一个），后面的为副分区静态分区：
静态分区在加载数据和使用时都需要在sql语句中指定
案例：(stat_date=’20120625′,province=’hunan’)
动态分区：使用动态分区需要设置hive.exec.dynamic.partition参数值为true，默认值为false，在默认情况下，hive会假设主分区时静态分区，副分区使用动态分区；如果想都使用动态分区，需要设置set hive.exec.dynamic.partition.mode=nostrick，默认为strick
案例：(stat_date=’20120625′,province)
Hive支持在group by时对同一列进行多次distinct操作，却不支持在同一个语句中对多个列进行distinct操作。