這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)公共安全領(lǐng)域 Kafka 應(yīng)用實(shí)踐是怎樣的，文章內(nèi)容豐富且以專(zhuān)業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都創(chuàng)新互聯(lián)公司是一家專(zhuān)注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃、重慶小程序開(kāi)發(fā)公司、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動(dòng)互聯(lián)開(kāi)發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立十載以來(lái)，已經(jīng)為1000+戶(hù)外休閑椅各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)?，F(xiàn)在，服務(wù)的1000+客戶(hù)與我們一路同行，見(jiàn)證我們的成長(zhǎng)；未來(lái)，我們一起分享成功的喜悅。

一、前言

本案例作為大數(shù)據(jù)框架在公共安全領(lǐng)域應(yīng)用實(shí)踐的開(kāi)篇之作，將從最基礎(chǔ)的數(shù)據(jù)架構(gòu)體系優(yōu)化講起。在接下來(lái)的章節(jié)里將詳細(xì)描述Kafka的基本原理、Kafka增強(qiáng)組件以及基于Kafka的Lambda架構(gòu)的具體應(yīng)用場(chǎng)景以及相應(yīng)的研發(fā)成果。

Lambda架構(gòu)由Storm的作者Nathan Marz提出。旨在設(shè)計(jì)出一個(gè)能滿(mǎn)足。實(shí)時(shí)大數(shù)據(jù)系統(tǒng)關(guān)鍵特性的架構(gòu)，具有高容錯(cuò)、低延時(shí)和可擴(kuò)展等特。

Lambda架構(gòu)整合離線(xiàn)計(jì)算和實(shí)時(shí)計(jì)算，融合不可變（Immutability，讀寫(xiě)分離和隔離 一系列構(gòu)原則，可集成Hadoop，Kafka，Storm，Spark,HBase等各類(lèi)大數(shù)據(jù)組件。 大數(shù)據(jù)系統(tǒng)的關(guān)鍵問(wèn)題：如何實(shí)時(shí)地在任意大數(shù)據(jù)集上進(jìn)行查詢(xún)？大數(shù)據(jù)再加上實(shí)時(shí)計(jì)算，問(wèn)題的難度比較大。Lambda架構(gòu)通過(guò)分解的三層架構(gòu)來(lái)解決該問(wèn)題：Batch Layer，Speed Layer和Serving Layer。如下圖所示意。

Lambda架構(gòu)圖

數(shù)據(jù)流進(jìn)入系統(tǒng)后，同時(shí)發(fā)往Batch Layer和Speed Layer處理。Batch Layer以不可變模型離線(xiàn)存儲(chǔ)所有數(shù)據(jù)集，通過(guò)在全體數(shù)據(jù)集上不斷重新計(jì)算構(gòu)建查詢(xún)所對(duì)應(yīng)的Batch Views。Speed Layer處理增量的實(shí)時(shí)數(shù)據(jù)流，不斷更新查詢(xún)所對(duì)應(yīng)的Real time Views。Serving Layer響應(yīng)用戶(hù)的查詢(xún)請(qǐng)求，合并Batch View和Real time View中的結(jié)果數(shù)據(jù)集到最終的數(shù)據(jù)集。

二、基于Kafka的Lambda架構(gòu)

2.1 某省大數(shù)據(jù)平臺(tái)實(shí)踐案例
以某省廳大數(shù)據(jù)建設(shè)方案為例，將Kafka作為統(tǒng)一的數(shù)據(jù)流通道（data pipeline）。Kafka分為地市和省廳兩級(jí)，地市數(shù)據(jù)首先經(jīng)過(guò)流式化處理發(fā)送到地市的Kafka，經(jīng)過(guò)標(biāo)準(zhǔn)化后，地市Kafka的再匯集到省廳Kafka。

某省大數(shù)據(jù)平臺(tái)實(shí)踐

