基于实时计算Flink版的场景解决方案demo

简介：通过两个demo分享技术实时计算flink版的解决方案

本文整理自阿里云智能行业解决方案专家GIN的直播分享
直播链接：https://developer.aliyun.com/learning/course/839

本文主要分享两个基于 Flink 制作的实时大数据的应用。为了更好的体现应用的价值以及它所代表的典型的场景，这次的分享定制了两个接近现实生活中的应用案例。

第一个是如何去做实时的 API 应用服务日志的分析，第二个是采用模拟的 IoT 遥测数据去分析车辆的引擎，并且做实时的异常侦测，以达到做预测维护的一个目的。

实时应用日志分析

场景描述

第一个场景的需求是比较普遍的，这个场景搭建了车辆隐私保护的API。这个API本身是可以对用户上传的车辆的照片进行一个隐私保护的处理，是一个深度学习的模型。

这个模型被封装成一个API，放在阿里云的公共云ECS上，供全世界各地的用户去访问。针对这个API首先需要做的就是去分析到底有多少人在访问他的反馈的频度，来自哪个国家或地区，以及他的访问的一些特征，是否为攻击或者正常的利用？

为了做这个实时的分析，首先需要有能力对各个API分散在各个服务器当中的本身的应用日志去进行海量且实时的一个收集的行为。不仅能收集我们，我们还要能够对它进行一个比较及时的实时的一个处理。处理包括可能有维度表的查询，有些窗口的聚合等等，这对流式计算来说比较常见的操作，最后把这些操作处理完的结果放在高吞吐低延迟的一个环境里边，使得下游的分析系统能够对数据进行一个实时的访问。

整个这个链路并不复杂，但是它代表了一个非常重要的能力，也就是通过使用 Flink 为代表的实时计算和处理，能够在秒级的单位内给业务决策人员提供一个数据驱动决策的功能。

Demo方案架构

具体来看一下这个demo是如何实现的，这里边的这个架构里边有几个重要的关键。

首先右上方是搭建好的API的环境，用的是Flask、 Pytho结合比较主流的Nginx、Gunicorn把它制成了一个API 。需要把API变成一个容器镜像，并且通过镜像将它部署到阿里云的ECS上面，为了高并发低延迟，还装了第七层的负载均衡，以及前面套了一个API Gateway网关去帮助用户去调用API的能力。

同时作为这个demo，我们也提供了一个 WEB APP ，使得用户不仅能通过代码去调用 API ，也可以使用图形化的界面去访问API 。当前端的用户去调用API 的时候，会使用SLS 简单日志服务去从API 本身的服务器当中收集实时的收集API 的应用日志，并且将它做简单的处理之后，投递到实时计算Flink中。
Flink 有个很好的一个特征，就是它可以去订阅来自简单日志服务的日志的投递，并且以流式计算的方式对这个日志进行窗口聚合维度表的查询结合等等这些操作，还有一个好处是它可以用习惯的SQL去做比较复杂的业务逻辑的定制。

当这些数据都处理完了之后Flink 就会把流数据以结构化表的方式写到Hologres，Hologres不仅作为数据的一个存储，也同时作为一个给下游 BI 数据展现提供动力的类似OLAP的引擎的性质。这些东西串起来，形成了本次的大数据实时日志采集分析的一个架构。

方案解析

具体来看一下，每个部件是如何使用的。

使用车辆隐私 API 作为实时分析的数据源
通过WEB APP可以允许用户非常简单的去上传自己的车辆的照片，API 会对他进行一个模糊化的处理。录屏中可以看到这张照片交由API 处理之后背景被虚化了，并且车牌的部分还有隐私信息的部分也被遮挡了。

SLS 日志中心
当有用户去访问这个API 的时候后台简单日志服务就会对他进行一个实时的采集。

日志采集之后会使用Log tail 的转换数据加工的能力，对原始的日志去进行一定程度的解析和转换，其中就包括将IP地址解析为例如国家城市纬度精度等这样的地理信息，方便后续做下游的分析的时候可以调度这些信息，除了简单的一些服务还提供一个非常强大的图形化的数据分析的能力。

实时计算Flink版
在这里可以做一个初级的数据分析的，或者是数据勘察的功能，可以看到原始日志的转换是否满足下游业务支撑的一个需求，当日志被采集转换处理完之后，会通过Log Hub将这个日志投递给流处理中心，也就是实时计算Flink 。

