CN116010452A - 基于流式计算引擎的工业数据处理***和方法、介质 - Google Patents

Abstract

本发明提供了一种基于流式计算引擎的数据处理***，包括数据采集模块：通过从终端采集获取原始数据后，同步编制发送端与接收端的编解码协议，从无界数据流中匹配对应的表信息完成对信息事件的采集；前置过滤模块：将采集筛选出的信息经由布隆过滤器提供的轻量级数据过滤，同步利用K‑V存储提供的海量数据过滤；数据预处理模块：流式计算引擎提供流批统一流处理，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象；数据血缘模块：通过流式计算引擎提供的SQL抽象处理，采用SQL语言编写脚本描述数据的流向，再提交到平台上解析启动作业。本发明实现了对数据价值的挖掘以及对非结构化数据的处理分析。

Description

基于流式计算引擎的工业数据处理***和方法、介质

技术领域

本发明涉及数据处理技术领域，具体地，涉及一种基于流式计算引擎的数据处理***和方法、介质。

背景技术

工业互联网是新一代信息通信技术与工业经济深度融合的全新工业生态、关键基础设施和新型应用模式，它以网络为基础、平台为中枢、数据为要素、安全为保障，通过对数据的采集挖掘、对技术的应用落地、对流程的智能改造以提升工业生产的效率。

随着工业生产的信息化以及智能化改造的推进，生产过程中产生的数据量呈指数级攀升。这些复杂数据分布于传感器设备、物联网设备、电子商务、企业通讯工具等等，具有来源复杂、非结构化、分布不均等特点，对于数据价值的挖掘以及对非结构化数据的处理分析提出了挑战。

数据源多样化会对数据集成***的连接扩展能力提出较高的要求，而分布式大数据存储***再在给业务带来更强能力的同时也释放了业务的压力，进而促使了数据量的加速膨胀。数据量级上的快速增长对数据集成平台的吞吐和实时性都需要更高的要求。当然作为数据相关的基础***，数据准确性则是基础的要求。

此外，***需要理解并整合散落在不同业务团队的数据，做好管理并确保数据访问的安全，整个流程是相对复杂的。虽然平台化能够将复杂的流程自动化起来，但数据集成工作所固有的高成本并不能完全以平台化的方式消除。因此尽最大的可能提升流程的可复用性和可控性也是数据集成***需要持续应对的挑战。

同时，流式数据现在面临需要查询持久化数据库，对底层数据库会产生压力的问题仍然未被解决。

经过检索，专利文献CN111475682A公开了一种基于超大规模数据***的智能运维平台，采用开放可扩展的数据采集底层架构，对接多种类型数据源，降低大数据采集门槛。对***内所有类型数据的全视角查看，并追踪各个数据节点的整个生命周期，共享展现各个数据节点间的链路关系。如通过***节点日志监控，实现用户、数据、作业任务、API、服务等多个维度的链路监控梳理数据血缘关系，保证细颗粒度数据和操作的可追溯，完成数据的全生命周期管理。该现有技术虽然能进行高亮显示对据及原始数据进行对比验证，确保数据的完整性和可审计性，但是还是不能解决对数据价值的挖掘以及非结构化数据的处理分析。

专利文献CN109637090A公开了一种基于SOA架构的灾害监测预警平台建设方法，解决了目前的地质灾害监测预警大多是通过人工巡查监测以及监测设备阈值报警进行预警，但由于诱发地质灾害的因素的多样性和不确定性，并且通常穿插交融着复杂的地理环境因素，对数据的管理与评价变得异常困难的缺陷。该项发明充分利用SOA架构的低耦合特点将AI预警服务更好的与监测***结合，同时利用机器学习算法处理复杂数据和精确分类的优势，在风险源的危险性评价及监测对象评价的基础上,实时监测各个监测对象的数据，预测危险区内一定时段可能发生的一系列不同强度地质灾害的等级，针对不同风险区的特点提出减少风险的各项对策，为地质灾害监测预警提供辅助决策。但是该现有技术仍然无法对复杂事件进行处理，对于流式数据中符合某种特征的模式进而触发对应的后续动作无法做到实时告警。

因此，亟需研发设计一种能够解决流式计算业务在工业智慧化改造落地时遇见的问题的***和方法。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种基于流式计算引擎的数据处理***和方法、介质，实现了对数据价值的挖掘以及对非结构化数据的处理分析，同时提升流程的可复用性和可控性。

根据本发明提供的一种基于流式计算引擎的数据处理***，包括：

数据采集模块：通过从终端采集获取原始数据后，同步编制发送端与接收端的编解码协议，从无界数据流中匹配对应的表信息完成对信息事件的采集，同时对业务字段信息进行清洗筛选；

前置过滤模块：将采集筛选出的信息经由布隆过滤器提供的轻量级数据过滤去重，同步利用Key-Value存储提供的海量数据过滤去重；

数据预处理模块：流式计算引擎提供流批统一的能力统一消息处理路径，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象；

数据血缘模块：通过流式计算引擎提供的SQL抽象处理，采用SQL语言编写脚本描述数据的流向，再提交到计算平台上解析启动作业。

