雄安网建 网站建设,天助可以搜索别人网站,网站建设需求文件,德州网站开发人员一、背景 由于公司规模较小#xff0c;大数据相关没有实现平台化#xff0c;相关的架构都是原生的Apache组件#xff0c;所以集群的维护和优化都需要人工的参与。根据自己的实践整理一些数仓相关的优化。
二、优化 1、简易架构图 2、ODS层优化 2.1 分段式解析 随着业务增长…一、背景 由于公司规模较小大数据相关没有实现平台化相关的架构都是原生的Apache组件所以集群的维护和优化都需要人工的参与。根据自己的实践整理一些数仓相关的优化。
二、优化 1、简易架构图 2、ODS层优化 2.1 分段式解析 随着业务增长数据量也不断增加凌晨任务经常基线预警、破线导致数据不能正常产出影响运营人员分析数据。在不增加成本的情况尽可能的优化。 经过团队研究发现 t-1 的日志解析占用非常长的时间且集群资源空闲时间点比较多。 把日志的解析分成两段式当天0点到22点数据可在22:15进行解析22点到24点数据在00:15解析大大节省了时间还充分利用了集群的资源。有效的缓解了破线问题。 2.2 小文件合并 1.原因a.读取的数据源文件本身就有大量的小文件b.动态分区插入数据每个reduce产生的文件个数为动态分区的个数产生文件个数reduce个数*动态分区数c.reduce/Task个数较多和文件数是一样的2.影响a.文件的数量决定了Mapreduce/Spark中Mapper/Task数量小文件越多Mapper/Task的任务越多每个Mapper/task都会对应启动一个JVM/线程来运行每个Task数据小个数大占用资源多甚至这些任务初始化的时间可能比执行的时间还要多影响性能当然这个问题 可以通过CombinedInputFile和开启JVM重用来解决。b.文件存储在HDFS上每个文件的元数据信息位置、大小、分块信息大约占150个字节文件的元数据信息分别存储在内存和磁盘中。 3.解决方法:通过 DISTRIBUTE BY 控制文件的个数distribute by 1distribute by cast(rand()*10 as int)distribute by dtdistribute by substr(udi,1,2)2.3 提高数据压缩比率 1.问题描述 使用 DISTRIBUTE BY INT(RAND()*300) 随机数的方式控制了文件的个数但是使用的SNAPPY压缩压缩比原则是十倍左右目前只能达到两倍左右。 原因每个文件里面的数据随机数据的相似性较小压缩比上不去 2.问题解决DISTRIBUTE BY SUBSTR(udi,1,2) 使用文本字段进行文件数的控制文件个数减少了并且文件的大小也变小了压缩比变大 说明udi前两个为(字母数字),截取前两个组合来作为文件的个数(最多36*36) 原理将相似的数据放在同一个分区里数据压缩比增大 2.4 分项目业务数据导入优化 1.问题描述由于项目数量比较多并且会持续增加项目之间的业务表相同按照sqoop传统导数据的脚本会编写很多冗余的脚本费时费力且增加新项目时开发成本较高 2.问题解决将不同的数据库的配置信息(host、IP、账号、密码、脚本路径) 配置到mysql表中编写相应的脚本脚本根据给定的参数去读取相应的配置进行对应项目的数据导入。
3、DWD层优化 3.1 缩减分区 1.问题描述初始建立二级分区项目天随着老项目的数据量增加以及新项目上线数据量较少 导致执行时造成数据倾斜以及多级分区造成文件数以及分区数成倍增加造成数据寻址时间过长。 执行时间较短但是刷盘的时间过长晚上流程的时间整体拖延。 2.问题解决将二级分区改为一级分区 3.解决方法a.建立同样的临时表 b.将历史数据mv导入到临时表中此时进行核对数据量 c.通过命令修复临时表的分区 d.将旧表删除建立新的分区表 e.将临时表的数据导入到新的表中核对数据
