G7 在实时计算的探索与实践

G7 主要通过在货车上的传感器感知车辆的轨迹、油耗、点熄火、载重、温度等数据，将车辆、司机、车队、货主连接到一起，优化货物运输的时效、安全、成本等痛点问题。

整个数据是通过车载的传感器设备采集，比如公司的 Smart 盒子，CTBox 盒子，油感设备，温度探头等，将车辆数据上报到后端平台，在后端平台计算和处理，最后展示到用户面前。

G7 的业务场景是典型的IoT场景：

• 传感器数据

• 数据种类多

• 数据质量差

• 数据低延迟

• 数据量大

其中，数据质量差的原因是整个链条会非常的长，从传感器采集的车辆的数据，通过网络运营商将数据上报到后端服务器，再经过解析， MQ ，过滤，调用三方接口，业务处理，入库，整个过程非常的长，造成数据在传输过程中出现数据重复，数据缺失等。另外一点，IoT 场景需要数据传输的延迟非常低，比如进出区域报警，当车辆进入到某个电子围栏中的时候需要触发报警，这个时候需要快速产生报警事件，通常不能超过 30 s，否则时间太长车辆已经通过了某个电子围栏区域再报警就没有价值了。再一个，数据量也是非常大的，现在每天产生轨迹点 20 亿+，每天产生数据量 100 亿+，对计算性能的要求非常高。

2.实时计算选型

从上面的场景我们可以感知到，在 G7 的 IoT 场景需要的是一个低延迟，处理速度快的实时计算引擎。最开始我们的一些架构是基于 Lambda 架构的，比如轨迹点计算，会使用实时计算引擎计算出实时数据，这份数据延迟比较低，但是数据不是很准确，另外需要用离线批量再计算一遍，这份数据通常比较准确，可以用来修复实时数据。这样做的缺点也比较明显，一是程序需要维护两套代码：实时程序和离线程序，二是实时数据不准确，准确的数据延迟又太高。后来我们惊喜的发现一种基于实时处理的架构体系 Kappa。

Kappa 的架构是强调数据的实时性，为了保证数据的实时性有些延迟太多的数据它会建议丢弃，所有的计算逻辑只有在实时计算中，整个计算只有一套逻辑，数据从 MQ 中获取，经过数据处理层计算和加工，最后落入到数据存储层，对外提供数据查询功能。相对 Lambda 架构，Kappa 架构更加适合 IoT 领域。

针对 Kappa 架构，我们对行业主流的实时流计算框架进行了对比：

分别对主流的流计算框架：Storm，Storm Trident，Spark Streaming，Google Cloud Dataflow，Flink 做了对比。基于微批量的 Spark Streaming 和 Storm Trident 延迟比较高，从这点就不适合我们的场景。Storm 的延迟很低，但是数据一致性是 At Least once，容错机制比较复杂，流控会比较抖动，这些方面都是不太适合。其中，Flink 的一致性保证（1.4 版本还支持了end-to-end 一致性），延迟比较低，容错机制的开销是比较小的（基于 Chandy-Lamport 的分布式快照），流控是比较优雅的（算子之间的数据传输是基于分布式内存阻塞队列），应用逻辑与容错是分离的（算子处理和分布式快照 checkpoint ），基于以上我们认为 Flink 是比较适合 IoT 这个场景的。

3. G7 业务应用案例

Flink 目前在 G7 的应用场景，主要有三方面：

• 实时计算

• 实时ETL

• 统计分析

下面分别介绍下以上三个场景的使用。

3.1 实时计算

在 G7 的场景中，有很多业务都属于实时计算的范畴，比如进出区域事件，超速事件，怠速事件，超速事件，疲劳报警事件，危险驾驶报警，油耗计算，里程计算等。其中疲劳报警计算是最早开始尝试使用 Flink 来落地的。

3.2 疲劳报警业务模型

这是 G7 针对客户推出的 G7 大屏，其中风险相关的部分是根据疲劳计算得出。

根据 G7 的大数据计算，因为疲劳驾驶造成货车事故的比重占到整个事故的 20%。对疲劳驾驶进行报警和预警就显得特别重要，可以有效降低事故发生的可能性。

根据车辆行驶的里程，驾驶员行驶的里程，驾驶时长，判断是否存在疲劳驾驶。如果超过报警阀值则报警，如果在报警阀值下面在预警阀值上面则预警。报警和预警都是下发语音到货车驾驶室提醒司机。

这个业务场景中面临的最大挑战是实时性，稳定性。只有用最短的时间、最稳定的方式将告警下发到相关人员才能最大程度减少风险。

3.3 业务流程

在整个处理流程中，首先会去获取疲劳配置，根据车辆的状态信息和司机打卡信息与疲劳配置结合，判断是否出现预警和报警。计算过程中会把疲劳驾驶开始的状态缓存起来，疲劳驾驶结束的时候获取之前的状态数据，匹配成功之后会生成一条完整的疲劳事件。中间会调用一些接口服务比如 Dubbo 获取车辆的配置数据、状态数据，产生的疲劳报警则会调用下发语音的接口，疲劳事件结果也会存储到 Hbase、 MySQL 、Kafka 等。

