1.2 案例分析

1.2.1 SK电信驾驶安全性评分

SK电信是韩国的移动通信运营商，T map是其手机导航App，类似于我国的百度地图和高德地图。这款App可对用户的驾驶安全性（超速、加速、减速）评分，汽车保险公司根据这个评分计算保费。T map的Driving score功能，如图1-8所示。

1.批处理架构

在行驶过程中，车辆的GPS位置（经度、纬度、海拔）信息由App实时上传至后台服务端。其中，GPS一分钟定位一次，App将五分钟内的位置信息打成一个数据包上传。

最初，系统采用批处理架构，GPS位置信息被定期抽取到Hive数据仓库中，计算Driving score的ETL（Extract Transform Load）批处理程序由Oozie调度执行，频率为每天两次，评分结果在第二天返回用户。从传统金融领域到电信领域，从零售领域到物联网领域，这种数据处理系统已经成为标配架构。但是这种 T+1处理架构的缺陷也很明显，即用户体验较差、决策反应速度较慢。Driving score批处理系统的架构如图1-9所示。

因此，SK电信将上述批处理架构重构为基于消息的流式数据处理架构，提供实时Driving score服务。

2.流式数据处理架构

笔者以12分钟一趟的驾驶为例，分析流式数据处理架构设计面临的问题及其解决方案。

App端将每5分钟内的300个GPS位置信息以JSON格式打包发给后台服务端，按照定位时间先后顺序，以a、b、c、d命名这4个数据包，系统在接收数据包d后立即返回Driving score。在计算机术语里，这12分钟一趟的驾驶称为session （一次会话）。针对这种应用场景做如下分析。

（1）乱序是常见情况：数据包 d不仅包含 GPS位置信息，还包含 session结束标志信息。即使系统能保证数据包在App端的上传顺序，也不能保证数据包到达处理节点的顺序，因为后台服务系统的分布式特性可能会导致数据包乱序，如计算Driving score的处理程序可能先收到数据包d，隔一段时间才收到数据包c。（2）窗口机制：在很多应用系统中，开始与结束标志信息并不存在，数据处理程序需要根据应用系统的领域知识推定。因此，什么时间点计算 Driving score是流式数据处理架构设计的关键点，这个关键点在流式数据处理架构理论中被称为窗口机制。

（3）松耦合：在企业级IT架构中，数据处理系统和业务逻辑系统通常是分开的，数据部门负责数据处理系统的开发与维护，软件开发部门负责业务逻辑系统架构的设计与程序开发。但是，由于数据处理系统的数据来自业务逻辑系统，这两个系统不可避免地会存在一定的耦合。并且，如果数据处理系统涉及底层软件模块，数据部门就需要将相关开发工作委托给软件开发部门，但复杂的数据需求实现流程、不同的技术栈带来的需求理解偏差等因素，将导致数据从软件开发部门到数据部门的周期过长，这是另一种耦合，因此流式数据处理架构需要松耦合设计。

基于以上分析，流式数据处理系统的前端部署分布式消息系统 Kafka，直接串接在 GPS 位置信息的传输通道上，Source 节点从 Kafka 订阅 GPS位置信息，并将JSON格式解析后的信息推送到时间窗口节点（Time&Window）处理，Sink节点将处理的结果信息写入Kafka，Kafka负责持久化或对接到下游系统。Driving score流式架构的逻辑模式如图1-10所示。

在图1-10中，每个处理节点只有一个实例，这是流式数据处理系统的逻辑模式。流式数据处理系统是分布式计算系统，因此在实际执行过程中每个相同功能的节点都会有多个并行实例对应于物理部署模式，如图1-11所示。

在物理部署模式中，每个Source节点实例会和所有时间窗口节点实例相连，这样同一个 session 的 GPS 位置信息可以被同一个时间窗口节点实例处理。数据处理“一直”在运行，而不是定时运行的（批处理采用定时触发运行机制），从而规避了T+1处理架构的缺陷。

在物理部署模式中，我们还观察到4个数据包的顺序为a、b、d、c，而不是按事件发生的顺序a、b、c、d。下面介绍解决上述数据包乱序问题的三种窗口机制。

1.设定固定时间间隔的session窗口

在时间轴上，两趟驾驶不会出现重叠，即两个活动session之间会有一定的时间间隔，可以通过数据分析的方法计算这个间隔的合理值（不一定是最小值，可参考1.4节和1.5节的内容），例如1小时。如果时间窗口节点实例在接收d之后的1小时内没有再观察到新的GPS位置信息数据包，则系统可以在这个时间点上返回Driving score。这种窗口机制很简单，但是仍需要等待1小时才能得到结果。