优选地，数据采集模块中对信息事件进行采集时，日志文件写入时为混合格式，需要根据记录存储格式分别解析出row格式以及statement格式的记录，日志文件在流式计算引擎提交事务刷新至磁盘后才会更新至日志文件中，需要记录日志消费点位应对作业异常重启情况。

优选地，数据采集模块对无界数据流采集后，无界数据流被发往消费队列，借由消息队列提供的高吞吐处理完成对数据的削峰填谷，对于消息队列的消息主题采用多分区设置。

优选地，数据采集模块在数据的管理和获取阶段提供包括HDFS和Kafka存储支持，同时支持多并行度的消费消息队列中存储的数据，保证数据链路的消费速度不在入口处形成短板。

优选地，前置过滤模块利用布隆过滤器内置的哈希函数对数据进行去重；

-利用Key-Value存储对持有相同key的消息记录进行合并；

-采用哈希算法将key转化为整型进行存储，使其最多占用8个字节。

优选地，前置过滤模块对经过去重处理过的数据流再通过自定义业务阈值或是编制自定义过滤规则的filter算子，对不合法数据进行过滤。

优选地，数据血缘模块在开发时先定义数据库模式定义语言指定数据元信息，再编写数据操纵语言指定数据加工过程，将实时的数据流定义成实时表存储至元存储组件，用户直接从中选择需要的数据源，然后仅需要写数据操纵语言的语句即可完成作业开发。

优选地，数据血缘模块在任务提交的时候，根据上下游数据库将转化的数据库模式定义语言语句进行补充，构成完整的Streaming SQL脚本进行提交，连通批处理业务和流处理业务的开发流程。

根据本发明提供的一种基于流式计算引擎的数据处理方法，包括如下步骤：

数据采集步骤：通过从终端采集获取原始数据后，同步编制发送端与接收端的编解码协议，从无界数据流中匹配对应的表信息完成对信息事件的采集，同时对业务字段信息进行清洗筛选；

前置过滤步骤：将采集筛选出的信息经由布隆过滤器提供的轻量级数据过滤去重，同步利用Key-Value存储提供的海量数据过滤去重；

数据预处理步骤：流式计算引擎提供流批一体的能力统一消息处理路径，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象；

数据血缘步骤：通过流式计算引擎提供的SQL抽象处理，采用SQL语言编写脚本描述数据的流向，再提交到计算平台上解析启动作业。

根据本发明提供的一种存储有计算机程序的计算机可读存储介质，计算机程序被处理器执行时实现上述的方法的步骤。

与现有技术相比，本发明具有如下的有益效果：

1、本发明通过对原始数据的压缩传递，数据指标之间的定义挖掘，聚合计算使用数据的预处理，数据血缘的规范治理等，实现了对数据价值的挖掘以及对非结构化数据的处理分析。

2、本发明通过采集获取原始数据后，同步编制发送端与接收端的编解码协议，考虑到了数据传输的可靠性与传输效率，同时对周期上传的数据进行压缩以提升数据发送效率。

3、本发明通过对生产过程中的日志包含的许多内部业务字段进行清洗筛选之后，实现了提取日志消息头中携带的业务字段信息的功能，从而提供对业务日志的抽取分析能力。

4、本发明通过布隆过滤器内置的哈希函数实现数据的去重，使得运算时不需要存储数据本身，只用比特表示，因此空间占用相对于传统方式有巨大的优势，并且能够保密数据；去重算法的执行效率较高，***和查询的时间复杂度均为O(k)；哈希函数之间相互独立，如有需要可以在硬件指令层面并行计算，增加处理效率。

5、本发明在计算节点可能经由维表关联、多流汇聚导致数据结构产生变更，通过追溯数据schema的血缘关系能够对变化的数据结构提供支持。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为本发明中基于流式计算引擎的数据处理***的整体框架流程图；

图2为本发明中基于流式计算引擎的数据处理方法的步骤流程图；

图3为本发明中基于流式计算引擎的工业数据监控***的任务调度流程图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

如图1所示，本发明提供了一种基于流式计算引擎的数据处理***，包括：

数据采集模块：通过从终端采集获取原始数据后，同步编制发送端与接收端的编解码协议，从无界数据流中匹配对应的表信息完成对信息事件的采集，同时对业务字段信息进行清洗筛选。具体地：

消息中数据采集和提取都比较复杂，包括很多难点，比如如何处理传感器信号数据、如何解析数据库二进制日志文件和如何筛选生产过程中的业务日志。

在处理传感器信号数据时，从终端设备中采集获取原始数据后，需要同步编制发送端与接收端的编解码协议，考虑数据传输的可靠性与传输效率，同时对周期上传的数据进行压缩以提升数据发送效率。

在解析数据库二进制日志文件时，首先需要从无界数据流中匹配对应的表信息从而完成对信息事件的采集。日志文件写入时为混合格式，需要根据记录存储格式分别解析出row格式以及statement格式的记录，日志文件在流式计算引擎提交事务刷新至磁盘后才会更新至日志文件中，需要记录日志消费点位应对作业异常重启情况。

在筛选生产过程中的业务日志时，生产过程中的日志包含了许多内部业务字段，进行需要进行清洗筛选，实现了提取日志消息头中携带的业务字段信息的功能，从而提供对业务日志的抽取分析能力。