3.4 Streaming 模型

最后开发成 Flink 的程序，从头到到尾分别由以下算子构成：消费 Kafka 算子、类型转换算子、数据过滤算子、异步调用第三方接口算子，窗口 排序 算子，疲劳处理业务逻辑算子，数据入库算子组成。

这个过程，也是踩了不少坑，我们也有一些心得体会：

• 算子表达尽量单一

• 每个算子尽量内聚，算子间尽量低耦合

• 算子打散，异步+多线程的性能发挥更好

• 单独设置每个算子单元的并行度，性能更优

• Hash 和 Balance 根据情况选择：只有需要使用 keyby 和 valuestate 地方才使用 Hash 重新分布数据。其他地方尽量使用 Balance 并且上下游并行度一致，会将 task 串联成一个线程，不会走网络 IO 性能更高

• 使用 Asynchronous I/O 调用 Dubbo 接口，Zuul，DB，Hbase等外部接口

3.5 实时ETL

有部分场景是数据简单采集、处理，入库，也就是实时 ETL，包括从 Kafka 采集数据到 HDFS、DB、HBase、ES、Kafka 等，这部分工作可以抽象成 Flink 的算子表达：Source -> Transformation -> Sink。

这部分通常可以 FlinkKafkaConumser、MapFunction、JDBCAppendTableSink 这类代码。如下：

3.6 统计分析

有部分场景需要有一些实时的统计分析，比如统计最近一小时内全国各城市，车辆总数，司机总数，疲劳事件，进出区域事件，打卡次数，点熄火事件等。这种场景，通常可以使用 Flink SQL 的做实时分析，SQL+ 窗口函数（固定窗口，滑动窗口）。代码大致如下：

4.实时计算平台开发和现状

在业务上的成功落地，我们也希望能把打造一个实时计算平台，服务各条业务线，经过差不多 3 个月的打磨，内部代号为 Glink 的实时计算平台上线，大致的架构如下：

Glink 主要由以下部分组成：

• HDFS 分布式文件系统。用来存储 Flink 任务中产生的 Checkpoint / Savepoint 数据，任务报、第三方依赖包的存储和分发，任务运行中产生的临时数据等。

• Yarn 统一计算资源平台。用来提供统一的分布式计算资源平台，任务提交，任务调度，任务执行，资源隔离功能。目前所有的 Flink 任务都是通过 Yarn 进行统一的计算资源管理。

• 性能监控 AMP 工具。使用点评开源的 Cat，在此基础上做二次开发并取名“天枢系统”。可以提供程序的耗时 95、99 线、平均耗时、最大耗时、Java GC 监控、线程监控、堆栈信息等。

• 集群监控管理。机器资源监控使用 Zabbix，提供CPU、内存、磁盘IO、网络IO、连接数、句柄监控。集群资源监控和管理使用开源 Ambari，提供自动化安装、配置、集群整体任务、内存、CPU 资源、HDFS 空间、Yarn 资源大小监控报警。

• 任务监控报警。使用 Flink 提供的 StatsD reporter 将数据上传导时序数据库 InfluxDB，通过扫描 InfluxDB 数据绘制出 task 的处理流量，通过监控流量阀值低于预期值报警。

• 诊断调试。使用成熟的日志查询系统 ES + Logstash + Kibana，通过采集每个节点的日志写入到 ES 中， 可以在 Kibana 中查询关键信息获取日志内存，提供诊断和调优程序的线索。

• Flink APP 程序应用层。具体开发的 Flink 应用程序，通常解决实时 ETL，统计分析，业务计算的场景。

• Glink 任务管控平台。将以下的功能进行封装，提供统一的任务管理，运维管理功能。

4.1 实时计算平台展示-任务管理

4.2 实时计算平台展示-日志和性能监控

平台的部分功能介绍：

• 任务管理功能。提供任务发布，修改，升级，停止，申请资源，资源审核，启动日志查看功能。

• 运维管理功能。提供日志查看，程序监控，任务监控，流量监控，异常报警等功能。

以上 Glink 实时计算平台的功能，基本上满足用户独立完成从程序开发，发布，调优，上线，运维的工作。

4.3 Glink-Framework 开发框架

除了提供相应的平台功能，还需要在 Flink 的生态上提供比较好的封装和 工具 类，因此我们提供了开发工具的脚手架：Glink-Framework 框架。

Glink-Framework 提供以下封装：

• 简化 pom 文件，减少大量的依赖、插件配置

• 三方调用集成：Dubbo，Zuul

• 三方数据库集成：MySQL，Redis

• 多环境管理

• 依赖版本管理

• 代码监测工具：Checkstyle，pmd，findbugs

