本章主要总结开发性能调优及作业调度相关的产品知识,性能调优主要是减少性能消耗和提高ETL作业时间,常见的调优就会数据倾斜调优、合并小文件、缓存中间数据、开发中间表等方式。
作业流程调度主要是完成各个画像标签对于的脚本后,需要调度该脚本所产生的调度流程的理解和数据监控相关的知识点总结。
一、开发性能调优
1、数据倾斜调优
当遇到认为执行一直卡在map100%,reduce99%时,这种情况一般是遇到了数据倾斜。问题的原因是当在分布式计算时,由于某些节点需要计算的数据较多,导致其他节点的reduce节点任务完成时,该节点的任务还没执行完成,造成其他节点等待的情况。如下这种典型的例子。
数据倾斜场景处理方式:
a、过滤倾斜数据
比如日志数据的脏数据特别多,比如null值,数量很多且没有实际意义的,就可以过滤掉。
b、引入随机数
数据按照类型group by时,会将相同的key所需的数据拉到一个节点进行聚合,当某组数据量过大时,就会出现数据倾斜情况。此时就可以通过添加随机前缀的方式,将原来的key拆为多个,分散到多个task上做一次聚合,最后去掉前缀再进行聚合。如下图。
2、合并小文件
因为HDFS是分布式文件系统,所以在spark执行“insert overwrite table 表名”的语句时,RDD默认分区200个,所以会产生200个小文件。在Spark内部会对每一个分区分配一个task执行,如果task过多,那么每个task处理的数据量很小,这就会造成线程频繁在task之间切换,导致集群工作效率低下。为解决这个问题,常采用RDD重分区函数来减少分区数量,将小分区合并为大分区,从而提高集群工作效率。
3、缓存中间数据
在画像标签开发中,一般从Hive中读取数据,然后将需要做中间处理的DataFrame注册成缓存表。这里将读取的用户数据缓存在内存中并注册为一张视图。后续直接从视图中读取对应用户数据。在该Spark任务执行完成后,释放内存,不需要清除该缓存数据。
4、开发中间表
在用户画像迭代开发的过程中,初期开发完标签后,通过对标签加工作业的血缘图整理,可以找到使用相同数据源的标签,对这部分标签,可以通过加工中间表缩减每日画像调度作业时间。
· 首先,梳理清楚用户标签计算时所依赖的数据仓库层所的表;
用户标签依赖上游数据仓库的表· 其次,梳理用户标签血缘图。通过对用户标签的血缘图进行梳理,找到共同依赖的上游数据。
用户标签血缘图梳理二、作业流程调度
在开发完每一个画像标签对应的脚本后,需要将该脚本提上调度流,每天定时作业刷昨天产生的新标签。
在开发迭代的过程中,开发初期会使用crontab命令调度开发任务定时执行,但随着调度任务规模的增加,使用Kettle、Airflow这样的工具替代crontab做定时调度会提高集群工作效率。一方面可以帮助厘清任务之间的依赖关系,另一方面当调度出现异常时可快速定位出现问题的位置。
1、工程化调度方案
在工程化调度实践中,对于用户画像每天的ETL调度工作,除了标签的调度,还包括同步数据到服务层、数据的监控预警(标签预警、同步到服务层的预警等)。
主要调度模块数据监控预警,相比Hive,开发时考虑对小数据读写速度快的MySQL进行存储监控表。数据监控预警整体涵盖以下几个模块:
a、标签监控预警
用于监控每个标签当日ETL是否产生问题,当数据量超出正常范围会触发警报邮件。开发人员收到报警邮件后定位问题标签的原因并进行处理。
报警邮件的脚本扫描这张标签监控表当日数据,当标签当日的产出量与历史相比出现较大程度波动时,可触发告警提示。例如男性标签历史每天产出覆盖用户数量是100万,今天产出覆盖的用户是120万,可视为出现较大波动。
·tagid:标签id。
·data_date:数据日期。
·tag_count:该标签覆盖的用户量。
·tag_total_wave:该标签覆盖用来占全量用户的比率。
·tag_dau_wave:该标签覆盖用户量占当日活跃用户的比率,通过该指标可看到该标签覆盖日活用户情况。
标签监控表示例数据b、人群计算预警
和标签监控类似,人群监控校验各个业务规则下每个人群当日ETL是否数据异常。
groupid:人群分组id;
data_date:数据计算日期,记录该人群的数量记录的日期;
group_count:人群数量,该人群当日数量是多少;
target_system:推送业务系统,该人群数据最好是推送到哪个人群系统之中提供服务的。
人群计算监控表示例数据c、业务系统同步预警
用于监控数据从数仓提供到服务层时的过程是否正常进行,一般通过对比数据仓库(Hive)中各个业务线的数量和各业务系统(如ES、MySQL、HBase、CSV文件等)中对于的数量。
业务系统监控表示例数据2、ETL异常排查
每日用户画像标签的ETL调度中,难免遇到失败的情况。这回造成线上的实时推荐,推荐不准确等影响。关于失败的原因,总结来看,按照错误方向优先级,主要考虑以下几个方面。
a、资源池内存不足导致作业失败
b、上游ETL延迟导致标签加工失败
c、上游数据ETL异常或失败导致标签加工失败
d、标签脚本逻辑导致数据加工失败
e、线上业务变动导致原有标签加工逻辑失效
参考资料
《用户画像:方法论与工程化解决方案》赵宏田 著
百度百科
网友评论