2.2 引入Kafka的必要性
在大數(shù)據(jù)系統(tǒng)中，常常會(huì)碰到一個(gè)問(wèn)題，整個(gè)大數(shù)據(jù)是由各個(gè)子系統(tǒng)組成，數(shù)據(jù)需要在各個(gè)子系統(tǒng)中高性能、低延遲的不停流轉(zhuǎn)。傳統(tǒng)的企業(yè)消息系統(tǒng)并不是非常適合大規(guī)模的數(shù)據(jù)處理。容易造成日志數(shù)據(jù)難以收集，容易丟失信息，Oracle實(shí)例之間的管道無(wú)法供其它系統(tǒng)使用，數(shù)據(jù)架構(gòu)易創(chuàng)建難擴(kuò)展，數(shù)據(jù)質(zhì)量差等問(wèn)題。為了同時(shí)搞定在線(xiàn)應(yīng)用（消息）和離線(xiàn)應(yīng)用（數(shù)據(jù)文件，日志），Kafka就出現(xiàn)了。Kafka可以起到兩個(gè)作用：
? 降低系統(tǒng)組網(wǎng)復(fù)雜度。
? 降低編程復(fù)雜度，各個(gè)子系統(tǒng)不再是相互協(xié)商接口，各個(gè)子系統(tǒng)類(lèi)似插口插在插座上，Kafka承擔(dān)高速數(shù)據(jù)總線(xiàn)的作用。

傳統(tǒng)數(shù)據(jù)架構(gòu)

引入Kafka后，可以構(gòu)建以流為中心數(shù)據(jù)架構(gòu)。Kafka是作為一個(gè)全局?jǐn)?shù)據(jù)管道。每個(gè)系統(tǒng)都向這個(gè)中心管道發(fā)送數(shù)據(jù)或者從中獲取數(shù)據(jù)。應(yīng)用程序或流處理程序可以接入管道并創(chuàng)建新的派生流。這些派生流又可以供其它各種系統(tǒng)使用。

以流為中心的數(shù)據(jù)架構(gòu)

三、Kafka技術(shù)分析

3.1 Kafka的特點(diǎn)
Kafka可以讓合適的數(shù)據(jù)以合適的形式出現(xiàn)在合適的地方。Kafka的做法是提供消息隊(duì)列，讓生產(chǎn)者單往隊(duì)列的末尾添加數(shù)據(jù)，讓多個(gè)消費(fèi)者從隊(duì)列里面依次讀取數(shù)據(jù)然后自行處理。

Kafka消息隊(duì)列

? 分布式系統(tǒng)，易于向外擴(kuò)展。所有的producer、broker和consumer都會(huì)有多個(gè)，均為分布式的。無(wú)需停機(jī)即可擴(kuò)展機(jī)器。
? 提供Pub/Sub方式的海量消息處理。 據(jù)了解，Kafka每秒可以生產(chǎn)約25萬(wàn)消息（50 MB），每秒處理55萬(wàn)消息（110 MB）。
? 以高容錯(cuò)的方式存儲(chǔ)海量數(shù)據(jù)流。
? 保證數(shù)據(jù)流的順序，處理關(guān)鍵更新。
? 提供消息的長(zhǎng)時(shí)間存儲(chǔ)，將消息持久化到磁盤(pán)，因此可用于批量消費(fèi)，例如ETL，以及實(shí)時(shí)應(yīng)用程序。通過(guò)將數(shù)據(jù)持久化到硬盤(pán)以及replication防止數(shù)據(jù)丟失。
? 能夠緩存或持久化數(shù)據(jù)，支持與批處理系統(tǒng)（如Hadoop）的集成。
? 為實(shí)時(shí)應(yīng)用程序提供低延時(shí)數(shù)據(jù)傳輸和處理。
? 支持online和offline的場(chǎng)景。
? 消息被處理的狀態(tài)是在consumer端維護(hù)，而不是由server端維護(hù)。當(dāng)失敗時(shí)能自動(dòng)平衡。

3.2 Kafka原理分析
3.2.1 Kafka總體架構(gòu)

Kafka總體架構(gòu)

