Hive架构层面优化之一分表

场景:某个日志表数据量很大,而且访问该表的作业比较多,造成耗时比较长;

解决方案:将用的比较少/不常用的字段剥离出去;

案例:

日志表trackinfo,每天约有2亿数据量,有5000个作业按天访问,每天的日志数据量有可能会继续添加下去,那么很可能就满足不了要求(每添加10%的数据量作业大概要添加20分钟);如何解决数据的增长呢?

方案:

将邮件营销EDM,网盟Union从trackinfo表中剥离出来,trackinfo表大概能降到1.5亿左右,这样作业的执行时间大概可以减少40-50分钟时间,表edm_union_track只存放邮件营销EDM、网盟的数据Union,这个表的数据只有大概5个作业按天访问,抽取出来的好处之一是,这几种类型的数据统计时不再需要去整个大表中查询,提高性能,同时也降低了大表的数据量;不剥离出来的话,5000个作业每次都会到表中去过滤,而这0.5亿的数据对这些作业来说是没用的。

Hive架构层面优化之一分表

时间: 2024-10-12 22:51:10

Hive架构层面优化之一分表的相关文章

Hive架构层面优化之五合理设计表分区(静态分区和动态分区)

合理建表分区有效提高查询速度. 重要数据采用外部表存储,CREATE EXTERNAL TABLE,数据和表只是一个location的关联,drop表后数据不会丢失: 内部表也叫托管表,drop表后数据丢失:所以重要数据的表不能采用内部表的方式存储. 在全天的数据里查询某个时段的数据,性能很低效------可以通过增加小时级别的分区来改进! Trackreal为例,有三个分区: 日增量: 按日期分区: 小时增量:按日期.小时分区: 10分钟增量:按日期.小时.step分区:每个小时要导6次. 场

Hive架构层面优化之四 常用复杂/低效的统计从源上给出,以避免上层作业过多计算

案例一:trackinfo,基础表处理常用的低性能UDF 背景描述:日志信息10分钟加载一次到实时日志表trackreal中(按小时分区),为了保证实时性,在加载的过程中并没有做任何的过滤处理,加载到trackreal表后再过滤非法数据.爬虫数据等,生成按天增量日志表trackinfo,然后根据不同的page_type来统计流量. 解决方案如下: select '首页', count(*) pv, #每条记录就是一条pv count(distinct session_id) uv #根据sess

Hive架构层面优化之二合理利用中间结果集(单Job)

是针对单个作业,针对本job再怎么优化也不会影响到其他job: Hadoop的负载主要有两部分:CPU负载和IO负载: 问题:机器io开销很大,但是机器的cpu开销较小,另外map输出文件也较大,怎么办? 解决办法:通过设置map的中间输出进行压缩就可以了,这个不会影响最终reduce的输出. 集群中的机器一旦选定了,那么CPU就没的改变了,所以集群的最主要的负载还是IO负载: 压缩技术虽然可以降低IO负载,但是同时也加重了CPU负载,治标不治本,CPU加重了,整体性能还是上不去:如果当前CPU

Hive架构层面优化之六分布式缓存

案例: Hadoop jar引用:hadoop jar -libjars aa.jar bb.jar …. jar包会被上传到hdfs,然后分发到每个datanode 假设有20个jar文件,每天jar文件被上传上万次,分发达上万次(百G级),造成很严重的IO开销. 如何使这些jar包在HDFS上进行缓存,同一个jar只需上传和分发一次,后续所有的job可以节省此jar的上传和分发的开销,从而减少不必要的上传和分发呢? 解决方案:使用分布式缓存 MapReduce如何使用分布式缓存 Hadoop

Hive架构层面优化之七压缩

常见的压缩有:对中间结果压缩.对输出结果压缩. 压缩对比: 算法 压缩前/压缩后 压缩速度 解压速度 GZIP 13.4% 21MB/s 118 MB/s LZO 20.5% 135 MB/s 410 MB/s Snappy 22.2% 172 MB/s 409 MB/s Snappy介绍: Snappy 网站:http://code.google.com/p/snappy/ Snappy的前身是Zippy.虽然只是一个数据压缩库,它却被Google用于许多内部项目程,其中就包括BigTable

Hive语法层面优化之六数据倾斜常见案例

常见案例一:空值产生的数据倾斜 日志表有一部分的user_id为空或者是0的情况,导致在用user_id进行hash分桶时,会将日志由user_id为0或者为空的数据分到一个reduce上,导致数据倾斜: 如:访户未登录时,日志中的user_id为空,用user_id和用户表的user_id进行关联的时候,会将日志中的user_id为空的数据分到一起,导致了过大的空key造成数据倾斜: 解决办法:随机函数解决数据倾斜 把空值的key变成一个字符串加上随机数(只要不与真正的end_user_id的

Hive语法层面优化之七数据倾斜总结

关键字 情形 后果 join 其中一个表较小,但key集中 分发到某一个或几个reduce上的数据远高于平均值 大表与大表关联,但是分桶的判断字段0值或空值过多 这些空值都由一个reduce处理,非常慢 group by Group by维度过小,某值的数量过多 处理某值的reduce非常耗时 count distinct 某特殊值过多 处理此特殊值的reduce耗时 Hive语法层面优化之七数据倾斜总结

Hive参数层面优化之一控制Map数

1.Map个数的决定因素 通常情况下,作业会通过input文件产生一个或者多个map数: Map数主要的决定因素有: input总的文件个数,input文件的大小和集群中设置的block的大小(在hive中可以通过set dfs.block.size命令查看,该参数不能自定义修改): 文件块数拆分原则:如果文件大于块大小(128M),那么拆分:如果小于,则把该文件当成一个块. 举例一: 假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(6个128m的块和

Hive语法层面优化之五分析执行计划追踪导致数据倾斜的原因

count(distinct key)案例 explain select count(distinct session_id) from trackinfo where ds=' 2013-07-21' ; STAGE DEPENDENCIES: Stage-1 is a root stage Stage-0 is a root stage STAGE PLANS: Stage: Stage-1 Map Reduce Alias -> Map Operator Tree: trackinfo T