这是彭文华的第117篇原创

上周在PMTalk分享了如何建设一个好的数据中台产品，今天把现场实录给大家，文末有ppt下载方式。

今天分享的内容就是这样一个节奏，先抛出一个问题，然后再看几个例子，最后总结一下。

一个好的产品是能系统性的解决问题的，能给整个链条带来超量增值。所以应该是一个完整的解决方案，能连接所有利益相关方，共同参与进来，让各方都收益。比如说集装箱。在集装箱出来之前，货物都是混装的，装的少不说，还得倒腾。所以码头通常会聚集大量的搬运工。

集装箱出来之后，一个集装箱内装一种货物，一艘船可以随便装。而且集装箱非常标准化，可以随便装。

除了集装箱，罐头也是一样。美军称霸全球，罐头功不可没。

总结一下：一个好的产品应该具有的两个品质：1、屏蔽复杂业务逻辑；2、提供简单有价值的服务。

所以数据中台当然是一种好的产品。他能屏蔽复杂的取数逻辑，降低数据的使用成本，然后提供托拉拽、接口、高价值的简单可行的数据应用。

阿里数据中台建设逻辑

那一个好的数据中台产品应该怎么打造出来？我选取了阿里、宜信和贝壳三种模式给大家分享一下。

首先我们看看阿里数据中台。

这个是阿里数据中台产品的全景图，包括Data Phin、Quick Bi、Quick Stock、Quick A+、Quick Audience、Quick Decision等组件。

Data Phin搞定底层数据，Quick Bi搞定图表可视化，Quick A+搞定用户行为分析，Quick Stock搞定人货场运营，Quick Audience搞定用户运营，Quick Decision提供全面精细化运营和决策。

如图所示，Data Phin解决的就是底层数据的处理。

实时和离线两条通道，将不同数据源的数据采集过来，然后分层建设数据仓库，然后再进行数据管理，对前端提供相关服务。

其实就是绝大多数大数据平台的功能。只不过阿**据自己的经验进行了优化而已。类似的产品很多，星环、华为、新华三等等，小厂就更多了。

这里除了产品，还需要用到阿里数据中台的One ID、One Model、One Service的3One方法论。最终实现One Data的目标。

这是Quick Bi的功能，很清晰，跟其他的BI产品没啥太大的区别。

Quick搭建在Data Phin之上，直接读取Data Phin处理好的数据，直接做展现和分发就行了。对标的产品就是各种BI产品，PowerBI、FineBI、SmartBi等等。

这是Quick A+解决的是日志埋点、采集、流量指标分析的需求。对标的就是各种日志分析起家的产品，神策、GIO、诸葛IO等等。

Data Phin还很技术，Quick BI和Quick A+也是大数据平台范围内必备的项目，Quick Stock就开始偏业务了。这张图上基本看不到技术的影子，全部都是在解决业务问题。这就偏流通环节的解决方案了。

这是Quick Audience，其实就是阿里数据中台的用户中心，大厂的标配。也是阿里One ID最广为人知的应用案例。

这是Quick Decision，就是各种策略运营手段的数据服务化。这是各大厂的运营策略的实验平台。

这些产品当然不是一下就做起来的。我帮大家标注了一下各自的发布时间。Data phin 最底层，是2017年做的。光有个底层数据平台没法体现任何价值。所以还得有一个数据可视化和分析系统，于是同年推出了Quick BI。后来再逐步推出用户行为分析和用户运营平台，毕竟用户是最重要的。

最后推出的是人货场运营平台和策略运营中心。这就精准命中使用场景了。

所以从阿里的玩法，我们可以总结出这几点：

全面规划，平台级建设。

自下而上，先技术后应用，最后解决方案。

这明显是产品主导的逻辑，我们产品人最喜欢这么建设，但是这种机会可遇不可求。阿里能这么做，是因为前面花了10年时间摸索，最近才产品化。

宜信数据中台建设逻辑

我们现在再看看宜信数据中台的建设逻辑。

我跟宜信卢山巍卢总请教过，他在19年也分享过“宜信敏捷数据中台建设实践分享实录”，感触很多。给大家选几页观察一下宜信是怎么做的。

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

这是ADX（敏捷数据中台缩写）的菜单，从这这里可以看到它的主要功能，非常全面。

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

图中蓝色的都是自研的。他当时的情况比较尴尬，处在底层数据和业务之间，逼得他只能进行平台级的开发。他把数据流向图梳理了一下，发现也只有这几个地方有机会。数据源那边没办法，总不能自己做一个数据库吧。MQ这边有Kafka、RocketMQ，已经足够好了。存储这边也非常全，那就只有数据集成、数据加工、数据计算和展示这几个环节了。于是他们就把这几个地方分别自研了一个工具，并且开源出来。

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

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

卢总是平台层技术，这些建设全部都是他们自己主导的，对于业务线来说，貌似感官不太大。所以总结一下他的建设逻辑：