其实用投递这个词并不是特别的精确，实际上是Flink 主动去订阅，在Log Hub 里边存储的Log Store 的这些处理过的日志的信息。Flink 有个非常好的地方，可以用常见的SQL去写编业务逻辑，包括转换处理一些逻辑条件。当SQL写完后只要点击上线，就可以包装成一个Flink的job ，并托管在Flink 的cluste里边，集群里边，通过这个控制台可以非常方便的访问。

那么现在的plus的集群的使用程度频度如何？CPU 如何，有没有异常，有没有报错，包括查看整个交付的情况等等，可直接通过Flink 托管，这是一个非常大的优势，几乎不用去为运维操心。

Hologres (HSAP)

Flink 处理完成，这个流数据通过 Flink 提供的接口，可以使得处理完的流数据，以一种类似于表格结构化的方式直接写入到我们的存储系统Hologress里，Hologress有一个特别大的特征就是它既是OLTP，也是OLAP。

具体来说既可以把它拿做OUTP去快速的写入，同时也可以对被写入的数据同时进行一个高并发的低延迟的查询分析。也就是常常说的OLAP引擎的能力，他把两者合并为一块，所以Hologress 也被称为HSAP。

DataV Dashboard
在本次的架构当中，它主要用来把处理完的数据展现给下游，也就是终端用户，终端的业务决策人员可以看到消费的实时的大屏。

这个实时的大屏会随着API 被访问，以秒级的延迟，把最新的信息处理完的信息给反映。在这个datav的实时大屏上，这样的话可以很大程度上减少决策人员看到数据时产生的延迟。

如果采用的是传统的那种批处理的方式的，那么每次处理可能要上TB级的数据，而且处理时间长达数小时。如果采用以flink 为核心的端到端的实时计算的方案的话，这个延迟就能从几个小时被压缩在几秒甚至是一秒以内。

车辆引擎实时预测维护

场景描述

第二个业务场景是结合IoT通过模拟的遥测数据，分析判断马路上行走的车的引擎是否展现一些异常的证照，可以提前判断是否可能存在问题，如果放任不管的话3个月之后可能某个部件就要坏了，这也是一个在实际应用场景当中经常会被提到的一个需求，我们称之为预测性的维护。预测性维护在实际的应用场景当中，可以帮客户方省下大量的金钱，因为当东西已经出现问题在进行修复，肯定不如在损坏之前提前给替换来的有效。

Demo方案架构

为了实现这么一个比较接近真实世界的场景，调研了解了在车载设备当中有个叫OBD II的这个诊断系统，它里边经常包含的经典数据，把这些数据采集了一部分过来对它进行加工、模拟。写了一个程序，模拟一个比较真实的在现实环境当中运行的车的引擎的一个数据。

当然本次因为不太可能真的让一辆车在马路上开，所以有了这个模拟程序，利用各种各样的统计分析的手法去模拟生成这样的行车数据，尽可能达到真实的效果。

这个程序会把模拟的行车引擎遥测数据把它给投递到Kafka ，然后通过实时计算Flink 消费订阅Kafka的Topic ，然后根据每个Topic进行不同的流式计算。结果的一部分将它归档在 OSS ，把它存储下来就有了历史数据，另一部分作为热流数据源直接投递给开发的异常侦测的模型，把它部署在PAI EAS上面，通过 Flink 可以直接去调用。

然后做了这个机器学习的判断后，再去看现在当下的这个引擎的数据有没有异常的征兆，再把这个结果写入到数据库里边，供AB进行一个进行一个进行一个消费。数据通过实时计算Flink做了实时的处理之后，一部分的数据把它归档到了OSS里。

这部分数据实际用来作为历史数据去建模，甚至是重新模型。因为每隔一段时间可能行车的这个特征万一发生了一些变化，俗称Data Drifting ，那么又可以用新产生的历史数据去对模型进行重新的训练，重新训练完的模型又可以把它作为 Web Service ，把它部署到PAI ES上供Flink 去调用，这样的话就完成了一个Lambda 架构的大数据解决方案。

方案解析

生成模拟行车数据

首先需要做模拟数据生成的工作，去把引擎的遥测数据OBD的数据把它给模拟出来，投递到这个云上去做分析。这边采用的是函数计算，函数计算非常的方便。它首先是一个托管服务，它是一个service 的服务。

其次可以把Python的脚本从本地开发好的脚本直接照搬copy配置到这个函数计算里边，利用这个托管的计算去执行这个模拟数据生成的这么一个程序脚本，非常的方便。

