转变，贝壳数据平台的演进-InfoQ



 写点什么

本文主要分享如何通过数据产品，帮助具有 20 年历史的传统企业在行业互联网数字化转型，促使业务更高效的应用数据，数据平台产品在公司数字化转型的过程中是如何演进的，会遇到什么样的困难，以及产品建设过程中的思考与实践。并重点介绍贝壳数据平台建设的演进、治理过程。

贝壳业务及数据应用的背景

1. 贝壳业务

贝壳是一家产业互联网公司，房屋买卖交易是公司的主业。在房屋买卖和租赁过程中，整个交易过程很大一部分是通过线下完成。从交易视角看，房屋买卖交易是低频，周期较长的。随着科技的进步，贝壳也成功的把很多线下环节拓展到线上。目前，贝壳的商机主要通过线下门店和贝壳 app 获取，之后会带看、签约、最后到成交，这一系列流程中涉及到房源、客源、商机、经纪人、门店等。

从数据视角看，贝壳目前有全国最全的楼盘、房源数据、大量的经纪人行为数据、线上\线下商机数据、门店数据等，数据纬度多、元素多，复杂度大。与纯粹的线上互联网公司不同的是，贝壳无法把所有交易过程线上化，只能尽可能的将交易关键节点先线上化。因为整个交易过程中，绝大部分关键节点都需要线下带看和经纪人沟通。这也就导致了很多数据是线下收集的，这也是贝壳数据呈线下化特点。另一个就是数据的延迟性。这里的延迟性是指数据的延迟性，并非系统的延迟性。比如签约、带看，并非完全和系统同步。在业务口都有“喜报”的说法，往往这部分数据都是线下先去填报统计但在时间上没有当天走线上流程，这样就会产生实际业务与系统记录的偏差。

综上，贝壳的数据呈类型多、复杂度高、线下化、延迟性的特点。

2. 贝壳数据

从数据建设以及数据应用的视角看，贝壳存在三类用户：

第一类，需要用到数据进行管理以及运营的，称之为数据应用用户。这类用户在贝壳包括经纪人在内的有 30 多万，他们通常用数据进行日常管理和运营，对数据诉求也非常多。
第二类，将数据进行加工处理、探索，做深度分析形成数据报告与分析结论的用户，如数据研发、数据分析师。从这张图可以看出，因为城市业务很“重”，业务对数据的诉求就是“快”、“准”，所以贝壳在全国近 100 个城市设有分公司以及加盟的品牌商，每个分公司都会设立相应的数据部门，每个部门人数不尽相同，但都承担着这个城市的数据收集、加工、分析、整合、报表制作、数据运维的工作，以满足城市大量用户的数据诉求。所以这类用户分布比较散，每个城市在从人员设定、系统性沉淀、组织协调、以及数据建设文化上会有很大的不同。全国来看，总共有上千人。他们给第一类用户提供管理、运营、店东、经纪人数据，这类用户也是平台的核心用户。
第三类，公司。从公司的视角看，在业务不断发展的过程中，日渐积累的大量数据如何衡量它的价值，如何构建良好的数据生态环境，赋能业务，是公司最关心的。对贝壳来说，最典型的数据资产价值是楼盘字典，通过楼盘字典将数据应用到业务应用中去，形成平台竞争优势。对于加盟品牌，在业务并网的同时，平台能否给予一套标准的数据解决方案，促使业务的增长。另一方面，贝壳大量的数据用户如何形成数据文化，怎样联动城市和品牌商在同一标准下进行良性的数据运转，都是公司视角最关注的。

3. 数据应用场景

贝壳的数据应用场景主要分为管理、实际作业和品牌（系统）的应用。

管理：可以理解为是战略层面的应用。贝壳业务重线下，管理层级深。管理的诉求是希望能够高效、精准的传达管理指令，从总部到城市，管理绩效、业绩、以及推行一些标准和规范，从而得到有力的管理抓手。例如今年在做的经营健康度管理，总部会用近百个健康度指标，通过多维度去观察各地的经营健康度，通过数据、指标达成统一的管理语言，确保城市和总部的理解一致。在这个过程中，指标数据需要进行高效的传递与交互。
作业：可以理解为是战术层面的应用，更细粒度的管理场景，通常是一城一策，覆盖店东、商圈经理、经纪人层面。所以，不同城市业务人员不同，对数据的使用颗粒度以及关注视角都不同。战术层面的数据使用粒度更细，会关注到人、单。例如门店管理时，会关注经纪人的带看情况。
品牌：是系统层面的，在品牌加盟的同时，有数据对接与供给、系统对接的诉求，贝壳希望能够给到他们一套完整、有标准化的系统提供数据服务的能力。

贝壳数据平台的演进

1. 过去

① 平台的样子

2018 年加入贝壳的时候，主要接手两个平台产品：

