技术干货 | Hive模式设计
默认，每个task都是一个新的JVM实例，都需要开启和销毁的开销。对于小文件（小于一个块的大小），每个文件都会对应一个task。会导致JVM开启和销毁的时间中可能会比实际处理数据的时间消耗要长。
理想的分区方案部应该导致产生太多的分区和文件夹目录，并且每个目录下的文件应该足够大，应该是文件系统中块大小的若干倍。
不能够找到好的、大小相对合适的分区方式的话，可以考虑使用分桶表数据存储。
Hive没有主键或基于序列密钥生成的自增键的概念。
分桶是将数据集分解成更容易管理的若干部分的另一个技术。如：在创建表时使用CLUSTERED BY(COLUMN_NAME) INTO 96 BUCKETS;
需要设置一个属性来强制Hive为目标表的分桶初始化过程设置一个正确的reducer个数，然后再执行一个查询来填充分区：set hive.enforce.bucketing=true;
from raw_logs insert overwrite table weblog partition (dt='2016-08-23') select user_id,url,source_ip where dt='2016-08-23'; 如果没有使用hive.enforce.bucketing属性，那么就需要自己设置和分桶个数相匹配的reducer个数，如用set mapred.reduce.tasks=96，然后在INSERT语句中，需要在SELECT 语句后增加CLUSTER BY 语句。因为桶的数量是固定的，所以它没有数据波动，桶对于抽样再适合不过。分桶同时有利于执行高效的map-side JOIN。
为底层数据增加一个新字段，旧的原始数据文件可能不包含这个字段，这种方式，无法再已有字段的开始或中间增加新字段。
几乎在所有情况下，压缩都可以使磁盘上存储的数据量变小，这样可以通过降低I/O来提高查询执行速度，但是压缩和解压缩会消耗CPU资源。一般情况建议使用压缩，除非CPU对性能有影响。