公共安全领域 Kafka 应用实践是怎样的
这期内容当中小编将会给大家带来有关公共安全领域 Kafka 应用实践是怎样的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
一、前言
本案例作为大数据框架在公共安全领域应用实践的开篇之作，将从最基础的数据架构体系优化讲起。在接下来的章节里将详细描述Kafka的基本原理、Kafka增强组件以及基于Kafka的Lambda架构的具体应用场景以及相应的研发成果。
Lambda架构由Storm的作者Nathan Marz提出。旨在设计出一个能满足。实时大数据系统关键特性的架构，具有高容错、低延时和可扩展等特。
Lambda架构整合离线计算和实时计算，融合不可变（Immutability，读写分离和隔离 一系列构原则，可集成Hadoop，Kafka，Storm，Spark,HBase等各类大数据组件。 大数据系统的关键问题：如何实时地在任意大数据集上进行查询？大数据再加上实时计算，问题的难度比较大。Lambda架构通过分解的三层架构来解决该问题：Batch Layer，Speed Layer和Serving Layer。如下图所示意。
Lambda架构图
数据流进入系统后，同时发往Batch Layer和Speed Layer处理。Batch Layer以不可变模型离线存储所有数据集，通过在全体数据集上不断重新计算构建查询所对应的Batch Views。Speed Layer处理增量的实时数据流，不断更新查询所对应的Real time Views。Serving Layer响应用户的查询请求，合并Batch View和Real time View中的结果数据集到最终的数据集。
二、基于Kafka的Lambda架构
2.1 某省大数据平台实践案例
以某省厅大数据建设方案为例，将Kafka作为统一的数据流通道（data pipeline）。Kafka分为地市和省厅两级，地市数据首先经过流式化处理发送到地市的Kafka，经过标准化后，地市Kafka的再汇集到省厅Kafka。
某省大数据平台实践
2.2 引入Kafka的必要性
在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能、低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。容易造成日志数据难以收集，容易丢失信息，Oracle实例之间的管道无法供其它系统使用，数据架构易创建难扩展，数据质量差等问题。为了同时搞定在线应用（消息）和离线应用（数据文件，日志），Kafka就出现了。Kafka可以起到两个作用：
• 降低系统组网复杂度。
• 降低编程复杂度，各个子系统不再是相互协商接口，各个子系统类似插口插在插座上，Kafka承担高速数据总线的作用。
传统数据架构
引入Kafka后，可以构建以流为中心数据架构。Kafka是作为一个全局数据管道。每个系统都向这个中心管道发送数据或者从中获取数据。应用程序或流处理程序可以接入管道并创建新的派生流。这些派生流又可以供其它各种系统使用。
以流为中心的数据架构
三、Kafka技术分析
3.1 Kafka的特点
Kafka可以让合适的数据以合适的形式出现在合适的地方。Kafka的做法是提供消息队列，让生产者单往队列的末尾添加数据，让多个消费者从队列里面依次读取数据然后自行处理。
Kafka消息队列
• 分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。
• 提供Pub/Sub方式的海量消息处理。 据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。
• 以高容错的方式存储海量数据流。
• 保证数据流的顺序，处理关键更新。
• 提供消息的长时间存储，将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。
• 能够缓存或持久化数据，支持与批处理系统（如Hadoop）的集成。
• 为实时应用程序提供低延时数据传输和处理。
• 支持online和offline的场景。
• 消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。
3.2 Kafka原理分析
3.2.1 Kafka总体架构
Kafka总体架构
Kafka的整体架构非常简单，是显式分布式架构，producer、broker（kafka）和consumer都可以有多个。Producer，consumer实现Kafka注册的接口，数据从producer发送到broker，broker承担一个中间缓存和分发的作用。broker分发注册到系统中的consumer。broker的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。客户端和服务器端的通信，是基于简单、高性能且与编程语言无关的TCP协议。
基本概念：
• Topic：特指Kafka处理的消息源（feeds of messages）的不同分类。
• Partition：Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。
• Message：消息，是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。
• Producers：消息和数据生产者，向Kafka的一个topic发布消息的过程叫做producers。
• Consumers：消息和数据消费者，订阅topics并处理其发布的消息的过程叫做consumers。
• Broker：缓存代理，Kafka集群中的一台或多台服务器统称为broker。
3.2.2 Kafka关键技术点
3.2.2.1 zero-copy
在Kafka上，有两个原因可能导致低效：一是太多的网络请求，二是过多的字节拷贝。为了提高效率，Kafka把message分成一组一组的，每次请求会把一组message发给相应的consumer。 此外，为了减少字节拷贝，采用了sendfile系统调用。
3.2.2.2 Exactly once message transfer
在Kafka中仅保存了每个consumer已经处理数据的offset。这样有两个好处：一是保存的数据量少；二是当consumer出错时，重新启动consumer处理数据时，只需从最近的offset开始处理数据即可。
3.2.2.3 Push/pull
Producer 向Kafka推（push）数据，consumer 从kafka 拉（pull）数据。
3.2.2.4 负载均衡和容错
Producer和broker之间没有负载均衡机制。broker和consumer之间利用zookeeper进行负载均衡。所有broker和consumer都会在zookeeper中进行注册，且zookeeper会保存他们的一些元数据信息。如果某个broker和consumer发生了变化，所有其他的broker和consumer都会得到通知。
3.2.2.5 分区
Kafka可以将主题划分为多个分区（Partition），会根据分区规则选择把消息均匀的分布到不同的分区中，这样就实现了负载均衡和水平扩展。多个订阅者可以从一个或者多个分区中同时消费数据，以支撑海量数据处理能力。由于消息是以追加到分区中的，多个分区顺序写磁盘的总效率要比随机写内存还要高，是Kafka高吞吐率的重要保证之一。
Kafka分区实现负载均衡，水平拓展，高吞吐率
为了保证数据的可靠性，每个分区节点都会设置一个Leader，以及若干节点当Follower。数据写入分区时，Leader除了自己复制一份，还会将数据复制到每个Follower上。若任一follower挂了，Kafka会再找一个follower从leader获取数据。若Leader挂了，则从Follower中抽取一个当Leader。
Kafka分区实现数据的可靠性
3.3 Kafka的技术选型
3.3.1 Confluent Platform概述
Confluent Platform 是一个流数据平台，能够组织管理来自不同数据源的数据，拥有稳定高效的系统。Confluent Platform 很容易的建立实时数据管道和流应用。通过将多个来源和位置的数据集成到一个中央数据流平台。Confluent Platform简化了连接数据源到Kafka、Kafka构建应用程序，以及安全、监控和管理Kafka的基础设施。
Confluent Platform架构
3.3.2 Kafka Connect
Kafka Connect，可以更方便的创建和管理数据流管道。它为Kafka和其它系统创建规模可扩展的、可信赖的流数据提供了一个简单的模型，通过connectors可以将大数据从其它系统导入到Kafka中，也可以从Kafka中导出到其它系统。Kafka Connect可以将完整的数据库注入到Kafka的Topic中，或者将服务器的系统监控指标注入到Kafka，然后像正常的Kafka流处理机制一样进行数据流处理。而导出工作则是将数据从Kafka Topic中导出到其它数据存储系统、查询系统或者离线分析系统等。
Kafka Connect特性包括：
• Kafka connector通用框架,提供统一的集成API
• 同时支持分布式模式和单机模式
• REST 接口，用来查看和管理Kafka connectors
• 自动化的offset管理，开发人员不必担心错误处理的影响
• 分布式、可扩展
• 流/批处理集成
Kafka connect工作原理
3.4 Kafka端到端审计
采用开源的Chaperone技术框架来实现对kafka的端到端审计。其目标是在数据流经数据管道的每个阶段，能够抓住每个消息，统计一定时间段内的数据量，并尽早准确地检测出数据的丢失、延迟和重复情况。
• 是否有数据丢失？是，那么丢失了多少数据？它们是在数据管道的哪个地方丢失的？
• 端到端的延迟是多少？如果有消息延迟，是从哪里开始的？
• 是否有数据重复？
Chaperone架构
Chaperone架构：AuditLibrary、ChaperoneService、ChaperoneCollector和WebService，它们会收集数据，并进行相关计算，自动检测出丢失和延迟的数据，并展示审计结果。在审计过程中保证每个消息只被审计一次，在层间使用一致性的时间戳。
Chaperone模块审计流程如下：
生成审计消息：ChaperoneService通过定时向特定的Kafka主题生成审计消息来记录状态
审计算法：AuditLibrary实现了审计算法，它会定时收集并打印统计时间窗
获取审计结果：ChaperoneCollector监听特定的Kafka主题，并获取所有的审计消息，存到数据库，生成仪表盘。仪表盘展示：数据的丢失情况、消息的延迟情况、查看每个主题中心的主题状态
准确展示结果：WebService提供了REST接口来查询Chaperone收集到的度量指标。通过这些接口，我们可以准确地计算出数据丢失的数量。
四、Kafka应用成果介绍
基于Kafka的技术特性，Kafka已成熟运用于某省厅的资源服务平台项目，主要用于收集日志、海量数据的微ETL，为各业务系统之间的数据共享提供一个大规模消息处理平台，以及在各地市与省厅之间形成一个数据管道。
结合对Kafka和Kafka插件的深入研究，新德汇大数据研究院自主研发了轻量级的FSP流处理引擎，用于轻便对接流数据，高效处理和实现各类流数据延展应用。
4.1 日志聚合
多个系统之间的日志通过kafka汇聚，提供审计或其他监控系统进行消费。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件服务器或HDFS）进行处理。然而Kafka忽略掉文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让Kafka处理过程延迟更低，更容易支持多数据源和分布式数据处理。比起以日志为中心的系统比如Scribe或者Flume来说，Kafka提供同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟。
4.2 消息系统
系统之间解耦，通过kafka驱动各业务系统之间的数据共享与业务流程驱动。
比起大多数的消息系统来说，Kafka有更好的吞吐量，内置的分区、冗余及容错性，让Kafka成为了一个很好的大规模消息处理应用的解决方案。消息系统一般吞吐量相对较低，但是需要更小的端到端延时，并常常依赖于Kafka提供的强大的持久性保障。在这个领域，Kafka足以媲美传统消息系统，如ActiveMR或RabbitMQ。
4.3 数据管道
Kafka让集成工作只需连接到一个单独的管道，而无需连接到每个数据生产方与消费方。
Kafka提供数据管道，让多个地市各种类型的数据资源，集成时不需要知道原始数据源的细节，发布数据时也不需要知道哪个应用程序会消费和加载这些数据，增加新系统，也只需要接入现有的Kafka流数据平台就可以。
某省厅Kafka数据管道案例
4.4 ETL流水线
未引入kafka时，数据的ETL过程需生成临时数据库，多次产生落地的文件，耗费内存，而且在再调用临时数据库时，会耗用内存。这样厚重的架构也不具备流数据处理能力。
引入kafka后，实现微ETL。通过Kafka对接流处理引擎，简化ELT流程，细化数据处理层次，低延时获取目标数据。
微ETL优点：
• 无缝衔接流处理引擎，完成数据快速ETL
• kafka构建一个可伸缩的，可靠的数据流通道
• 交互低延迟
• 微ETL实现轻便的数据处理流程
传统ETL与微ETL的对比
4.5 FSP流处理引擎
4.5.1 FSP架构
FSP架构
流处理平台：对流数据，提供核心处理引擎，流采集工具的可配置化管理平台
核心处理引擎：PIPELINEDB允许我们通过sql的方式，对数据流做操作，并把操作结果储存起来；Kafka插件可扩展kafka功能，实现SQL on kafka的各类流数据的延展应用
流采集工具集：Kafkacat实现Kafka与 sqluldr、copy收集的数据的对接，实现流数据的采集
4.5.2 Kafkacat
4.5.2.1 抓取发送消息的工具
Kafkacat是NON JVM TOOL，速度快，轻便，静态编译小于150kb，提供元数据列表展示集群/分区/主题。
Kafkacat工作模式
4.5.2.2 通过kafkacat命令加载数据生成GP外部表
通过Kafkacat实现GP与kafka的数据对接：kafkacat工具根据外部表协议可以获取GP和kafka的数据，并生成外部表，实现数据的并行加载。以外部表的形式实现数据格式错误行的容错处理
Kafkacat 加载GP外部表
五、Kafka延展应用展望
整合NiFi与kafka，并将MiNiFi作为数据采集器布放到对端数据源，形成一条可拓展并流动的流式数据处理生产线。
Kafka与NiFi结合
5.1 NiFi介绍
NiFi是一个易用、强大、可靠的数据处理与分发系统。简单来说，NiFi是用于自动化管理系统之间的数据流。通过与Kafka的对接，提供可视化命令与控制，实现数据流的展示与编辑处理功能，实现数据流的全程追踪。
NiFi特点：
1.可视化命令与控制
基于Web的用户界面，无缝体验设计，监视，控制数据流。
高扩展性
NiFi通过提供自定义类装载器模型，来确保每个扩展组件之间的约束关系被限制在非常有限的程度。因此，在创建扩展组件时，就不用再过多关注其是否会与其他组件产生冲突。数据流处理程序能够以可预测和可重复的模式执行。数据回压
NiFi提供所有队列数据的缓存，并且在队列达到指定限制或者超时的时候，能够提供数据回压。高度可配置
数据丢失容错和保证交付，低延迟和高吞吐量，动态优先级，流可以在运行时修改。安全性
系统间，NiFi可以通过双向SSL进行数据加密。并且可以允许在发送与接收端使用共享密钥，及其他机制对数据流进行加密与解密。
用户与系统间，NiFi允许双向SSL鉴定，并且提供可插入授权模式，因此可以控制用户的登录权限（例如：只读权限、数据流管理者、系统管理员）。
5.2 NiFi实现统一实时采集数据的分布式流平台
数据实时采集器MiNiFi：
• 实现增量数据和流数据的实时采集，而不是传统的定时采集，实现了更细致化的数据获取
• 可支持多种数据源，适用性强
• 实现端到端的数据采集
分布式流平台NiFi：
• 采集而来的数据，形成数据流，并对数据源进行自动记录，索引，跟踪
• 精确控制数据流
• NIFI单节点的性能是每秒处理百兆级数据，搭建NIFI集群可以提升到每秒处理G级别数据
NiFi分布式流平台
上述就是小编为大家分享的公共安全领域 Kafka 应用实践是怎样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。
