Improvementsto the Hive Optimizer
Hive可以自动优化，在Hive 0.11里面改进了一些优化用例
1、JOIN的一边适合放在内存，有新的优化方案
a)把表按照hash表的形式读进内存
b)只扫描大表
c)fact表只使用少量内存
2、星型join
3、在很多情况下，不再需要hint
4、Map Join自动优化
StarJoin Optimization
先介绍一下星型模型和雪花型模型
===================开始=======================
1、简介
星形模式是一种多维的数据关系，它由一个事实表（FactTable）和一组维表（Dimension Table）组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。事实表的非主键属性称为事实（Fact），它们一般都是数值或其他可以进行计算的数据；而维大都是文字、时间等类型的数据，按这种方式组织好数据我们就可以按照不同的维（事实表主键的部分或全部）来对这些事实数据进行求和（summary）、求平均（average）、计数（count）、百分比（percent）的聚集计算，甚至可以做20～80分析。这样就可以从不同的角度数字来分析业务主题的情况。
在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。
当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型， 如图 2 。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
下图为销售数据仓库中的星型模型：
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图 2，将地域维表又分解为国家，省份，城市等维表。它的优点是 :通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
下图为销售数据仓库中的雪花型模型：
星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。
2、使用选择
星形模型(StarSchema)和雪花模型(SnowflakeSchema)是数据仓库中常用到的两种方式，而它们之间的对比要从四个角度来进行讨论。
1）数据优化
雪花模型使用的是规范化数据，也就是说数据在数据库内部是组织好的，以便消除冗余，因此它能够有效地减少数据量。通过引用完整性，其业务层级和维度都将存储在数据模型之中。
▲图1 雪花模型
相比较而言，星形模型实用的是反规范化数据。在星形模型中，维度直接指的是事实表，业务层级不会通过维度之间的参照完整性来部署。
▲图2 星形模型
2）业务模型
主键是一个单独的唯一键(数据属性)，为特殊数据所选择。在上面的例子中，Advertiser_ID就将是一个主键。外键(参考属性)仅仅是一个表中的字段，用来匹配其他维度表中的主键。在我们所引用的例子中，Advertiser_ID将是Account_dimension的一个外键。
在雪花模型中，数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中，所有必要的维度表在事实表中都只拥有外键。
3）性能
第三个区别在于性能的不同。雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低。举个例子，如果你想要知道Advertiser的详细信息，雪花模型就会请求许多信息，比如AdvertiserName、ID以及那些广告主和客户表的地址需要连接起来，然后再与事实表连接。
而星形模型的连接就少的多，在这个模型中，如果你需要上述信息，你只要将Advertiser的维度表和事实表连接即可。
4）ETL
雪花模型加载数据集市，因此ETL操作在设计上更加复杂，而且由于附属模型的限制，不能并行化。
总结
雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”
在决策支持系统或者数据仓库中，一个简单的模式是星型模式，事件都是存储在大的事实表（facttables）里面的，很多小的维表（dimensions）来描述事实表中的数据。
TPC DS就是星型模式中的一个例子。
Selectcount(*) cnt
Fromstore_sales ss
join household_demographics hd on(ss.ss_hdemo_sk = hd.hd_demo_sk)
join time_dim t on (ss.ss_sold_time_sk =t.t_time_sk)
join store s on (s.s_store_sk =ss.ss_store_sk)
Where
t.t_hour = 8
t.t_minute >= 30
hd.hd_dep_count = 2
order by cnt;
Hive支持MAPJOINS，，很适合这个方案-至少对于dimensions小到足够放到内存。
在Hive 0.11之前，hive.auto.convert.join默认值为false，如果需要使用MAPJOIN，则使用优化器hint方式：
select/*+ MAPJOIN(time_dim) */ count(*) from
store_sales join time_dimon (ss_sold_time_sk = t_time_sk);
或者通过设置参数后自动进行mapjoin：
sethive.auto.convert.join=true;
selectcount(*) from
store_sales join time_dimon (ss_sold_time_sk = t_time_sk);
在Hive 0.11.0开始，hive.auto.convert.join默认值为true。
MAPJOINS把小表hash map的形式读进内存，然后和大表匹配key，以下是各阶段的分工：
1） Localwork：本地
readrecords via standard table scan (including filters and projections) from sourceon local machine ——–扫描表
buildhashtable in memory ——-在内存中建立hash表
writehashtable to local disk ——–hash表写进本地磁盘
uploadhashtable to dfs ———–上传hash表到hdfs
add hashtable to distributed cache ——–把hash表加进分布式缓存
2） Maptask：Map任务
readhashtable from local disk (distributed cache) into memory ——从本地磁盘（分布式缓存）把hash表读进内存
matchrecords’ keys against hashtable——–与hash表匹配key
combine matches and write to output ——–合并匹配，并写出output
3） Noreduce task：MapJoin特点，没有reduce
Limitationsof Prior Implementation
MAPJOIN在Hive 0.11之前有如下的一些限制：
1） 一个mapjoin只能一次处理一个key，它可以执行多表连接，但只有当所有的表都加入了相同的key。（典型的星型连接不属于这一类）
2） 就算是加了hint也未必真的使用mapjoin。
3） 一连串的mapjoins不会合并成一个单一的map job，除非查询写成一个级联的mapjoin（mapjoin(table,subquery(mapjoin(table, subquery….).自动转换后的也不会变成一个单一的map job。
4） mapjoin中用到的哈希表，每个子QUERY运行都会生成，先下载，再分发给map。
Enhancementsfor Star Joins
调优主要从三方面入手的：
1） 使用MapJoinHint时，把一连串的MapJoin操作变成一个map-only的job。
2） 把优化方案尽可能的变成自动优化(顺便备份下执行计划)。
3） 使得hashtable在taskside(map端)直接生成，现在的方案是先在本地生成，然后传到HDFS，再分布式缓存去分给每个map，未来版本会实现。
下面部分将描述每个优化加强方面：
OptimizeChains of Map Joins
下面的SQL会被分解为2个独立的map-only jobs执行：
select/*+ MAPJOIN(time_dim, date_dim) */ count(*) from
store_sales
jointime_dim on (ss_sold_time_sk = t_time_sk)
joindate_dim on (ss_sold_date_sk = d_date_sk)
where t_hour = 8 andd_year = 2002;
将小表读进内存，如果fact只读了一次，而不是2次，那么会极大的减少执行时间。
Current and Future Optimizations当前和未来调优的方向
1) MergeM*-MR patterns into a single MR. —-把多个map-only的job+MRjob的模式变成单个MR
2) MergeMJ->MJ into a single MJ when possible. —–尽可能的把mapjoin嵌套模式变成一个mapjoin
发现一种久违的感动。