上述场景中涉及的设备诊断数据通过MEMS传感器采集，将湿度、温度、压力等模拟检测值转变为数字信号传输至诊断***中，在数据处理部分需要将传感器寄存器中的二进制数据重建成对分析作业有效用的数据，具体包括：

1、通过采集计算公式还原出测量值数据。

2、通过记录传感器采集的初值，在测量值中消除采集数据的零偏误差。

3、选择滤波器合理的截止频率，降低带外噪声，减小因为随机噪声信号带来的误差。

无界信息流被采集或者推送至***后，首先被发往消费队列，借由消息队列提供的高吞吐能力完成对数据的削峰填谷，从而不会因为相同采集间隔的传感器数据上传导致处理***的压力陡增。对于消息队列的消息主题采用多分区设置提高并发效率。

在数据的管理和获取阶段，提供了非常丰富的连接器组件，包括HDFS，Kafka等多种存储支持，同时支持多并行度的消费消息队列中存储的数据，保证数据链路的消费速度不在入口处形成短板。

现有的流式计算引擎包括***中使用的Flink，在目前都还没有提供对整个数据集的管理功能，本发明通过数据库接口进行了一定的扩展，将所有接入的数据源的数据信息通过数据库传递到下游。

前置过滤模块：将采集筛选出的信息经由布隆过滤器提供的轻量级数据过滤去重，同步利用Key-Value存储提供的海量数据过滤去重。具体地：

上游流程在数据采集、消息投递、格式解析等环节往往容易造成数据重复，数据重复会对于下游应用如数据监控等造成影响，除了统计UV等传统用法之外，去重的意义更在于消除不可靠数据源产生的脏数据——即重复上报数据或重复投递数据的影响，使流式计算产生的结果更加准确。

本发明实现了一个经由布隆过滤器提供的轻量级数据过滤，在上游数据源仅能保证at least once投递语义时，会导致下游统计数据偏高。

布隆过滤器通过内置的哈希函数实现数据的去重，其优势在于：

1、运算时不需要存储数据本身，只用比特表示，因此空间占用相对于传统方式有巨大的优势，并且能够保密数据。

2、去重算法的执行效率较高，***和查询的时间复杂度均为O(k)。

3、哈希函数之间相互独立，如有需要可以在硬件指令层面并行计算，增加处理效率。

但是布隆过滤器不能保证过滤的完全准确，如是需要100％准确率的场景不适用。

对于需要准确去重的场景，本发明实现了一种通过Key-Value存储特性提供海量数据的去重方式。借由诸如Flink引擎提供的RocksDB状态后端的Key-Value存储特性对持有相同key的消息记录进行合并。适合对业务数据要求很高，不容忍错误的情况。在提供了准确过滤能力的同时，需要对进行过滤过程的作业做到精细的状态管理，通过设置超时时间以及配置增量检查点等方式避免状态无限制的增长。

考虑到数据的key占用空间较大时会出现状态膨胀的问题，采用哈希算法将key转化为整型再进行存储，保证其最多占用8个字节。但由于哈希算法无法保证不产生冲突，需要根据业务场景确定是否需要启用。经过去重处理过的数据流再通过实现自定义业务阈值或是编制自定义过滤规则的filter算子，实现对不合法数据的过滤，减轻下游的计算压力。同时完成对原始数据的拆包，根据业务需要包装成所需使用的数据格式。最后为进入流式计算***的数据流记录打上时间戳，方便后续处理。

数据预处理模块：流式计算引擎提供流批统一的能力统一消息处理路径，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象。具体地：

在数据的预处理及特征工程阶段，流式计算引擎致力于提供流批统一的计算能力，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象，提高作业开发的效率。基于这些特性，相比传统方案，本发明可以借由统一计算引擎来统一实时和离线两条链路的开发逻辑从而规避数据加工链路不一致导致的计算语义不一致的现象，从而使得下游数据不需要重复进行清洗过滤。

经过过滤的工业数据在数据预处理阶段还需要经过有效的裁剪：

1、从消息队列中消费获取到采集器发来的数据包，根据传输协议进行解析。

2、通过采集器以及器件标识对数据流进行拆分，然后将相同标识的数据收纳在同一数据流中。

3、根据预先设定的数据处理分组进行数据组合，将关联分析的数据合并至同一分组。

4、根据时间窗口对数据进行聚合，通过窗口的滑动，将聚合的数据重新生成无界流。

5、基于简单的阈值逻辑对数据进行清理，将不满足要求的数据或是明显异常的数据记录至异常分支流供***优化分析使用。

6、记录数据处理过程中的有效数据占比以及处理规则命中数供***优化分析使用。

数据血缘模块：通过流式计算引擎提供的SQL抽象处理，采用SQL语言编写脚本描述数据的流向，再提交到计算平台上解析启动作业。具体地：

通过流式计算引擎提供的SQL抽象能力，能够快速的描画任务作业中数据的处理过程。因此***中提交构筑流计算任务主要手段是采用SQL语言编写脚本描述数据的流向，再提交到平台上解析启动作业。

