如何从0开始，搭建企业的实时数据中台？ _数据中台

笔者之前讲过很多次数据中台，数据中台的计算载体包括hadoop、MPP以及流处理引擎，但你会发现这三类计算载体承载的数据内涵是不一样的。
现在大家都急着在为大数据找场景，实际上，你只要把传统企业内任何一个离线营销的场景增加一个实时的维度，就有可能创造新的价值点，这是传统企业大数据赋能业务低垂的果实。
【如何从0开始，搭建企业的实时数据中台？】但现实情况是实时应用的场景实现门槛有点高，假如你这个企业不能用简单的SQL快速的实现一个实时场景应用，还需要用3-6个月去完成一个实时应用项目的建设，那么很多探索或创新就没了。
很多公司的大数据平台三大技术组件hadoop、MPP以及流处理很多年前就具备了，但为什么实时应用就没法做到像取数那样的百花齐放？
因为诸如IBM STREAM等各种流处理引擎有一定的开发门槛，比如几年前我们的数据团队甚至没有一名流处理开发人员。
我们企业要能大规模的使用实时数据，就必须建立起实时的数据中台，让开发实时应用数据简单到就像写一个SQL 。

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

文章插图

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平台之外，其往往属于应用本身的一部分，应用需要通过编写特定脚本去消费和处理流处理引擎中的原生数据，这种处理的门槛不仅高，而且资源浪费也挺严重，每个实时应用其实都是流数据的孤岛。