数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技

本文摘自数澜科技CIO创享群内嘉宾分享内容，发布已获作者授权。

大家好，我是彭文华。之前做过多年的数据技术工作，这两年也对数据中台做了一些研究。今天算是给各位当个马前卒，把我之前研究和实践的结果向大家汇报一 下。

这是我的数据研究经历，纯技术讨论。

起因是我之前研究的时候发现了贝壳的ACN机制，把混乱的房地产中介给安排的明明白白的，太神奇了。

于是就写了好些篇文章分享出去，就引起了数澜同学的注意，这才有了今天的分享。

今天分享的内容很简单，就三块，先给大家一个显微镜，然后带着显微镜观察三个典型的数据中台建设模式，最后是我对三个模式的理解。希望能够给大家一些帮助。

01 忒修斯之船和数据仓库发展历程的启示

忒修斯之船是一个非常古老的思想实验。说的是一艘用来纪念忒休斯的船，为了保存它，需要不停的修缮。那如果这艘船上的所有木头都被替换了，这还是原来那艘船吗？

亚里士多德用四因说解释：所有事物都有质料因、形式因、动力因和目的因。

忒修斯之船的质料因变了，但是其形式因、动力因和目的因都没变，因此即便是忒修斯之船所有木头都更换了，它还是忒修斯之船。

对于忒修斯之船来说，质料因、形式因、动力因和目的因分别是木头、桨船、斧头和纪念忒修斯。

对于船本身来说，形式因（桨船）决定了这是忒修斯之船。

对于其目的来说，目的因（纪念忒修斯）才决定了这是忒修斯之船。

我们去旅游的时候，买一个塑料做的忒修斯之船，大家也会叫这个“忒修斯之船”。

所以我认为其目的因和形式因才是最重要的。

对于数据中台来说，其质料因是代码、组件、数据；形式因是数据中台长成什么样子，也就是平台的功能和界面；其动力因就是建造这个平台所需要的动力（工匠和工具），就是码农程序员和服务器；目的因是建造企业护城河，创造经济价值。

那么，我们来判断一下以下那句话是对的？

1、数据中台必须接入所有的数据；

2、数据中台必须要有所有数据相关功能；

3、数据中台必须部署在我的服务器上；

4、数据中台可以不用考虑商业价值。

多扯一句，中国有一个更好的忒修斯之船的例子：雷峰塔。

我们称呼现在的很漂亮的塔为雷峰塔，但是我们看到的这个只是新塔，老塔在新塔里面。对于外面这层铜制新塔来说，其外表、材质、制造工艺全部变了。但是其承载的文化还在，其根本目的还在。

那么我们说，这就是镇压白娘子的雷峰塔。这就是发掘出“佛螺髻发”舍利的雷峰塔。所以只要形似，神还在，那就是雷峰塔。甚至我们还能买一个小雷峰塔带回家。

这点很重要，这直接决定了我们如何确定“数据中台”的成功。

数据中台的概念18年才定下来，19年开始盛行。但是概念刚刚开始热起来，就被称为“CIO”杀手。

其实在数据中台之前，有一个概念几乎与数据中台有一样的经历。那就是数据仓库。

数据仓库之父Bill Inmon提出数据仓库概念之后的几年中，几乎所有数据仓库项目都失败了。玩过数仓的大佬们都知道，Inmon提的建设方案是自上而下，全面建设。

这难度太大了。即便是现在，也几乎没有这么做的。所以失败似乎是必然的。

这时候Kimball站出来了，提出了数据集市的概念。

先抓住商业价值最大的核心业务部门，以终为始，以商业价值为目标，逐步向数据上游一层层设计，最终摸到原始数据。

跟inmon反着来，自下而上的建设。这样需求小了，建设内容少了，业务变化也少了，关系也简单了，难度也低了，成功率大大提升了。

这就是数据仓库经典面试题-数据仓库建设流派的完整答案。

有些人会搞混了，这个自上而下好像写错了，其实没有。上和下指的是数据流向的上和下。

