Hello 数据中台

中台是为了通过服务化的⽅式实现技术、资源复⽤，解决快速⽀撑业务 发展的问题。

在传统 IT 时代，无论项目如何复杂，都可分为 “前台” 和 “后台” 两部分，简单明了。

这里的前台不是我们理解的前端，而是大前端(PC、移动等)，还包括提供的各种服务。

后台指的是底层的服务，例如研发人员为了方便，自己抽取出的公共模块/方法

在传统IT时代，项⽬的发展相对稳定，并不需要像互联⽹时代那么快速的去迭代和试错，所以这种结构并⽆问题。

在互联⽹快速发展的今天，竞争越来越激烈。只有以⽤户为中⼼，快速适配⽤户的需求，不断迭代和试错，才能让 企业在竞争当中⽴于不败。以阿⾥的中台为例：

华为把作战⼩分队⽐喻为前台项⽬团队，把中台⽐喻成战地指挥部。在这个⽐喻当中，中台的作⽤就是提供资源⽀ 持：要数据给数据、要技术给技术。正是因为有了中台战略，华为才能快速孵化出华为⼿机、华为荣耀、华为云等 品牌。

一、数据中台概述

1.1. 数据中台架构

数据中台，⽬的总结下来⼀句话：**通过服务化的⽅式增强数据的共享能⼒以实现数据的复⽤，解决数据研 发、数据分析、数据运营时碰到的痛点问题:**

• 指标⼝径定义不⼀致
• 数据研发效率低问题
• 数据质量问题频发
• ⼤数据建设成本越来越⾼
• 数据发现的能⼒低下导致数据好不好⽤的问题

1.2. 数据中台架构

数据中台架构：为了⽀撑数据中台⽽设计的⼤数据平台架构，数据中台架构有问题将直接导致数据中台建设⻁虎头蛇尾甚⾄失败。

因为没有明确的数据中台建设的⽬标，没有很清晰的落地场景、落地成果⽆法直观的量化，最终导致数据中台规划 很⼤，落地的时候遇到很多困难和挑战：研发效率低、数据质量差、研发效率低、成本⾼。

二、⽆数据中台的苦恼？

这⾥以阿⾥数据中台为例，来阐述下数据中台建设的重要性

2.1. ⽆中台数据体系

在没有建设数据中台之间，⼀般公司的数据体系如下图：

2.2. ⽆数据中台⾯临的挑战

2.2.1. 各种慢

• 数据需求交付慢，起码一周
• 数据发现慢，一堆表不知道要使用的数据在哪里
• 取数据慢，一堆数据开发成天在帮业务部门取数据，恨不得嚼碎了喂数据
• 报表查询响应慢
• 数据故障处理慢

2.2.2. 各种不准

• 数据指标不准确频繁被投诉
• 数据部门很难发现数据不准确问题，只能等着使用方反馈
• 各个口指标定义不统一导致各种误解

2.2.3. 各种浪费

• 不少表长期无人访问却占用大量存储却不敢下线
• 不知道我的表被谁使用了，上线容易下线难，浪费越来越大

2.3. 原因分析

2.3.1. 烟囱式开发模式

传统的数据研发效率低，都是接到需求，从底向上分层开发（ODS->DWD->DWS->ADS），压根没有考虑复⽤，有 可能ODS层数据早就存在了，⼤量的中间表可以复⽤。

2.3.2. 数据治理缺失

谁访问了我的表，我的表在哪⾥，下线⼀张表也不知道谁使⽤我的这张表

2.3.3. 数据使⽤⻔门槛⾼

业务部⻔门要使⽤数据，要么提供标准的数据产品，要么采⽤SQL⽅式提数据，很多运营、产品不会写SQL，全部产 品化投⼊太⼤还不能复⽤。

2.3.4. 缺少全链路的数据质量监控

⼤数据链路是很⻓长的，重跑⾮常困难。

2.3.5. ⽆成本意识

为了快速出结果，没有考虑成本，不使⽤的资源没有及时下线。

