万字详解数据中台 | 人人都是产品经理

万字详解数据中台

数据中台的概念已经出现了好几年，而到目前，互联网企业、IT软件企业等企业都推出了自己的产品与战略，进军数据中台领域。怎么理解数据中台及其产品形态呢？这篇文章里，作者结合具体产品做了一定梳理和分析，一起来看。

1. 从世界大数据的角度去看

1991年，Bill Inmon出版了《建立数据仓库》。也就是目前我们还是一直在使用的数据仓库的概念。在落地方面，没有准确的消息当时的技术是如何将大批量的数据入仓库的，但是因为其非实时性质，应该不是问题，数据进仓之后再花一些时间去完成汇总层的计算。

2003年，Google公布了其内部处理海量数据的技术——分布式文件系统GFS、并行处理框架——MapReduce、高效数据存储模型BigTable等等。这些促成了Hadoop的诞生，再后面是Hadoop的完善、更多的大数据相关开源项目的诞生，以致于每个场景都有了框架去使用，例如：Flink、Impala、Kudu、Kafka等等。

2008年~2011年，这期间是学术界对于大数据讨论的繁荣时期，Nature、EMC世界大会、麦肯锡全球研究院、Gartner都在发表自己对于大数据的看法。大数据开始成为人们热议的话题。

2011年以及之后，世界多国都将大数据作为战略，更是推动了大数据的发展。

2. 从国家大数据角度去看

2014年开始探索大数据，并持续地去运用大数据，将大数据作为战略，可见大数据的重要性。我想比较明显的感受是一些政务可以在网上处理了，不一定要本人到现场办理。

3. 从数据产品的角度去看

数据使用需要一种方式。

在久远的年代或者是落后的企业环境里，我们还不会使用数据仓库，只是使用数据库去存我们的所有数据，但是这让我们大量的数据难以完成计算，时效低。

到了数据仓库的时代，开始使用数据仓库去存和使用数据，使用效率开始有了较大的提升。

什么样的人，适合做B端产品经理？

要想成为优秀的B端产品经理，懂业务和懂产品是两个很重要的标准。B端赛道非常细分，产品迭代和推广的速度也很慢，这就产生了大量工作机会...

查看详情 >

同样是数据仓库的形式，到了企业里面之后，随着对于数据的管理实践，渐渐总结出了数据平台这个东西，可能是基于组织架构。

到现在，我们主要还是为了提升使用数据的效率，因而产生了数据中台，这种高复用的使用和管理数据的方式。

4. 从数据中台的角度去看

数据中台的概念最早起源于2015年。

2015年，马云在拜访参观芬兰游戏公司Supercell时注意到该公司拥有一个强大的技术平台来支持公司内部小团队的游戏开发，从而各团队可以专注创新，基础且同质化的技术内容已实现共享支持。如果将这种思维转化到企业治理中，则需要构建一个资源整合和能力沉淀的平台，达到对不同部门进行总协调和支持的目的，数据中台的概念由此诞生。

2016 年，阿里巴巴开始实施数据中台战略，通过构建创新灵活的“大中台”、“小前台”的组织机制和业务机制，实现管理模式的创新。

2017年，滴滴出行跟进了数据中台战略，并于同年12月分享了《如何构建滴滴出行业务中台》的企业战略。

2018 年，京东于12月宣布采用前台、中台与后台的组织架构。

2019年，数据中台建设规模开始迅速增长，传统企业与创新企业均积极参与建设，同时，行业中涌现了一批以建设数据中台为核心业务的创新业务服务商。

截至目前，互联网企业、IT软件企业、移动运营商及IT解决方案提供商均推出自己的产品与战略，进军数据中台领域。

二、数据中台的形态总结

1. 核心能力

我认为是强大的服务能力，能够快速响应业务的需求。一般企业内的数据中台并没有数据业务化，也就是说数据中台是不赚钱的，此时数据中台扮演的角色是辅助业务决策。

而扮好这个角色就是业务有很多需求，数据中台都能够及时地消化，这是很难的，相信一定会有出现一个需求两个月才完成的情况出来，从需求提出到产品梳理到技术开发到测试到验收到上线，这是一个漫长的过程。

如果任何一个需求都是这样去开发地话，完成业务的需求需要大量的人力，但这是难以做到的，企业需要考虑用人成本，而现在的技术成本是相当高的。那么数据中台此时就是为提升服务业务的能力而生。

onedata和oneentity的理论的理论来自于阿里。经过我的其他一些认知结合，我对这2个方法论的认知如下。oneentity是数据的底层根基，作用在于打通数据。常见的数据打通是人的数据的打通，但实际上oneentity不仅仅指的是人，物也是需要打通的，也就是说需要对人或者物进行唯一标识。

通常一个人即是唯一的，此时常用的方法论是ID-Mapping。物的话，一个物可以是唯一的，但是如果是批量的商品，那么往往还会有唯一的型号，用以标识都是同一类型的商品。这样后续需要统计商品的销售情况时，可打通全域的数据进行全面的统计。