最后，这两个方法论合二为一，形成CIF的标准，沿用至今。我们到现在建设数据仓库，包括数据中台，都还是在这三个逻辑中选一个。没有第四种方法。

所以我们得辩证的去看待这类问题。《人月神话》中早就告诉大家，没有银弹。但是现在市场上宣传的太夸张了，如同我的介绍一样，把我夸的太优秀了。

但是实际上一看，也就是一个普通人么，这时候大家就失望了。我其实是很委屈的。

数据中台也是一样，市场把数据中台的能力夸到无边无际，把老板的期望抬高了。导致向上管理根本没法做。期望太高，一旦没达到，项目就会被定义为失败了。

很多CIO也被市场忽悠了，一脑门钻进去，结果完全不是这样的，最后就被“一把手工程”的帽子给盖死了。这才是数据中台“CIO”杀手的真正原因。

之前分享过，我曾经主持建设过数据中台，但是不太顺利，面临的问题太多了，阻力太大了。

我这边设计好模型，业务那边逻辑改了，原始数据那边结构也改了。按下葫芦起来瓢，没法玩。

其实不只是中台，很多信息系统的成功建设和价值产出，都是有很多前提条件的。数据源的稳定和高质量提供、业务逻辑的清晰和可到达、可见的商业价值、清晰的目标。中国人最是吃苦耐劳，但是最害怕没有希望的盲目重复劳动。

所以，我开始研究各个公司的数据中台建设套路，想知道数据中台建设成功的先决条件。也开始认真思考得失。

建设过程中我做了一些数据中台的选型工作，同时也搜集了大量数据中台建设方法论、案例进行研究。以下内容均摘抄自各大公司的公开分享内容。只是搜集和整理信息，不敢妄评。毕竟了解的有限，如有谬误，还请恕罪。

02 外脑式建设：数澜、阿里数据中台

这个是数澜的方法论和数栖平台。

数据中台基本功能都很全，可以让数澜的同学给大家开一个试用账号去看看。

最早的数据中台都只是卖产品，但是产品卖出去，用户不会用。

所以又卖人头，帮忙用户做。后来发现还是不行，因为想建数据中台的用户都不知道数据中台的需求是啥，到底该怎么做，价值怎么体现。

所以他们又开始卖咨询服务，做培训，做整体的架构设计、数据中台能力设计等等。

另外我还有一份阿里巴巴数据中台架构师的培训内部资料，我们来看看阿里巴巴做数据中台的套路。

从项目流程上来看，方方面面都考虑到了。

有几个点可以关注一下：确认人力资源、技术/数据调研、应用产品设计、数据设计。这几个圈起来，要考的。

这几个点是区别其他项目的核心。也是决定数据中台项目成败的关键节点。

拿其中的数据应用设计来说，他们会进行专门的场景化设计，找到该场景中数据应用产品解决什么问题，以及其核心价值。

培训教材里自带了一定的方法论和业内案例。但是这些数据应用只能让大家达到及格线，并不能做出优秀的数据应用。

自然也就没办法形成企业级数据中台的：“建造企业护城河，创造经济价值“目标。

换句话说，咱业内人士都想不明白的，业外人士更清楚且能转为你一家解决的概率实在是太小了。

不过不是不可能哈，有一个咨询公司就是这么牛，就是贝恩资本的贝恩模式。他们专门找经营遇到问题的成熟型公司，派出数据分析师团队进行长达几个月的研究。如果还有救，直接收购自己做。

总结一下：

外脑模式有很非常成熟的方法论，有现成的通用产品，你今天交钱，明天就给你部署好，还给你带全套的技术人员过来，还给你很多客户案例供你参考。简直不要太舒服！

但是一旦项目困难了，乙方就祭出“一把手工程”的幌子，拿着合同保护自己。甲方则开始到处挖人。

所以咱可以把外脑当工具，不要把希望寄托于外脑。因为外脑不能代替你决定公司的核心商业价值。