2.设定session的事件推进标志

流式数据处理架构使用水印来推进事件时间，即Source节点或业务逻辑系统在 GPS 位置信息流中定期插入时间推进控制信息，用于表明某个时间点之前的GPS 位置信息数据包均已接收完毕，这样时间窗口节点能够实时计算 Driving score。从这层意义上看，水印是流式数据处理系统中事件流转的同步信号。虽然这种窗口机制的用户体验好，但是需要深刻理解应用领域知识，生成水印的代价较高，特别是，当企业级业务系统有多个关联子系统时，设计水印异常复杂。

3.触发器实时生成近似结果

对数据部门而言，深刻理解应用领域知识，特别是深刻理解应用系统架构知识的代价较高。为此，流式数据处理系统提供触发器机制以实时生成近似结果，即数据处理系统行先计算出正常的session结束时间点，并在这个时间点上实时计算出Driving score，如果之后观察到属于这个session的迟到的GPS位置信息数据包，那么时间窗口节点会撤回之前的结果并生成新的 Driving score。这种窗口机制广泛应用在一些对实时性要求比较高的数据处理场景中。

1.2.2 流式机器学习应用

1.线下训练模型、线上实时抽取特征

在机器学习中，求得一个与训练数据集相吻合的函数的过程被称为数据拟合，也被称为曲线拟合。下面是用Python语言编写的多项式拟合程序：

这种机器学习算法根据训练数据集（train_x，train_y）的八次多项式特征（Feature）训练线性回归模型（Model）。在模型应用于线上预测时，流式处理系统从实时数据（x）中抽取特征（quadratic_featurizer.transform（x）），模型根据抽取的特征输出预测值（y）。

这种以 Feature 和 Model 为核心组件，线下训练模型、线上实时抽取特征的机器学习方法在传统金融安全等领域有着广泛的应用。其中，反欺诈是金融机构IT 团队面临的主要挑战之一。欺诈的形式从 App 签名漏洞、ATM 盗刷分离器、网络仿冒到恶意商业间谍 APT（Advanced Persistent Threat，如“银行大盗”Carbanak木马可命令受感染的ATM直接吐钱），欺诈的规模从个体犯罪逐步演变成有组织的犯罪。为了应对不断升级的欺诈手段，金融机构的应对措施也从最开始的手动检测、规则检测，发展到基于监督学习的模型检测、基于非监督学习的异常检测。

考虑到安全形势的严峻性、金融业务的复杂性及分支机构的跨地域性，反欺诈系统可以采用线下训练模型、线上实时抽取特征的机器学习方法。为了便于共享与分发，通常采用PMML的方式定义线上机器学习模型的需求，如图1-12所示。PMML（Predictive Model Markup Language，预测模型标记语言）利用XML描述和存储数据挖掘模型，是一种在不同应用程序之间快速共享模型的可选方案，已经被W3C所接受。PMML中定义了数据挖掘不同阶段的相关信息：头信息（Header）、数据字典（Data Dictionary）、挖掘模式（Mining Schema）、数据转换（Transformation）、模型定义（Model Definition）和评分结果（Score Result）。

2.实时机器学习

随着电子商务的高速发展，互联网电商平台的数据呈爆炸式增长，其存量数据可达EB（Exabyte，艾字节，1EB=1024PB）级，每天增量数据可达PB（Petabyte，1PB=1024TB）级，这会带来巨大的模型训练计算量。

反向传播算法（详细分析参见第 4章）是深度学习模型训练的通用算法，如果进行全量样本训练，则每次训练需要计算所有样本的损失和，再进行梯度运算，计算开销太大，很难进行在线学习；如果进行单样本训练，那么每次训练只计算每个样本的损失与梯度，但是整个模型训练的收敛速度和泛化效果都不理想。

我们先将样本数据分成多个微批（microBatch）数据集，然后在每个微批数据集上进行梯度运算。下面的代码片段是使用TensorFlow实现Word2Vec的例子：

此外，电商数据的特征并不平稳，如“双11”时商品的价格、活动的规则与平时完全不同，通过历史样本数据训练出的模型往往不能拟合出让人满意的结果，图1-13概括了这种非实时机器学习方式的特征。

实时机器学习是电商应用的合理选择：线上实时特征抽取，采用微批方式实时训练模型。图1-14展示了阿里巴巴实时机器学习模型的架构。

图1-14中的上半部分为实时抽取数据特征的过程，下半部分为实时训练的过程，这样整个系统可以根据实时特征更新模型参数，并将更新后的模型部署到线上。