技术领域
[0001] 本发明涉及实时计算框架技术领域，尤其涉及一种针对静态批次数据、流式数据的基于信创环境的实时计算框架搭建方法。
相关背景技术
[0002] 信创环境，即信息技术应用创新环境，指的是国家构建自己的信息技术产业标准和生态，使得IT产品跟技术安全可控。在传统的数据处理流程(离线计算)中，先是收集数据，然后将数据存储到数据库中。当需要某些数据时，可以通过对数据库中的数据做操作，得到所需要的数据，再进行其他相关的处理。这样的处理流程会造成结果数据密集，结果数据密集则数据反馈不及时。对于配网的数据采集、流式存储、实时计算等功能的实现而言，传统的数据处理流程反馈速度慢，难以满足业务场景的需求。对于电网一类的企业所使用的数据处理系统而言，海量数据的高效处理和安全性的高度保障都是不可或缺的，因此有必要基于信创环境搭建一套能够满足配网各种静态批次数据、流式数据处理需求的实时计算框架。
具体实施方式
[0036] 以下结合附图对本发明的原理和特征进行描述，所列举实施例只用于解释本发明，并非用于限定本发明的范围。
[0037] 参照图1，本实施例提供一种基于信创环境的实时计算框架搭建方法，所述方法包括以下步骤：
[0038] S101、搭建分布式环境，所述分布式环境基于流批一体处理框架的独立集群模式实现。
[0039] S102、使用第一测试用例对分布式环境性能进行测试。
[0040] S103、使用第二测试用例对分布式环境在大数据量的计算场景下的可靠性进行测试。示例性的，本实施例中第二测试用例可以采用ETL测试用例，以测量TB级别数据量的计算场景下，在出现流处理作业迁移、集群升级时分布式环境的可靠性。
[0041] S104、完成分布式环境对外公开的应用程序接口的抽象，从而提供针对静态批次数据、流式数据的数据操作功能，方便用户能够快速编写分布式任务。
[0042] S105、基于配网的业务需求，在分布式环境中实现相应的业务功能，包括实现配变重过载、低电压实时预警场景的数据采集、流式数据存储、实时业务计算、结果数据存储、预期提醒、统计结果展示等功能，支撑提升配网抢修响应效率、优化配网运行工作、辅助配网投资优化等业务。
[0043] 本实施例中，实现分布式环境的流批一体处理框架采用Flink流计算引擎，Flink原理是CPU密集型的内存计算，因此尽可能采用核数较高的CPU，并配备较大内存。
[0044] 在步骤S102和S103之前，需要对分布式环境的测试环境进行软硬件配置。本实施例中，分布式环境包括三台服务器node0、node1和node2，其中node0上部署的软件包括Flink Master、Redis、Flink worker、Zookeeper和Kafka broker；node1和node2上部署的软件包括Flink worker、Zookeeper和Kafka broker。Zookeeper为Kafka的前置依赖，Kafka作为数据源，Redis用于存储计算结果。
[0045] 在步骤S102和S103之前，还包括步骤：生成测试数据，测试数据由数据生成器生成，并存储到Kafka中，对于kafka的每个分区，数据生成器首先置入开始标记，用于标记计算开始，并按预设的程序参数要求生成测试数据，最后在Kafka的每个分区置入结束标记，用于标记计算结束。
[0046] 本实施例以一个业务场景为例，后续将基于该业务场景说明实时计算框架的搭建过程。该业务场景具体为：每个计量点每15分钟会产生一条数据，每个数据包括：计量点编号、计量点获取数据时间、A相电压、B相电压、C相电压。低电压检测算法为：在某计量点的一天96时间点中A、B、C三相电压中任一相出现电压低于198的情况且没有出现过A、B、C三相电压中任一相高于300V的情况，则认为该用户存在低电压的情况，状态记录为低电压。在某计量点的一天96时间点中A、B、C三相电压中任一相高于300V的情况则判定该用户的电表采集异常，状态记录为异常。输出结果包含：计量点编号、低电压日期、状态。输入数据格式为：mpoint；mptime；Va；Vb；Vc。其中mpoint表示计量点编号，mptime表示计量点获取数据时间，Va表示A相电压，Vb表示B相电压，Vc表示C相电压。输出结果保存在Redis的Hash结构中，Key为mpoint_mptime，其中mptime格式为yyyy.MM.dd，Value为结果状态，其中‑1表示异常，1表示低电压，0表示正常电压。
[0047] 步骤S102中，使用第一测试用例对分布式环境性能进行测试是为了选择业务相关且数据量大的测试用例分别测试Flink流处理和批处理性能。采用监控软件记录耗时、CPU占用情况、内存消耗时间等数据，对比分析不同配置之间的性能差异，确定FLink优化配置方向。S102具体包括以下步骤：
[0048] S201、同步node1、node2和node3的系统时钟。
[0049] S202、将测试数据输入到应用程序中，将应用程序提交到分布式环境的Flink集群中执行，应用程序执行预设算法对测试数据进行处理。
[0050] S203、在应用程序执行结束后获取结果。
[0051] S204、基于应用程序的执行过程获取性能评价指标。
[0052] 若需要多次测试，则可以在获取结果后，取消Flink中的任务，重新提交应用程序，在测试不同参数对性能的影响时，输入数据应保持一致，不应该重新生成数据。本实施例中，对于同一测试场景，采用预热一次，测试三次取平均值的方式，即在生成测试数据后，执行步骤S202‑>步骤S202‑>步骤S203‑>步骤S202‑>步骤S203‑>步骤S202‑>步骤S203。
[0053] 在Kafka的每个分区中，数据的格式都形如Start,data,data,data,…,End。其中Start为开始标记，End为结束标记。步骤S204中，性能评价指标包括计算总时间和任务调度时间，计算总时间的获取包括以下步骤：
[0054] S301、在应用程序执行过程中，当读取到测试数据中的开始标记时，将当前时间写入Redis中的Key中，将该Key命名为voltage_start，若voltage_start已存在，则取最小值存入；
[0055] S302、当读取到测试数据中的结束标记时，将当前系统时间写入Redis中的另一Key中，将该Key命名为voltage_end，若voltage_end已存在，则取最大值存入，并分别创建名为voltage_time、voltage_end_count的Key，将voltage_end‑voltage_start的结果存入voltage_time中，若voltage_time已存在则对其进行更新，更新voltage_end_count为自增1；
[0056] S303、当voltage_end_count与voltage_end_num相等时，读取voltage_time得到计算总时间，voltage_end_num为Kafka分区数；
[0057] 任务调度时间通过读取Flink JobManager的日志信息计算得到。通过对比不同配置下的计算总时间和任务调度时间长短，可以对不同配置的性能进行评价，从而确定分布式环境的配置优化方向。
[0058] 步骤S105中，在分布式环境中实现低电压检测业务场景下的数据链路和数据处理算法，数据处理算法包括以下步骤：
[0059] S401、数据从数据源进入Kafka，Kafka中每个分区内的数据格式均为D(mpoint)(mptime)，例如D11|D21|D31|D12|D22|D32|…，也即第一批数据、第二批数据、…。这里数据是有序的，不同批次数据间不会乱序。其中mpoint表示计量点编号，mptime表示计量点获取数据时间。
[0060] S402、Flink Kafka Connector从Kafka中读取数据，按照数据的Key进行划分，将其发往对应处理该Key的Flink worker。
[0061] S403、Flink worker维护一个KeyedState，每个Key对应一个State，在接收到数据时，Flink worker对当前Key的State进行更新，并在所接收数据的mptime对应的一天结束时注册事件。
[0062] S404、当新一天的数据到来时，将该数据的mptime作为event time触发Flink的watermark更新，使得之前注册的事件被触发，汇总前一天所有数据的State被存储到Redis中，并把State更新为初始状态。
[0063] 理想情况下，Kafka的分区数应与Flink任务的并行度相同，如果分区数小于并行度，会有部分Connector闲置，如果分区数大于并行度，会增加Kafka Connector和Kafka Broker上的处理复杂度。
[0064] 当Kafka有多个分区时，不同分区间的数据消费速度可能不同，虽然同一mpoint对应的数据都在同一分区，但其他mpoint的数据会导致watermark的更新和事件的触发，因为watermark是全局共享的，而非根据Key划分。由于数据可能乱序，需要检测迟到的数据。与Flink中迟到元素的定义不同，Flink称所有event time晚于watermark的元素都为迟到元素，而在本实施例的业务场景中，只有对应时间区间的状态已经输出的元素才会对处理流程产生影响，才被称为迟到元素。对于迟到的数据，因为其对应时间区间的State已经输出，需要从Redis中取回State，更新后重新写回。对于迟到元素的数量可以使用Flink的Counter进行统计，便于后续分析，可以通过Flink的REST API获取Counter的聚合值。
[0065] 对上述提及的算法设计进行测试，在软件所测试环境下，测试数据量为108条，每个Flink worker配置20个Task Slot，Task Manager内存配置为40G，得到结果如表1所示：
[0066] 表1
[0067]
[0068] 表1处理后得到结果如表2所示：
[0069] 表2
[0070]
[0071] 本实施例中，性能优化从算法实现开始，通过复用DataFormat对象，在分区数1并行度60的情况下，计算时间从330s减少到230s，通过使用Unix时间戳代替Date对象，计算时间减少到87s。在分区数增大的情况下优化效果不明显，这是因为分区数1时，数据的输入和序列化是系统瓶颈，此时优化该过程效果显著，而当分区数提高后，系统瓶颈为process部分，此时优化数据输入过程效果不明显。除此之外，通过对Random对象的复用，也使得数据生成器的生成时间有约10％的减少，虽然对应用执行没有影响，但减少了测试中数据生成的时间，提高了测试效率。
[0072] 对优化后的算法进行详细测试，得到结果如表3所示：
[0073] 表3
[0074]
[0075] 表3结果处理后如表4和图2所示：
[0076] 表4
[0077]
[0078] 分析上述结果，可以发现，当分区数为1并行度为1时，提高并行度可以加快任务运行，这是因为数据读入速度快于数据处理速度。而当并行度增大后，Kafka的数据消费速度成为系统的瓶颈，此时提高分区数应该获得性能提升，理想的水平可扩展情况下，性能应成倍提升。然而，结果恰恰相反，随着分区数和并行度从1提高到15，计算时间反而延长，这是因为迟到元素过多，而对于迟到元素的处理，需要从Redis中取回该State，更新后重新写回。这一操作的耗时远大于Flink内部的状态更新，在Redis与Flink worker在同一机器上时，不考虑网络延时的情况下，两者也有30倍的速度差距，如果加上网络延时，则速度差距更大。同时，当一个Flink worker遇到迟到元素时，对迟到元素的处理会严重拖慢其处理速度，导致该worker上的迟到元素进一步累积，进入恶性循环。极端情况下，一个元素的迟到会导致后续所有元素都迟到。这也可以解释测试结果中计算时间波动大的现象，由于迟到元素的出现时机不确定，导致整体计算时间的不确定。另一方面，随着分区数和并行度的进一步提高，计算时间快速下降，这是因为系统的性能瓶颈在于访问Redis，而并行度的提高等同于增加Redis client的数量，增加并行访问Redis的连接数。
[0079] 因此，需要关注和减少迟到元素的占比，这可以通过延迟结果输出事件的时间实现。在本实施例中，迟到元素出现的根本原因，是不同mpoint的数据消费速度不同时，消费速度快的mpoint的数据导致watermark更新，触发其他mpoint的结果输出事件，而致使其他mpoint未处理的元素成为迟到元素。但不同mpoint的数据及其处理间并没有耦合关系，这一耦合来自于Flink引擎共享watermark，而非算法和业务场景。因此，可以避开Flink的watermark实现，手动管理KeyedWatermark，对于每个mpoint管理各自的watermark和结果输出事件，就可以解除这一耦合，实现系统的高水平可扩展。
[0080] 对于所述实时计算框架的软、硬件基础环境，由于Flink的原理是CPU密集型的内存计算，需要尽可能采用核数较高的CPU，并配备较大内存。因此，可采用飞腾公司腾云S系列CPU组装服务器，安装银河麒麟高级服务器操作系统、达梦数据库、JRE软件，并通过各软件主要功能测试确认软硬环境的相互适配，从而搭建一套可支持流批一体实时计算的国产化服务器基础环境。
[0081] 本实施例基于国产服务器和操作系统，与现有指令集进行深度适配，研究数据缓存块的动态伸缩能力，通过数据缓存块超时值的动态变化，实现对延迟和数据吞吐量的动态平衡，同时满足批次数处理和流式数据处理需求，从而在国产信创环境下兼顾时延和数据吞吐，建立流批一体化的数据计算框架。
[0082] 以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