挖人解决不了问题。哪怕是把所有人都挖过来，该失败还是失败。人、方法论、数据都不是最终决定忒修斯之船的因素。

之前一个数据中台大佬开玩笑跟我说，他们做一个项目丢一个架构师，都成了业内数据中台架构师训练营了。

我们按照四因说来给外脑式打个分。

外脑式建设模式有很大的制约，给3星；形式因可以得满分。也可以快速获得技术力量，但是合同到期就全撤了，力量不属于你，给3星；目的因也会帮忙设计，但是肯定不会非常牛，给2分。

另外，只要是甲乙双方，就会出现合作上的僵化。合同内容一旦定下来，就是按合同办。非常容易变成两张皮。虽然双方会进行各种修补，但终归是雇佣兵，不如家兵来的如臂使指。

外脑能做的是别人有的，你能有。

外脑不能做或者很难做的，是创造你的核心竞争力。

03 纯技术建设：宜信敏捷数据中台

19年的时候认真学习过宜信卢山巍卢总的“宜信敏捷数据中台建设实践分享实录”。当时说的细节已经忘记很多了。PPT倒是一直保留着。给大家选几页观察一下宜信是怎么做的。

这是宜信的中台定位。宜信的组织架构有很像阿里，一个数据中台团队+N个业务数据团队。

外挂数据管理、安全、运维团队予以保障。宜信的业务线非常多，这种组织结构是必然的产物。因此数据中台也只能平台化。

这是ADX（敏捷数据中台缩写）的菜单，从这这里可以看到它的主要功能，非常全面。各位可以跟数澜的数栖平台产品功能对比一下。名字可能不一样，但是用途和解决的问题是一样的。

从这张图可以看到各个环节所使用的技术。其中采集、流处理、展示（蓝色部分）都是自研的。存储形式很丰富：”结构化、kudu、Hbase、cass、hdfs、hive、ck、druid、kylin、es、mongodb，后面还加了一个…，基本上当时主流的数据存储方案都用到了。

这个是数据中台的核心Wormhold（流处理平台）架构，从kafka获取数据，经过spark和flink的计算，sink到N种库中。然后一堆的管理、安全、运维保障组件。可以通过api和web进行访问平台。

这是宜信敏捷数据中台的价值主张。可以看到起核心价值的优化方向是在于数据中台对技术本身的优化，体现架构的降本增效原则。

卢总对敏捷数据中台定位很准，就是快、精、准。

卢总还分享了几个数据中台案例，大家可以看到，基本都跟前台没太大关系，还是数据这一趴。

对比外脑的介绍，宜信的数据中台建设是不是太技术了？数澜的是不是要友好的多？

纯技术建设往往是迫于无奈。业务线太多，无法一一顾及，所以只能平台化。

但是对于真正的使用者来说，感官可能并没有那么明显。之前用马车能跑，现在换汽车也是一样跑，并没有外面宣传的那么神奇。

甚至某些特殊场景还没马车跑的快，因为业务的抽象，必然会引起部分个性化需求的丢失和忽略。那时候业务线就会鸡蛋里挑骨头，说中台不成功。

所以纯技术建设往往吃力不讨好。

同样按照四因说来给纯技术式打个分。

因为是自己团队，所有的代码、组件、数据全部都掌控着，但是跨部门沟通略有障碍，给4星吧；形式因给3星吧，毕竟跟数澜这种做了好多年的来比，还是差点意思；技术人员、服务器都是自己的，完全掌控，给满分；目的因就差点意思，从卢总自己分享的价值主张和建设成果来说，离建造企业护城河、创造经济价值差的比较远，给1星吧。卢总不要打我。

纯技术建设投入的成本较大。其实宜信之前在大数据这块的投入就非常多，上面提到的几个自建工具都是早就已经做好的。而且光是组建这支数据团队就得花不少力气。这些人很贵的。

04 自生长建设：贝壳数据中台