通常在开发时需要先定义DDL(数据库模式定义语言)指定数据元信息，再编写DML(数据库操作语言)指定数据加工过程，多数任务中DDL(数据库模式定义语言)定义语句是重复但却没有在作业开发中获得收益。元数据信息也储存在持久化存储的metastore(元存储)组件存储中，同时也能在上下游的catalog(数据库)中取得。因此方案中将实时的数据流定义成实时表存储至metastore组件，用户可以直接从中选择需要的数据源，然后仅需要写DML语句即可完成作业开发。在任务提交的时候，***会根据上下游catalog将转化的DDL语句补充上去，构成完整的StreamingSQL脚本进行提交。可以进一步降低作业开发难度，同时也能够进一步打通批处理业务和流处理业务的开发流程，使得两者的开发步骤更加趋近相同。

此外，方案的规则引擎支持配置规则的不断升级。托管在metastore的元数据能够对不同数据节点引入的数据schema不一致的情况提供一定的兼容能力。数据处理过程中通常会将预处理的数据写入消息队列中，然后进行在线训练，训练的过程是持续不断的，期间会不断的产生动态的模型，然后推送给在线的推理模块进行推理。在线的机器学习的特点就是模型的动态更新、持续训练和不断验证。同时需要比较复杂的模型监控，模型部署和模型回滚等策略。在计算节点可能经由维表关联、多流汇聚导致数据结构产生变更，通过追溯数据schema的血缘关系能够对变化的数据结构提供支持。

如图2所示，本发明还提供了一种基于流式计算引擎的数据处理方法，包括如下步骤：

数据采集步骤：通过从终端采集获取原始数据后，同步编制发送端与接收端的编解码协议，从无界数据流中匹配对应的表信息完成对信息事件的采集，同时对业务字段信息进行清洗筛选。

前置过滤步骤：将采集筛选出的信息经由布隆过滤器提供的轻量级数据过滤去重，同步利用Key-Value存储提供的海量数据过滤去重。

数据预处理步骤：流式计算引擎提供流批统一的能力统一消息处理路径，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象。

数据血缘步骤：通过流式计算引擎提供的SQL抽象处理，采用SQL语言编写脚本描述数据的流向，再提交到计算平台上解析启动作业。

本发明又提供了一种存储有计算机程序的计算机可读存储介质，计算机程序被处理器执行时实现上述的方法的步骤。

本发明构建任务的方式主要为SQL，并由此开发了StreamingSQL的编辑器，提供了对***定义的SQL规范的支持，同时兼容StromSQL、SparkSQL、KSQL、HiveSQL和FlinkSQL语法。除了提供了引擎方言SQL的支持之外，还提供了SQL模板。方便平台的用户基于SQL模板快速开发预设场景的SQL任务。此外对于业务人员还提供了web式的引导页面，帮助其通过表单填空的方式在不编写代码的情况构建出流式处理任务。

此外，编辑器还提供了自定义函数的组件库，包含了丰富的内置函数，包括时间函数、集合函数、Json处理函数及字符串函数。丰富的内置函数可以方便用户的开发，省去用户自己去开发的时间。组件库中还包含了开发人员编写的使用说明以及使用案例等，供平台用户检索查阅。组件库也提供了云平台，供***用户上传下载业务中累积的自定义函数以及自定义算子，方便不同***部署时的数据共享，以及后续开发支持。

编辑器还实现了针对StreamingSQL的语法检测和智能提示，用户在编写语句的过程中能够做出实时的语法检测并给出一定程度的提示，还能够对语句中涉及的表和字段等提供元数据的补全功能，优化了开发体验。

编辑器同时支持在线调试的功能，对于流式计算这种能力是非常重要的。避免了任务需要上线之后再根据观察的结果进行调整的情况，节约了开发成本。***可以接受文本文件作为数据源来检验输出是否符合预期，也能采样消息队列中的消息主题或是数据库表中的数据进行业务逻辑校验。

在SQL解析过程中，最为复杂的是通过维表关联进行数据表的打宽。发明中通过热存储进行表关联。数据从数据源导入后，***使用Async I/O技术访问后端，***后端使用Data Accessor接口访问后端的存储。***后端存储支持从分布式存储***、结构化数据库、NoSQL数据库、消息队列等数据管道中获取数据，同时后端会将数据缓存于LRU Cache模块中。通过在消息队列中在维表更新时进行广播，减少维度数据更新不及时的情况。在***中为维表关联后的数据开发了多种大数据工具的存储支持，从而大大增加了***的兼容性。

由于规则匹配情况和业务需求场景不断变化，规则经常需要根据实际变化做出频繁调整。业务人员在前端的特征管理界面，对规则库中的规则因子进行增删改查的操作，通过对不同的规则因子的组合构筑出不同的特征规则。然后可以指定试验的结果集对构筑的规则进行简单测试，测试结果合适之后再进行整体保存。不在每次操作时直接对规则库进行变更，从而实现业务规则与规则因子的解耦。

在衡量整体效果方面，通过对规则的命中率以及规则的报警频次的分析，确定规则是否合理。

需要判断规则是否失效，比如拦截率的突然降低。

判断规则是否多余，比如某规则从来没拦截过任何事件。

判断规则是否有漏洞，比如在进行某个操作后，但没有达到预期效果。

此外，规则灰度上线机制也基于规则的整体效果评价构筑，通过对不同区域设置白名单或者是导入真实数据测试结果或者是限流上线正式环境等优化规则发布流程。