onedata指的是数据只存一份，口径统一。所有的数据汇集到数据中台，各个计算好的指标或者维度都是统一的，企业内的任何地方需要统计数据都是从这一份数据拿数据进行统计。

乍一听感觉是比较简单的一个方法论，但是在实践的过程中不好将所有的口径进行统一，因为各个业务线对于口径都有自己的看法。然而，我认为尽管如此，我们还是可以制定出公认的标准的口径，这样的话高层在看数据的时候就不至于因为多口径而误解了数据，至于那些个性化的口径可以使用某个规则将尽可能多的个性化口径覆盖，还有部分个性口径实在没有办法覆盖则为之创建特定的表去计算。

3. 核心逻辑

1）关于oneentity

关于人，我曾写过一个相对详尽的ID-Mapping的方案，在此不再赘述，逻辑比较复杂。

关于物，这个的逻辑比较简单，主要就是物都经过中台，带有唯一标识，所带的标识将会去到订单、行为日志等等数据里，这样的话，便可基于唯一标识去打通全域的物体。而这个事情通常是由业务中台去做，数据中台再基于业务中台的数据去统计。

2）关于onedata

在过去我们建设数据仓库总是先有数据分析需求，然后才是ETL工程师去设计数据仓库并进行开发。我认为了解业务，从业务的角度去建设数据仓库会是更好的做法。

两种做法得到的结果的区别在于业务的附加程度是不一样的，前者可以说基本就是基于技术的角度去设计数据仓库的，可能会造成之后的修改或者不断的新增更多相似的表，单点的开发并不会考虑更多的事情，基于需求能够完成需求即可。后者则是在充分了解业务的情况下，以俯视的视角去进行设计，考虑到业务的情况，之后有更多的其他的数据时，不需要频繁新增表或者改表，而是在良好的表基础上进行扩展——简单理解就是加字段。

这样的设计背后的逻辑常常是基于主流程主数据考虑的。我们会梳理出主流程，并在主流程中找到我们认为重要的主数据，然后基于主数据进行标签或者指标的设计。

而这些标签/指标将依附在我们的表中。每一张表其实代表的是主数据的一个分类，而主数据是这个分类的根节点。如下例子所示，用户是主数据，是根节点，注册信息是分类或者可以叫它子节点（对应的是我们的表），而首次注册的APP、首次注册的渠道则是树节点（对应的是我们表中的字段）。当然这个树结构可能没有这么简单，根据企业的实际情况建立树结构。

• 标签体系设计：主要是产品或者是资产设计师建立标签体系，相当于给技术提需求。这里的标签可能是指标也可能是标签。
• 标签同步与加工：需求到了技术时，当技术完成开发后，需要将相关的元数据同步回到系统。
• 标签管理：产品/资产设计师对于标签的管理，从标签的上架到下架。
• 标签门户：标签的展示，相当于标签超市。
• 标签应用：各种服务组件，也就是各种各样的功能。

因为我曾写过一篇比较详尽的文章描述这个落地方法，在这里就不再赘述了。

5. 行业情况

2019年被称为数据中台元年。单从数据来看，目前，我国数据中台行业已经从萌芽发展阶段转换到高速发展阶段。根据艾瑞咨询数据，数据中台市场已从2018年的17亿元增长至2020年的68亿元，三年CAGR为100%， 到2023年，数据中心市场规模有望达到183亿元，五年CAGR可达到48.1%。

虽然数据看起来不错，但是置身于这个行业会发现很少真的将中台的所有能力都标准化出来的软件服务商，大多应该都还是提供咨询服务，走的是项目制。

这里的数据中台其实应该更多指的是数据产品，并不是企业自建的那种厚重的中台，很少听说企业会将自己的所有数据都放在一个外部的平台上，大多数时候都是某个产品使用某个数据平台。而且由于中台的复杂性，标准的组件一般难以满足需求。

那到底复杂在哪里？或者说并不是复杂，而是企业的所有数据不会都交由第三方处理，所以现在的数据平台一般都是提供比较简单的标准化的功能，像用户行为分析、用户画像、智能推荐等等。

从大数据企业的排行榜来说，深耕这个行业的SaaS公司似乎比大厂更有竞争力，在前30的榜单上没有看到大厂的身影。

另外，在数据行业，不管什么公司，大多产品都以服务业务为导向，以业务价值为导向，不再片面地追求厚重的中台，更加聚合的理想的中台，反而顺应企业的发展情况，一般而言中小公司都是不太注重建设厚重的中台，反而希望能够更轻量地实现需求，可能实现地没有那么完美，但是应该是低成本的不需要影响到公司级别的员工去配合。

我也在这段时间里从希望能够比较理想地建设中台到更加希望服务业务为主，至于是否非常规则高级地实现是次要的。至于如何轻量地实现，按我的理解是不去大改目前的情况，以间接地小改去实现需求。