Kafka的整體架構(gòu)非常簡(jiǎn)單，是顯式分布式架構(gòu)，producer、broker（kafka）和consumer都可以有多個(gè)。Producer，consumer實(shí)現(xiàn)Kafka注冊(cè)的接口，數(shù)據(jù)從producer發(fā)送到broker，broker承擔(dān)一個(gè)中間緩存和分發(fā)的作用。broker分發(fā)注冊(cè)到系統(tǒng)中的consumer。broker的作用類(lèi)似于緩存，即活躍的數(shù)據(jù)和離線(xiàn)處理系統(tǒng)之間的緩存?？蛻?hù)端和服務(wù)器端的通信，是基于簡(jiǎn)單、高性能且與編程語(yǔ)言無(wú)關(guān)的TCP協(xié)議。

基本概念：
? Topic：特指Kafka處理的消息源（feeds of messages）的不同分類(lèi)。
? Partition：Topic物理上的分組，一個(gè)topic可以分為多個(gè)partition，每個(gè)partition是一個(gè)有序的隊(duì)列。partition中的每條消息都會(huì)被分配一個(gè)有序的id（offset）。
? Message：消息，是通信的基本單位，每個(gè)producer可以向一個(gè)topic（主題）發(fā)布一些消息。
? Producers：消息和數(shù)據(jù)生產(chǎn)者，向Kafka的一個(gè)topic發(fā)布消息的過(guò)程叫做producers。
? Consumers：消息和數(shù)據(jù)消費(fèi)者，訂閱topics并處理其發(fā)布的消息的過(guò)程叫做consumers。
? Broker：緩存代理，Kafka集群中的一臺(tái)或多臺(tái)服務(wù)器統(tǒng)稱(chēng)為broker。

3.2.2 Kafka關(guān)鍵技術(shù)點(diǎn)
3.2.2.1 zero-copy
在Kafka上，有兩個(gè)原因可能導(dǎo)致低效：一是太多的網(wǎng)絡(luò)請(qǐng)求，二是過(guò)多的字節(jié)拷貝。為了提高效率，Kafka把message分成一組一組的，每次請(qǐng)求會(huì)把一組message發(fā)給相應(yīng)的consumer。 此外，為了減少字節(jié)拷貝，采用了sendfile系統(tǒng)調(diào)用。

3.2.2.2 Exactly once message transfer
在Kafka中僅保存了每個(gè)consumer已經(jīng)處理數(shù)據(jù)的offset。這樣有兩個(gè)好處：一是保存的數(shù)據(jù)量少；二是當(dāng)consumer出錯(cuò)時(shí)，重新啟動(dòng)consumer處理數(shù)據(jù)時(shí)，只需從最近的offset開(kāi)始處理數(shù)據(jù)即可。

3.2.2.3 Push/pull
Producer 向Kafka推（push）數(shù)據(jù)，consumer 從kafka 拉（pull）數(shù)據(jù)。

3.2.2.4 負(fù)載均衡和容錯(cuò)
Producer和broker之間沒(méi)有負(fù)載均衡機(jī)制。broker和consumer之間利用zookeeper進(jìn)行負(fù)載均衡。所有broker和consumer都會(huì)在zookeeper中進(jìn)行注冊(cè)，且zookeeper會(huì)保存他們的一些元數(shù)據(jù)信息。如果某個(gè)broker和consumer發(fā)生了變化，所有其他的broker和consumer都會(huì)得到通知。

3.2.2.5 分區(qū)
Kafka可以將主題劃分為多個(gè)分區(qū)（Partition），會(huì)根據(jù)分區(qū)規(guī)則選擇把消息均勻的分布到不同的分區(qū)中，這樣就實(shí)現(xiàn)了負(fù)載均衡和水平擴(kuò)展。多個(gè)訂閱者可以從一個(gè)或者多個(gè)分區(qū)中同時(shí)消費(fèi)數(shù)據(jù)，以支撐海量數(shù)據(jù)處理能力。由于消息是以追加到分區(qū)中的，多個(gè)分區(qū)順序?qū)懘疟P(pán)的總效率要比隨機(jī)寫(xiě)內(nèi)存還要高，是Kafka高吞吐率的重要保證之一。

Kafka分區(qū)實(shí)現(xiàn)負(fù)載均衡，水平拓展，高吞吐率