在积累分析优化数据方面，需要发现组合规则，通过识别某种行为的组合来防止出现操作中每个步骤均为正常可用，但行为结果累计出现异常；需要做出群体识别，比如通过图分析技术，发现群体并且打上群体标签，防止出现每个部分表现都正常，但整个区域内却出现异常状况的情况。

在发明的规则的模式匹配中，使用Rate算法提升匹配效率，减少了重复计算造成的时间冗余性。在规则数量和事实样本较多时，每条事实数据都需要与Rete网络中的Alpha节点相匹配。大多数规则所含的条件原子相同，即存在被多个规则同时包含的条件原子，依次与每个Alpha节点匹配就存在了一定时间浪费。因此，一个预匹配模块，将多条规则聚合成少量的规则组。通过规则组筛选，在预匹配阶段过滤掉部分正常数据，减少事实和节点的匹配次数。实现逻辑是将含有多个相同条件原子的规则划分到同一规则组中，规则组中出现次数最多的条件原子作为该规则组的特征条件。全量数据通过预匹配模块中规则组的筛选，即可过滤掉部分数据，对剩余样本执行所在规则组内的规则判断。

规则学习的目标是产生一个能覆盖尽可能多的样例的规则集，最直接的方式就是顺序覆盖，即逐条归纳，这也是规则学习最简单的一种训练思想，在训练集中每训练生成规则后，就将该规则覆盖的样本从训练集中取出，然后用剩下的样本训练出另一组规则。当然为了避免模型的过拟合，一般算法都会加入剪枝优化的策略。

要训练出高可用的模型，优秀的特征必不可少。优秀特征的重要特点是区分度较高，这就需要算法开发人员和敏感度高的业务人员紧密配合，对配置的规则进行分析，提取出较好的规则因子，同时，算法开发人员还应对业务流程非常熟悉，结合实际情况，创造出高可用的特征。对实际业务而言，很多情况下，一个准确的特征的加入比模型参数调优甚至模型优化更加有效，同时，准确的特征还可以防止过拟合的发生。本发明中通过对历史数据的分析处理以及对工业监控业务的流程梳理抽象出详细的业务参数可供组合筛选。

模型训练一个重要的需求就是样本的数量要尽可能的多，然而监控业务天然有这方面的缺陷，异常规则配置之后，实际被筛选出的案例极少，这就导致正负样本数量极不平衡，因此发明采用重采样的方法增加正样本的数量，具体方法是将样本包含的数值化特征采用SMOTE方法进行重采样，对标签化特征采用随机选择的方法重采样，最后将二者组合成新的样本。实际训练过程中，需要对算法包含的最大迭代次数、步长、最大树深等参数进行多次适当的调节，选择出识别率最高的参数。

通过***处理的事件流不断增长，业务规则会跟着数据集进行一定的演化。再通过实时的业务数据和归档历史数据验证规则的有效性后，规则引擎能具备一定的进化能力。

基于上述发明，可以在工业物联网中加入本发明提供了一种基于流式计算引擎的工业数据监控***，包括：

如图3所示，状态监控模块：采用流式计算引擎原生支持的Prometheus进行实时指标采集和存储，通过meta节点定时抓取所有子节点指标进行汇总，统一数据源提供给Grafana进行可视化以及告警配置。具体地：

为流式计算引擎设计的前端界面提供了大量的运行时信息供用户了解任务当前运行状况，但是存在无法获取历史状态监测的问题导致用户无法了解任务历史运行状态，本发明采用计算引擎原生支持的Prometheus进行实时指标采集和存储。通过meta节点定时抓取所有子节点指标进行汇总，方便统一数据源提供给Grafana进行可视化以及并通过dashboard进行告警配置。

在流式计算作业过程中，由于数据源源不断地流入清洗处理，很难去监控作业的运行情况。即使开启了检查点也无法确定是否丢失数据或丢失了多少数据。因此，本发明设计了心跳的机制，为每个作业注入了心跳信息以监控其运行情况。

伴随着每一个数据源的传入，元数据服务会生成一组定时的心跳信号，由作业进行消费。心跳信息流入每个作业后，会随数据流一起经过每个节点，在每个节点上打上当前节点的标签，然后跳过该节点的处理逻辑流向下个节点。流经作业组件末端时，会通过JMX被采集至展示页面。

该指标包含了心跳信号产生的时间，流入作业的时间以及到达每个节点的时间。通过这个指标可以判断一条数据被整个管道处理所用的时间和每个节点处理数据所用的时间，进而判断该作业的性能瓶颈。

由于心跳信号是定时发送的，因此每个作业收到的心跳信息个数应该一致。若最后发出的指标个数与期望不一致，则可以进一步判断是否有数据丢失。

吞吐能力和延迟作为衡量实时任务性能最重要的指标，经常需要通过这两个指标来调整任务并发度和资源配置。如果启用计算引擎原生的latency参数追踪任务延迟跟踪会显著影响集群和任务性能，本发明采用消息主题消费堆积作为衡量任务延迟的指标，通过JMX获取引擎作业中消费的偏移量反查消息队列中持久化的消息主题的挤压情况，同时通过引擎提供的JMX采集作业节点的背压情况综合分析推断作业是否出现数据堆积的现象。

