三分钟了解数据中台——什么是数据中台？

@[toc]

### 什么是数据中台？
#### 背景
> 2015年全年产生的数据量等于历史上所有人类产生数据的总和，人类的数据增长正式从乘法型增长变成了指数型增长，海量数据处理成为了全人类的挑战。
阿里提出了DT时代已经到来：DataTech替代ITTech，强调数据驱动的重要性。
阿里走在了前面，阿里用几百人的团队支撑了几万亿的GMV，其中60%-70%来源于数据支持的机器决策，机器智能赋能业务，用更低的成本，更高的效率去服务顾客，提供个性化推荐。
阿里的数据处理经理了四个阶段，分别是：
一、数据库阶段，主要是OLTP（联机事务处理）的需求；
二、数据仓库阶段，OLAP（联机分析处理）成为主要需求；
三、数据平台阶段，主要解决BI和报表需求的技术问题；
四、数据中台阶段，通过系统来对接OLTP（事务处理）和OLAP（报表分析）的需求，强调数据业务化的能力。


#### 作用
>所谓的中台就是：通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来，以减少人与人之间的沟通成本，同时还能最大程度地提升协作效率。

#### 定义
那么什么是数据中台呢？——中台，企业级能力**复用平台**。

>数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时**统一标准和口径**。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。这些服务跟企业的业务有较强的关联性，是这个企业独有的且能复用的，它是企业业务和数据的沉淀，其不仅能降低重复建设、减少烟囱式协作的成本，也是差异化竞争优势所在。
### 中台类型有哪些？
#### 业务数据双中台
- 业务中台
>  业务，更白话一些来说，就是为了售出产品、换取利润，各行业中需要处理的商业上的相关事务。
所以，我们 常提到的业务中台，可以理解成狭义的业务中台，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。

- 数据中台
> 业务中台就是在产生数据，数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。」
> 

#### 技术中台
除了业务数据双中台，最常被提到，在我看来介于主流和非主流之间的就得属技术中台了。技术中台相比业务中台和数据中台，边界也会更加清晰，简单来讲就是 在 CloudNative 下将使用云或其他基础设施的能力、各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台、数据中台的快速建设。不过业界也有说法，认为技术中台没有很强的业务属性，只是一些中间件的集合，顶多算是个中间件平台而已，称不上中台，你怎么看呢？

#### 研发中台
软件开发是一项工程，涉及到管理、流程、测试、团队协作等等方面。如何将企业的开发流程、最佳实践沉淀成可重用的「能力」，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注开发效能管理的平台叫作研发中台。

#### 移动中台
在移动互联网时代，移动优先的原则已经成为不争的事实，将 App 开发过程中的通用技术组件进行封装沉淀到移动中台中，就可以在构建新的 App 时大量复用已有组件和能力，快速构建和响应。

#### 管理中台
最近很多企业开始尝试把中台思维应用到企业内部，重新对人、事、流程、企业运营进行平台化 / 中台化改造。试图通过中台化建设，加速企业管理标准化和提升运营能力

#### 组织中台
在穆胜老师的书《释放潜能：平台型组织的进化路线图》中，通过分析了海尔平台化组织的演进过程，他提出了组织中台的概念。组织中台很像企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供类似于投资评估（项目甄别）、投资管理、投后管理（孵化与风控），真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新。

好了，非主流系列我们就介绍到这里。其实远远不止这些，其他还有像财务中台、采购中台、供应链中台、AI 中台、运营中台、安全中台、管理中台等等，也曾出现在我们的视野里，今天就不一一展开了。

### 企业为什么要建中台？
#### 需求变了
我们看到很多企业的后台，**在创建之初的目标，并不是主要服务于前台系统的业务创新**，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱采购的套装软件，需要每年支付大量的服务费，并且版本有的也已经非常老旧了，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，基本改不动了，也是企业所谓的“遗留系统”的重灾区。可以这么说，大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度就根本跟不上前台业务发展的节奏。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。

#### 匹配失衡

此时的前台和后台就像是两个不同转速的齿轮**，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂**，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好， 转速也自然是越慢越安全。所以，随着企业业务的不断发展，这种“前台 + 后台”的齿轮速率“**匹配失衡**”的问题就逐步显现出来了。

#### 鱼和熊掌

企业业务不断发展壮大，后台修改的成本和风险越来越⾼，**这就驱使我们尽量保持后台系统的稳定性，但同时还要响应用户持续不断的需求**，怎么办？最自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中，因为前台离用户近，响应也相对快。但是这样也是有代价的，这样的后果就是引入重复，同时还导致前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低，企业竞争力也随之不断下降。

面对这样的情况，我们该怎么办呢？

中台应运而生了。我们既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，**为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层**，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的支援。

企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。但是，并不是所有的企业都适合构建中台。

### 成功的中台推荐

#### 阿里数据中台
本方案围绕阿里云各类数据中台解决方案，基于《数据安全成熟度模型》国家标准，以数据流转为核心安全关注点，分层分步构建数据中台安全架构，保障企业核心数据安全。

#### 网易业务中台
基于云原生、DevOps、微服务技术栈打造支持多个前台业务的共性能力，优化业务架构，实现能力复用，提升需求响应速度，降低研发与运维成本，并确保业务全链路稳定，促进企业高效率高质量发展。


#### 百度AI 中台
依托百度大脑十余年AI技术与能力的积累，面向金融、能源、互联网、教育、运营商、制造、政府等行业提供智能中台解决方案，助力企业构建统一的AI基础设施，实现AI资产的共建共享、敏捷的智能应用开发，加速企业智能化升级。


#### ……

### 最后

今天我们讨论了企业又为什么需要建中台。以用户为中心的持续规模化创新，是中台建设的核心目标。企业的用户响应能力和规模化创新能力，是互联网时代企业综合竞争力的核心体现。平台化包括中台化只是帮助企业达到这个目标的手段，并不是目标本身。中台（⽆论是技术中台、业务中台还是组织中台）的建设，根本上是为了解决企业响应力困境， 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾，提供⼀个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力。

所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了这条正确的大道上。

最后我们给中台下了一个定义，既 **企业级能力复用平台** 。有了这个定义后，我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实，对于如何建中台的思路也能豁然开朗。

因为如果说「中台就是企业级能力复用平台」的话，那「中台化」也就是「利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程」。