為了保證數(shù)據(jù)的可靠性，每個(gè)分區(qū)節(jié)點(diǎn)都會(huì)設(shè)置一個(gè)Leader，以及若干節(jié)點(diǎn)當(dāng)Follower。數(shù)據(jù)寫(xiě)入分區(qū)時(shí)，Leader除了自己復(fù)制一份，還會(huì)將數(shù)據(jù)復(fù)制到每個(gè)Follower上。若任一follower掛了，Kafka會(huì)再找一個(gè)follower從leader獲取數(shù)據(jù)。若Leader掛了，則從Follower中抽取一個(gè)當(dāng)Leader。

Kafka分區(qū)實(shí)現(xiàn)數(shù)據(jù)的可靠性

3.3 Kafka的技術(shù)選型
3.3.1 Confluent Platform概述
Confluent Platform 是一個(gè)流數(shù)據(jù)平臺(tái)，能夠組織管理來(lái)自不同數(shù)據(jù)源的數(shù)據(jù)，擁有穩(wěn)定高效的系統(tǒng)。Confluent Platform 很容易的建立實(shí)時(shí)數(shù)據(jù)管道和流應(yīng)用。通過(guò)將多個(gè)來(lái)源和位置的數(shù)據(jù)集成到一個(gè)中央數(shù)據(jù)流平臺(tái)。Confluent Platform簡(jiǎn)化了連接數(shù)據(jù)源到Kafka、Kafka構(gòu)建應(yīng)用程序，以及安全、監(jiān)控和管理Kafka的基礎(chǔ)設(shè)施。

Confluent Platform架構(gòu)

3.3.2 Kafka Connect
Kafka Connect，可以更方便的創(chuàng)建和管理數(shù)據(jù)流管道。它為Kafka和其它系統(tǒng)創(chuàng)建規(guī)?？蓴U(kuò)展的、可信賴(lài)的流數(shù)據(jù)提供了一個(gè)簡(jiǎn)單的模型，通過(guò)connectors可以將大數(shù)據(jù)從其它系統(tǒng)導(dǎo)入到Kafka中，也可以從Kafka中導(dǎo)出到其它系統(tǒng)。Kafka Connect可以將完整的數(shù)據(jù)庫(kù)注入到Kafka的Topic中，或者將服務(wù)器的系統(tǒng)監(jiān)控指標(biāo)注入到Kafka，然后像正常的Kafka流處理機(jī)制一樣進(jìn)行數(shù)據(jù)流處理。而導(dǎo)出工作則是將數(shù)據(jù)從Kafka Topic中導(dǎo)出到其它數(shù)據(jù)存儲(chǔ)系統(tǒng)、查詢(xún)系統(tǒng)或者離線(xiàn)分析系統(tǒng)等。
Kafka Connect特性包括：
? Kafka connector通用框架,提供統(tǒng)一的集成API
? 同時(shí)支持分布式模式和單機(jī)模式
? REST 接口，用來(lái)查看和管理Kafka connectors
? 自動(dòng)化的offset管理，開(kāi)發(fā)人員不必?fù)?dān)心錯(cuò)誤處理的影響
? 分布式、可擴(kuò)展
? 流/批處理集成

Kafka connect工作原理

3.4 Kafka端到端審計(jì)
采用開(kāi)源的Chaperone技術(shù)框架來(lái)實(shí)現(xiàn)對(duì)kafka的端到端審計(jì)。其目標(biāo)是在數(shù)據(jù)流經(jīng)數(shù)據(jù)管道的每個(gè)階段，能夠抓住每個(gè)消息，統(tǒng)計(jì)一定時(shí)間段內(nèi)的數(shù)據(jù)量，并盡早準(zhǔn)確地檢測(cè)出數(shù)據(jù)的丟失、延遲和重復(fù)情況。
? 是否有數(shù)據(jù)丟失？是，那么丟失了多少數(shù)據(jù)？它們是在數(shù)據(jù)管道的哪個(gè)地方丟失的？
? 端到端的延遲是多少？如果有消息延遲，是從哪里開(kāi)始的？
? 是否有數(shù)據(jù)重復(fù)？