指标平台：主要基于 Kylin 构建。通过平台构建指标，设定度量和维度，数仓基于指标需求开发数据表，在进行 cube 的构建。用户可基于已经开发好的指标，再进行报表的创建。用户获取数据、报表查看都集中在指标平台，另外还有结合不同用户群体的定制化产品，例如特定面向经纪人、店东的数据产品。
数据管理平台：是数据底层能力集，面向数据研发，包括数据采集、加工、调度、以及数据服务的能力。

两个平台从数据加工采集到数据应用都涵盖了，那么对于公司、用户来说，都有哪些问题？以下将从效率、平台、数据质量、安全的角度剖析。

② 面临的问题

公司的数据能力建设以及应用、是一个复杂而庞大的体系化工程，单点突进（例如查询引擎特别好，数仓建设的完备）对用户来说，依然会在某些场景有体感不适的情况。所以数据能力建设一定是齐头并进，抽象聚焦的。一般来说，重点聚焦在：数据应用效率、数据质量、平台系统、数据安全几方面。

效率：

从效率讲，主要是数据流转问题：

报表、看板：数据应用中最基础最常见的报表、看板需求。以往基于指标平台，需要先有指标、开发，然后通过指标数据再进行数据可视化配置。所以这就带来一个问题，必须要先有指标，才能配置报表，这样会非常依赖数仓开发指标的人力资源，一个成本高，另一个是效率会有瓶颈。从管理以及用户的角度看，由于缺少横向拉通，重复建设的情况非常严重，所以平台指标的复用性对效率非常关键。当时的现象是指标设计不够灵活，平台设计、产品引导上也没有引导用户去复用他人的指标，另外受制于权限的审批，导致很多人不会去利用已有的指标，而是新增指标，这就增加了数仓的开发压力，进入恶性循环。业务经常抱怨往往提一个指标，基本都是 T+1 周起，有时候时间长了，指标开发出来了，业务又变化了。这种情况导致用户都自己去写 sql 提数据，集群每天的查询负载非常高。
城市：当时的指标、以及数据源是没有办法设定行级权限的，导致城市的用户无法使用指标数据，致使他们的数据获取更复杂，需要在平台上、系统上、线下收集各种数据，然后通过各类第三方工具将数据整合起来。所以每天会花费大量的时间来进行这个操作，效率非常低。各个城市也会有很大差异，有的城市为了简化这个过程，招聘一些有技术的分析师，搭建本地库，通过自动化脚本的方式来提高效率，最后整合成用户需要的数据，通过截图、excel 的方式传递给用户。这种情况一是会导致数据安全性无法保障，另一个会形成无数个数据孤岛，平台逐步变成了数据源供给平台，公司的数据建设没有统一性，数据的准确性、一致性、以及数据运维难度会越来越大。
权限：很多线下审批并没有到线上，通常都是固定在每周的某一天固定由专人处理，导致效率非常低。

平台：

从平台视角看，kylin 解决方案满足不了所有场景，贝壳的业务维度多，很容易发生维度灾难。平台的设计是基于当时历史情况来设计，但业务、公司的变化飞快，平台不能适应变化导致系统模块在平台上融合度不够。用户另一个直接感受是技术元素过高，平台的易用性不够，很多功能使用前需要咨询，增加了沟通成本，平台门槛过高。

质量：

同时，对于当时的平台设计，也是缺乏数据管理与管控的。指标需求越来越多，埋点也越来越多，导致指标、埋点、数据表等只增不减。最后，指标数量破万，埋点事件 2 万多。这样的情况对于用户来说，不知道该用哪个，自己再重新提需求建设，进入恶性循环。对于公司来说，存储、计算压力与日俱增。并且由于效率问题，大家开始自行写 Sql 提数据，下载数据与线下数据整合等，数据出口非常多。没有统一的管理，数据准确性、一致性遭到用户的存疑，数据信赖度降低，每天的对数成本非常高。

安全：

数据安全同样存在问题，平台的主力功能是数据获取，用户从平台下载数据到本地，通过截图、PDF、Excel 进行传播，也没有水印，数据安全存在非常大的隐患。

用户感受：

过去，我们的用户花了 70%-80%的时间停留在权限获取/数据处理加工和对数上。从右边五个维度看，平台打分也都不是很高。所以对于未来，贝壳平台要如何演进？

③ 需要什么？

我们希望减少用户在数据加工上的时间，提高用户上层的效率，产出更多价值。同时，致力于成为提供高效、安全、可信赖的平台。

④ 怎么做？

贝壳需要怎么做？主要考虑以下两方面：

整合扩展：把平台上的能力整合到一个地方，形成闭环。
线上化：之前的分析模式包括数据供给模式都是线下，怎么能够将线下跟线上数据做整合，并且用线上的方式实现需求，同时保证质量和安全。

2. 演进

① 平台演进路线

从背景以及平台带来的问题来看，如果要解决效率、质量、安全的问题，需要把用户整个分析流程全部囊括到平台中来，降低门槛，给予用户更多的自主性、灵活度，同时也要有规则标准进行保障约束。

