大数据场景下多源异构数据的实时处理分析

随着大数据应用的发展，人们对实时数据的要求越来越高，大数据也逐渐从最初的离线数据仓库架构发展到Labmda架构，实现了离线实时更新的目标。到后来的Kappa体系结构中，Labmda体系结构的实时部分被提取出来单独运行。实时大数据时代已经到来，本文在此背景下介绍了一种基于Kappa体系结构的多源异构数据实时处理与分析体系结构。

一、架构介绍

下图为基于Kappa架构的多源异构数据实时处理分析体系结构，如图所示，它主要包括数据采集、流数据处理、流数据存储、数据服务四个环节，其中数据服务没有固定的结构，在不同的业务场景变化很大。以下主要介绍了三个环节：数据采集、流数据处理和流数据存储。

1、数据采集

采用ELK构件结构实现数据采集，其中Logstash接收多源异构数据并同时发送到消息队列进行流数据处理，ElasticSearch用于源数据存储。Logstash支持多种传输模式，包括TCP、UDP、JDBC和Kafka等，它还支持多源数据的类型验证，并在初期过滤不符合规范的异构数据。Kibana是ElasticSearch的可视化查询工具，能够使用组合嵌套查询语句全局查询ElasticSearch中的数据。

2、流数据处理

Flink实时流计算引擎用于实现流数据处理，订阅发送到第一个链路Logstash的消息队列，从消息队列中获取多源异构数据，并根据业务需求进行数据过滤、重复数据删除、补全、格式转换、索引提取等ETL操作。格式化数据和指标数据经过ETL后可以继续用于统计分析、匹配算法，实现业务需求的画像、预测等结果数据。

3、流数据存储

流数据存储也采用ELK组件结构，它不仅存在于整个建筑的尾部，也存在于建筑的中间环节。在第一个环节中，Lostash将数据传输到消息队列或将其存储到ElasticSearch，两者都是流数据存储。在第二个环节中，中间阶段的数据需要推送到消息队列中，同时存储到ElasticSearch中，推送到消息队列用于中间存储，便于后续处理流程订阅数据进行业务处理，存储到ElasticSearch中则是传统数仓架构中中间表留存的思维，用于中间数据的存储和查询。第二环节处理后的结果数据根据需要可不推送到消息队列，只进行ElasticSearch存储。

二、关键技术点

多源异构数据的实时处理分析架构中最为复杂和难以设计的是第二环节流数据处理。采用Flink实现流数据处理的方法是丰富多样的，可能存在的问题也是多种多样的。为了减少问题出现的概率，本文介绍以下两种维持Flink稳定高效运行的优化解决方案。

1、检查点重启策略

由于各种原因，Flink流数据处理任务可能会中断。为了实现因故障中断的任务的自动重启，保证系统的鲁棒性，需要配置检查点重启策略。其原理是定期对Flink任务进行快照，当任务由于故障而中断时，如果配置了重启策略，程序将从最新的快照位置恢复。

当然，检查点重新启动策略只是一种故障安全策略，重新启动只能解决部分问题，还有许多问题是重新启动无法解决的。在这种情况下，任务会反复重启，直到重启次数超过设置的限制而出现中断，这时就需要工程师来手动解决。

2、内存模型优化

下图显示了Flink任务运行时容器的内存模型。当Flink任务启动时，将启用一个严格按照下图内存模型分配内存的容器。一般情况下，默认的内存分配无法支持生产环境下的任务运行，因此每位大数据工程师都应该掌握内存分配技能，以支持业务任务的运行。

但是仅仅支持运行是远远不够的，内存分配的合理程度对系统的稳定性和鲁棒性有着巨大的影响。例如，若集群之间的网络交换速度是系统的瓶颈，短时间内的大量数据吞吐可能会导致交换内存占满，无法进行数据交换导致任务中断。在这种情况下，可以通过增加网络交换内存来提高瓶颈的吞吐量，避免系统故障。

三、总结

本文介绍了多源异构数据实时处理与分析体系结构的流程结构并阐述了两种保持系统稳定性和鲁棒性的关键技术。该架构可以应用于各种生产业务场景，目前鹏信科技已将该架构应用于态势、反诈、研判等安全项目，支撑项目稳定高效运行，效果显著。