Chaperone架構(gòu)

Chaperone架構(gòu)：AuditLibrary、ChaperoneService、ChaperoneCollector和WebService，它們會(huì)收集數(shù)據(jù)，并進(jìn)行相關(guān)計(jì)算，自動(dòng)檢測(cè)出丟失和延遲的數(shù)據(jù)，并展示審計(jì)結(jié)果。在審計(jì)過(guò)程中保證每個(gè)消息只被審計(jì)一次，在層間使用一致性的時(shí)間戳。

Chaperone模塊審計(jì)流程如下：

1. 生成審計(jì)消息：ChaperoneService通過(guò)定時(shí)向特定的Kafka主題生成審計(jì)消息來(lái)記錄狀態(tài)

2. 審計(jì)算法：AuditLibrary實(shí)現(xiàn)了審計(jì)算法，它會(huì)定時(shí)收集并打印統(tǒng)計(jì)時(shí)間窗

3. 獲取審計(jì)結(jié)果：ChaperoneCollector監(jiān)聽(tīng)特定的Kafka主題，并獲取所有的審計(jì)消息，存到數(shù)據(jù)庫(kù)，生成儀表盤(pán)。儀表盤(pán)展示：數(shù)據(jù)的丟失情況、消息的延遲情況、查看每個(gè)主題中心的主題狀態(tài)

4. 準(zhǔn)確展示結(jié)果：WebService提供了REST接口來(lái)查詢(xún)Chaperone收集到的度量指標(biāo)。通過(guò)這些接口，我們可以準(zhǔn)確地計(jì)算出數(shù)據(jù)丟失的數(shù)量。

四、Kafka應(yīng)用成果介紹

基于Kafka的技術(shù)特性，Kafka已成熟運(yùn)用于某省廳的資源服務(wù)平臺(tái)項(xiàng)目，主要用于收集日志、海量數(shù)據(jù)的微ETL，為各業(yè)務(wù)系統(tǒng)之間的數(shù)據(jù)共享提供一個(gè)大規(guī)模消息處理平臺(tái)，以及在各地市與省廳之間形成一個(gè)數(shù)據(jù)管道。

結(jié)合對(duì)Kafka和Kafka插件的深入研究，新德匯大數(shù)據(jù)研究院自主研發(fā)了輕量級(jí)的FSP流處理引擎，用于輕便對(duì)接流數(shù)據(jù)，高效處理和實(shí)現(xiàn)各類(lèi)流數(shù)據(jù)延展應(yīng)用。

4.1 日志聚合
多個(gè)系統(tǒng)之間的日志通過(guò)kafka匯聚，提供審計(jì)或其他監(jiān)控系統(tǒng)進(jìn)行消費(fèi)。日志聚合一般來(lái)說(shuō)是從服務(wù)器上收集日志文件，然后放到一個(gè)集中的位置（文件服務(wù)器或HDFS）進(jìn)行處理。然而Kafka忽略掉文件的細(xì)節(jié)，將其更清晰地抽象成一個(gè)個(gè)日志或事件的消息流。這就讓Kafka處理過(guò)程延遲更低，更容易支持多數(shù)據(jù)源和分布式數(shù)據(jù)處理。比起以日志為中心的系統(tǒng)比如Scribe或者Flume來(lái)說(shuō)，Kafka提供同樣高效的性能和因?yàn)閺?fù)制導(dǎo)致的更高的耐用性保證，以及更低的端到端延遲。

4.2 消息系統(tǒng)
系統(tǒng)之間解耦，通過(guò)kafka驅(qū)動(dòng)各業(yè)務(wù)系統(tǒng)之間的數(shù)據(jù)共享與業(yè)務(wù)流程驅(qū)動(dòng)。

比起大多數(shù)的消息系統(tǒng)來(lái)說(shuō)，Kafka有更好的吞吐量，內(nèi)置的分區(qū)、冗余及容錯(cuò)性，讓Kafka成為了一個(gè)很好的大規(guī)模消息處理應(yīng)用的解決方案。消息系統(tǒng)一般吞吐量相對(duì)較低，但是需要更小的端到端延時(shí)，并常常依賴(lài)于Kafka提供的強(qiáng)大的持久性保障。在這個(gè)領(lǐng)域，Kafka足以媲美傳統(tǒng)消息系統(tǒng)，如ActiveMR或RabbitMQ。

