干活讲解下数据治理中台

导读：数据治理经过多年的沉淀，积累了比较完善的理论体系；但是落地时候，治理范围如何聚焦，数据产品如何定位、具象设计和推广运营，不同公司有着不同的设计实现。本文会结合贝壳找房近两年的业务数据中心建设经验，从产品视角来谈谈数据治理的问题。主要内容包括：

• 数据治理目的及内容

• 结合公司特点聚焦治理范围

• 中台侧实践的建设内容及思路

• 治理项目的目标管理

• 产品及运营落地经验

1. 贝壳找房介绍

贝壳的主要C端产品是贝壳找房app，围绕居住领域，提供二手、新房、租赁、装修等品质服务。

2. 数据治理目的

① 共享

共享性的提升，是指让公司内部所有的要用到数据的同学，知道公司有哪些数据，找人找数更加便捷。

首先从业务视角来看，在日常的需求对接中，通常会通过邮件、PRD、共享文档等载体来管理和记录数据，一旦发生人员调转，或者业务组织架构调整，数据的背景前提就无法考证。很多情况下，数据逻辑只有相关产研了解，需要较高的沟通成本。另一方面，从公司视角去看共享性这个问题，公司的业务系统众多，导致数据分散在各个部门管理，无法流通起来。在这种情况下，我们需要一系统平台，对数据做统一的收口，使得高流通的数据可见、可查、可申请、可管理。

② 准确

第二个方向是基于准确性的考量。

• 在现实场景中，一个业务字段可能需要从多个维度去定义和描述，包括业务含义，图文解释说明等。但是数据提供方的记录文档，常常不够清晰和完整。我们希望，业务方通过系统平台看到相关数据后，可以判断出它的业务含义，以及是否符合诉求，是否可用。数据治理想做的事，就包括通过工具约束，对字段进行维护和补全。

• 业务自身在迭代过程中，会产成多个版本；数据业务含义的历史变更等，都需要进行维护。

• 不管是实时的业务系统数据还是接口数据，我们希望提高搜索的准确性，降低沟通成本。

• 业务迭代过程中，上游发生变化时，需要及时触达到下游的关注方，这也是我们系统要解决的问题。

③ 可用

可用性主要是指做到让数据可信赖。已经下线的数据，如果文档没有同步下线，可能造成下游使用方继续调用数据，影响业务；此外，对数据健康状态的监控预警，如事件类消息的消费积压等，也需要及时触达下游；然后，通过元数据的血缘关系，可以帮助业务方更快查找问题；最后，为降低下游消费方解析数据的成本，应该尽量保证流通性数据的数据格式统一。

3. 数据治理范围

对于大量的用户数据，我们会对相应的埋点数据进行管理；加工用户数据的数仓表，需要进行元数据和数据血缘的管理；加工得到的指标，需要解决的问题包括指标合理化定义，指标认证，指标高效检索等。

除了上面介绍的离线数据，还有一些业务主体数据，如贝壳经纪人相关的作业数据等业务系统实时数据，会落到mysql表中，或是加工成流通的数据形式：如以kafka消息，或实时接口的形式提供。完善的数据治理需要多年的时间，公司可结合自身业务特点和系统交互模式，针对现阶段问题对症下药进行治理，把小类问题做好，即可发挥数据治理的价值。

下面介绍，我们在以往的经验中，是如何结合公司业务的需求，确定数据治理的范围的。

1. 系统特点

主要从两个方面来看贝壳对数据治理的要求。

首先，贝壳业务数据系统特点，更偏中台属性，许多前台应用无法实现数据的自给自足，需要依赖中台进行数据传输，如C端界面呈现的大多数信息等。同时，一些精细化的运营动作，风控、品质相关的智能算法，实时金额奖励等都需要用到中台侧的实时数据，这部分需求的特点是高频且强依赖。

另一个视角看，中台侧自身也存在一些同质化问题，比如数据本身的黑盒化：数据都收口在中台，没有向用户普及，就会影响数据的共享，造成沟通成本较高。另外，一些需求的开发成本较高，需要较多产品、研发、测试同学参与，需要进行提效。第三点是存在格式混乱、可读性较差的问题，这些问题会导致中台侧对一些紧急的数据需求无法及时响应。

基于以上问题，需要业务中心来对中心化的数据做统一的治理、收口和质量管控。主要包括两个核心：数据收敛和提效建设。数据收敛主要解决数据不共享的问题，把一些高流通的接口和事件类数据做集中的发布，并做相应的质量管控。提效建设是为了让更少的人力参与到高频且复杂的数据流通过程中，把产研人力释放出来，投入到对公司价值更高的业务开发和业务迭代中。