流式计算引擎为了适应大规模数据处理的需要通常提供了分布式计算的能力，向平台提交的所有任务会由调度器统一调度到任意计算节点，因此任务的运行日志会分布在不同的机器，用户定位日志困难。本发明通过调整log4j日志框架默认机制，按天切分任务日志，定期清理过期日志，避免异常任务频繁写满磁盘导致计算节点不可用的情况，同时在所有计算节点部署agent实时采集日志，抽集到消息队列中再汇聚到Elasticsearch等非关系型数据库，方便用户在需要通过日志定位判断异常信息时快速找到作业对应日志。

资源调配模块：对实时任务进行分析提供足够的内存给作业，同时对任务消息进行实时处理，结合实时任务内存分析所得相关指标、实时任务并发度的合理性，得出实时任务资源预设值，调整实时任务资源，达到实时任务资源配置。具体地：

对于实时任务资源分析思路，主要包含两点：

一方面是从作业占用的内存入手，从运行时堆内存方面对实时任务进行分析，提供足够的内存保证作业稳定执行。

另一方面则是从实时任务消息处理能力入手，保证满足数据处理需求的同时，尽可能合理使用CPU资源。

之后再结合实时任务内存分析所得相关指标、实时任务并发度的合理性，得出一个实时任务资源预设值，调整实时任务资源，最终达到实时任务资源配置合理化的目的，从而更好的降低机器使用成本。

在对任务内存的管控方面，***会根据配置间隔定时扫描所有正在运行的流式计算任务，结合实时任务GC日志，同时根据内存优化规则，计算出流式计算任务推荐的堆内存大小，并与实际分配的流式计算任务的堆内存进行比较，如果两者相差的倍数过大时，可以认为流式计算任务的内存配置存在浪费的情况，接下来会产生报警提示到任务调度进行优化。

在对于实时作业任务消息处理能力分析方面，主要是通过判断实时任务消费的数据源单位时间的输入和实时任务各个Operator/Task消息处理能力是否匹配。通过监控数据源的流量结合作业中Operator的吞吐情况，判断作业是否会出现数据倾斜，流量背压的情况，通过作业的优化规则提醒调整算子并行度，优化作业资源分配。

通过流式计算引擎提供的原生K8s支持，作业能够主动向调度器申请资源从而达成作业资源的弹性扩容从而应对突发的数据尖峰。基于此构建实现了任务资源的优化全部自动化，会结合实时任务历史不同时段的资源使用情况，自动化推测和调整实时任务的资源配置，从而达到提升整个实时集群资源利用率的目的。

异常状态模块：利用SideOutput来收集流式作业各环节中出错的数据，汇总到统一的错误流，通过在流式数据中发现符合设定特征的模式进而触发对应的后续动作进行实时告警。具体地：

错误记录中包含***预设的错误码、原始输入数据以及错误类和错误信息。一般情况下，错误数据会被分类写入分布式文件存储***，用户通过监控存储目录可以得知数据是否正常。

恢复数据时通常有三种情况。

1、数据格式异常，比如日志被截断导致不完整或者时间戳不符合约定格式，这种情况下***中提供通过精确离线批作业来修复数据，跳过处理不正常的数据事件或者对数据重新进行修正后重新打入作业流程，将数据回填到原有的数据管道。

2、作业管道异常，比如数据实际的schema有变更但流表配置没有更新，可能会导致某个字段都是空值，但整体作业并没有出现异常。通过指标输出报警进行提示后，提醒用户进行补数据处理操作。

3、数据链路异常，比如数据源主从集群发生异常情况进行了切换，但消费配置没有进行改变，会导致下游数据应用出现超时等情况。通常情况下依托***提供的重试机制和异常恢复机制，能够及时的切换到健康的数据源，如果作业失败会进行报警告知。

补数据作业时，首先更新线上的流表配置为最新，切换至健康的数据源，保证不再产生更多异常数据，这时存储里仍有部分分区是异常的。所以发布独立的补数作业来专门修复异常的数据，输出的数据会写到一个临时的目录，并在metastore上切换partition分区的location来替换掉原来的异常目录。因此这样的补数流程对离线查询的用户来说是透明的。最后再在合适的时间替换掉异常分区的数据并恢复location。

利用流式引擎进行查询优化：

维表关联的场景下因为维表经常发生变化，尤其是新增维度，而关联操作发生在维度新增之前，经常导致关联不上。针对此种场景***中开发了针对不同需求的异常处理策略，如果在关联时发生异常，则暂时将数据缓存起来之后再进行尝试，并且可以控制尝试次数，能够自定义延迟关联的规则。

同时在SQL支持中添加了一个可以支持延迟关联维表的算子。当关联没有命中时，本地缓存不会缓存数据集为空结果，同时将数据暂时保存在一个状态后端中，之后根据设置定时器以及它的重试次数进行重试。

通过作业结构拓扑分析，流式引擎作业时计算算子和关联计算算子是连接在一起的。因为它没有唯一键分流的语义。当作业并行度比较大，每一个维表关联的子任务访问的是所有的缓存空间，这样对缓存来说有很大的压力。

但观察管理操作的SQL实现，等值连接是天然具有哈希属性的。在包装算子时直接开放了配置，用户可以把维表关联的key作为哈希的条件，将数据进行分区。这样就能保证下游每一个算子的子任务之间的访问空间是独立的，这样可以大大的提升作业开始时的缓存命中率。

