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 DistributedCache的使用

Configuration conf = new Configuration();
DistributedCache.createSymlink(conf);
//   假设:/user/bi/input/xxx.jar为文件名
//  #后的testFile为指定的名称,可以用testFile代替前面的文件
DistributedCache.addCacheFile(new URI("/user/bi/input/xxx.jar#testFile"), conf);
Job job = new Job(conf); 

DistributedCache的操作一定要放在job的初始化之前,否则会报出文件找不到的异常

在map端打开:

FileReader fr = new FileReader("testFile");

Hive作业如何使用分布式缓存

hive的add jar 是基于分布式缓存来进行设计的,会将jar自动加入到分布式缓存中。

在hive脚本使用:

add jar /opt/software/lib/UDF.jar;
create temporary function getPageId as ‘com.xxx.GetPageID‘;

或者是在通过设置hive的配置文件hive-site.xml 加入

<property>
    <name>hive.aux.jars.path</name>
    <value>file:///opt/software/lib/UDF.jar</value>
</property>

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

时间: 2024-08-04 00:26:19

Hive架构层面优化之六分布式缓存的相关文章

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架构层面优化之一分表

场景:某个日志表数据量很大,而且访问该表的作业比较多,造成耗时比较长: 解决方案:将用的比较少/不常用的字段剥离出去: 案例: 日志表trackinfo,每天约有2亿数据量,有5000个作业按天访问,每天的日志数据量有可能会继续添加下去,那么很可能就满足不了要求(每添加10%的数据量作业大概要添加20分钟):如何解决数据的增长呢? 方案: 将邮件营销EDM,网盟Union从trackinfo表中剥离出来,trackinfo表大概能降到1.5亿左右,这样作业的执行时间大概可以减少40-50分钟时间

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

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

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架构层面优化之七压缩

常见的压缩有:对中间结果压缩.对输出结果压缩. 压缩对比: 算法 压缩前/压缩后 压缩速度 解压速度 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参数层面优化之一控制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参数层面优化之二控制Reduce数

Reduce数决定中间或落地文件数,文件大小和Block大小无关. 1.Reduce个数的决定因素 reduce个数的设定极大影响任务执行效率,不指定reduce个数的情况下,Hive会猜测确定一个reduce个数,基于以下两个设定: 参数1:hive.exec.reducers.bytes.per.reducer(每个reduce任务处理的数据量,默认为1000^3=1G) 参数2:hive.exec.reducers.max(每个作业最大的reduce数,默认为999) 计算reducer数

Hive语法层面优化之一数据倾斜介绍

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点: 由于数据并不是平均分配的,会导致各个节点上处理的数据量是不均衡的,所以数据倾斜是无法避免的: 造成数据倾斜的最根本原因:key分发不均匀造成的: 常见的数据倾斜的症状 1)  Map阶段快,reduce阶段非常慢: 2)  某些map很快,某些map很慢: 3)  某些reduce很快,某些reduce很慢: 4)  任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成,