数据中台：阿里中台（大中台小前台）

第一章、大中台小前台战战略 简介 什么是 “ 大中台，小前台 ” 战略？ “ 大中台，小前台 ” 的由来第二章、中台的定义义 什么是中台？ 中台的划分 阿里巴巴电商系统发 展的四个阶段第三章、阿里各部分中台介绍绍 技术中台 移动中台 EMAS 研发中台 业务 、数据“双中台” 组织 中台第四章、其他名企的中台模型 腾讯 、海尔、滴滴目录录2015 年 12 月 7 日，时任阿里巴巴集团 CEO 的张勇通过一封内部信说，“今天起，我们全面启动阿里巴巴集团 2018 年中台战略， 构建符合 DT 时时代的更创创新灵活的“大中台、小前台”组织组织 机制和业务业务机制 。即从左边的单项 目单平台，变成右边的联合中台模式用户提供服务项目 B 前台项目 A 管理后台项目 B 管理后台项目 A 前台提供配置淘宝天猫支付宝聚划算阿里妈妈阿里菜鸟盒马生鲜用户中心商品中心交易中心评价中心搜索中心营销中心Aliware小前台大中台阿里巴巴提出来“大中台，小前台”的战战略什么是 “ 大中台，小前台 ” 战略？“小前台大中台”的理论来自美军的作战理论。美军目前的作战单 位都是 11 人以下小班排（类似前台），而导弹 智慧系统类 似于后台。但是管理上的难度在于，后台资源无法被前台直接有效使用，并且更新迭代迟缓 。 设置“中台”就是为了提炼前台共性需求，把后台产品做成标准化组件供前台部门使用 。01北欧游戏公司 Supercell 的超高人均产值 背后的组织设计美军的“特种部队（小前台） + 航母舰群（大中台）”模式02 阿里巴巴的大中台战战略主要来源于两方面：Ilkka Paananen支付系统数据分析系统用户基础设 施开发工具游戏引擎皇室战争部落冲突卡通农场海岛奇兵前台中台想了解更多关于美军 “ Team of Teams” 的组织设计 ，可参考书蜜 021 赋能游骑兵排ranger platoon海豹突击队SEAL squads陆军 特种部队Army Special Forces units中央情报局CIA美军特遣部队（ the Task Force ）刚开始管理模式试着让他们在一个将他们都包含在内的指挥系统下运作 。但是这样 随之而来带来的各式的问题等待“最高指挥官”理清状况及反应，导致决策延误团队 开始互相竞争及保护他们的资源和自己的优越性每支团队 都想表现自认为 最好的一面，即使那对整体行动毫无用处团队 之间的问题 从 1 支 专 家团队 交接到另 1 支专家团队 很困难而这样的敏捷团队，被称为“小前台”，而他们都有一个统一的“中台炮火群”来支持这些敏捷团队。美军小队中台炮火群中台的定义2. 中台支持的是多个前台业务业务 。1. 中台是一种共性能力组织组织 ，支持了多个业务业务 。中台是支持多个前台业务业务 且具备业务备业务 属性的共性能力组组织织，平台是支持多个前台或中台业务业务 且不具备业务备业务 属性的共性能力。中台的定义还义还 要求以下两点：对于很多企业来说，现在会用 Hadoop 的集群来储存业务 数据，但这个不能说是中台，它顶多是一个数据平台。现在大家比较公认的数据中台 ，指的是确保 OneID 、 OneData 得以实现 的组织 ，使 得 数 据 不再 是 各 前 端业 务 独 立 管理 ， 而 是 通过 统 一 的 团队 在 数 据 标识 、 指 标 、数 据 仓 库 等 方面 实 现 了 跨业 务 的 整 合 。 之 所 以 这样 大 家 会 认为 是 名 符 其实 的 数 据 中台， 是 因 为指 标 一 定 是 面向业务 的，数据仓库 的建设一定也包含了一些业务逻辑 。所以那个大大的 Hadoop 并不是数据中台，而是大数据平台。1. 没有业务业务 属性的不是中台。如果只能支持一个业务的，只能称为一个业务后台，而中台是为效率而生，它的特性就是整合多种功能在一起，能够同时支持多个业务发 展的中间件。2. 只支持一个业务业务 的能力不能称为为中台项目 A支付中心搜索中心项目 B商品中心用户中心项目 C营销中心交易中心前台业务中台业务业务 中台业 务 中 台 在 前文 中 反 复 提 及 ， 就 是 把 各个 项 目 的 共 通业 务 进 行 下 沉 ， 整 合 成 通用的服务平台项目 AMQ分布式缓存项目 BRPC框架容器项目 C分布式事务分库分表前台技术中台技术术中台技 术 平 台 ， 为了 避 免 研 发 人员 重 复 发 明轮 子 ， 向 各个项 目 提 供通 用的 底 层 框架 、引擎、中间件：项目 A数据建模项目 B日志分析项目 C用户画像前台数据中台数据中台数 据 中 台 ， 为各 个 项 目 进 行各 种 数 据 采集和分析项目 A语音识别推荐算法项目 B图像识别人机对话项目 C搜索算法垃圾过滤前台算法中台算法中台算 法 中 台 ， 为各 个 项 目 提 供算 法 能 力 ，比 如 推 荐 算 法、 搜 索 算 法 、图 像 识 别 、语音识别 等等：当有大中台思路之后，第一 ，我们这个体系里有什么样的能力，可以让各业务很清楚的知道，也可以让前台业务方更快的理解、选择和使用中台能力第二 、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。在阿里提出大中台，小前端战战略之后的这这近两年时间时间 里，阿里巴巴生态态的基础设础设 施构建进进一步完善。 一个明显变化是，在生态边界扩张的同时，阿里的基础服务组件，交易、营销、会员、电子凭证、资金、店铺、评价等商业运作的环节都被体系化打磨好，作为完整的解决方案被用于各个创新业务当中。而相对应的，新业务能够在直接利用这些解决方案的同时提出新要求，并对这些服务进行针对性创新，从而进一步促进平台创新。 其实实阿里的中台战战略发发展是历经历经 不同的阶阶段，每一步的发发展也见证见证 阿里业务业务 的发发展。淘宝早期分布式业务系统第二淘宝集市 + 淘宝商城时时期，分布式业务业务 系统阶统阶 段。淘宝集市 + 淘宝商城时期三淘时期业务中台化垂直化事业部时期单一业务系统第一淘宝生长长期，单单一业务业务 系统阶统阶 段。业务平台化第三三淘 ( 淘宝、天猫、一淘 ) 时时期、业业务务平台化阶阶段。第四个就是目前的垂直化事业业部、业业务务中台化阶阶段。第一阶段：单一业务 系统第一个阶段是淘宝早期的建立，业务简单，一个业务系统、几台机器就支撑了。这 个 阶 段 一 开 始 使 用 的 是 PHP 的 系 统 。随 着 业 务 的 发 展 ， 逐 步 改 造 成 了 Java 技术体系。系统名字叫 Denali 。淘宝首页 2003 年第二阶段：分布式业务 系统这就到了第二个分布式业务 系统阶 段 。阿 里把原来的单一系统拆分成多个高内聚 ，低耦合的中心化系统 。现在耳闻目详的用户中心 ， 商品中心，交易中心，店铺 中心，就是这个阶段出现的。每个独立的系统可以独立设计 、独 立接需求、独立发布，整个 研发效 率和 系统稳 定性都上了一个台阶。 阿里 知名的 中间间 件体系 也是这这个时时候发发展起来的。淘宝首页 2003 年第三阶段：业务 平台化 三淘时期淘宝拆分成立淘宝、天猫和一淘三个独立的事业部。三个事业部的业务决策链路更短，业 务 发 展 更 快、技术人员也快速增长 。 而且三个事业部的定位不一 样 、 业 务 发 展 方 向 不 一 样 、 业 务 的 管 控 规 则 不 一 样。 而 且 在 一 些 业 务 规 则上可能还相互冲突。我们都知道在做业务系统的时候，为了快速应对每天的业务需求变更，很多时候都是通过代码来写业务逻辑 的。在业务抽象建模，系统架构的开放性方面都是不足的。这就会导致业务逻辑 之间的耦合和相互影响，研发效率大幅下降。第三阶段：业务平台化 三淘时期在这一阶段，系统架构必须升级，这就进入了第三个业务中心平台化阶段。什么是平台？就是要把基础能力跟每个业务方的特性业务拆分，要把业务和业务之间的逻辑进 行隔离。比如说天猫的业务跟淘宝网的业务有可能是冲突的，但他们需要在一个平台上执行，这时候阿里必须把业务的逻辑分开，开始升级会员平台、商品平台、交易平台等等。平台化最核心的是业务抽象建模和系统架构的开放性。业务抽象解决共性的 80% 问题，系统架构开放性解决 20% 的个性化问题。第三阶段：业务 平台化 三淘时期第三阶段：业务平台化 三淘时期整个电商体系有 10 几亿的商品，涉及商品本身的物理属性、不同渠道的销售价格、库存等等。还有很多的不同类目的管控规则，比例医疗器械，必须要有企业资质证 明，要有检验证 明等等。而且还有些类目，因为市场定位不一样，管控的力度也不一样，比例淘宝和天猫在手机的管控上也都有差异。怎么去解决差异性的问题？就要通过建立元数据中心、规则中心、商品发布界面自动生成、图片扫描等等来实现商品管理的平台化。第三阶段：业务平台化 三淘时期我们知道每一个人去逛淘宝买东西，每一笔交易都在交易平台上发生，但是在 不 同 的 交易 的 流 程 和规 则 是 不 一样 的 。 比 如我 们 买 实 物商 品 、 买 虚拟 商 品 ，还有线下洗头服务等等，它的交易流程不同，有些是先支付在发货，有些是先发货后支付。比如说汽车可能需要在购买的时候同时申请贷款。支付宝给我们提供了很多支付方式，但不同业务需要的支付方式是不一样的，这些东西都是需要通过交易平台来实现。平台化要把不同业务的逻辑隔离开，避免相互影响。微淘消息push举例：交易平台达人品牌商行业运营外部抓取服务接口平台发布百川开放作者基础属性类型标签动态 属性阅读量 点赞数筛筛选选内容元素看图购视频搭配锚点商品帖子照片清单文字平台能力质量控制规则定制页面组件数据投放产产品头条极有家爱逛街清单用户户触达分享组件第四阶段：业务平台化但随着生态的复杂度、业务 的复杂度、系统复杂度的升级，阿里又遇到了新的问题 。 平台化解决了领域内部的问题 ，但是其中每一个业务 的执行都是跨领域的，涉及会员 、 商品、交易、营销 、店铺、评价、支付、物流、售后等等，业务逻辑 横跨几十个系统。这就导致了非常大的挑战，比如说店家卖一件衣服，就会有不同的规则 ，例如商品 发 布规则 、交易规则 、营销规则 等。这些规则 分散在不同的系统中，而且还是相互有关联的。逐渐地，新做一个需求需要 1 个月或更长的时间 ，这变 成了一个复杂生态的协作问题 ，而不仅仅 是一个技术问题业务业务 中台化阶阶段主要解决 4 个问题问题 ：第四阶段：业务平台化1 、信息获取成本高。2 、互联互通成本高。3 、服务具有不确定性。4 、低水平重复建设。解决问题问题 的3 个办办法：第四阶段：业务平台化1 、协议标 准、运行机制。2 、满足标准的分布式执行单元。3 、中心化的控制单元。第四阶段：业务平台化业务中台需要一个中心化控制单元，就是运营平台。它主要由协议标 准，能力 地 图 、 业务 需 求 结 构分 解 、 全 局业 务 身 份 、业 务 全 景 图、 业 务 度 量等 构 成 。能让我们有一个地方纵观全局，把控细节。其中能力地图是一个最基础的设施，要能把电商生态里面的能力都呈现出来，并在过程中不断的优化完善。就 象 我 们 现在 出 行 离 不开 高 德 地 图一 样 ， 今 后所 有 的 业 务方 需 要 做 业务 规 划 ，业务创 新，都可以到这儿来寻找需要的基础能力。业务 中台化 产品形态能力地图图1 、能力裂变2 、能力详情，活动评价需求结结构化1 、业务新建 / 业务变 更2 、配置工具业务业务 清单单1 、业务列表2 、业务全景业务业务 度量1 、业务度量了解 / 评估过程业务身份标识配置实现能力发布丰富度质量可读性第四阶段：业务 平台化为了能将业务逻辑 本身与实现逻辑 分离，可以将业务逻辑 下发给不同实现的执行系统，引入竞争，方便业务平台的改造升级，阿里将控制信息从业务平台中抽离到业务中台，以业务身份为主线来进行组织管理和呈现。并以生态角色的视角来重构信息架构。这样的变革对我们原来的系统架构提出了更高