从 今年以来，朋友圈、微博、技术论坛全网挂起了中台的风潮，下图就是百度统计给出的趋势图。那么中台未来是会成为主流发展方向还是昙花一现只是一个热门话题呢？我希望先从“中台”这个名词的来源开始，或许会有一个更加理性的认识。
起初就是那个名为supercell的公司，马云去拜访，觉得为什么人家只有300人却能创造出这么巨大的利润？CEO要求员工不要被流程和管理机制束缚，给每个小团队足够的决策权。而且由于资源稀缺，每个小团队可以更加聚焦手中的资源，选择做最重要的事情。
说不定某个阳光明媚的早晨，你正在吃着手抓饼，老板忽然把你们一群人拉进会议室，语重心长跟你们说 —— 你们要搞数据中台！
背景
项目有很多对内/对外/辅助，但无论项目内部的如何复杂，大体的结构都是 “用户前台”和“管理后台”。
用户前台
面向用户、直接产生交互，页面注重设计/交互，与服务端产生数据交换引导用户完成业务流程. 比如：
管理后台
面向运营人员的配置管理系统，后台为前台提供了一些简单的配置。比如：
用户前台、管理后台、用户之间的关系如下：
传统模式下，项目迭代周期基本以月、季度为单位。长开发周期也意味着需求一旦变动，要么996，要么交付推迟。
而且项目之间相对独立，许多项目都在重复发明相同的“轮子”。让项目越来越臃肿的同时，也让开发效率越来越低。
但现实是互联网进入下半场，企业竞争越来越激烈的今天。产品项目不能够快速迭代、低成本试错的后果，就等同让企业处于一定的竞争劣势。为了解决以上问题，“中台”的概念就有了。
中台的种类
我们按照难易程度倒序逐一论述。
1.技术中台（基础服务中台）
技术中台指的是将大家都通用的技术能力聚合到一起，由同一个团队负责，防止重复造轮子，是最容易实现的中台化。核心价值是降成本，刚刚提到了。
各公司的基础服务，以账号体系为代表，都已经是中台化的了。淘宝、天猫、飞猪等业务之间，快车、专车、顺风车等业务之间，美团外卖、酒旅、团购之间，必然要做打通。
2.数据中台
顾名思义，表面上数据中台是各业务的数据能够打通。不过在实际运用中，又分为多种。
基本的数据采集、数据仓库建立和数据分析能力的共享，其实是数据技术中台的范畴，是将做数据相关工作的技术团队整合，来支持各业务。核心价值是降成本。
各业务线的数据打通、数据共享和协同运用，则属于业务中台的范畴，是以业务目标牵头的（比如阿里的88VIP会员的前提就是用户数据打通）。
有时这两者是耦合在一起的，既有技术能力的共享，又有业务支撑。不过在国内数据分析的认知还比较浅（认为数据都是拉报表的），后者往往效果不佳。前者在不少互联网公司倒是确实落地了。
在有些公司，数据中台只是很粗浅地把数据整合到一起，并没有解决任何问题，或者让整合产生什么价值。阿里云中间件架构总监谢纯良曾经说过，许多公司的数据中台就是把数据加工成“大屏”，搞一个展示用的“大屏”就以为实现了中台。意思就是，数据中台如果不为业务服务，或者说为业务中台服务，那就没有价值。
3.业务中台
既然技术模块可以抽象出来复用，那业务模块是不是也可以？在淘宝时用过的营销策略，能不能直接挪到飞猪用？专车的策略能不能直接给快车用？这就是业务中台的概念。
很显然的，由于业务存在更高复杂度，因此难度更大。
业务中台是各大公司追求的最终效果：前台业务敏捷推进，后台业务稳固支持。不过真实情况往往事与愿违，难尽人意，真正做到业务中台运转良好的，很少见。
4.组织中台
组织中台刚刚讲 Supercell 时提到了，是嫁接在前三种中台基础上，再加入“放权机制”的中台结构。
阿里的中台业务支撑能力可以支持新的电商相关业务快速创新；字节跳动把增长能力中台化，头条的增长部队可以快速投入到抖音中去，甚至可以投入到海外各个国家各个产品；美团有试错小团队，会利用既有的技术能力、用户流量等资源快速试错，找到新的方向，包括外卖在内都是这样来的。
这些都是组织中台的体现。组织中台与其说是中台能力，倒不如说是内部创业的空间。它的核心价值应该在于“旧业务能否帮到新业务”，很考验组织能力。有的公司内部创业，封闭隔离，跟这个公司自己投资了个新团队，没啥区别。
数据中台的特征
一直以来，企业的BI数据管理跟IT是紧捆绑的，但跟公司的战略、业务脱节非常厉害，很多企业几乎没有想过企业获取利润跟数据管理有多少直接的关系。企业有投资，有费用，反正属于IT要干的事就去干吧，大家都在做，我们当然也要做，在我刚开始做元数据管理的时候，就是这个感觉，从没想到这个东西跟企业的利润有半毛钱关系。
做了怎么样？不做了又怎么样？我们甚至连自己都骗不过。直到开始做大数据，当商务、开发必须紧密衔接的时候，当发现某个数据问题已经导致变现困难的时候，才感觉到数据管理的真正价值，才知道自己的数据管理工作该干什么。
这是我以前的困惑。
自己不止一次的提到过：IT是业务的后端，而数据是后端的后端，数据要往前走面临着巨大挑战。DT时代给了我们一次机会，但有了势，没有方法和举措，你也抓不住，还好，我们有数据中台为自己正名。
但十多年前数据仓库如火如荼兴起的时候，为什么它就不能称为数据中台？为什么数据仓库就不能更好的创造价值？
笔者认为数据中台起码有三个特征，是传统的数据平台很难兼顾的：业务化、服务化及开放化。业务是根本，服务是手段，开放是价值，而数据中台把三个都占全了。
那么，实时的数据中台怎么做？
下面是实现实时数据中台的一种逻辑架构，方便你去理解，其实最关键的是实时模型那一层。
1、实时接入
不同类型的数据需要不同的接入方式，flume+kafka现在是标配，其他还有文件、数据库的DSG等等技术。比如运营商就有B域的订购、通话，O域的位置、上网等各类实时数据。
2、计算框架
这里只列出一种，基于Kappa架构实现实时/离线一体化业务开发能力，相对于传统Lambda架构，开发人员只需面对一个框架，开发、测试和运维的难度都相对较小，且能充分发挥Flink流式计算框架一点执行、高吞吐、毫秒级响应、批流融合的特点。
比如将流计算组件划分实时数据切片，批处理组件提供离线数据模型（驻留内存），两类数据在处理过程中实现批流关联。
3、实时模型
跟数据仓库模型一样，实时模型肯定首先是面向业务的，比如运营商有流量运营、服务提醒、竞争应对、放好拉新、厅店引流、语音消费、运营评估、实时关怀、实时预警、实时洞察、实时推荐等一系列的实时场景，你总是要基于你的实时业务提炼出具备共性的数据模型要素。
比如放号拉新中的外来务工实时营销，其中可能的触发场景是针对漫入到某个交通枢纽并驻留10分钟以上的用户进行营销投放，“在某个位置的驻留时长”这个公共要素可能就是一种可复用的实时模型。
实时模型纵向可以划分为DWD和DW两层，DWD模型做的其实是针对各类实时数据做命名的标准化和过滤字段的操作，方便进行数据的标准化管理，DW模型这里分成了三大类：动态模型、事件模型和时序模型，每种模型适合不同的场景，同时需要采用与之适配的存储格式。
动态模型：对实时的数据进行汇总统计，适合做实时的统计指标分析，比如实时的业务办理量，一般可存储于Kafka和Hbase。
事件模型：把实时的数据抽象成一系列业务事件，比如从位置日志轨迹中记录用户的位置变更事件，从而可以触发LBS的位置营销，以下是典型的位置事件模型设计，一般可存储于MQ和Redis：
你也可以设计滑动窗口模型，比如保存最新一小时的分钟级的滑动窗口位置信息：
时序模型：主要保存用户的在线的时空位置等信息，可以基于业务场景需要进行各种快速的计算，比如非常方便的计算驻留时长，存储于Hbase或TSDB（时序数据库）：
4、实时服务
有了实时模型还不够，数据中台还需要提供图形化、流程化、可编排的数据开发工具，才能真正的降低实时数据开发成本。但由于离线和实时数据处理的技术手段不同，导致针对这两种类型的数据开发和管理大多是在不同的平台承载的。
比如以前我们的离线数据模型是通过DACP平台管理的，但实时数据则游离在DACP平台之外，其往往属于应用本身的一部分，应用需要通过编写特定脚本去消费和处理流处理引擎中的原生数据，这种处理的门槛不仅高，而且资源浪费也挺严重，每个实时应用其实都是流数据的孤岛。
站在应用的角度看，业务其实需要的是一个统一的数据开发管理平台，离线和实时数据应作为统一的对象进行管理，比如具备混合编排，混合关联等能力，用简单的类SQL定制化输出应用所需的各类数据，从而高效的对外提供实时/离线数据服务。
5、实时应用
这块讲的东西就有很多了，后续会慢慢讲，想看的话转发加收藏，人数够了就开始写。
总结
1.中台化还是要遵循“具体问题，具体分析”的道理。没有放之四海而皆准的中台化策略，有的业务就不需要中台化，有的中台化反而会适得其反。有的公司压根就只有一个业务，或者有几个业务都没有重复造轮子的现象，那硬去学习阿里的中台，一定是东施效颦了。看阿里谢纯良的采访，包括我跟阿里的朋友了解到的，阿里的中台也是“痛极思变”的过程，在跌跌撞撞中成长的，不是老板一声令下就全部到位的。
2.中台化的目标都是降低成本，分两种：第一，现存业务之间重复造的轮子合并，降低成本；第二，为某些业务尤其新业务提供能力，可以低成本快速试错。
3.对于有的大公司，中台化不是个技术问题，反而变成了组织问题，就是各业务线要不要接受别人提供的东西，还是我就要自己做；以及对于新业务来说，能否得到老业务既有能力的支持。
4.对产品经理和运营来说，一定要加入可以业务自闭环的团队，不要加入纯支撑的中台团队。离业务远会很容易成为“鸡肋中台”。比如在许多公司，基础服务的中台，压根是没有产品和运营这样的业务岗的，都是技术。