2. 业务特点

以上是从公司业务系统交互模式上考虑，需要建设数据治理中心。下面从公司本身的业务特点来分析。

许多为传统行业赋能的互联网公司都有作业的主体，如贝壳找房的经纪人等，这就导致很多业务运营诉求的产生：需要利用数据，对业务进行正向牵引，对作业人员进行管控。比如对经纪人上传房源的备件信息来保证房源质量等正向行为的激励，对一些作弊行为的处罚等。这类需求的特点是对数据的实时性要求非常高，奖励要及时发放，关黑等处罚要及时处理。而上述这些正向牵引和管控，依赖对实时数据源的监听，要求数据中心本身要收口足够丰富的数据。

以“共享”和“业务语义可读”举例来说，业务运营的同学需要配置一些运营规则时，能够通过数据源，快速判断如何使用数据，来辅助运营策略。

许多公司都会遇到运营规则演变一段时间后，策略规则需要优化和提升。这就需要数据准确且可回溯，能够找回依赖的数据源，完成策略优化工作。

结合贝壳的业务特点，我们的业务数据中心主要对业务主体关联的明细信息接口，和业务节点的kafka消息做重点治理。

以上从系统特点和公司业务特点，介绍了数据治理的背景环境。下面展开介绍数据收敛和提效建设的必要性。

3. 数据收敛必要性

首先，由于中台维护的数据不够全面，有大量的高成本单次取数需求，需要业务方来支持，且这些数据往往缺少文档记录，完成需求需要较高的沟通成本。这类需求量级大，频率高，管理者可能会采用增加人力的方式来解决。造成人力成本较高。

公司在做数据赋能过程中，包括AI、品质风控、精细化运营等团队，需要来自不同业务方的大批量数据，取数效率低会成为卡点，影响核心项目的展开。所以有必要通过业务中台对数据进行治理。

4. 提效建设必要性

提效建设方面，如果通过管理层从上向下推动，往往不够高效。建议结合数据流通中产研的痛点问题，将提效做到平台产品中，释放人力，这样执行层就会更通畅地接入。

1. 建设内容

提效建设围绕从生产到发布测试的整个流程，包括自助测试、查询订阅等功能，方便整个公司更高效地访问数据。数据从生产、测试、查询使用、权限申请的闭环都通过平台来管控。

2. 产品框架

在产品架构上，根据治理的数据主体分为不同类，如接口、事件、指标、数据表等。每个类下面有多个领域模块。比如生产环节提效方面，支持配置化开发；发布时统一格式规范和查询入口；支持用户根据需求，自主订阅查询；测试时支持自助联调测试；以及通过监控和预警模块，对数据质量进行管控等。

3. 建设思路

建设思路首先要建能力。我们有很多的数据生产方，所以针对生产环节进行了一系列功能性建设，支持数据更便捷的加工、发布、关联业务属性，以及从生产者视角查看下游链路、订阅方，数据变更的触达等。

平台对消费方的支持，包括支持统一的查询、自助订阅、对已授权数据的管理、变更触达等。生产和消费功能具备后，就可以启动推广。推广过程中的问题怎么解决，后面会有具体的例子来说明。

当数据都收敛到平台上之后，才知道有哪些数据可以治理。首先要识别有哪些问题数据；另外要完善数据认证的功能，来提高取数的便捷性；在质量维护方面，通过线上的反馈和触达机制，结合问题报告等管理方法，来代替运营走查的方式，形成良性循环。

数据治理工作依赖很多组织的配合。比如公司通常有治理委员会，还需要跟安全、法务部门有协作，以及会有一些自上而下的数据规范标准等，这些组织依赖会影响数据治理的设计。能力依赖方面，数据有非常多的应用，以数据请求为例，就需要基础且统一的服务标识；还可以通过链路日志的分析，来辅助识别问题；鉴权方面也需要相应的能力等。

目标管理第一是能找到数据。许多核心业务项目的数据，都通过平台来获取，可以通过平台对业务数据需求的满足率来评价。第二要求在业务方使用数据过程中，数据清晰可理解，量化为核心指标字段信息的完备率、以及平台中心化认证数据的占比。第三要提高数据使用中的质量，减少badcase数量，这方面可以和公司的工作流系统、故障组等配合，来量化这个指标。