4.3 數(shù)據(jù)管道
Kafka讓集成工作只需連接到一個(gè)單獨(dú)的管道，而無(wú)需連接到每個(gè)數(shù)據(jù)生產(chǎn)方與消費(fèi)方。

Kafka提供數(shù)據(jù)管道，讓多個(gè)地市各種類(lèi)型的數(shù)據(jù)資源，集成時(shí)不需要知道原始數(shù)據(jù)源的細(xì)節(jié)，發(fā)布數(shù)據(jù)時(shí)也不需要知道哪個(gè)應(yīng)用程序會(huì)消費(fèi)和加載這些數(shù)據(jù)，增加新系統(tǒng)，也只需要接入現(xiàn)有的Kafka流數(shù)據(jù)平臺(tái)就可以。

某省廳Kafka數(shù)據(jù)管道案例

4.4 ETL流水線(xiàn)
未引入kafka時(shí)，數(shù)據(jù)的ETL過(guò)程需生成臨時(shí)數(shù)據(jù)庫(kù)，多次產(chǎn)生落地的文件，耗費(fèi)內(nèi)存，而且在再調(diào)用臨時(shí)數(shù)據(jù)庫(kù)時(shí)，會(huì)耗用內(nèi)存。這樣厚重的架構(gòu)也不具備流數(shù)據(jù)處理能力。

引入kafka后，實(shí)現(xiàn)微ETL。通過(guò)Kafka對(duì)接流處理引擎，簡(jiǎn)化ELT流程，細(xì)化數(shù)據(jù)處理層次，低延時(shí)獲取目標(biāo)數(shù)據(jù)。

微ETL優(yōu)點(diǎn)：
? 無(wú)縫銜接流處理引擎，完成數(shù)據(jù)快速ETL
? kafka構(gòu)建一個(gè)可伸縮的，可靠的數(shù)據(jù)流通道
? 交互低延遲
? 微ETL實(shí)現(xiàn)輕便的數(shù)據(jù)處理流程

傳統(tǒng)ETL與微ETL的對(duì)比

4.5 FSP流處理引擎
4.5.1 FSP架構(gòu)

FSP架構(gòu)

流處理平臺(tái)：對(duì)流數(shù)據(jù)，提供核心處理引擎，流采集工具的可配置化管理平臺(tái)

核心處理引擎：PIPELINEDB允許我們通過(guò)sql的方式，對(duì)數(shù)據(jù)流做操作，并把操作結(jié)果儲(chǔ)存起來(lái)；Kafka插件可擴(kuò)展kafka功能，實(shí)現(xiàn)SQL on kafka的各類(lèi)流數(shù)據(jù)的延展應(yīng)用

流采集工具集：Kafkacat實(shí)現(xiàn)Kafka與 sqluldr、copy收集的數(shù)據(jù)的對(duì)接，實(shí)現(xiàn)流數(shù)據(jù)的采集

4.5.2 Kafkacat
4.5.2.1 抓取發(fā)送消息的工具
Kafkacat是NON JVM TOOL，速度快，輕便，靜態(tài)編譯小于150kb，提供元數(shù)據(jù)列表展示集群/分區(qū)/主題。

Kafkacat工作模式

4.5.2.2 通過(guò)kafkacat命令加載數(shù)據(jù)生成GP外部表
通過(guò)Kafkacat實(shí)現(xiàn)GP與kafka的數(shù)據(jù)對(duì)接：kafkacat工具根據(jù)外部表協(xié)議可以獲取GP和kafka的數(shù)據(jù)，并生成外部表，實(shí)現(xiàn)數(shù)據(jù)的并行加載。以外部表的形式實(shí)現(xiàn)數(shù)據(jù)格式錯(cuò)誤行的容錯(cuò)處理

Kafkacat 加載GP外部表

五、Kafka延展應(yīng)用展望

