常用复杂或低效统计源上给出，以避免上层作业过多计算
背景：日志10分钟加载一次到实时日志表trackreal中，过滤非法数据，爬虫数据。。。生成按天增量日志表trackinfo（增加url_page_id)
上层应用就不需要调这个udf
统计首页某一 天流量：
select '首页',
count(*) pv,
count(distinct session_id) uv
from tracking where ds='2015-11-11'
and url like 'http://www.yhd.com/%';
＝＝＝
session_info，常用的session_id以及属性和指标统一给出
背景：用户行为分析
表分区：合理建表分区有效提高查询速度
重要数据用外部表，create external table，因为这个表drop掉之后，数据是不丢失的
内部表也叫托管表
增量表：增量的频率，或者说时间粒度，决定hive表的分区结构
日增量：日期
小时增量：日期，小时分区
10分钟增量：日期，小时，step
在全天数据里查询某个时间段的数据，低效－－增加hour分区，trackreal为例
场景：大量小时级作业访问trackinfo，改造为trackinfo_hour（由日期和小时分区）
tracking_hour生成频率? 0-9点：忙时
10点后执行，可以用动态分区
动态分区：数据自动找分区，和关系数据库类似
动态分区：
主分区静态分区，次分区是动态
（ds string, hour string)
所以hive在架构层面优化策略：
分表
合理利用中间结果，重视查了就丢的资源浪费，hadoop的io负载瓶颈
常用复杂或低效统计源上给出，以避免上层作业过多计算
合理设计表分区，静态分区和动态分区
压缩技术