这是我之前整理的贝壳6层堡垒。贝壳从链家继承了太多资产了。其中楼盘字典从08年就开始建设了。是一个单独的团队在做，网传最多的时候有500多号人。贝壳融合其他品牌的时候，都会不断扩充这个楼盘字典。

这个楼盘字典还从技术层保障了住建部严禁“虚假房源”的要求。

而基于信任和合作的ACN，则从人性和规则层保障了房源的真实性。

我们从四因说的角度上来看，楼盘字典就是一个技术含量算高，同时非常费时费力，但是建好之后可以成为公司超级护城河的核心资产。这与阿里的One ID的思路是一致的。

从贝壳的大数据平台的三个阶段可以看出他们的建设逻辑：够用，然后优化。贝壳大数据平台到现在都是Lambda的架构，没有上批流一体。原则都是为业务服务，技术够用就行。

OLAP平台也是这样，先够用。然后不断发展。贝壳是kylin的深度用户，给kylin做了很多贡献。注意我这里圈出来的地方。

他们在前台的指标API和Kylin之间，加了一层查询接口层，对查询进行转换，在架构层面做了服务降级、熔断等保障性的服务管理。

有了这个查询接口层，等于有了一个万能转换器，底层的OLAP引擎就可以随便换了。所有现在的架构就可以支持druid、ck、doris等产品。

肖博士在分享的时候也曾透露，建设的时候参考了阿里的One Data逻辑。但是在贝壳这边不太好弄。贝壳的业务太复杂了，很多地方没法进行统一业务建模，One Model建的不够好。

我理解不是不可能，而是在短时间内不太可能进行统一建模。并且受限于贝壳的组织架构，想要跨部门推动，旷日持久啊。所以只好退而求其次，先把底层的模型建好，业务模型还是分着来吧。

每个平台一个团队的组织形式，必然导致团队内外部的沟通成本高企。其实很多问题都是因为组织、业务形态导致的，在单点上没法解决，还得回到系统上才能解决。

这是DMP架构。是为精准营销、人群分析、个性化推荐等服务提供基础数据。

DMP建设的时候使用的就是ID Mapping的思路，使用Spark + graph X进行 id之间的图计算，识别相同的用户。

为了提升圈人的效率，DMP大量使用位图技术，亿级别用户的圈人可以秒出。

这是DMP的核心应用：圈人和预测。

这是贝壳推荐平台，一样是价值优先。

两个场景，一个是用户购房推荐，一个是经纪人维护营销。

推荐平台也是也是按照快速搭建、慢慢发展的逻辑来建设的。

这是目前的召回策略详解。

他们对每一个推荐策略都给了一个id，然后观察每个推荐策略的成功概率。

这个是算法中台。为商业化服务。你看他的业务场景很有意思，是给经纪人用的。

按照我这个外行人士的理解，贝壳是一个卖房的平台，真正的用户不是购房者吗？商业化的目标不应该是购房者吗？

这就是贝壳业务理解的独到之处。也是我认为贝壳中台的成功之处：所有的技术都是为了业务核心价值服务，这个抓手抓的非常准。

金贝平台是给经纪人用来获得客源的平台。

经纪人通过做各种任务获得贝币，通过消耗贝币，获得曝光和IM潜客沟通。这就形成了一个内部的经济循环。贝壳用金贝平台为抓手，驱动经纪人完成众包任务，同时给予贝币奖励，经纪人用贝币换回潜客商机，力争成单获取利润。

贝壳的商业化是在经纪人身上的，而不是真正的用户身上。这对我这个外行来说，是很惊讶的。这个洞察很值钱，把算法资源投入到这里更值钱。

贝壳现在也在继续优化。Python实在是不太够用，现在基本都在往java方向转了。

贝壳的建设逻辑其实也很简单，跟着业务走。左晖总的业务理解太深了，对人性理解的太透了。

还记得我一开始画的那张图吗？以人性为内核，外面包上一层又一层的堡垒。你就说，你能攻破几层？

