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

本文摘自数澜科技CIO创享群内嘉宾分享内容,发布已获作者授权。
数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第1张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第2张图片

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第3张图片
今天分享的内容很简单,就三块,先给大家一个显微镜,然后带着显微镜观察三个典型的数据中台建设模式,最后是我对三个模式的理解。希望能够给大家一些帮助。

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第4张图片

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第5张图片

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

对于船本身来说,形式因(桨船)决定了这是忒修斯之船。

对于其目的来说,目的因(纪念忒修斯)才决定了这是忒修斯之船。

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

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

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

那么,我们来判断一下以下那句话是对的?

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第6张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第7张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第8张图片

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

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第9张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第10张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第11张图片

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

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第12张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第13张图片
数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第14张图片

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第15张图片

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第16张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第17张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第18张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第19张图片

总结一下:

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

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第20张图片

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第21张图片

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

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

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

03 纯技术建设:宜信敏捷数据中台
数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第22张图片

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第23张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第24张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第25张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第26张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第27张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第28张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第29张图片

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

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第30张图片

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第31张图片

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第32张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第33张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第34张图片

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

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

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第35张图片

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第36张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第37张图片

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第38张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第39张图片

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第40张图片

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

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第41张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第42张图片

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第43张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第44张图片

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

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

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

所以目的因我给满分。

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第45张图片

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

05 三种建设模式对比启示

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第46张图片

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第47张图片

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

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第48张图片

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

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

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

数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第49张图片
我的分享就差不多结束了。

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

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

人性的丑恶,在业务上体现,最后还得信息化来背黑锅。这就是我们信息系统建设者的困境。
数澜、宜信、贝壳三种数据中台建设模式探讨 | 数澜科技_第50张图片

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

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

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

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

你可能感兴趣的:(技术交流,大数据)