2.3.6. 深层次原因

• 流程规范缺失：没有完善的流程和规范，⼤家只在关注需求，有了需求就开发，导致越来越失控。
• 技术架构跟不上：保证流程和规范可以⾼效的被执⾏，所以依赖技术架构，这块需要⼤量的⼈⼒投⼊
• 组织架构分散：部⻔门⾃⼰构建⾃⼰的⼩数仓，n多个⼩数仓相互割裂，跨数仓同步数据困难。

三、建设数据中台

3.1. 数据中台建设⽅法论

数据中台建设的⽅法论就是我们的指导思想，主要分为2⼤块：数据统⼀管理 和服务化

3.1.1. 数据统⼀管理

数据统⼀管理有如下⽅法/要点

• 按主题域管理

  数据按照业务主题域管理，⽐如⽤户域、订单域、物流域等等。

• 数据完备

  数据中台中的数据尽可能完备，从业务过程⻆角度看覆盖范围是完善的（各主题域要覆盖所有业务，提前梳理和熟悉 整体的业务，⼲掉烟囱），从分层的⻆角度来看，尽量避免跨层构建，即避免明细层数据和轻度汇总层数据缺失

  

  ODS 层：原始数据层，存放原始数据，直接加载原始⽇志、数据，数据保持原貌不做处理。

  DWD层：明细数据层结构和粒度与 ods 层保持⼀致，对ods层数据进⾏清洗(去除空值，脏数据，超过极限范围的数据)，也有公司叫dwi。

  DWS层（轻度汇总层，按业务要求的最细粒度汇总） 服务数据层 以dwd为基础，进⾏轻度汇总。

  ⼀般聚集到以⽤户当⽇，设备当⽇，商家当⽇，商品当⽇等等的粒度。 在这层通常会有以某⼀个维度为线索，组成跨主题的宽表， ⽐如 ⼀个⽤户的当⽇的签到数、收藏数、评论数、抽奖数、订阅数、点赞数、浏览商品数、添加购物⻋车数、下单 数、⽀付数、退款数、点击⼴告数组成的多列表。

  ADS层(数据集市层) 数据应⽤层: ⾯向实际的数据需求，以DWD或者DWS层的数据为基础，组成的各种统计报表。 统计结果最终同步到RDS以供BI或应⽤系统查询使⽤。

  这⾥所说的数据集市指的是狭义的数据集市，也就是加⼯好的数据可以拿出来了(好⽐摆在”集市“上卖)

  ⼴义的数据集市可以理解为部⻔门级别的数仓，正好跟数据中台是反着来的。

• 制定并推⾏命名规范

  好的命名规范应该根据表名就知道所属的主题域、分层、表类型(快照表、增量表)

• 提⾼数据模型复⽤性

  模型设计尽量考虑复⽤性，不要⼀个表的数据被翻来覆去重复加⼯，⽽是统⼀成⼀个模型供⼤家复⽤。

• 统⼀指标⼝径

  指标⼀致性：不同的系统出现相同的指标名

3.1.2. 服务化

如果没有数据服务化，数据接⼊和访问不是⼀个标准化的流程，则会导致⼀系列问题。要把整个数据开发的流⽔线 通过系统的⽅式去打通。

3.2. 数据中台技术体系

数据中台的落地是需要⼀套技术体系来⽀撑的，数据中台架构就是这套体系的具体实现：

3.3. 数据中台组织架构

数据中台是⼀个集数据采集、融合、治理、组织管理、智能分析为⼀体，将数据以服务⽅式提供给前台 应⽤，以提升业务运⾏效率、持续促进业务创新为⽬标的整体平台。从下⽽上往往只能看到其中⼀个点，难免会以 偏概全，毕竟⼤部分员⼯很难站在⼀定的⾼度去做⼀个”看⼗年、做⼀年“的规划，特别是当⼀件事和眼前的 KPI 难 以达成平衡时，中台的⼯作会受到各个⽅⾯的挑战。因此，⾼层的坚定⽀持是中台战略的第⼀必要条件。

