标签：style blog http color 使用 strong
案例一：trackinfo，基础表处理常用的低性能UDF
背景描述：日志信息10分钟加载一次到实时日志表trackreal中（按小时分区），为了保证实时性，在加载的过程中并没有做任何的过滤处理，加载到trackreal表后再过滤非法数据、爬虫数据等，生成按天增量日志表trackinfo，然后根据不同的page_type来统计流量。
解决方案如下：
select ‘首页‘, count(*) pv, #每条记录就是一条pv count(distinct session_id) uv #根据session_id来统计uv from trackinfo where ds=‘2013-11-11‘ and url like ‘http://cms.yhd.com/cmsPage/show.do?pageId=%‘ ;
由于将URL规则硬编码到代码中，很不灵活，故可以将其交给UDF处理。
改造后的方案如下：
select ‘首页‘, count(*) pv, count(distinct session_id) uv from trackinfo where ds=‘2013-11-11‘ and getPageID(url)=1
采用UDF之后，每行数据在进行流量统计的时候都要进行一次类型的匹配，几乎所有的统计流量作业都要用到这个UDF，getPageID性能就比较低下，这属于低效统计，如何再进行优化处理呢？
再一次改造的方案：在原上直接给出page_type的类型。
在生成trackinfo的时候添加一个字段url_page_id用以区分。后续上层作业在调用时就不再需要使用UDF了，而是直接使用这个字段即可，性能提高很多。
案例二：session_info，常用的session_id及属性和指标统一给出
背景描述：用户行为分析。有多个作业需要查询一些属性，比如：着陆页（访问该系统的第一个网页是哪个，landing_referer）、来源（网盟、搜索引擎、收藏， tracker_u）、PV等信息。这些信息使用一个job抽取到一个表中session_info，用一个job将用户的属性和行为完全计算出来，上层作业只要使用这张表的数据即可。这属于复杂统计。
session_info表的常用介绍：
session_id string #每次重新打开一个浏览器都会变化 start_time string stay_time bigint pv int province_id int guid string #每台电脑生成一个，每次访问页面都相同，只要不重装系统都一致 ip string end_user_id bigint landing_page_url string #着陆页 is_new_access string #是否新访户 landing_referer string #着陆页上一页面是：搜索引擎、网盟、广告联盟 tracker_u string #是否是来源的编号 tracker_src string city_id bigint search_engine_id int landing_keyword string product_pv bigint cart_pv bigint add_cart_num bigint detail_add_cart_num bigint adg_keyword string checkout_pv bigint order_finish_pv bigint platform string app_vers string ds string #按天分区字段
总结：类似于此种低效或者复杂统计，建议在源上给出。
Hive架构层面优化之四 常用复杂/低效的统计从源上给出，以避免上层作业过多计算,布布扣,bubuko.com
Hive架构层面优化之四 常用复杂/低效的统计从源上给出，以避免上层作业过多计算
标签：style blog http color 使用 strong
原文地址：http://www.cnblogs.com/luogankun/p/3850415.html
