为什么企业要从离线数据中台走向实时数据中台？

这是傅一平的第291篇原创

作者：傅一平

个人微信：fuyipingmnb

笔者讲过很多次数据中台，数据中台的计算载体包括hadoop、MPP以及流处理引擎，但你会发现这三类计算载体承载的数据内涵是不一样的。

Hadoop、MPP中的数据模型往往是精心打磨的离线数据仓库模型，无论是维度建模还是关系建模，其强调数据模型的复用，并且通过建模屏蔽了底层数据的差异，从而高效率的支撑上层应用。

但流处理不一样。

在大多数企业内，流处理还仅仅是个技术引擎，往往没有所谓的数据仓库建模的概念，在实践中每建立一个实时应用，都需要对原始的流处理数据进行一次消费计算。

其实这本身没有问题。

但随着大数据应用的深入，实时化，场景化成为很多企业营销的新常态，比如以前运营商校园营销大数据做的是就是离线定位目标用户，但近几年针对漫入、驻留学校的学生进行实时服务逐步成为了必需品。

现在大家都急着在为大数据找场景，实际上，你只要把传统企业内任何一个离线营销的场景增加一个实时的维度，就有可能创造新的价值点，这是传统企业大数据赋能业务低垂的果实。

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

站在应用的角度看，业务其实需要的是一个统一的数据开发管理平台，离线和实时数据应作为统一的对象进行管理，比如具备混合编排，混合关联等能力，用简单的类SQL定制化输出应用所需的各类数据，从而高效的对外提供实时/离线数据服务。

5、实时应用

数据中台如果能支持实时数据的快速编排，根据我们的测算，其实时场景应用的数据开发、测试、部署周期会由0.5-1个月降低为1-2天，效益是很高的。

对于运营商来讲，由于其实时数据足够多，场景足够丰富，建立实时数据中台的必要性还是非常高的。

笔者记得3年前当我们开始搞校园实时营销的时候，总是要提前3-6个月时间去做实时应用的规划和建设，然而每年需求都要改，然后应用就得推倒重来，而且没有任何知识留存下来。

随着大数据内外运营的深入，我们发现这种需求越来越多，你会惊奇的发现，很多时候需求是随着你技术能力的加强而增加的，很多时候，技术就是第一生产力。我们很多负责变现的产品、运营经理应是深有体会的。

从那个时候起，笔者就想着，我们能否建立一个真正的实时数据中台，能够快速高效的创建海量的实时应用，从而将大数据的管理和应用水平提升到一个新的阶段，终于我们现在走到了这条路上。

希望我的分享于你有益。

完

作者：傅一平 （微信号：fuyipingmnb）

---

可能错过的近期精选文章（点击链接即可阅读）

---

一起成长，让我们与数据同行

忙完工作，偷得浮生半日闲，讲述自己的数据人生

大叔/电信博士/500强央企/大数据/人工智能/统计取数/数据挖掘/数据产品/数据管理/数据仓库/数据变现