数据中台是 “⼀把⼿” ⼯程，需要从上到下进⾏,企业要想建设数据中台，⾄少需要 CIO 或者 CTO 层⾯推动，最好是 最⼤boss推动。中台是战略层⾯的事情⽽不是战术层⾯，⾃下向上推动⼏乎没有可能，⽐如涉及标准统⼀等。

当企业⾼层决定建设数据中台后，下⼀步就要考虑中台团队的⼈员组成以及整个团队在组织架构中的位置。对于是 否要进⾏⼤的组织架构调整，⾸先要看企业的业务复杂程度。类似阿⾥巴巴、京东等⼤⼚需要通过组织架构调整来 保障战略顺利推进，但规模相对较⼩的企业可能没有必要进⾏组织架构调整；其次，取决于企业决策者对数据中台 战略的态度，是否将其放到整个公司的战略⾼度，类似阿⾥巴巴、京东等⼤⼚已经将数据中台作为重要战略，陆续 进⾏了组织架构变更。

典型的数据中台组织架构如下：

组织架构是基础，各个团队分散到各个部⻔门，数据中台基本不会建⽴起来的。⼀般典型的做法是，整个数据中台团 队由原来的⼤数据团队整编过来，直接汇报给CTO/CIO，也可能会报给⽼板，整个部⻔门⼀般会有⼀个⼤数据总监来 负责。

• 数据产品团队：负责数据产品、数据中台的整体规划，制定数据相关规范监督落地
• 数据平台团队：平台⼯具的研发，整体架构的演进，⼀般会⾼配⽐较厉害的架构师
• 数据开发团队：⽇常数据研发、数据集成、计算、治理等等
• 数据应⽤团队：数据应⽤产品研发，⼀般是⾯向业务过程、⾏业的、通⽤的数据应⽤

3.4. 开源数据中台架构

数据中台整体建设是CTO、⼤数据总监、⼤数据负责⼈该考虑的，起码得考虑1年以上，建设周期1年起步（分阶 段），作为架构师应该考虑的是⽀撑数据中台建设的架构。

3.4.1. 数据中台架构应该具备的能⼒

• 基础设施/基础平台

  • 存储引擎
  • 计算引擎
  • 辅助服务

• 数据集成

• 数据开发

  • 数据开发IDE

• ⼯作流调度

• 数据治理

  • 数据质量
  • 元数据管理
  • 数据安全

• 数据可视化 DevOps 其他数据服务

3.4.2. SiROS 数据中台架构

四、中台战略思考

4.1. 数据体系及架构的演进

数据体系和架构的演进

4.1.1. 数据体系演进

数据仓库->数据平台->数据湖->数据中台(通⽤业务下沉)

4.1.2. 技术架构演进

hive->CDH体系->更全->更全

4.2. 数据中台未来发展⽅向

4.2.1. 实时数据中台

⽬前各⼤公司数据中台中实时数据计算占⽐少，模型复⽤率低，公共计算逻辑下沉做得不好。未来需要把现在的理念推⼴到实时加⼯链路，构建实时数据中台。

4.2.2. 云原⽣数据中台

基于k8s，弹性资源调度，实现在线和离线混布，提⾼资源使⽤成本。

4.2.3. ⾃动化数据研发流⽔线(DataDevOPS)

可视化操作，可视化ETL，数据开发⾃动化流⽔线

4.2.4. 智能元数据管理

智能数据发现，智能元数据分析。

4.2.5. 通⽤数据产品建设

更多的企业会研发⾃⼰的通⽤数据产品，甚⾄有更多通⽤的数据产品被开源出来，例如⽤户⾏为分析产品。

4.3. 中台战略反思

4.3.1. 中台并⾮万能钥匙 ！

中台并⾮万能钥匙，当初为了解决组织和效率的问题，⼤多数企业开始跟⻛风建设，最后发现有效果但是矫枉过正 了，把太多的东⻄西放在了中台导致不利于业务创新。

