首页 > 代码库 > Hive架构层面优化之四 常用复杂/低效的统计从源上给出，以避免上层作业过多计算
Hive架构层面优化之四 常用复杂/低效的统计从源上给出，以避免上层作业过多计算
案例一：trackinfo，基础表处理常用的低性能UDF
背景描述：日志信息10分钟加载一次到实时日志表trackreal中（按小时分区），为了保证实时性，在加载的过程中并没有做任何的过滤处理，加载到trackreal表后再过滤非法数据、爬虫数据等，生成按天增量日志表trackinfo，然后根据不同的page_type来统计流量。
解决方案如下：
select ‘首页‘, count(*) pv, #每条记录就是一条pv count(distinct session_id) uv #根据session_id来统计uvfrom 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) uvfrom 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 stringstay_time bigintpv intprovince_id intguid string #每台电脑生成一个，每次访问页面都相同，只要不重装系统都一致ip string end_user_id bigintlanding_page_url string #着陆页is_new_access string #是否新访户landing_referer string #着陆页上一页面是：搜索引擎、网盟、广告联盟tracker_u string #是否是来源的编号tracker_src stringcity_id bigintsearch_engine_id intlanding_keyword stringproduct_pv bigintcart_pv bigintadd_cart_num bigintdetail_add_cart_num bigintadg_keyword stringcheckout_pv bigintorder_finish_pv bigintplatform stringapp_vers stringds string #按天分区字段
总结：类似于此种低效或者复杂统计，建议在源上给出。
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。