4.4 平台与业务方 BP 合作方式

另外一方面，我们认为 Flink 是有一定的技术门槛，特别对于之前没有并发编程、集群开发经验的小伙伴，需要有一段时间的学习才能上手，针对这个痛点，我们提出了技术 BP 的技术合作方式。我们会根据业务的复杂度，平台指派一至多名技术人员参与到业务方的整个开发和运维工作中，从需求分析到上线落地全程参与，后期还会有持续的技术分享和培训帮助业务方学习开发能力。

4.4 踩坑

在整个平台化，以及业务开发的过程中，Flink 也踩坑不少，比较典型的 下面一些。

• 并行度太多造成 Barrier 对齐的花费时间更长，有个并行度 28 的子任务的对齐时间超过 50 s;

• Valuestate 不能跨算子共享;

• Flink 1.3 Kafka connector 不支持 partition 增加;

• 与 Spring 整合，出现 handler 匹配的问题;

• Hadoop 的包冲突造成，程序无法正常启动的问题且无异常;

其中比较有意思的是并行度太多，造成 barrier 对齐花费时间太多的问题。要理解这个问题首先要了解 Flink 在生成 Checkpoint 的过程中，会在 source 的插入 barrier 与正常消息一起往下游发射，算子中等到指定的 barrier 后会触发Checkpoint。如下图所：

这是在一个流的情况下，如果有多个流同时进入一个算子处理就会复杂一点。flink在做 Checkpoint 的时候，发现有多个流进入一个算子，先进入这个算子的 barrier 对应的那段消息就会 buffer 到算子中等待另外的流对应的 barrier 也到达才会触发 checkpoint，这个 buffer 再等待的过程称为 checkpoint alignment（barrier 对齐），如下图：

在线上运行的某个程序的一些算子因为 barrier 对齐的时间超过 50 s，造成程序  Checkpoint 超时失败。对于这个问题，我们的调优策略是两种，一是尽量减少并行度，就是让流入一个算子的流尽量少，如果在 4 个以内 barrier 对齐的时间是比较少的。另外一种方式，使用 at least once 的语义替换 Exactly once 的语义，这样 checkpoint 的时候不会去做 barrier 对齐，数据到了算子马上做 checkpoint 并发送下游。目前 我们的解决办法是根据不同的业务场景来区分，如果使用 at least once 数据保证就能满足业务需求的尽量用 at least once 语义。如果不支持的，就减少并行度以此减少 barrier 对齐的数据量和时间。

4.5 平台收益

通过近段时间的平台化建设，在”降本增效“方面的收益主要体现在以下几个方面：

• 资源利用率提高 。目前通过对整个集群的监控，在混合部署的情况下平均 CPU 利用率在 20% 左右，在某些 CPU 密集计算的业务 CPU 利用率会更高一些。

• 开发效率提升 。比如 ETL 采集程序的开发，传统开发采集数据、转化、入库大概需要 1 天左右时间，通过平台化的方式开发简单的 ETL 程序在 1 小时内完成开发。

• 数据处理量大 。平均每天处理数据量在 80 亿条以上。

• 业务覆盖面广 。平台上线业务 30+，预计年内突破 100+。服务于公司各条业务线，IoT 平台，EMS，FMS，智能挂车，企业解决方案，SaaS，硬件部门等。

5.未来规划

未来对于 Flink 的规划，我们主要还是会围绕“降本增效，提供统一的计算平台”为目标，主要聚焦在以下几个方面：

• 资源隔离更彻底。目前的资源隔离使用yarn的默认隔离方式只是对内存隔离，后续需要使用yarn+cgroup对内存和cpu都做隔离。另外会考虑使用yarn的node label做彻底机器级别隔离，针对不同的业务划分不同类型的机器资源，例如高CPU的任务对应CPU密集型的机器，高IO的任务对应IO比较好的机器。

• 平台易用性提高。平台包括代码发布、debug、调试、监控、问题排查，一站式解决问题。

• 减少Code。通过使用Flink SQL+UDF函数的方式，将常用的方法和函数进行封装，尽量用 SQL 表达业务，提高开发效率。另外也会考虑CEP的模式匹配支持，目前很多业务都可以用动态CEP去支持。

• 通用的脚手架。在Glink-Framework上持续开发，提供更多的source、sink、工具等，业务封装，简化开发。

▼ 往期精彩回顾  ▼ 

| 原理解析

Apache Flink 结合 Kafka 构建端到端的 Exactly-Once 处理

谈谈流计算中的『Exactly Once』特性

Flink 原理与实现：Window 机制

Flink 原理与实现：Aysnc I / O

Flink 原理与实现：内存管理

Flink 原理与实现：Table & SQL API

| 案例应用

OPPO数据中台之基石：基于Flink SQL构建实数据仓库

美团点评基于 Flink 的实时数仓建设实践

Flink 靠什么征服饿了么工程师？