中台并不是不⽀持创新，正相反，阿⾥中台孵化出“盒⻢鲜⽣”这样的现象级产品，如果没有中台，不可能半年打造 出⼀整套线上线下新零售系统。

准确的说，中台适合做“组合式创新”，没法做“颠覆式创新”。所谓组合式创新，是把现有⼏个能⼒进⾏组合，形成 新的能⼒，它强调能⼒的标准化，这个恰恰是中台所擅⻓长的。以“盒⻢马鲜⽣”为例，它复⽤了中台的商品、库存、⽤ 户、⽀付、AI、安全等多个服务能⼒，经过重新组合，形成了“零售新物种”。

但是，颠覆式创新，是从根上做创新，它要打烂前台、中台、后台，颠覆现有模式和能⼒。⽐如智能制造颠覆传统 制造、智能⼿机颠覆传统⼿机，你没法在现有⽣产线上去创造，只有打破原有模式。所以，中台不⽀持颠覆式创 新，这是中台的基因所决定的。

把最抽象的部分留在中台，这样中台就剩下很薄的⼀层，通过这⼏年沉淀下来的通⽤能⼒来提⾼效率，可以⼤⼤减 少⼈⼒，释放出来的⼈去前台做个性化的改造。

4.3.2. 不同企业应该量体裁⾐

• 初创公司正经历从 0 到 1 的阶段：没必要建设中台，⽣存下去最重要，中台还没搭建好公司可能就死了

• 中⼩型公司从 1 到 N 的阶段适合搭建中台：⽣存问题已经解决，在项⽬没有太复杂之前下沉通⽤业务，为后续业务爆发做准备

• 中⼤型公司从 N 到 N+1 阶段中台战略势在必⾏

4.4. 碎⽚化中台

中台会越来越薄+碎⽚化中台

2015年底阿⾥推出“中台”战略，将庞⼤的业务服务能⼒，都装进了“业务中台”⾥，包括交易中⼼、⽀付中⼼、清算 中台、⽤户中⼼、产品中⼼等13个业务域，这是阿⾥中台早期的架构图

随着阿⾥中台战略的深⼊，2018年阿⾥提出了“业务-数据双中台”战略，可以理解为升级版的中台战略，依托阿⾥云 ET⼤脑，向社会输出中台能⼒和⽅法论。阿⾥的中台⼀分为⼆：数据中台、业务中台，如下图：

这⼀“拆”，仿佛打通了中台战略的任督⼆脉，从此⼀发不可收拾，相继拆分出：移动中台、技术中台、⻛风险能⼒中 台、研发效能中台等等。⾄此，阿⾥在“拆”中台的路上，越⾛越远。

五、中台战略的三个阶段

碎⽚化中台，是中台架构演进的必经阶段，各⾏业经过⼏年的实践，也逐渐沉淀出⼀些贴合⾃⼰⾏业的中台实践。 不同⾏业，不同企业，遇到的问题不同，解决的路径也是不⼀样的。从中台演进的过程来看，⼤致分成三个阶段。

5.1. 业务中台

企业从业务顶层规划、业务建模开始，梳理出各业务领域的边界、服务能⼒，进⽽指导系统的服务化建设，⽐较好 的实践有：企业EAI、微服务等等。

5.2. 双中台

企业具备了业务领域建模、数据治理⽅⾯的能⼒，逐步建⽴起基于业务中台和数据中台的“双中台”模式，在这个过 程中，沉淀⾃⼰的中台⽅法论和实践。值得注意的是，由于业务领域建模和数据治理的⾏业性、专业性太强，这类 ⼈才⼤概率只能在企业内部培养。

5.3. 碎⽚化中台

在完成业务中台、数据中台的建设之后，企业组织的效率已经有了显著提升，企业成本也随之降低。这个时候，中 台建设进⼊到了碎⽚化中台阶段，组织内部按业务线或职能进⾏更细粒度拆分，⽐如：安全中台、财务中台、移动 中台、客服中台、供应商中台、物流中台等等。