作者简介：冷面，网易云音乐资深数据开发工程师，长期从事大数据开发，数仓建设、模型设计、数据治理、数据应用和服务等工作。目前主要负责云音乐离线数仓建设、会员业务线上数据服务、离线/实时ABTEST系统开发。

导读： 云音乐数仓在经历了前期混沌摸索，中期建设完善，如今已逐步形成了一套适合自己的数仓体系和建设规范。增量模型及任务全部走线上设计评审流程，但仍有大量历史任务“年久失修”等待治理。本文以重构会员自动化运营模型为例，分享下数据任务重构实践。

1 背景

云音乐会员自动化运营，通过对人群、资源位、投放规则等配置打包形成不同的投放策略，完成站内资源整合。针对不同用户不同行为不同位置推送不同资源内容，精准投放，加强转化，提高会员渗透率，提高会员续费率。

（自动化运营策略）

运营效果的评估，依赖大量数据指标在不同分析维度的表现。数据指标如投放PV/UV、触点曝光PV/UV、触点点击PV/UV、收银台曝光PV/UV、SKU点击PV/UV、购买人数、订单数，以及各阶段的漏斗转化数据等；分析维度如投放策略、投放资源、投放位置、投放人群、用户OS、SKU类型等等。

（自动化运营指标分析）

2 问题

早期数仓建设缺乏方法论指导，更多是烟囱式开发，没有分层，没有主题域，没有规范。需求驱动，模型设计复用性考虑不足，所有表产出自一个任务流，耦合严重，在稳定性和可用性方面存在不少问题。

（auto-om-flow）

3 重构

本次重构以对业务影响最小，尽量做到下游无感知为原则，从规范、效率、质量方面着手，进行任务治理。

3.1 规范

模型设计：遵循高内聚低耦合的原则，划分合适的业务主题域，给出清晰的表分层。建表、字段遵循数仓通用规范。

主题域：云音乐-事实-交易营收。

表分层：dwd用户行为明细层、dws原子指标轻度聚合层、ads业务场景指标高度汇总层。

  • dwd

    music_new_dm.dwd_act_auto_om_di

  • dws

    music_new_dm.dws_act_auto_om_di

  • ads

    music_new_dm.ads_act_auto_om_di

    music_new_dm.ads_rev_vip_autoom_buy_di

    music_new_dm.ads_act_vip_stgy_di

任务解耦：一个任务流产出一张正式表，任务名即表名，任务按业务归属、表分层部署在对应网易有数大数据平台目录下。

任务节点：

  • 开始节点：任务入口，虚拟节点，建议命名：start。
  • 结束节点：任务终点，虚拟节点，有数大数据平台默认以任务名为结束节点。
  • 说明节点：任务注释文档说明用，有数大数据平台无文档节点，建议使用SQL节点注释语法实现，命名readme。
  • 依赖节点：表依赖节点，MR节点，以while循环check表数据文件时间戳形式检测表是否ready。建议命名：dep-表名［-分区名］
  • 计算节点：临时表或正式表产出节点，SQL节点。建议命名：［insert-］表名［-分区名］
  • 依赖配置：有数大数据平台支持线上模式编辑调度配置任务依赖、节点依赖，任务或节点需同属于有数大数据平台任务，暂不支持配置Pandora任务依赖。也可使用任务内MR节点方式配置依赖。两种方式各有优劣，按需配置，不做要求。
  • 临时表：任务逻辑较为复杂或需要复用中间结果时，考虑使用临时表或视图表。因磁盘读写速度远低于内存读写，故应多使用内存表，尽量减少临时表落盘。但是，当不得不做一件有代价的事情的时候，应考虑最大化利用其价值。

操作建议：

  • 数据量较小时，建议使用view或with as语法组织代码，提高可读性，减少磁盘io；
  • 数据量较大时，建议落实体表到临时库，设置生命周期定时清理，既提高数据复用，又方便出错时异常排查，当下游修改逻辑时又可降低数据回跑成本；
  • 考虑语法标准及查询引擎的支持度，不建议使用temporary table/temporary view等语法建临时表、临时视图；
  • 考虑表元数据稳定及查询便利性，建议任务上线即固定临时表命名，使用动态日期分区而非动态表名区分每天数据。

开发测试：有数大数据平台任务支持开发模式、线上模式，所有任务节点需在开发模式测试通过后才可提交上线。

上线审核：圈选任务提交上线，走工单审批，需业务负责人check通过后可通过上线。

调度配置：任务上线调度需配置调度参数，调度周期，调度时间，任务依赖，执行队列，并发设置等，详见数仓通用规范。

报警配置：任务上线默认配置负责人接收失败报警。按需配置报警对象（任务、节点），触发规则（失败、延迟），报警接收（负责人、报警组），报警方式（邮件、短信、电话、popo），循环报警等。

以下五张为详细任务解耦图：

（dwd_act_auto_om_di）

（dws_act_auto_om_di）

（ads_act_auto_om_di）

（ads_act_vip_stgy_di）

（ads_rev_vip_autoom_buy_di）

3.2 效率

执行引擎：原workflow仍有大量任务使用hive执行，本次全部迁移spark。

性能优化：分析输入输出数据量级，业务计算逻辑，CPU/内存等资源参数调节，达到性能优化目的。

Spark调优：

  1. 开启动态资源分配 dynamicAllocation
  2. cpu/内存配比建议同集群总资源配比，最大化利用集群资源
  3. 开启broadcastjoin，有数大数据平台环境默认关闭（内存限制），spark官方建议开启，可极大提高join小表性能
  4. 调节parallelism和repartition参数，提高并行度
  5. 开启convertMetastoreParquet，充分利用spark读parquet性能
  6. lateral view explode优化，多次explode前，手动触发shuffle操作，减少单分区处理数据量大小
  7. 控制输出文件大小，减少小文件数，减轻nn压力
  8. 充分利用spark3 AQE优化

性能提升：单节点执行效率提升5倍，整体产出时间提前3小时，存储空间占用降低80%，文件数占用降低90%。

（重构前后对比）

dwd_act_auto_om_di 存储及文件数降低。

（存储及文件数降低）

ads_act_auto_om_di表提高并行度及explode优化以提高执行效率缩短时长示例。

（优化计算示例）

ads_act_vip_stgy_di表执行时长由60分钟缩短至10分钟，产出时间由11点提前至9点。

（产出时间提前）

3.3 质量

数据校验：重构应保证数据准确性、一致性，对重构前后产出数据做一定的规则校验。如count、count distinct、NULL值、枚举值范围、数值型分布、最大最小值比较等。


-- 分区前缀代表不同优化策略
select dt,
    count(1) as c,
    count(distinct os) as c_os,
    count(distinct positionid) as c_pos,
    sum(vipbuy_amt) as s_amt,
    ma