用户画像5:开发性能及作业调度

本章主要总结开发性能调优及作业调度相关的产品知识,性能调优主要是减少性能消耗和提高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、线上业务变动导致原有标签加工逻辑失效



参考资料

《用户画像:方法论与工程化解决方案》赵宏田 著

百度百科 

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,948评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,371评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,490评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,521评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,627评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,842评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,997评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,741评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,203评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,534评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,673评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,339评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,955评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,770评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,000评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,394评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,562评论 2 349