在 2018 年底，结合用户和公司的诉求，公司开始研发数据分析平台——奥丁。希望通过平台建设，将原来不能满足的诉求一一实现，将用户自成体系的建设数据方式，逐步迁移到平台上来，把数据孤岛逐步整合到一起。

首先要能覆盖用户线下加工分析到传播的全流程模式：

接入：我们对数据源接入进行了扩展。不单单是 kylin 为基础，这个期间我们扩充了更多的查询引擎，例如 druid\presto\impala，进行统一的路由，用户也可以直链到 hive、excel、csv。不再单单是指标了。
数据建模：分析过程整合集成数据建模、数据探索的能力。原来的数据加工基本是在数仓团队，或者有能力开发的人通过写脚本在客户端开发，绝大部分的人数据整合、探索依赖第三方工具。平台整合后扩展了数据查询、数据建模，可以更佳的自主化，把探索建模过程落地到线上，而不是各自为战。
可视化：提供统一的简单可视化配置能力，用户可以方便的通过拖拽的方式完成数据可视化的工作。以上三步其实更多是在分析师的层面上也是就是数据内容制作者去实现的，可视化内容制作后，我们会结合不同的应用场景给予不同的输出模式。
应用：通过数据应用配置结合场景给到相应用户，可以配置移动端、门户以及驾驶舱。

通过提供一套完整的数据分析体系，整合底层数据引擎、权限、数据管理的能力，输出一整套数据平台能力和服务，释放给平台用户。

但在这个过程中，平台的能力建设是重要的一步，另外更重要的是数据内容建设本身，数仓的模型建设是更重要的，用户需求多样，数仓在这个过程中抽象需求，形成高可用、易懂的数据供给。

② 奥丁分析平台

奥丁分析平台于 2018 年启动，前后经过了几个版本，这几个版本都是结合当时不同的情况进行的迭代。实际上线到今天为止，已经把全国 70%-80%的城市纳入。

③ 数据资产化管理

对于数据资产化管理，我们从底层服务支持上做了扩展，包括数据可管理、权限可管理、资源可管理、数据质量可控：

数据权限体系：权限线上化灵活配置，功能数据权限解藕、拆解数据权限，设定行级权限，角色。比如说可以让某个人只看到两室三厅的房子。
工作空间：很多公司在搭建大数据体系的时候，资源都是放在一起用的，这样对于公司来讲，很难做到资源管控，成本可控。通过对开发团队的划分，以团队为最小力度进行拆解，把存储资源和计算资源打散切割，基于这个设计，我们可以在资源管控上开展更深的工作，例如监测到不良资产、超级任务等，并且对资源进行弹性设计和隔离。
规则引擎：统一构建规则引擎。从平台治理的视角，我们需要识别出各种类型的不合理情况，例如笛卡尔积查询，上万行的 sql 查询，生命周期的规则，成本分摊规则，计算优化规则等，有正向的，有负向的，有强规则，弱规则，保障平台的运行和可控。
元数据管理：将事物可量化，通过评分机制对资产、任务、存储、计算进行评价，形成模型，实现价值的衡量和评估。
数据监控、治理：对于数据监控形成事前、事中、事后的全套解决方案。
IDE：最上层画虚线部分，是开发过程，还没完全做到线上。

④ 数据工厂

数据工厂的演进过程也是从 2018 年底开始，首先做了权限系统的监控，然后希望通过业务的语言了解数据的组织，所以做了元数据图谱。2019 年相继做了数据开放等，到今年我们将工作空间、规则引擎建设完毕。

⑤ 效果

从效果来说，对于各城市受益最大。数据分析师有更多时间做分析，在效率、质量上都得到保证，从安全上数据能达到不落地。

⑥ 有哪些困难？

在演进的过程中，我们面临如下困难：

历史惯性：大家在以往的数据应用上，对于分析师来说，很多内容已经形成基础和规模了，从一种模式到另一种模式是需要很大的迁移成本的。对于用户来说，绝大部分用户是不关注数据怎么给到我，最关心的是数据什么时间能给到我，给我的是否可信。那么一旦换了承载形式，用户会不习惯，就必须找到一个差异点去引导用户转变。我们在初期，找到了和分析的共鸣-提高数据流转效率，利用这个共鸣点，牵引整个数据体系的建设。
组织：如果想在公司中对数据平台、内容的建设上很顺利，组织的适配程度非常重要，一是需要战略上从上至下的顶层设计，另一个是组织在数据应用过程中的关键角色是否存在。例如如何对数据指标口径进行管理，能够拉通平台的数据一致性，服务保障能否联动，都必须在组织层面上达成一致。每个组织的目标，关注点都不同，绝大部分组织更关注业务的变化和增长，数据是辅助的，占比不高，导致数据建设过程协调成本极高。
运营：运营是对以上两点的加持，公司在推行数据文化、认知，数据标准化推行，尤其像贝壳，如何对上百的城市达到平台使用的标准化，都是对运营的诉求，非常需要运营去发展。