中台的分类及实时数据中台构建

中台的种类

1.技术中台（基础服务中台）

技术中台指的是将大家都通用的技术能力聚合到一起，由同一个团队负责，防止重复造轮子，是最容易实现的中台化。核心价值是降成本。
各公司的基础服务，以账号体系为代表，都已经是中台化的了。淘宝、天猫、飞猪等业务之间，快车、专车、顺风车等业务之间，美团外卖、酒旅、团购之间，必然要做打通。

2.数据中台

顾名思义，表面上数据中台是各业务的数据能够打通。不过在实际运用中，又分为多种。
数据中台的本质就是“数据仓库+数据服务中间件+实时性”。
基本的数据采集、数据仓库建立和数据分析能力的共享，其实是数据技术中台的范畴，是将做数据相关工作的技术团队整合，来支持各业务。核心价值是降成本。
各业务线的数据打通、数据共享和协同运用，则属于业务中台的范畴，是以业务目标牵头的（比如阿里的88VIP会员的前提就是用户数据打通）。
有时这两者是耦合在一起的，既有技术能力的共享，又有业务支撑。不过在国内数据分析的认知还比较浅（认为数据都是拉报表的），后者往往效果不佳。前者在不少互联网公司倒是确实落地了。
在有些公司，数据中台只是很粗浅地把数据整合到一起，并没有解决任何问题，或者让整合产生什么价值。阿里云中间件架构总监谢纯良曾经说过，许多公司的数据中台就是把数据加工成“大屏”，搞一个展示用的“大屏”就以为实现了中台。意思就是，数据中台如果不为业务服务，或者说为业务中台服务，那就没有价值。

3.业务中台

既然技术模块可以抽象出来复用，那业务模块是不是也可以？在淘宝时用过的营销策略，能不能直接挪到飞猪用？专车的策略能不能直接给快车用？这就是业务中台的概念。
很显然的，由于业务存在更高复杂度，因此难度更大。
业务中台是各大公司追求的最终效果：前台业务敏捷推进，后台业务稳固支持。不过真实情况往往事与愿违，难尽人意，真正做到业务中台运转良好的，很少见。

4.组织中台

组织中台是嫁接在前三种中台基础上，再加入“放权机制”的中台结构。
阿里的中台业务支撑能力可以支持新的电商相关业务快速创新；字节跳动把增长能力中台化，头条的增长部队可以快速投入到抖音中去，甚至可以投入到海外各个国家各个产品；美团有试错小团队，会利用既有的技术能力、用户流量等资源快速试错，找到新的方向，包括外卖在内都是这样来的。
这些都是组织中台的体现。组织中台与其说是中台能力，倒不如说是内部创业的空间。它的核心价值应该在于“旧业务能否帮到新业务”，很考验组织能力。有的公司内部创业，封闭隔离，跟这个公司自己投资了个新团队，没啥区别。

那么，实时的数据中台怎么做？

下面是实现实时数据中台的一种逻辑架构，方便你去理解，其实最关键的是实时模型那一层。

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定制化输出应用所需的各类数据，从而高效的对外提供实时/离线数据服务。