数据凌乱，埋点差，难以归因？数据治理有妙招！
共 7716字，需浏览 16分钟
·
2021-11-23 22:46
导读：大数据时代的到来，让很多企业看到了数据资产的价值，开始探索应用场景和商业模式，并建设相关技术平台。因此，数据治理成为了挖掘数据价值的重要手段和工具。但数据治理不仅需要完善的保障机制，还需要理解具体的治理内容，比如数据该怎么规范，元数据该怎么管理等。这些问题是数据治理过程中最实际也是最复杂的问题，今天我将从数据治理的各个核心领域来和大家分享一下云音乐在数据治理中的探索与实践。
本文会围绕以下四个方面展开：
音乐数仓概况
数据规范
埋点治理
资产治理
首先介绍一下云音乐目前所面临的一些问题与挑战，也就是为什么要做数据治理。
1. 整体情况
数据体量大。
业务场景复杂。
历史包袱重。
以上几方面导致了数据仓库在保障数据质量、控制计算与成本等方面面临了越来越大的挑战。
2. 问题与挑战
问题主要有三个方面：
数据规范：因为早期数仓建设的时候迭代速度快，没有一个标准的设计模式，导致数据非常凌乱。
数据生产：云音乐是个内容流量产品，目前在数据埋点这方面存在埋点定义混乱，埋点质量问题多，以及埋点信息不够全面等问题。埋点信息不够全面也导致我们无法支持要求越来越高的精细化运营场景。
数据资产：大数据开发经常面临开发周期长、交付质量差的问题；另外计算和存储的成本迅速增长也是我们目前急需解决的问题。
接下来就针对上述三方面来展开介绍一下云音乐的数据治理工作。
数据规范是数据治理建章立制的一个基础。在音乐数据仓库这一块，我将从设计规范和开发规范这两方面来介绍我们云音乐标准化改造的过程。
1. 设计规范-问题和痛点
在设计规范方面遇到的主要问题和痛点：
缺乏顶层设计：早期数据开发以需求为导向，跟随业务的变化而快速迭代，因此数据模型复用率低，造成了大量的跨层引用。比如大量的数据报告表都是直接从原始日志或者业务表中提取数据来做分析的。
数据孤岛：数据开发的模式主要是按照业务来划分的，开发相对独立，信息也相对独立，所以缺少公共数据资产的沉淀，从而导致难以应对跨业务的需求。
数据质量：数据异常，如空值、缺失、脏数据；数据的一致性问题，如活跃，留存，CRT等在不同的报表里面结果可能是不一样的。
这块我们需要从数据的稳定、效率和质量方面来解决。
2. 设计规范-数据域
从整体架构上来讲，我们将云音乐的整个数据进行了一个数据域的划分，用来确定一个高稳定性的数据仓库。主题域是一个要保持稳定不变的高度抽象的概念。我们将整个云音乐划分为参与者、服务及产品、事实、协议，以及公共数据这五个主题域。基于这五个主题域，我们又对业务场景做了进一步的子主题的划分，子主题的划分也是相对稳定的。数据划分后，当业务发生迭代时，新的数据也能够有一个相对明确的数据域的归属。
数据的划分主要是为了实现业务形态和实体关系的表达。我们按照以上五个主题域来进行划分是因为我们的数据核心其实就是参与者和服务及产品这两个方面。参与者就是用户，服务及产品主要是内容。
参与者和服务及产品之间会达成一些协议，比如直播协议，版权协议等。另外，参与者和服务及产品之间会产生各种各样的业务过程，这就是事实。其中主要包括流量数据，互动数据，支付数据。
在人、坑位和资源的不同粒度中，我们的分层模型设计就是针对这样的核心数据来进行的。
3. 设计规范-模型分层
上图是云音乐数据仓库分层的一个基本情况。跟大部分流量型产品的数据分层一样，我们也分为ODS贴源层，DIM的维度，以及DWD的明细，DWS的汇总层。另外我们在应用层支持了非常多的产品，比如活动跟踪、用户歌曲画像、流量罗盘，以及各种to C和to B的数据产品。
我们模型设计的核心是对DWS这个汇总层进行了进一步的拆分，比如在这个图里我们可以看到有横向拆分和纵向拆分。
横向是对不同的汇总粒度和方式进行的拆分。汇总粒度既包括明细/轻度/高度，又区分多维度/双实体/单实体。汇总方式包含周期快照以及累积快照。
纵向区分主要针对的是维度和业务过程的一个拆分。维度主要是一些核心的实体，就是人、资源、坑位。业务过程主要包括交易营收、社交互动，以及场景流量。
我们最终的设计目标是，通过这样一个模型设计来达到高效率高质量的数据生产和使用。
4. 设计规范-平台管控
我们通过网易数帆开发平台对设计规范的落地进行管控。上图是平台提供的一个工单机制，对我们的数据域、分层结构进行设置和规范，也对表和字段的命名也进行规范，帮助我们将设计思想真正落到实际的生产过程中去。
5. 数据规范-开发规范
开发规范造成的问题也是屡见不鲜，我们也在新的体系下对开发工作进行调整和改进：
很多任务会直接读写文件，导致数据血缘缺失。为达到一个完备的数据血缘，新的规范会强制要求所有人要在读写表的基础上进行。
任务会有纯SQL，或者是SQL和API结合的方式。为了统一开发规范和流程，降低运维成本，新规范要求公共层模型必须用纯SQL来执行，并且我们定义了一个SQL规范来去执行。
多表和多任务可能会合并到一个workflow里面去，导致一个workflow里可能有几十个甚至上百个任务节点，对任务管理造成了比较大的影响，也不利于性能和资源分析，因此我们要求一个workflow只能输出一个正式表，额外的好处是任务的查找也变得更加方便。
多workflow间通过数据检查依赖去执行的方式，对运维也造成了一定影响。比如任务出现了失败或者异常如何快速做数据恢复。在新的规范里，我们基于开发平台做跨流任务依赖，以此构建任务血缘，进而有效地进行基线诊断和运维。
6. 数据规范-DQC
另外我们的数据开发平台提供了一个数据质量控制的功能，上图是一个规则配置的页面。这个功能除了可以支持标准化表组件的唯一性检测，表行数检查，字段空值检查，字段枚举值检查等模板规则，还可以支持一些我们自定义的规则。这样我们能够在任务上线之后，对数据质量进行监控，及时发现并阻塞异常向下游扩散。
数据治理中解决数据源头问题是关键，下面将从技术方案和流程管理两方面来介绍埋点治理工作。
1. 埋点治理-问题和痛点
云音乐目前在埋点这方面遇到的问题和痛点，主要分为四个方面。
格式凌乱：埋点字段含义不统一，规则定义不精确，管理平台功能单一，埋点查找困难。
数据质量低下：上线较为随意，埋点的多错漏难以检查。另外我们数据方面的设计，以及客户端都是面向单次需求开发的，导致新老埋点容易相互影响，造成数据异常频出。
开发效率低：人工进行埋点编码和开发ETL任务占据了大量工作，数据需求也是直接从原始日志来进行解析的。另外业务数据，比如说像归因分析这样的需求还是依赖数据层面的复杂逻辑加工来实现的。
看数困难：目前的埋点无法支持自动化的取数看数以及精细化的指标产出。虽然我们也去落地了一些取数平台以及流量罗盘，但是这些产品基于老的埋点体系更新十分繁琐，更新周期也特别长。
为此云音乐启动了一套全新的埋点改造方案。
2. 技术方案-SDK
技术方案是联合客户端来进行设计和实施的。客户端实现了一个埋点的SDK来对埋点生产进行标准化，其中有以下几个重点：
对SPM和SCM进行一个对象化，对像化的核心就是对象能够复用，大大降低了设计和开发的成本。
复用的意思如右图，每个节点每个位置都是一个对象，不同的对象组装成一个对象逻辑树。如果对象发生了位置的修改，只需要修改它所在的父节点的位置，这样就能够大大简化设计和开发的效率。
点击和播放事件埋点，每个埋点会带上它的Refer信息。Refer信息包含了跳转到某个页面或坑位的多级行为链路及其关联的资源和策略。
埋点生产标准化的结果是埋点格式的变化。埋点格式，我们以往是用扁平的JSON方式，里面就是key/value。但在新的标准下，我们会生成一套嵌套的JSON，里面携带全局公参、事件公参、对象标准参数、对象业务参数。
3. 技术方案-数据仓库
数据仓库我们也会重新接入新的埋点数据，使我们能够实现离线和实时统一数据源接入和模型设计。
离线和实时都将具备精确的归因分析能力。
在数据仓库的数据易用性角度，我们对改造之后的嵌套JSON做了适当的扁平化。
针对这样一个标准的埋点范式进行自动的ETL，使得能够更高效地支持Ad-hoc查询以及敏捷的数据探索。
右边是我们基于新的埋点方案的数据流示意图。通过这次埋点治理，我们会同步推进历史任务的治理。以前很多任务都是直接从ODS上提取和解析数据的，希望这次通过对埋点格式的修改，能够切断以往ODS直接访问的方式，将我们之前的分层模型设计实实在在地落地到整个数据生产的环节当中去。
4. 技术方案-归因设计
我们的归因大致分为以下几方面：渠道归因、内容归因、搜索归因、策略归因。
渠道归因，主要指内容在App中分发的资源位，如首页不同模块。
内容归因，主要指内容的包装形式，如歌单、相关资源推荐。
搜索归因，根据一次搜索请求产生的后续整个链路的流向，去分析这个搜索的效果。
策略归因，主要指推荐或算法模型的归因，我们通过这个策略归因来支持算法模型的离线或者实时的模型训练。
右边展示了我们目前设计的几个refer的形式，refer同时包含了SPM和SCM的信息。比如：
_psrefer是页面对象创建，就是首次曝光时生成的来源对象；
_pgrefer是页面 每一次曝光时生成的来源对象；
_hsrefer是App内整个消费起始链路的来源；
_multirefers是行为链路上的5级页面的_psrefer顺序拼接；
_addrefer和_playrefer主要是针对云音乐的播放场景，_addrefer是触发内容添加到播放列表的对象，_playrefer是触发内容播放的对象；
_rqrefer主要是针对一些互动行为，比如评论，收藏，点赞等行为，由客户端触发服务端请求对象来记录并传给服务端来打点。
5. 埋点治理-流程管理
埋点治理的另一个重点是流程管理，因为整个埋点流程会涉及到很多团队，决定了技术方案能否高效率高质量的应用到生产流程当中。
第一步，策划、BI以及数仓的开发会录入埋点需求以及参与方案的设计；
第二步，大前端开发会根据埋点设计来设置刚刚说的一些对象参数；
第三步是SDK，根据业务设置的一些对象信息来自动构建对象逻辑树，并自动进行曝光和点击的埋点，同时会带入归因相关的refer的信息。
接下来一步，依据选择的需求中对象和树的规则进行埋点上报，上报到系统里，由QA进行实时的埋点验证和测试。
当整套流程都测试通过之后，埋点才能最终上线接入到数据仓库，进入到后续的数据分析中去。其中有两个关键的环节，就是埋点设计和数据测试，这两块会接入到我们新的埋点平台来进行管控。
6. 埋点治理-埋点平台
上图是我们埋点平台大致的页面情况。
埋点平台主要面向的是上述埋点流程中会涉及到的团队和角色：产品策划、数据开发、大前端开发以及QA。
埋点平台承载的功能是一些元数据管理，包含一些对象管理，版本管理等，以及整个需求工作流的管理和实时埋点测试。未来还会规划更多功能，比如说质量监控，BI分析等
7. 埋点治理-预期成效
埋点治理的改造项目是一项正在进行的工作，我们希望能够通过流程管控和技术支撑来提高开发效率，实现数据质量和数据价值的提升，主要包含以下三个方面：
不需要再人工进行坑位标准化，所见即所得，埋点上线后直接用于数据分析、数据产品等；
归因链路不需要再人工梳理和单点开发，埋点上线后携带多种归因字段，精确的位置和资源信息，支持实时归因；
埋点质量提升，埋点时机口径标准化，多端一致，上线流程优化。
降本提效是资产治理的一个核心，这一块将从数据流治理和生命周期治理两方面来介绍我们的工作。
1. 资产治理-问题和痛点
资产核心就两个部分：计算资源和存储资源。
计算资源：目前整个集群CPU内存的使用率绝大多数时间都在80%以上，我们的任务在半年内增长了15%，接下来我们可能就会遇到一个数据开发团队普遍会遇到的问题，就是核心任务延迟。
存储资源：整个集群存储量的日均增长近0.4%，在整个量级是PB级的存储情况下，这个增量也是非常可观的；另外还有90%的表可能都是无引用的表。
从计算和存储两方面来看，也有很多历史包袱的问题。比如可能存在大量的无人浏览的报表，大量的历史遗留任务等，这些都是我们在资产治理方面需要解决的问题。
2. 资产治理-数据流治理
数据流治理又分两个小点：分层模型数据和治理、单任务内数据流治理。
分层模型治理，本质上是数据标准、数据规范的一个落地。
当我们遇到一个数据产品各项指标需求的时候，需要去分析什么样的指标是可以沉淀到公共模型去的，什么样的指标是需要在ADS才完成的。比如我们ADS处理的是一些不可加指标、自定义规则标签以及自定义的多维分析。
我们也需要去分析什么样的指标是需要沉淀到我们的公共资产里面去的。比如说客观事实的派生指标可能需要的团队不同，可能时间周期要求不一样，可能有的要求看1日的指标，有的想看7日的，有的30日，有的3日。这些可能在我们的整个DWS层处于同一个加工流程只是一个不同时间周期的处理。另外多团队一致复杂指标的典型案例就是我们对一些资源或者用户会进行一个综合评分，综合评分会用到多种多样的场景。
一些缺失的原子指标必然需要从我们的DWD层去重新加工。
单任务内数据流治理这块主要讲一下我们在做单任务优化的时候的大任务拆解策略。
大任务内部逻辑是否需要拆解我们从两个方面来考虑：
拆解执行过程，降低任务的失败或者延迟恢复的成本。因为某一个节点失败之后，可能我们只需要从这个节点重新进行恢复，不需要重新执行整个任务，因为有时候重新执行整个任务需要好几个小时。
避免做过度拆解，因为可能多余的任务启动和IO的过程反而会导致效率的下降。
这边简要总结几个我们在优化过程中的经验：
需要缓存的中间结果拆解。要考虑先做子节点的拆解，避免重复计算。
尽量避免拆解为串行任务。拆为串行任务并没有优化整个执行过程，反而导致了多余任务启动还有IO过程的问题。
依赖产出不稳定的多个部分拆解。比如将上游产出不稳定的部分拆分为多个节点，这样就能够降低上游任务的影响，分散计算资源占用的时间。
案例：我们有一款数据产品是一个推歌的产品，核心是生产歌曲画像标签。歌曲画像我们总共做了400多个标签，之前随着产品快速迭代和烟囱式开发，产生了大量ADS表，其中包含许多重复的数据加工逻辑。在落地我们的模型设计规范之后，减少了十个ADS表，沉淀了50多个指标到CDM，让我们整个数据的产出时间提早了两个多小时。有的任务里面可能会加工特别多的数据，我们通过对单任务数据流的优化，实现了单表耗时减少30%以上。
3. 资产治理-生命周期治理
资产治理的另外一部分就是生命周期治理，生命周期治理主要考虑三个部分：
业务场景分析：在模型设计的时候，需要我们综合业务场景、应用场景去规范设置表的生命周期，并对过期的任务和数据进行清理；同时对于一些新老模型更替的情况，即使对老任务和相关依赖进行迁移和下线。
数据血缘分析：数据血缘能够帮助我们去识别表被引用和访问的情况，做自动的生命周期诊断，基于分析结果进行针对性清理。
成本分析：成本分析是帮助我们针对一些高计算、高存储成本的任务和数据进行重点排查和治理，针对不同的情况做优化、改造或下线。
这块我们也借助网易数帆开发平台中的数据资产中心，支持我们做存储分析、计算分析、报表分析，来帮助我们去更好地管理任务和表的生命周期。通过这个平台我们已经下线了100多个报表和相关的任务，节省存储超过1PB。
最后对我们云音乐未来数据治理做一些规划和展望，我们希望做到的是自动化的数据治理方案。主要有几个方面：
数据资产的可视化。将我们整个数据仓库的标准做一个可视化，让更多的数据使用方明确地知道仓库里面有什么样的数据，怎样使用仓库中的数据。
SQL静态代码检查以及性能监测与告警。目前数仓开发需要同时完成开发和测试工作，而且数仓团队的规模也在不断扩大，光靠人工保障开发质量是不可控，还是需要结合平台能力来对我们的代码进行管控。
制定健康度评分。这个是希望从数据生产和使用的多个方面，对数据本身或者数据工作者进行一个综合的判断，并反过来去指导我们更高效更合理地做数据生产和分析。
精彩问答
Q：数据治理之后的显著成果有哪些？
A：第一个是数据规范的落地。之前整个数仓是没有一个明确的分层定义的，现在我们会将整个数据资产搬到我们的数据平台去，重新定义好分类，重新构建DWD、DWS、DIM。现在有一百多个已经分好数据域数据分层的模型。第二个是新的埋点正在逐步上线。因为涉及到历史埋点和新埋点的兼容问题，所以目前正在做上线前的测试以及新老数据的对比工作。资产治理方面，通过数据平台管理任务，我们下线了100多个报表，使得线上的一些核心任务能够能有更好的计算资源的保证。
Q：数据治理的成果如何来通过指标来量化？
A：基于我们网易的开发平台，有一些资产大盘。我们现在目前整个存储增长是一个什么样的情况，表的生命周期管理是什么样的情况，有多少推荐下线的表以及我们真的下线了多少，这些具体指标我们平台里面都会有。
Q：能详细说一下技术架构吗？
A：这个架构图DIM层、DWD层可能各个公司都一样，主要讲一下DWS层。比如从社交互动这一块，因为我们是个内容平台，除了有消费者之外还有生产者。所以我们根据内容、生产者、消费者这三个核心，以及坑位来去设计这一块。这里总共分了两条线，一个是我们区分多个维度的一个聚合的快照；另外一个是我们在做一些活动、报告或者总结的时候，经常会用到的比如用户的首次行为是什么样子的，歌曲的首次行为样子的这种信息。我们会针对这类需求再做一些公共模型，比如落到每种资源的首末次详情。除此之外，我们还会做比如播放或者互动行为的留存情况。这一块的设计是，在流量这块我们也会有一个简单的多维分析的聚合，也会有针对用户和坑位的首末次情况，以及用户和坑位的留存情况。其实在整体设计上来说，思路都是一样的，只不过我们从横向和纵向再进一步做了一个拆解。然后顶层这一块，因为我们经常会用到，比如歌曲画像里面，歌曲什么时候达到了它的播放峰值，还有其他类似相关的时间点级对应数据的记录，我们针对这类需求场景做了一些的累计实时的快照表，这样方便我们去对资源或者对用户进行整个生命周期的分析。
Q：可以聊一下数据和业务之间的关系吗？哪一个更重要？
A：数据和业务应该不存在说哪个更重要，因为我们数据需要根据业务来做迭代，业务需要用数据来做支撑。比如说怎样合理的分配我们的流量，怎样合理的分发歌曲，怎样合理的设计产品，这些东西都需要我们数据去做支撑。另外一个就是数据的价值，音乐版权的采买情况或者是ROI的分析，需要我们从数据层面来进行支撑。通过这一套数据我们做了一个版权评估系统去支持我们的业务做相关决策。