围绕数据流向，集成优秀产品，抽象公共需求，自研平台化产品。

卢总透露，其实这么做也是无奈之举。他也想做一些更有价值的事情，比如商业化的内容，但是组织架构在这里摆着，手伸不过去啊。这也是技术主导的烦恼。

贝壳数据中台建设逻辑

我们转过头看看贝壳哈。

这是我之前整理的贝壳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大量使用位图技术，亿级别用户的圈人可以秒出。

这是贝壳推荐平台，一样是价值优先，两个场景，一个是用户购房推荐，一个是经纪人维护营销。

也是快速搭建、慢慢发展的逻辑建设的。

这是最新的推荐平台架构图，已经是3.0版本了。之前还有两版，最早那版很粗糙的。

这个是算法中台。为商业化服务。你看他的业务场景很有意思，是给经纪人用的。按照我们业外人士的理解，贝壳是一个卖房的平台，真正的用户不是购房者吗？这就是贝壳的业务理解。也是我认为贝壳中台的成功之处：所有的技术都是为了业务核心价值服务。

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

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

贝壳现在也在继续优化。Python实在是不太够用，数据量一大，速度就没法保障了。所以现在基本都在往java方向转了。

贝壳的建设逻辑其实也很简单，跟着业务走。左晖总的业务理解太深了，对人性理解的太透了。产品和技术完全为业务服务，构建了一个又一个的护城河。

OK，大家可以看出，贝壳完全是业务主导。我们绝大多数企业都是这种建设逻辑。这种逻辑下，技术和产品每天都是鸡飞狗跳，日夜加班。

但是好处是很明显的，能够抓住核心商业价值，小步快跑，快速迭代。

三种模式的对比

产品主导呢，基本上都是有中台团队的。在一开始都是有顶层规划的，商业价值不用说，是能挣钱的。但是难度是相当的大，需要前期投入太多。现在市面上数据中台产品基本上都是从阿里出来的。

技术主导基本都是独立平台部门，在平台层进行规划和建设，一般来说不太会直接解决业务问题，因此商业价值较低，也比较难以量化。

业务主导一般都是要啥平台就建一个小部门开干，直接解决业务需求，商业价值也很高，但问题在于缺乏总体规划，通常是做着做着，平台就不行了，要推到重来。

打造一个完美的产品，大多数产品人或许会认为产品主导肯定是最好的。其实不然。

这里分享一个迪斯尼设计小路的故事。迪斯尼乐园中各个经典相距较远，设计师罗培斯想了很久都没有好的方案。于是他就出了一个绝招，在空地上撒草籽，变成草坪，路人自行践踏形成小路。最后这个设计获得了大奖。

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

这跟产品的MVP逻辑是一致的。

所以大家有没有发现这三种模式都遵循一个什么规律？

人月神话中有提到一个“康威定律”，用人话说也就是说组织形态决定了产品形态。产品主导就是上帝视角进行建设，技术主导是在业务逻辑基础上，因势导利，建设平台，业务主导最野蛮，河流往哪走，地形就得跟着变。

所以如果咱的公司是产品主导，那就直接抄阿里的作业。

如果是技术主导，那就帮技术好好策划一下平台产品。

如果咱是业务主导，那咱就加班硬抗吧，这个没办法。

以史为镜-数仓发展历史启示

最后呢，再花几分钟给大家过一下数据仓库的发展历史，希望给大家带来一些启发。

其实数据中台和数据仓库非常像的。Inmon最早提出了数仓的概念，并且提出了完整的建设方案。方案是从数据上游向数据下游的方向全面建设，这很像产品主导的模式。但是这种模式遭遇到了前所未有的大败局：几乎所有的数仓项目都失败了。

自上而下的数仓建设模式失败之后，kimball提出了数据集市的概念。他的理念是从数据下游向数据上游逐步设计，跟Inmon恰好相反。但是正是因为这样，以终为始，缩小范围，成功率大大增加，这跟MVP的逻辑是一致的。

最后两者融合，开启CIF的时代，一直沿用至今。

所以，一个新理念的提出，必然会经历萌生、成长、成熟的阶段。目前数据中台距离成熟还有段距离，需要我们共同努力。但是未来可期，同志们，我们共同努力！

扩展阅读：《PMTalk如何建设一个好的数据中台产品》+《阿里全套产品白皮书》，公众号“大数据架构师”后台回复“PM”即可下载。

配合以下文章享受更佳

下载 | 带你去看“字节跳动数据中台服务化的发展与实践”分享会

干货 | 楼盘字典为什么能成为贝壳的超级护城河？

干货 | 到底什么是中台？我把贝壳解剖了给你看！

下载 |一口气说穿数据中台-给你架构师的视角

干货 |一口气说透中台--给你架构师的视角

我需要你的转发，爱你哟