在本次demo当中采用了每一分钟执行一次函数计算，也就是生成一个批次的遥测数据，然后每次生成间隔3秒投递一个数据到Kafka里边去尽可能去模拟一个真实环境当中的这个数据产生的一个频度。

收集/发布行车数据

Kafka也是一个常用的大数据的Pub/Sub的一个系统，它非常的灵活，扩容性非常的棒，在阿里云上的Kafka，可以在EMR 里边自建一个Kafka集群，也可以使用叫Kafka on MQ的一个托管服务，来搭建一个完全service 。

这是个kafka系统，本次demo 为了方便就采用了kafka去搭建了一个托管式的 Pop Subject System ，这System 其实只是用来囤积前方生成的，也就是车辆投递过来的这个引擎的数据，那么在实际的生产环境当中车不可能是一辆，甚至肯定是几万辆，几十万辆都有可能，采用kafka的话就可以非常方便的去扩容。不管前端的车有10辆还是10万辆，整体架构都不需要做太大的改变，可以从容的应对这些扩容的弹性的需求。

实时计算和异常分析模型调用

实时计算的部分，仍然采 Flink 的这个实时计算系统，只不过在本次demo当中使用用的是 Blink 的独享集群，也就是所谓的半托管式的这个实时计算的平台。其实跟刚才在上一个场景当中的全托管使用方法几乎是一模一样的。

只不过在制作这个demo 的时候，一部分的区域还未上线Flink 全托管版本，所以选择了一个叫Blink 独享集群的服务，同样也是挂在实时计算的这个家族当中，用起来的方法几乎跟全托管是一模一样的，开发人员也只需要focus 在写这个脚本去做业务逻辑的处理，点击上线，剩下的基本上就是完全由Flink 代为管理，只需要去监控看有没有异常的出现，包括做一些调优等等的工作，非常的方便。

那么在这边值得一提的是把PAI-EAS的这个模型调用的接口嵌入到了Flink 里边，使得Flink 在实时处理流数据的时候，同时也可以把一部分的数据扔给PAI去做模型的这个推论，得出的结果再和实时流数据合并起来，最后一并写入到下游的存储系统里边，体现了Flink计算平台的一个延展性和扩容性。

异常检测模型的开发

这部分展现如何用一个图形化的学习平台去设计开发一个非常简单的二元分类模型。

这个二元分类模型主要就是从过去引擎的历史数据当中，学习哪些特征会被用来判断为引擎有问题，哪些是是比较属于正常的这个数值。通过这个模型，就有依据可以用来对未来新产生的引擎数据进行一个判断，这样有助于业务人员提早去预知目前引擎的数据问题。

模型部署和调用服务

因为模型从过去已经学习到了相关的特征以及这个Data的pattern。这个模型的开发整个过程用的studio ，完全是拖拽搭建，几乎没写过一条代码，非常的方便快捷，完全可以通过纽扣来实现一个模型的开发。更好的一点在于当模型开发完了之后，通过PAI可以一键部署把它包装成一个rest API 和Web Service 放在PAI的平台上去供用户去调用。一键部署之后，对这个部署完的模型的服务进行一个测试调用，非常的方便。

高吞吐结构化数据存储 (RDS)

当模型部署完成，可以通过Flink 让他判断有没有异常这个流数据进行实时的处理之后，最后把它写到了一个MySQL 的数据库里边。

这个数据库就会作为数据源去给下游的实时大屏提供一个数据的支撑。这样的话业务人员就可以实现实时也就是隔几秒的这个状态就能看到目前在路上跑的这个车到底有没有问题？

Near Realtime Dashboard

通过这个链接： https://datav.aliyuncs.com/share/9fff231ff81f409829180ee933e7bcee 可以打开这个实时的大屏。

data v 的大屏是预设每5秒更新一次，也就是说每5秒就会从数据库当中把最新的预遥测数据，包括这个判断有没有异常的数据，把数据展示在大屏上。

红色代表的是这个时间点采集上来的数据，代表是有问题的，那么蓝色就代表normal，也就是比较正常的数据。这个数据的正常标准，完全是由之前产生的模拟数据function computer 去在控制。因为在function computer 逻辑里边人为加了一些会让引擎看起来出错的这种数据，使得这个demo 的不正常的部分体现的更多一点。

以上就是本次分享的2个demo，感兴趣的同学可以使用实时计算Flink版搭建自己的应用。

原文链接：https://developer.aliyun.com/article/789208?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。