利用流式引擎进行索引优化：

数据库为了加速数据检索，往往会事先为数据创建索引，再在扫描数据之前通过索引定位到数据的起始位置，从而加速数据检索。而传统数据库常见的是行索引，通过一个或若干字段创建索引，索引结果以树形结构存储，此类索引能够精确到行级别，索引效率最高。

某些大数据项目也支持了行索引，而它所带来的弊端就是大量的索引数据会造成写入和检索的延时。而平台处理的多数是采集数据，例如传感器这类数据，它的特点是重复度非常高，而分析的结果往往非常少，极少数的目标行为会隐藏在海量数据里，占比往往会是千分之一甚至更少。所以选择性价比更高的块索引方案，已经能够支撑目前的应用场景。

现有的方案中多是将索引数据以文件的形式存储在磁盘上，外加一些高速缓存机制来加速数据访问，而***中是将索引数据直接存在了数据库中。主要有以下两个方面的考虑：

1、Transaction，通常来说列存文件往往是无法更新的，而***在定期优化文件分布时会做多个文件内容合并操作，为了保证查询一致性，需要数据库提供transaction能力。

2、Performance，数据库拥有较强的读写和检索能力，甚至可以将谓词下推到数据库来完成，数据库的高压缩比也能进一步节省存储。

利用流式引擎进行异常优化：

由于流式作业需要缓存大量的中间过程，以及申请不少的计算资源。作业从异常失败到作业重启需要大约一两分钟的时间，这对于某些在线业务场景来说是不能接受的。

通过对作业异常产生过程进行分析发现，异常检测和初始化的消耗是主要瓶颈。异常检测受制于接口轮询间隔，资源初始化受制于容器初始化步骤。在这两方面***分别进行了优化，作业运行时做到快速发现失活。此外，还要预留资源，当宕机出现时，可以省去申请资源，以及初始化的时间。

***中在流式计算引擎之上增设了一个多数派的连通性检测服务，检测服务集群中多个工作节点会周期性地检测集群中每台机器的连通性，由于它是多数派的，所以可信度是有保障的。

此外，在预留资源方面，***扩展了流式引擎作业的资源申请模型，在流式作业提交时可以设定资源冗余参数，当冗余参数被激活后，会自动保障冗余资源量会高于单点故障导致的资源缺失量，且在资源排布上避免冗余资源的聚集性。

同时，应对集群硬件资源满载的情况***会控制数据源的消费速度。引入协调员，周期性检查作业集器上的资源消耗情况以及数据源水印的进展。并根据全局的现状，预测出来各个数据源接下来允许读到的最大位置之后，下发给所有数据源。数据源根据得到的最大位置以及当前自己的位置，确定读取速度。并根据负载限制数据的消费速度。动态调节所有数据源的消费速度，从而保证流式作业的稳定。

Prometheus是一个开源的服务监控***和时间序列数据库；meta是html语言head区的一个辅助性标签，位于文档的头部，不包含任何内容；Grafana是仪表盘和图形编辑器；SideOutput是侧输出，任意数量额外的侧输出结果流；JMX是一个为应用程序、设备、***等植入管理功能的框架；agent是能自主活动的软件或者硬件实体；log4j是Apache的一个开源项目，通过使用Log4j，可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等。Transaction，一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元。Performance是前端性能监控的API。它可以检测页面中的性能，W3C性能小组引入进来的一个新的API，它可以检测到白屏时间、首屏时间、用户可操作的时间节点，页面总下载的时间、DNS查询的时间、TCP链接的时间等。

将基于流式计算引擎的数据处理***与基于流式计算引擎的数据监控***相结合之后的工作场景流程如下：

1、根据场景需要，用户通过上传模块，以jar包形式上传针对业务逻辑开发的自定义函数，扩展定义数据处理过程中需要使用的数据处理算子以及SQL函数

2、用户通过SQL语句描述作业中的数据流向，整理编排出作业数据处理的前后关系，再根据需要调整每个处理节点的并行度以及整体作业的资源分配。同时也支持上传jar包通过实现接口编排任务过程实现对作业过程更精细的控制。

3、根据业务需求增加规则引擎的判定规则，包括阈值判断、模式判断、组合逻辑判断等，对于复杂的关联判断规则也支持用户自定义，在上传实现***规定接口的jar包后，便能在***中进行配置。

4、根据作业需要配置***的规则学***台的***演化功能，在***处理数据过程中不断地训练规则模型，通过学***台的规则。演化出更加符合业务作业特点的细化规则经过人工确认后上线。

5、配置作业的数据源以及数据下沉通道，支持从分布式存储***、结构化数据库、NoSQL数据库、消息队列等数据通道中读写数据。同时支持json、protobuffer、avro等多种数据格式的构造及解析。

6、提交至作业***编排，首先通过逻辑拆解生成处理模块同时检查作业流程中的语法规范以及自定义包的编写规范。在页面上展示分模块构建的有向无环图，能够清晰地展示作业的数据流向以及算子的编排顺序，检查无误之后再提交给任务调度模块请求资源并拉起作业。

