基于元数据构建智能化治理平台建设实践
共 10020字，需浏览 21分钟
·
2023-10-12 15:20
1. 音乐数据平台的规模和现状
2. 治理平台的建设背景和目标
3. 治理平台的建设和落地
出品社区｜DataFun
音乐数据平台的规模和现状
我们通过数据平台整合技术和业务，对业务赋能，使用户能够高效、稳定、安全、经济和准确地使用数据。
云音乐是网易集团一个比较大的BU，我们基于集团的数据平台数帆结合音乐的业务打造了面向音乐业务的相对垂类的数据开发平台 - 云村数据平台。我们的用户和网易数帆有些不同，我们的用户主要是音乐的开发。云音乐经过10年的发展，已经到了一个人人用数据的阶段。除数仓开发以外，技术中心的开发、前端、后端、QA、甚至一些非技术的运营都会用我们的平台来使用数据、做数据处理工作。
我们的很多组件是基于业务需求定制的，希望能够减少用户的使用成本，让数据开发工作的门槛更低，可以更高效、更安全地处理数据、使用数据。
我们提供了很多能力，除基础的JAR包任务、SQL等，我们还根据业务的需求做了很多定制模块，例如实时NoteBook、离线数据传输、离线数据邮件、离线NoteBook、离线数据流等等，并基于这些基础组件打造了批流一体的低代码的平台FastX，这是我们近两年在做的主要工作，一切都围绕业务需求来建设。
云音乐上线十年左右，我们的平台建设也已经有五年多的时间，累计用户超过800，每天的UV有200多，因为大部分用户都是非数仓专业的数据开发，所以面对的问题就更多。
业务类型上，主要场景有算法特征开发、样本生成、索引构建、内容监控、数据报表、线上统计服务等等，支撑音乐主站、直播、心遇等所有音乐的业务。
任务规模上，我们目前的离线调度任务有7000+，执行中的实时任务有1500+，比较好的是我们80%以上的任务都是基于平台现成的组进行开发的，而不是自由度更高但是运维更难的JAR包任务，这对于我们日常运维支持工作是非常有利的，我们能够很清楚地知道用户的业务逻辑，更加方便地进行指导和优化。
集群规模上，我们目前的计算节点有2000多台，每天的日志量达到千亿级别，在这个数据量的背景下，整体稳定性还是有一些挑战的。
治理平台的建设背景和目标
接下来介绍一下治理平台的背景。
首先来看一下我们面对的问题。
开发质量问题：在我们大部分用户为非专业数据开发的背景下，平台上任务的开发质量问题是非常凸显的。
非专业用户数据开发相关技术的知识储备是非常薄弱的，很多时候我们都是回答用户很基础的开发问题，例如配置任务资源、任务怎么去开发实现他们的业务逻辑等。特别是实时任务，不像离线任务的SQL已经很成熟，实时SQL虽然有，而且功能也已经比较强大了，但是因为和离线有比较大的差异，整体问题就更加多，整体运维压力也更大。
用户的数据意识是非常薄弱的，在很多人眼里的数据任务还是等同于不重要的任务，任务的运维报警处理意识差。
代码质量问题多：因为用户的背景问题，用户的代码治理问题也比较多，如用户不知道用分区表必须指定分区、实时任务状态如何选择、或者使用不合法或不规范的SQL
资源浪费问题：开发质量问题会造成资源浪费：闲置表不及时下线、代码质量、资源配置不对导致的资源浪费、以及一些做活动的业务萎缩，但任务资源没有及时调整导致的资源浪费等。
运维负担问题：以上的问题会导致非常非常大的运维负担。
从我们的系统工单上看，平均每月100个左右工单问题，其中有60%以上的问题都是一些基本的使用问题。
日常治理的推进：因为这两年是降本增效的大年，我们要花大量的人力去推进用户做任务下线、数据下线、离职的转让、资源的优化等等，任务繁琐、耗费人力。
开发辅助：日常除了解答一些问题以外，我们要去辅导用户做一些任务的开发、资源的调优等工作，非常琐碎，其中重复的、可沉淀的东西非常多。
回到治理场景，我们在搭建治理平台以前，任务治理、表治理大概的流程如下：
这里展示的是日常我们做任务治理、表治理的一个通用的流程：
①. 首先我们会以人工或者脚本的方式扫描出来想要治理的类型的任务或者表，简单的时候一条SQL就可以找到，复杂的时候需要收集大量资源的元数据，然后通过人工或者脚本的方式才能梳理出我们想要的治理资源。
②. 找到这些资源以后，我们需要推进用户进行治理工作，在这个阶段，我们一般是先整理一个共享的Excel协作文档，然后拉齐所有的开发推进治理，准备一个操作文档，让用户按照操作进行治理工作。
③. 开发收到通知以后，按照治理文档，手动进行治理工作，然后把治理的状态和结果手动登记到共享文档上。
整个流程走下来，显而易见，效率非常低下，用户也很难一直保持积极性来配合平台进行治理工作；在操作的时候，用户也不一定会严格按照文档进行治理动作，治理期间也可能导致问题、严重点可能会产生事故；其次治理期间梳理的脚本，没有地方统一沉淀迭代；或许如果换一个人来推进，或者中间隔了很久的话，又会产生大量的重复工作，另外一点就是，我们这些治理工作往往都是运动式的，没法做到健康的可持续发展的状态。
为了解决以上问题，我们希望打造一个自动化的、智能化的治理平台，做到问题早发现早治理，责任到人，保持整个数据生态的健康发展：
①. 在开发阶段：提供如代码优化建议、资源配置建议、运维配置检查等等，保证整体的代码质量。
②. 在服务阶段：任务健康度巡检：如任务自身日志量监控、闲置任务探查、是否多次异常failover、资源合理性检查、资源利用率是否充分等等。
③. 在下线阶段：推进资源及时下线、自动化的回收治理效果，以及输出一些红黑榜的机制、质量分机制来提高用户治理的积极性等。
在系统功能的设计上，我们希望做到以下几点：
自动化，系统要具备调度能力，自动化巡检所有的资源，发现不合理的资源，自动发送统计中推进用户进行治理动作，回收治理效果。
智能化，通过灵活的规则配置和优化，让系统随着迭代成长，智能化、准确地发现不合理的资源，智能化地为用户提供开发建议，高效地完成开发工作。
易扩展，系统要具备灵活扩展的能力，可以方便地支持多种多样的资源对象，各种形式的规则配置以及各种形式和任意的三方系统进行对接。
可复用：除了数据治理场景以外，我们希望这个平台迁移到其它的场景，多样的资源治理场景，比如服务治理、Kafka topic治理、机器资源治理等等。
治理平台的建设落地
接下来介绍我们治理平台的建设和落地实践。
先来介绍平台几个大的概念：
资源对象：指我们治理的对象或者相关的对象，比如平台任务、用户、HIVE表、Kafak Topic等。
元数据：资源对象的属性数据，或者说是特征数据，比如任务的代码，任务的负责人、失败率、类型；用户的部门、在职状态等等，在元数据这块我们需要做到丰富准确，保证数据够用、数据能用。
规则：读取资源对象的元数据，遍历所有的资源对象，根据规则发现问题资源，给出开发建议，规则可以是简单的if else、也可以是复杂的的模型，在规则这一部分我们希望做到是全面、智能、准确，能够尽量全面的考虑各种场景，扫描出不合理的问题，智能的给出准确的开发和治理建议。
治理：订阅读取规则的执行结果，和三方系统对接，推进用户，走标准化的治理流程，执行治理动作，推动资源对象问题收敛，在这一步我们需要做到有效触达，保障用户在知晓问题的同时，也有足够的动力来进行治理动作；同时也需要提供高效的治理平台，让用户能够高效准确的进行治理操作。
上图是平台的整体架构，其中紫色部分都是可以扩展的，包含元数据模块、规则模块和治理模等。
元数据模块：包含特征插件和迭代插件。
规模模块：沉淀规则，发现有问题的资源。
治理模块：负责和三方系统对接上报数据，回收治理结果。
整个系统的逻辑是这样一个流程：从三方系统读取、沉淀资源对象的元数据；规则模块利用这些元数据，给出有问题的资源数据通过治理模块上报到三方系统；或者三方系统通过API主动调用规则模块获取开发建议；最后用户在三方系统上执行治理动作，同时把治理结果数据回流给治理模块。
接下来详细介绍每个模块的设计。
元数据模块包含以下几个部分，第一个部分是资源对象，刚才已经介绍过，就是治理的对象或者相关对象，比如任务、表等，是这些对象的特征列表，每个特征包含名字、类型、读取方式等，主键特征，唯一定位资源对象实例的特征，如任务ID、表的库表名等、用户的邮箱等。
元数据模块有两大类的可扩展的插件，迭代器插件和特征插件。
迭代器插件：类似于table scan，遍历所有的资源，在做资源巡检的时候通过迭代器来遍历所有的资源对象。
特征插件：遍历到资源以后，要通过特征插来读取所需要的资源的特征数据，我们的特征主要有两种类型，主键特征和普通特征，主键特征唯一标识资源对象，类似表的主键，迭代器返回的就是资源的主键特征的值，普通特征就是资源其它的一些特征值，如表类型、存储大小、上下游任务等等，每个特征值都有自己的数据类型；特征的读取方式有两种：一个是仓库读取，一个是插件读取。仓库读取会把特征先落到我们自己治理平台的KV里，然后从KV读取，这样做的好处是使用的时候不会对三方系统造成任何影响。而第二种方式插件读取直接调用三方平台接口或者直接读取三方平台数据库拿到特征数据，虽然会对三方系统造成一定的调用量，产生一定的影响，但是数据非常实时准确，不像仓库读取可能会有一定延迟。两种读取方式会有不同的使用场景，接下来会有介绍。
规则模块遍历所有资源，发现有问题的资源。或者被主动调用通过规则匹配，返回不同的结果。
规则模块包含以下属性：
迭代器，在巡检模式下，巡检资源时，使用哪个资源迭代器遍历资源对象，进行规则过滤；
资源对象，规则治理的资源对象是什么；
调度策略，在巡检模式下，以怎样的频率，什么时候进行巡检操作；
治理模块，规则的结果需要上报给哪些治理规模；
触达用户，如果规则命中，需要通知哪些用户，这个用户可以是资源的某一个特征，也可以是一个固定的用户或者用户组；
执行方式：巡检模式：定时调用，发现有问题的任务和资源；主动调用：被主动调用用来辅助开发，或者做一些流程卡点的动作。
特征读取策略，在执行规则时，优先以那种方式读取特征，是仓库读取还是通过插件读取，在我们的设计中，一个特征可以同时支持通过仓库读取还是插件读取，在巡检模式下，需要遍历所有的对象，这种方式一般对特征的实时性要求不高（如闲置表下线），但是调用量大，为了不对三方系统造成压力，比较适合使用仓库优先的方式读取，保障三方系统的稳定；在主动调用模式下，这种往往是做些开发辅助的工作，如上线校验卡点、资源配置推荐、任务问题诊断等。往往执行单个资源，调用量小，但是数据特征必须是最新的，这种Case下就必须使用插件优先的方式操作，获取实时准确的数据。在规则配置上我们可以通过对接口的二次封装来支持各种形式的规则配置，最基础的是通过JAR包方式，继承左边接口来扩展，经过封装， 我们可以使用Python脚本、可视化的方式来扩展规则，降低规则配置的门槛，上面的代码为规则插件最上层的接口方法。
3. 治理模块
治理模块主要负责订阅规则模块的结果数据，上报到三方系统，以及回收三方系统的治理的效果数据，它是治理平台和三方系统之间的一个桥梁。比如我们需要做一个闲置表治理的工具，在我们的数据开发平台上提供一个闲置表治理页面，那么闲置表治理页面的后台，就需要通过治理模块和治理平台进行联动，接收治理规则巡检扫描出来的的数据，然后展示到治理页面上，用户可以通过这个治理页面，快速地看到有问题的资源数据，同时通过这个页面进行高效的治理操作；在三方系统完成治理动作以后，同时还需要执行回调，把治理结果返回给治理模块，回收治理效果，形成数据闭环。如上图所示，治理模块插件的扩展接口很简单，只有一个report方法，把规则的扫描结果上报给三方平台。其中第一个参数是拿取任何资源对象特征的service；第二是默认展示的特征列表，需要哪些特征会通过dispalyFeathers传进来，然后再上报出去；接下来是runtimeContext运行环境、resourceKey资源主键、以及规则的执行结果；最后需要触达的用户列表数据。
4. 落地实践
我们现在已经落地的包括任务的连续失败下线、任务的报警频繁不处理、任务无效归属，负责人已经转岗或者离职、任务重试率高，数仓闲置表治理、数仓游离表治理、数仓表业务线没有归属等等规则，这些规则结果会通过开发平台上治理页面透出，通过网易内部POPO聊天工具发起通知，并通过和质量分对接来推进用户及时操作治理。
接下来我们通过数仓闲置表治理这个非常典型的场景来讲一下我们是如何使用这个平台进行治理工作的。
闲置表治理的目标是希望不再使用的表能够及时下线，减少存储成本，同时降低HDFS以及HiveMetaStore的压力，落地闲置表治理包含以下几块工作：
第一个是收集元数据：收集HIVE表相关数据，作为规则的输入；
第二个是配置规则：读取元数据判断数仓表是否为闲置表；
第三个是对接治理页面：和平台对接，提供前端方便用户进行治理操作；
最后一个是要推进用户主动去做，提高用户的积极性，这一点反而是最难的。
首先是元数据收集部分，在Hive闲置表治理场景，我们需要收集的元数据主要包含三类：
Hive表的基础元信息，包含存储信息、生命周期信息、更新信息、负责人信息等；
血缘信息，包含各种来源的血缘，静态代码扫描的血缘，Hive、Spark上报的运行时血缘，Impala血缘，以及相关下游报表的血缘；
Hive表相关的业务信息，比如HIVE表的主题域、重要等级、是否白名单、负责人信息等包含负责人的部门，直接上级，当前在职状态等等；
在元数据部分我们需要做到丰富准确，保障数据质量和覆盖面，既要够用也要能用，特别是在闲置表治理场景对数据的全面和准确要求非常高，因为错误的元数据很容易导致错误的结果，导致真正有用的表被下线，造成事故。
接下来是规则配置：
有了丰富的元数据，我们需要考虑的就是配置正确的规则来发现无用的闲置表，在这里我们平台支持通过Python脚本来配置规则，这里我们主要考虑几点：
首先我们要确定它是否在治理范围内，有些新表或者生命周期本身就很短的表是不用治理的，比如这个表才创建十天，它虽然没有人读，可能用户还没有开发好，所以创建时间大于60天的表我们才会把它囊括进来。另外，如果表的生命只有60天，就没有治理的必要。最后还要看是否白名单，如果这个表是备份用的，用户加了白名单，也没有扫描治理的必要。
第二判断它是否还有在使用。其实前面几点都比较简单，就是通过Hive血缘、Spark血缘、Impala血缘、任务依赖等，来判断相关数据表是否还在使用。
然后就是相关表，目前我们主要判断两种情况：第一如果产生这张表的任务，同时产生两张表，虽然没有直接的上下游关系，如果一张表下线了会对另外一张表也会产生影响，其次就是两张表指向同一个路径情况，如果把这个表下线，可能另外一张表有人读，会导致系统问题，所以我们需要找出指向同一个路径的表，不能把它下线。
最后还需要考虑表底层文件的使用情况，因为Hive本身底层是HDFS文件，不是所有的开发、或者框架都会通过表去读取数据，我们遇到过最多的是算法模型训练的场景，他们的TF框架很多都是直接读数据文件，我们需要拿到这个表的相关文件的open时间，去做文件的审计追踪，来关联判断相关表是否还在被使用，防止表被下线，导致下游任务出现问题。
以上就是闲置表治理整个规则判断的一个概述。在规则配置这块我们要结合使用场景和历史经验尽量考虑全面，不断迭代，做到比人工判断更准确。右边是我们平台的一个截图，目前还是通过Python脚本的方式来配置规则，后续我们希望能够提供更加方便可视化的规则配置方式。
下面是平台对接，规则巡检完成以后，除了会将结果落地以外，还会将结果对接到三方的治理平台当中，三方系统订阅接收规则模块上报的数据结果，将这些问题的资源在系统展示，然后通知用户在治理平台进行操作治理，最后将治理效果回调给治理平台，回收治理效果；在这个部分治理平台需要做到以下几点：
提供高效的治理操作，比如在闲置表治理这个场景，我们提供了一键下线、批量下线等支持，同时还支持同时下线表相关的生产任务，保障用户高效地一站式完成下线操作；
透明的判定数据，在平台上需要让用户清楚表为什么被判定为闲置表，同时透出相关的数据，给出判断依据，让用户能够看到足够的信息，再做一次人工check校验；
自动的效果回收，在用户操作完下线以后我们需要自动回收下线数据，包含下线的记录（表和任务）、节省的存储、计算资源、以及相应的成本；
兜底的回滚策略，当平台产生误判，用户下线了不应该下线的数据时，平台需要提供快速高效的回滚能力，保障数据能够快速恢复，止损；
最后一个是有效的反馈机制，当平台发生误判时，用户可以通过平台直接反馈，帮助平台不断地优化规则，及时发现平台问题，提升后续规则判断的准确度。
最后一步是推进治理，对于我们这些做技术的同学来说是最难的。我们面对的几百个用户，每个用户的业务目标都是不同的，每个用户对于治理操作的积极性也是不同的。所以这里我们需要做的关键点是：
有效触达：找到对的用户，让用户知道有些资源需要治理，为什么需要治理，不治理会有哪些影响等，这一点相对简单，我们通过公司内部的IM工具每天发送相关报表，自动发送发闲置表的情况，告诉他闲置表有多少张要治理，多少成本；还会同时发给团队leader，告诉他团队的闲置表的汇总情况。
对齐目标，让用户有动力、有积极性去做治理操作，这一点往往是比较难的，目前主要有以下几个手段：
整合开发的质量分，把资源使用不合理、开发质量不合理等整合进云音乐内部skynet的质量分，这个质量分相当于是一个评比，每个团队有一个合格分，通过上层对下层的制度约束去推进相关开发的治理积极性，主动进行治理操作。
第二个就是红黑榜，通过榜单说明谁做的好谁做的不好，通过这种通晒评比的方式来提升。
最后一个杀手锏是关联治理效果和平台使用权限，如果整体资源的健康指标达不到合格的标准，平台直接禁止一些操作权限，如新任务、新表创建、限制自主分析查询资源等。例如如果某个用户的闲置表治理情况不合格，提前一周开始预警，如果长期不治理就禁止其创建新的任务，甚至直接禁止相关用户所在团队的使用权限。这样用户自然而然就会有动力做这个事情。
整套流程走下来，达成治理目标主要有四大关键点：
第一是要有丰富准确的特征数据；
第二是有一个准确的智能的规则；
第三是有一个好用的治理工具；
最后一个是有效的推进机制。
结合这四大要素，构成一个智能化的治理流程闭环，做到比人更智能、比人更高效、以及比人更规范，最终达到一个可持续的健康生态，从平台运维运动式治理的主动收益，变成平台自动化推进用户主动操作治理的被动收益，平台方躺着拿到治理的结果，形成一个健康的可持续发展的治理生态循环。
治理平台的未来规划
最后简要介绍一下我们的未来规划：
首先是更丰富更准确的特征数据，巧妇难为无米之炊，不管做数据治理还是做模型训练，我们都会强调数据的丰富性和准确性，因为只有有了更多的数据、更准确的数据、更详细的数据，我们才能把治理做得更细致、更准确、覆盖面更广。
第二是更好用的规则配置手段，我们的平台目前是第一个版本，规则配置手段还是比较弱的，目前只支持Python脚本方式，未来我们会支持更多样、更简单的配置方式，比如增加可视化的拖拽的方式和低代码的方式，降低整体的使用门槛，让运维和开发以外的更多的用户来用，比如让数仓同学也能够快速地配置他们想要的规则来提高开发质量分，我们可以提醒他高质量表的热度，有哪些表被穿透，哪些表是没有被用的，在开发数仓过程中提供一些质量监督手段。
最后就是更多的场景覆盖，有了更多的数据，更方便的配置手段，就要去覆盖更多的业务。除数据场景以外，我们希望去做比如模型的治理、机器的治理、服务的治理、中间件的治理Kafka或者其他数据库的表等等，希望能够做成统一和通用的治理平台。
以上就是本次分享的内容，谢谢！
Q&A
答：插件是针对规则的，目前我们针对HDFS的治理主要有两点，第一是闲置数据，第二是小文件。在这块我们优化改造了文件的审计日志，在日志中除了能到客户端IP、操作情况以外，还有任务的信息，比如ApplicationID也会传入审计日志，这样我们可以快速定位到产生问题的源头。
答： 第一是监控重点目录，比如Flink的状态文件、Spark/Hive的临时文件等固定目录。第二是超大目录的扫描判断。最后对于SQL产生的小文件，这点我们对我们的SQL引擎是有经过改造的，默认会在最后多做一步计算，自动合并小文件。
答： 刚才规则部分已经介绍，第一点是判断表是否在治理范围内，通过表的生命周期和创建时间，配置是否有白名单；第二点是判断表的使用情况，通过血源，任务的血源、报表的血源、Impala的血源，任务的依赖关系来判断。同时还需要考虑相关表的使用情况。另外，我们还会把这些数据全部透出给用户，让用户去做一次人工确认。