这么玩有弊端吗？有的！左晖总看的太深，太远，基本都在天上飞，贝壳的技术团队根本没有时间停下来造一架飞机，只能在地上边开车边修发动机。

我猜贝壳的业务需求应该长期处于欲求不满的状态，工作人员也基本都处于人肉、死磕的状态。这对各方都是一个考验。

同样按照四因说来给自生长式打个分吧。

从产品功能上来说，还不够全面。团队的敏感性也不太够，现场分享的PPT里有大段的代码、表名、表字段、命名规则、编码规则等敏感信息。所以前三项我给3星。

虽然贝壳没有说他们建的五个平台是数据中台，但是从形式因、目的因来说，这已经算是数据中台了。尤其是楼盘字段、金贝平台等可以直接成为公司核心护城河的存在。

所以目的因我给满分。

这个没的说。对比一下外脑式和纯技术的数据中台，是不是比较公平？

自生长的优缺点也是蛮清晰的，优点就是注重价值，小“船”快跑。缺点就是人肉，要不断优化，甚至推倒重建。

05 三种建设模式对比启示

外脑模式适合快速对标同类企业，提升基础数据能力；

纯技术模式适合业务线多、基础较好的企业，提质增效降本用；

自生长模式适合发展速度快、业务逻辑清晰的公司。

从企业战略角度上考量，所有信息系统的核心目的是为企业建立核心竞争力，构筑企业护城河，创造商业价值。

从这点来说，贝壳模式无疑是最合适的，当前成本最小，累计产出最大。但是时间太长了，太为难人了，这就是一个苦差事。

对于数据中台本身来说，宜信建设模式最像阿里，也是内部建设比较标准的，组织形态、产品形态、建设逻辑都像，但是中台部门屏蔽了很多底层的东西，也就承接了所有的问题，最容易变成前台业务部门的炮火集中地，这个心更累。

数澜模式是标准的商业服务外包模式，相当于均富卡，可以快速提升企业数据管理和使用能力，这个最轻松。

群里都是信息化建设大佬。都能体会信息化建设的难处。如何管理好老板及公司对数据中台的期望，如何平衡商业价值与技术实现之间的平衡，如何解决企业各级人员对数据的迫切需求，如何处理好技术实现和业务目标之间的矛盾，这都是我们的痛苦之处，不足为外人道也。

这些事情别人帮不上太多的忙，只能咱自己默默的抗。

迪斯尼的案例与贝壳的发展路线异曲同工，需要大数据平台了，就先成立一个小组弄一个凑合用着，然后慢慢进化。需要OLAP分析了，就成立一个小组快速搭一个用着，日拱一卒。需要楼盘主数据了，成立一个团队，死磕，一条一条数据清洗。

我的分享就差不多结束了。

最后吐个槽，信息化建设中很多我们意想不到的问题。左边这张图是我十一旅游时遇到的事情：某调查员，现场指导要填什么数据，选什么内容。你说这样调查出来的结果有啥用？

右边是抖音大V教买房套路，到售楼处不留真电话。我们辛辛苦苦建一个CDP，结果数据从源头就是假的。

人性的丑恶，在业务上体现，最后还得信息化来背黑锅。这就是我们信息系统建设者的困境。

不要管别人怎么样，我们自己思考就好了。如果左晖总天天跟其他房地产中介学习，那也就没贝壳什么事情了。

思考人性，思考核心价值。只要认准了，就去死磕，用时间来构建一道坚不可摧的商业护城河。

以上就是我的分享内容，感谢各位。

嘉宾简介
彭文华，北京航空航天大学硕士，高级工程师、大数据专家、数据分析专家，项目管理专家。有过创业经验，对商业模式、组织建设有深入的理解和研究。在电商、政务领域有十多年的工作经历，多次从0到1搭建完整数据团队，带领团队服务公司内外部客户，支撑并创造价值。在数据治理、数据分析、商业智能、大数据平台、数据中台等多领域拥有丰富的实战经验。