以下是一些想要共享的建议。治理团队最好不要做只负责建设工具的独立团队，在设计之初，承接一段时间业务需求，才会了解业务方真实的诉求。“治理团队要长在业务的土壤中”。在需求场景中发现的问题，是只通过调研访谈用户无法发现的。我们在做治理中心的时候，会承接业务方的数据需求。通过对整个流程中，产品、研发、测试的具体工作有比较深刻的体验，才能设计好产品。

1. 数据收敛经验——目标用户触达

产品设计完成后，一般结合几个试点用户的反馈来建设能力。之后就需要进行推广。首先要明确平台服务的用户，如果用户是整个公司的产研，可以利用公司内的电子屏、海报机等展位，以及公司的内网来对用户进行触达。

2. 数据收敛经验——深度需求挖掘

即便进行了大量的宣传和推广，可能收效仍然有限。这种情况下，可以到各个业务线进行深度访谈和宣讲，使得产品功能与用户诉求相匹配。通过宣讲，也可以发现一些产品还欠缺的关键的能力点，帮助我们完善产品建设。此外，可以通过集思广益，广泛收集反馈，以及与行业内同类产品对标，通过需求驱动产品的进一步规划。

3. 数据收敛经验——良性牵引

除了前期的推广，产品更重要的是要通过核心的价值点，来吸引目标用户。以下是结合贝壳自身特点的举例，并不一定适用于所有业务线。我们做的比较好的一点是对数据格式进行来收敛。因为格式不统一是数据使用方很大的痛点，平台实现了这个功能，使用方就会驱动生产方将数据生产迁移到平台上。推动格式统一的过程中，如果生产高流通数据的业务方不愿意遵守格式规范，中台会通过产研支持的方式，帮助完成中间层的开发和转化。

另外一点比较好的经验是与公司核心数据获取方建立合作机制，让相关系统的规则引擎、运营产品等，使用业务数据中心平台的数据，借此驱动更多数据的生产方将数据发布到业务数据中心，使得平台的数据源更加丰富和全面。建设初期，中心主动跟进一些数据需求，并将需求发布到平台上，由数据中心平台来做统一的收敛和治理，沉淀出新的功能点、管理手段、规则标准等，来推动工具建设。平台能力建设好之后，再通过自上而下的推动，平台产品的价值会得到越来越多的接受和认可。

4. 治理难点及举措

最后介绍一下我们遇到的一些问题，以及解决这些问题的举措。

首先，数据治理涉及生产提效、数据统一、标准收口、数据共享、内容治理、质量、稳定性等很多方面，需要公司给予战略层级的支持，需要相关的架构负责人共同讨论和设计，自上而下去推动。

产品设计方面，要结合公司自己的业务形态去摸索、迭代和沉淀。这个过程中，首先要尊重用户，不能只调研少量业务方后，就设计产品功能。而应制定标准，做好迭代。最初可以从文档管理开始，逐步进行系统化收口。此外还要大胆创新。一些产品功能，比如业务词典，依赖对业务的深刻理解。业务本身产生的数据，如核心SOP流程、名词解释、测试链接、账号等，都需要系统化梳理，才能保障更好地使用数据。

此外我们也会做一些前沿的探索，感兴趣的同学可以一起交流。

能力依赖方面，需要和公司的基础设施、业务系统都有好的联动，所以合作共赢的意识非常重要。

推广运营需要擅长借力，一方面通过自上而下的驱动，另一方面产品要有核心的竞争力。此外，推动数据收口和治理，流通管控过程中，可以与安全、法务团队紧密合作，一起推动。

Q：数据收敛与数据治理的区别

A：这里所说的数据收敛，是指把管控的高流通数据都统一收口到平台。数据治理首先要让数据透明化，将猎物关在篮子里，才能对质量进行管控。 

Q：如何解决不同业务之间模糊地带的权责划分？

A：中台工具搭建之后，数据治理更多是依赖工具的使用者来推动。

Q：中台部门是成本部门，在贝壳的实践中，中台提升数据价值是如何体现的？如何让中台部门的同学有好的收益，对团队更有信心？

A：举个例子，比如业务新增加一个上报的动作，如果业务方自己开发，功能开发之后需要等待测试同学排期，以及后续一系列上线流程都比较耗时。但是如果是中台来做，我们会监控原始数据的变动，然后根据业务事件定义的规则，对新增加的事件进行定义和自助测试。这个过程不需要测试同学介入即可完成上线发布。如果后续有同学需要用这些新增加的数据进行联调，我们可以提供测试样例，并把这部分数据发到对方的kafka topic里。