三、行业产品分析

1. 分析的目的

我们仅是从产品的角度去分析各个厂商做出来的产品是什么样的，有什么可借鉴可学习的地方。

2. 竞品的选择

神策、巨量引擎、友盟。神策是我比较关注和常用的数据产品，在业界比较出色。巨量引擎是今年接触到的字节产品，是一个比较新的产品，我比较喜欢它的架构。友盟则是老牌大厂的一个产品，用以对比。

火山引擎：

总的来说，这样的架构是符合典型的业务流程的。

• 先通过广告进行引流。
• 当流量来了之后，对其进行行为分析、画像分析。不知不觉中进行智能推荐，千人千面地进行触达。
• 每次触达都需要使用内容，因而也就有了内容管理，追踪转化的内容归因。
• 当客户有了潜力之后可能就进入客户管理系统中。
• 涉及到比较复杂的情况时，就需要进行A/B测试。

实际上这样的架构还不是一定的，只能说比较相似，神策与巨量引擎的比较相似，友盟咋一眼看上去不相同，但实际是相似的，只是功能的结构不一样。友盟相比其他的，多了很多分析的模型，在很多的分析模型上加上一些常规功能，例如画像、用户行为分析，最后组成了一整套的解决方案。

四、我的认识

1. 中小企业表面临的一些困境

企业数据氛围不够：大多数企业已经在倡导数据说话，但是对于数据的认识不够，就像一个初级的数据使用者，对于数据的理解停留在比较表层，抛出几个简单的数据，然后就草草完成结论。这是司空见惯的。这样的情况，导致这些数据本就是比较基础的，业务自己就可以完成数据统计，根本就用不上大数据，大数据被晾在了一边。

业务疲于完成kpi：如果大数据试图去引导业务去使用更细致的数据，此时在纠缠下可能输出了一个方案，但最后很可能效果并不好，业务可能看了几次就放弃了这个功能。有人可能会怼说，这应该是你们产品的责任，需求都没确认好。可是产品确实是与业务确认过了才开发的。责任问题有点难以判定得很清楚，但是我分析一个比较重要的点是因为业务不太在意这个事情，可能是被推着去做的这么一件事情，口里虽认同，心里则不然。另外，业务更在意完成kpi，因此可能对你的方案并不太上心，不想花太多的时间去处理。

功能影响范围大：如果每一个功能的影响范围都覆盖全公司，那么大数据系统可能很难以迭代起来，推动的成本会很高。此时更优的方案是，先做出一个功能尽管只有一个部门使用，但其实这个功能是通用的，未来其他部门要是合适用也可以用。

人才缺失：大数据的人才也是数据平台建设的关键一环。其是否有宽阔的眼界，能否搭建一套良好的产品架构，满足未来的需求，是影响一个系统能否走向更好的关键因素。此时更建议大数据人才能够了解行业的各种做法，取长补短，吸收行业的先进思想应用起来。

一般而言，高层对于数据的理解是比较透彻的，只是一线员工不是都能到达这个层面。如果有一些不好推动的事情，可以找高层推，这个基本是最优的方法。

2. 关于产品架构

其实产品架构不是固定的。我们可以参考现在的经典的架构就是如上所述。但就企业内部而言，我觉得可以是这样的。

标签平台：对于标签的管理，也是数据资产的管理，可以让数据像商品一样上架到超市供业务取用。

指标平台：统一的一套指标体系，在此标签体系上进行扩展。

用户行为分析：常规。

用户画像：常规，但我们要思考得更加深入，不能只做静态的标签，也要做动态的，而且要充分利用模型，尽量不要买了什么商品就一直打上这个商品的标签，其实这样的做法是比较粗暴的。

举个例子说，今天我买了一个篮球就表示我喜欢篮球吗，不是的，可能我只是给弟弟买，或者班级买等等，我们要充分考虑各种情况再给用户打标签，再深入思考一层，用户的兴趣也是有可能减退的，可能今年我喜欢打篮球但是明年就不一定了。

广告分析：常规。

内容管理：在这个内容为王的年代，只要你的内容能够吸引流量，那就有很大的机会转化。因此对于内容的管理能够识别出最优的内容，帮助企业做出更好的选择。

智能推荐：千人千面的，无时无刻不在创造客户转化的机会。

触达：这个非常重要，可以是运营人工设置一次触发，也可以是一个流程画布，根据用户的行为路径进行一系列的触达。

看板：常规。

总而言之，还是要多思考深入一点，这样才能挖掘到更多的转化机会。不局限于一般的营销手段，可以大胆地采用算法模型给业务赋能，不局限自己的想法，多参考业内先进的思想。

3. 参考资料

• 《阿里巴巴云上数据中台之道》
• 中国信息通信研究院
• 国泰君安证券研究
• 《标签类目体系》