打造数据驱动的新零售电商实践之路

打造数据驱动的 新零售电商实践之路 实践手册系列 NETEASEDIGITALSAIL 第一篇：离线数仓质量建设实践 一、保障等级确认 01 01 第二篇：数据任务治理实践 一、事前——模型上线前第一道防线 05 05 第三篇：用户行为分析实践 一、商业模式 15 15 第四篇：全渠道营销与智能化触达实践 一、什么是全渠道 23 23 前言 二、数据质量建设目标01 三、数据质量实施策略02 四、质量衡量04 二、事中——基于「基线」任务运维09 三、事后——报警干预措施及常态化机制12 四、未来一些思考14 二、用户需求17 三、分析框架17 四、深入应用20 二、严选为什么要建全渠道触达系统24 三、严选全渠道触达的业务场景25 四、需要解决的问题27 五、方案架构29 六、消费者运营产品落地31 前言 大数据时代，我们正由流程驱动走向数据驱动的变革，数据驱动成为新时代企业运作的核心特征。网易严选所采用的ODM模式要求电商平台深度接入生产、物流、营销和运营等环节，对于供应链运作效率要求较高，在其业务快速增长过程中，充分利用了网易数帆大数据经验，通过大数据技术的应用，优化价值链各个环节，帮助自身业务更快速、灵活地感知市场。 针对应用众多、时效性依赖较高的多业务场景特点，网易数帆数据开发治理平台EasyData为其提供了高可用的数据库方案，支持多样化的数据存储和计算引擎，并且支持实时计算和离线计算的融合，加速数据产出的时效。 基于数据分析工作大量增加的实际情况，网易数帆有数BI的可视化建模和自助式分析的特性，以及丰富的图表形式，提供了PPT式的报告制作，大大提升了严选数据分析团队的效率。 如何在全渠道范围运营好严选的用户流量？利用网易数帆消费者运营平台EasyCDP构建用户画像，方便业务方更方便的更高效的进行业务策划，广告投放，电商定价以及商品推荐，精准定位用户喜好，满足用户需求，提升企业营销成果，加强用户黏性，实现高效转化。 本实践手册邀请到四位大数据技术领域的资深专家，围绕严选在离线数仓质量建设、数据任务治理、用户行为数据分析、消费者运营平台等方面的实践之路进行分享。看严选如何通过网易数帆全链路数据生产力平台，提高运作效率，更精准高效地管理供应链，同时借助可视化报表与看板，实时将数据反馈到各个一线部门感知市场需求，助力企业持续保持敏感，为用户提供高品质商品。 希望本实践手册内容能够给行业内相关企业在数字化转型之路上带来一些参考。 离线数仓质量建设实践 蒹葭网易严选资深数据开发工程师 主要负责供应链数据建模及离线数仓质量治理相关工作。 做数仓最重要的是什么？ 模型易用性 数据质量 模型易用性我们可以通过建模规范、指标管理等方式去实现。而对于数据质量呢？本章节将以严选数仓为例，从建设目标、保障措施、效果评价等几方面探讨数仓质量建设。 保障等级确认 网易严选离线数仓目前主要基于大数据平台进行调度及管理 （Azkban），FLOW数量4000+，首先我们要做的事情就是从中识别出每个任务的重要程度，以此确定保障的策略。 具体做法是：基于CMDB的服务分级确定终端场景的重要性，再通过数据血缘上推依赖的FLOW，如果一个FLOW被多个服务依赖则取较高的服务等级作为该FLOW的分级。 数据质量建设目标 这个就比较老生常谈了：完整性、准确性、一致性、及时性。 完整性 一致性 数据完整性包含两方面：记录完整性、字段信息完整性。即某张表数据记录是否缺失，某些非null字段是否为null。 对于企业数据仓库，一份数据在多个场景使用是很常见的，一致性即指对于同一个数据定义，可以是一个原始字段或一个加工后的指标，任意使用场景所使用的数据都是一样的。比如供应链和商品开发都关注缺货率指标，他们可能分属不同团队，对接不同的数据开发，但是用到的缺货率指标只能是同一份。 准确性 及时性 准确性指数据是否存在异常或者错误的信息，如明细数据相对原始数据是否失真，汇总数据是否符合指标口径定义等。 及时性指业务需要看数时，要有数可看，具体落实下来就是数仓的FLOW要能稳定按时产出。 数据质量实施策略 针对前面提到的建设目标，目前主要有以下策略。 数据源质量控制 要做好数据质量首先我们要保证数据源是“干净”的，且数据开发要能及时感知到上游系统的各种变更。这里主要有以下3点策略： ODS层入仓监控 严选数据入仓使用自研Datahub平台，在数据入仓阶段对binlog收集、日志收集、T+1快照生成等任务做了时效监控，保障源数据的及时性。 上游变更感知 数仓的数据来自于上游业务系统，上游系统的逻辑变更必然对数仓造成影响。考虑到如果直接做发布审批卡点，流程会比较重，目前我们的做法是由数据开发自行跟对接的上游开发强调，有变更时需要把变更点告知数据开发，由数据开发评估影响。 上游DB运维感知 这层更接近于是兜底逻辑，理论上变更及运维操作都应该在发生前同步到数据开发。严选CMDB支持对服务配置“数据负责人”角色，当业务后端对服务相应的DB发起DDL或者DML工单时，变更详情会通过邮件及POPO同步到数据开发。 ETL质量控制 ETL质量控制这里指数据开发的在大数据平台开发FLOW构建数仓主题域模型的过程的质量控制措施和能力。 任务测试卡点 这里主要指大数据平台FLOW未在开发环境运行通过的，无法提交上线。同时开发环境提供测试集群，依模型重要性可以选择在测试集群进行调试，从而不影响线上数据。 任务发布卡点 大数据平台支持按规则圈选任务，对于选定的任务要求先审批后上线。借助这个能力可以实现对日常重点任务或者全局封板的发布卡点，要求CR和测试报告才能审批上线。（该机制目前暂未运行） 表质量监控卡点 主要基于大数据平台的数据稽核能力，以任务分级为基础，围绕完整性、准确性、一致性对可能的数据质量问题做出监控卡点。目前已提“支持DQC结果订阅”的需求给到数帆。 SQLSCAN静态分析 代码静态分析这块调研了SonarQube的方案，在开源方案的基础上需要解决3个问题。（1）代码集成，可借助严选自己的“血缘插件”收集的执行记录实现。（2）代码检查规则，这块需要自行开发插件，SQL相关的检查插件目前开源的方案都是针对OLTP场景的。因暂时没开发资源能投入这块，所以暂无实施计划。 产出基线控制 以任务分级为基础，将重点数仓任务划分到2:30、4:30、5:30、7:30、9:30五条基线上，基线DDL30分钟前未产出即开始预警，由值班介入处理，保障及时性。 终端质量控制（出口控制） 终端质量控制目前主要针对数据产品，QA参与建设的“指标测试平台”提供了对指标产出及时性、指标波动、不合理数值、null值等的预警能力，且由QA直接跟进异常处理。 横向巡检预警及复盘 前文提到的数据源质量控制、ETL质量控制、终端质量控制更多是分散到各个数据开发及各个任务的bycase处理，除此之外我们还建设了横向的巡检及复盘机制。事前异常变更巡检。每天下班前抓取当天的数仓变更点，进行以下筛查并通知到部门群里。 检查基线任务当天有修改的记录 检查有DDL变更却没有关联任务变更记录；事后打标分析。每天早上抓取近期基线破线记录，通知值班填报标记破线原因，用于事后复盘及破线责任归因。 稽核质量巡检 因为弱稽核失败不阻塞任务，可能负责人没有及时处理，针对连续失败未处理的任务进行抓取并通知到部门群里。 次日基线预警 如果当日的任务修改可能导致第二天的基线破线，则也定位到具体的可疑任务并通知到群里。 质量惩罚措施 针对有明显违反质量规范的行为执行“罚一天值班”的惩罚，比如表稽核连续失败3天及以上未处理。 可以看到这部分涉及了很多需要通知到人/通知到群的场景，那以一个数据开发的角色，我们怎么低成本地实现这一机制呢？ 巡检这块一开始建设的时候做的比较简单粗暴，直接用Python脚本获取需要的基础数据，进行处理后对接飞书openapi，借助飞书机器人把需要的消息通知出来。Python脚本丢服务器上用crontab调度。 场景比较少时这么做没什么问题，但是场景一多显然会导致总开发成本比较高且脚本管理混乱。这里一开始考虑的方案是把分散的巡检脚本工程化整合重构一下，规范下开发及部署流程。但其实还是比较重，最终想到一种比较巧妙的方案，通过Hive/Spark的UDF对严选消息中心的接口做一层包装，这样简单写几行SQL就能发送消息通知，且调度可以直接在大数据平台上完成，大大降低了巡检消息的开发成本。 效果大概长这样： 质量衡量 前面提到这么多措施，具体实施得怎么样，效果又怎么样呢？这里是数仓的传统技能了，收集各类元数据，计算DQC配置率，基线破线率等指标，并通过网易数帆有数BI报表进行呈现。一方面直观呈现数仓现在的质量情况；另一方面指标拆解到个人，配合消息通知工具发送待办作为推进改进的抓手。 网易数帆数据开发治理平台EasyData EasyData是网易数帆基于数据生产力方法论打造的一站式数据开发治理平台，在业内首先提出并实现开发治理一体化。强调可持续集成、可持续交付、可持续部署的DataOps数据开发能力，提供数据集成、数据开发、任务运维等产品。结合包括元数据管理、数据标准、指标系统、数据建模在内的DataFusion数据治理能力，聚焦企业数字化转型，深挖数据价值，提升企业数据生产力。 在线咨询 免费试用 数据任务治理实践 静远网易严选数仓资深数据开发工程 目前主要负责服务线（供应链&财务）主题域架构设计和数据应用开发，具有丰富的数仓体系建设和维度建模经验。 在严选数仓建设过程中，会陆续面对新的挑战，这些挑战促进了严选数仓逐渐向更成熟和更好的方向演进。（如：任务及时准确稳定产出、减少报警且报警后可干预、具备任务链路感知能力、降低资损事件发生、重大事故快速恢复等），面对这些挑战严选又是如何来解决的？本文会以事前>事中>事后的思路和大家一起分享这些建设经验。 事前——模型上线前第一道防线 模型上线前的第一道防线主要总结为5个保障分别为： 流程保障 模型设计保障 数据质量保障 测试保障 链路感知保障 流程保障 严选数仓研发一直有比较好的研发流程和规范，主要有以下三个阶段组成： 第一阶段为需求阶段 目前需求来自业务人员、分析师、产品经理等，并通过jira的形式来管理，需求阶段会明确需求背景、主要内容（如：涉及指标口径）、产出价值、希望完成时间等。需求阶段会完成需求评审，评审时再次明确相关指标口径，没问题后由产品经理录入到指标管理系统（仓颉）中。 第二阶段为研发阶段 在需求评审后数仓开发依据需求内容进行模型设计并形成模型设计文档，会组织一次模型设计评审会议，此次会议中会再次明确在模型设计中有异议的指标和问题，并重点给出后端开发时使用模型的注意事项（例如：模型粒度、不可累加性指标如何计算，如何关联模型汇总数据等），模型设计后会将模型设计通过模型设计中心进行相关设计沉淀； 接下来是任务开发，数据开发有一些公共的规范约定，如：要求单任务产出单模型，任务名和模型名要一致，如果任务存在需要将模型数据同步传输到其它DB（如hbase,mysql,kylin,es等）供统一服务来对外部系统提供服务，则要求与同步任务分开（避免同步任务耗时过久造成后续依赖任务等待）设计，还有很多规范在此不做阐述； 任务开发之后便进入了测试阶段，目前在测试阶段会有工具来辅助形成测试报告，后续会详细讲解；测试之后由需求提出方来进行验收（明确没问题后在jira中确定验收通过），自此研发阶段基本完成。 第三阶段为生产阶段 生产阶段主要核心内容为数据质量稽核配置和任务运维，数据质量稽核是由数仓开发在数据质量中心对待稽核表或字段进行稽核规则配置（说明：稽核规则配置实际执行时可以在研发阶段或者上线后配置，本文中暂时归到生产阶段）； 生产阶段中任务运维相关事项由任务运维中心来承载，主要包括任务异常报警通知处理、补数据、重跑