7、作业请求从资源集群中申请到作业资源之后，会不断的从数据源获取对应标签的数据，根据配置的规则进行数据处理后，通过规则引擎进行规则判断后，再输出至实时展示模块或是进行数据下沉。作业过程中，用户可以通过任务监控模块了解作业详情，例如作业吞吐，网络IO、资源占用以及模块背压等信息都能让用户了解作业的运行状态。

8、根据用户配置，在作业过程中会分时段或是作业批次生成确认点，包含了当前作业的全部状态信息。同时在业务流程的间隔周期会生成业务存档点，包含当前作业的计算结果。配合以上两种机制，能够累计作业指标，分析作业状态。同时在作业单元出现异常时，提供异常恢复的能力。

9、当作业流程中出现异常情况时，会根据用户配置来进行异常恢复，包括尝试作业重启、尝试从确认点进行恢复、异常数据的记录、或是快速失败然后推送等异常处理配置。作业监控模块中的任务状态也会实时的进行更新，帮助运维人员及时获知任务异常信息

10、当作业终止时，资源监控模块会在获取到当前任务的状态信息后进行资源回收，释放运算资源、清理文件缓存、根据用户配置保留或是清理存档点和确认点。将任务过程中的状态数据存入时序数据库后结束流式计算作业。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的***及其各个装置、模块、单元以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的***及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以，本发明提供的***及其各项装置、模块、单元可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置、模块、单元也可以视为硬件部件内的结构；也可以将用于实现各种功能的装置、模块、单元视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims (10)

1.一种基于流式计算引擎的数据处理***，其特征在于，包括：

数据采集模块：通过从终端采集获取原始数据后，同步编制发送端与接收端的编解码协议，从无界数据流中匹配对应的表信息完成对信息事件的采集，同时对业务字段信息进行清洗筛选；

前置过滤模块：将采集筛选出的信息经由布隆过滤器提供的轻量级数据过滤去重，同步利用Key-Value存储提供的海量数据过滤去重；

数据预处理模块：流式计算引擎提供流批统的能力统一消息处理路径，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象；

数据血缘模块：通过流式计算引擎提供的SQL抽象处理，采用SQL语言编写脚本描述数据的流向，再提交到计算平台上解析启动作业。

2.根据权利要求1所述的基于流式计算引擎的数据处理***，其特征在于，所述数据采集模块中对信息事件进行采集时，日志文件写入时为混合格式，需要根据记录存储格式分别解析出row格式以及statement格式的记录，日志文件在流式计算引擎提交事务刷新至磁盘后才会更新至日志文件中，需要记录日志消费点位应对作业异常重启情况。

3.根据权利要求1所述的基于流式计算引擎的数据处理***，其特征在于，所述数据采集模块对无界数据流采集后，无界数据流被发往消费队列，借由消息队列提供的高吞吐处理完成对数据的削峰填谷，对于消息队列的消息主题采用多分区设置。

4.根据权利要求1所述的基于流式计算引擎的数据处理***，其特征在于，所述数据采集模块在数据的管理和获取阶段提供包括HDFS和Kafka存储支持，同时支持多并行度的消费消息队列中存储的数据，保证数据链路的消费速度不在入口处形成短板。

5.根据权利要求1所述的基于流式计算引擎的数据处理***，其特征在于，所述前置过滤模块利用布隆过滤器内置的哈希函数对数据进行去重；

-利用Key-Value存储对持有相同key的消息记录进行合并；

-采用哈希算法将key转化为整型进行存储，使其最多占用8个字节。

6.根据权利要求1所述的基于流式计算引擎的数据处理***，其特征在于，所述前置过滤模块对经过去重处理过的数据流再通过自定义业务阈值或是编制自定义过滤规则的filter算子，对不合法数据进行过滤。

7.根据权利要求1所述的基于流式计算引擎的数据处理***，其特征在于，所述数据血缘模块在开发时先定义数据库模式定义语言指定数据元信息，再编写数据操纵语言指定数据加工过程，将实时的数据流定义成实时表存储至元存储组件，用户直接从中选择需要的数据源，然后仅需要写数据操纵语言的语句即可完成作业开发。

8.根据权利要求7所述的基于流式计算引擎的数据处理***，其特征在于，所述数据血缘模块在任务提交的时候，根据上下游数据库将转化的数据库模式定义语言语句进行补充，构成完整的Streaming SQL脚本进行提交，连通批处理业务和流处理业务的开发流程。

9.一种基于流式计算引擎的数据处理方法，其特征在于，包括如下步骤：

数据采集步骤：通过从终端采集获取原始数据后，同步编制发送端与接收端的编解码协议，从无界数据流中匹配对应的表信息完成对信息事件的采集，同时对业务字段信息进行清洗筛选；

前置过滤步骤：将采集筛选出的信息经由布隆过滤器提供的轻量级数据过滤去重，同步利用Key-Value存储提供的海量数据过滤去重；

数据预处理步骤：流式计算引擎提供流批统一流处理，避免离线与实时两套业务开发产生的资源浪费，并且通过提供SQL支持对数据流向进行抽象；

数据血缘步骤：通过流式计算引擎提供的SQL抽象处理，采用SQL语言编写脚本描述数据的流向，再提交到计算平台上解析启动作业。

10.一种存储有计算机程序的计算机可读存储介质，其特征在于，所述计算机程序被处理器执行时实现权利要求9所述的方法的步骤。

Images