整合NiFi與kafka，并將MiNiFi作為數(shù)據(jù)采集器布放到對(duì)端數(shù)據(jù)源，形成一條可拓展并流動(dòng)的流式數(shù)據(jù)處理生產(chǎn)線(xiàn)。

Kafka與NiFi結(jié)合

5.1 NiFi介紹
NiFi是一個(gè)易用、強(qiáng)大、可靠的數(shù)據(jù)處理與分發(fā)系統(tǒng)。簡(jiǎn)單來(lái)說(shuō)，NiFi是用于自動(dòng)化管理系統(tǒng)之間的數(shù)據(jù)流。通過(guò)與Kafka的對(duì)接，提供可視化命令與控制，實(shí)現(xiàn)數(shù)據(jù)流的展示與編輯處理功能，實(shí)現(xiàn)數(shù)據(jù)流的全程追蹤。

NiFi特點(diǎn)：
1.可視化命令與控制
基于Web的用戶(hù)界面，無(wú)縫體驗(yàn)設(shè)計(jì)，監(jiān)視，控制數(shù)據(jù)流。

2. 高擴(kuò)展性
   NiFi通過(guò)提供自定義類(lèi)裝載器模型，來(lái)確保每個(gè)擴(kuò)展組件之間的約束關(guān)系被限制在非常有限的程度。因此，在創(chuàng)建擴(kuò)展組件時(shí)，就不用再過(guò)多關(guān)注其是否會(huì)與其他組件產(chǎn)生沖突。數(shù)據(jù)流處理程序能夠以可預(yù)測(cè)和可重復(fù)的模式執(zhí)行。

3. 數(shù)據(jù)回壓
   NiFi提供所有隊(duì)列數(shù)據(jù)的緩存，并且在隊(duì)列達(dá)到指定限制或者超時(shí)的時(shí)候，能夠提供數(shù)據(jù)回壓。

4. 高度可配置
   數(shù)據(jù)丟失容錯(cuò)和保證交付，低延遲和高吞吐量，動(dòng)態(tài)優(yōu)先級(jí)，流可以在運(yùn)行時(shí)修改。

5. 安全性
   系統(tǒng)間，NiFi可以通過(guò)雙向SSL進(jìn)行數(shù)據(jù)加密。并且可以允許在發(fā)送與接收端使用共享密鑰，及其他機(jī)制對(duì)數(shù)據(jù)流進(jìn)行加密與解密。

用戶(hù)與系統(tǒng)間，NiFi允許雙向SSL鑒定，并且提供可插入授權(quán)模式，因此可以控制用戶(hù)的登錄權(quán)限（例如：只讀權(quán)限、數(shù)據(jù)流管理者、系統(tǒng)管理員）。

5.2 NiFi實(shí)現(xiàn)統(tǒng)一實(shí)時(shí)采集數(shù)據(jù)的分布式流平臺(tái)
數(shù)據(jù)實(shí)時(shí)采集器MiNiFi：
? 實(shí)現(xiàn)增量數(shù)據(jù)和流數(shù)據(jù)的實(shí)時(shí)采集，而不是傳統(tǒng)的定時(shí)采集，實(shí)現(xiàn)了更細(xì)致化的數(shù)據(jù)獲取
? 可支持多種數(shù)據(jù)源，適用性強(qiáng)
? 實(shí)現(xiàn)端到端的數(shù)據(jù)采集
分布式流平臺(tái)NiFi：
? 采集而來(lái)的數(shù)據(jù)，形成數(shù)據(jù)流，并對(duì)數(shù)據(jù)源進(jìn)行自動(dòng)記錄，索引，跟蹤
? 精確控制數(shù)據(jù)流
? NIFI單節(jié)點(diǎn)的性能是每秒處理百兆級(jí)數(shù)據(jù)，搭建NIFI集群可以提升到每秒處理G級(jí)別數(shù)據(jù)

NiFi分布式流平臺(tái)

上述就是小編為大家分享的公共安全領(lǐng)域 Kafka 應(yīng)用實(shí)踐是怎樣的了，如果剛好有類(lèi)似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。