• 治理项目的目标管理

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

数据治理的终极目的，是提升数据的使用价值。数据是公司的重要资产。数据使用包括两方面：一是通过数据为用户提供更好的服务，如推荐算法；另一方面是利用数据，来为管理提供抓手，更高效地管控业务，在这种情况下，功能创新和管理提效，都依赖于数据被更好地利用，这也是数据治理要解决的核心问题。以下是提升数据使用价值的三个方向。

1） 共享

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

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

2）准确

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

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

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

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

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

3）可用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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