這期內容當中小編將會給大家?guī)碛嘘P公共安全領域 Kafka 應用實踐是怎樣的，文章內容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
一、前言
本案例作為大數(shù)據(jù)框架在公共安全領域應用實踐的開篇之作，將從最基礎的數(shù)據(jù)架構體系優(yōu)化講起。在接下來的章節(jié)里將詳細描述Kafka的基本原理、Kafka增強組件以及基于Kafka的Lambda架構的具體應用場景以及相應的研發(fā)成果。
Lambda架構由Storm的作者Nathan Marz提出。旨在設計出一個能滿足。實時大數(shù)據(jù)系統(tǒng)關鍵特性的架構，具有高容錯、低延時和可擴展等特。
Lambda架構整合離線計算和實時計算，融合不可變（Immutability，讀寫分離和隔離 一系列構原則，可集成Hadoop，Kafka，Storm，Spark,HBase等各類大數(shù)據(jù)組件。 大數(shù)據(jù)系統(tǒng)的關鍵問題：如何實時地在任意大數(shù)據(jù)集上進行查詢？大數(shù)據(jù)再加上實時計算，問題的難度比較大。Lambda架構通過分解的三層架構來解決該問題：Batch Layer，Speed Layer和Serving Layer。如下圖所示意。
Lambda架構圖
數(shù)據(jù)流進入系統(tǒng)后，同時發(fā)往Batch Layer和Speed Layer處理。Batch Layer以不可變模型離線存儲所有數(shù)據(jù)集，通過在全體數(shù)據(jù)集上不斷重新計算構建查詢所對應的Batch Views。Speed Layer處理增量的實時數(shù)據(jù)流，不斷更新查詢所對應的Real time Views。Serving Layer響應用戶的查詢請求，合并Batch View和Real time View中的結果數(shù)據(jù)集到最終的數(shù)據(jù)集。
二、基于Kafka的Lambda架構
2.1 某省大數(shù)據(jù)平臺實踐案例
以某省廳大數(shù)據(jù)建設方案為例，將Kafka作為統(tǒng)一的數(shù)據(jù)流通道（data pipeline）。Kafka分為地市和省廳兩級，地市數(shù)據(jù)首先經過流式化處理發(fā)送到地市的Kafka，經過標準化后，地市Kafka的再匯集到省廳Kafka。
某省大數(shù)據(jù)平臺實踐
2.2 引入Kafka的必要性
在大數(shù)據(jù)系統(tǒng)中，常常會碰到一個問題，整個大數(shù)據(jù)是由各個子系統(tǒng)組成，數(shù)據(jù)需要在各個子系統(tǒng)中高性能、低延遲的不停流轉。傳統(tǒng)的企業(yè)消息系統(tǒng)并不是非常適合大規(guī)模的數(shù)據(jù)處理。容易造成日志數(shù)據(jù)難以收集，容易丟失信息，Oracle實例之間的管道無法供其它系統(tǒng)使用，數(shù)據(jù)架構易創(chuàng)建難擴展，數(shù)據(jù)質量差等問題。為了同時搞定在線應用（消息）和離線應用（數(shù)據(jù)文件，日志），Kafka就出現(xiàn)了。Kafka可以起到兩個作用：
? 降低系統(tǒng)組網復雜度。
? 降低編程復雜度，各個子系統(tǒng)不再是相互協(xié)商接口，各個子系統(tǒng)類似插口插在插座上，Kafka承擔高速數(shù)據(jù)總線的作用。
傳統(tǒng)數(shù)據(jù)架構
引入Kafka后，可以構建以流為中心數(shù)據(jù)架構。Kafka是作為一個全局數(shù)據(jù)管道。每個系統(tǒng)都向這個中心管道發(fā)送數(shù)據(jù)或者從中獲取數(shù)據(jù)。應用程序或流處理程序可以接入管道并創(chuàng)建新的派生流。這些派生流又可以供其它各種系統(tǒng)使用。
以流為中心的數(shù)據(jù)架構
三、Kafka技術分析
3.1 Kafka的特點
Kafka可以讓合適的數(shù)據(jù)以合適的形式出現(xiàn)在合適的地方。Kafka的做法是提供消息隊列，讓生產者單往隊列的末尾添加數(shù)據(jù)，讓多個消費者從隊列里面依次讀取數(shù)據(jù)然后自行處理。
Kafka消息隊列
? 分布式系統(tǒng)，易于向外擴展。所有的producer、broker和consumer都會有多個，均為分布式的。無需停機即可擴展機器。
? 提供Pub/Sub方式的海量消息處理。 據(jù)了解，Kafka每秒可以生產約25萬消息（50 MB），每秒處理55萬消息（110 MB）。
? 以高容錯的方式存儲海量數(shù)據(jù)流。
? 保證數(shù)據(jù)流的順序，處理關鍵更新。
? 提供消息的長時間存儲，將消息持久化到磁盤，因此可用于批量消費，例如ETL，以及實時應用程序。通過將數(shù)據(jù)持久化到硬盤以及replication防止數(shù)據(jù)丟失。
? 能夠緩存或持久化數(shù)據(jù)，支持與批處理系統(tǒng)（如Hadoop）的集成。
? 為實時應用程序提供低延時數(shù)據(jù)傳輸和處理。
? 支持online和offline的場景。
? 消息被處理的狀態(tài)是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。
3.2 Kafka原理分析
3.2.1 Kafka總體架構
Kafka總體架構
Kafka的整體架構非常簡單，是顯式分布式架構，producer、broker（kafka）和consumer都可以有多個。Producer，consumer實現(xiàn)Kafka注冊的接口，數(shù)據(jù)從producer發(fā)送到broker，broker承擔一個中間緩存和分發(fā)的作用。broker分發(fā)注冊到系統(tǒng)中的consumer。broker的作用類似于緩存，即活躍的數(shù)據(jù)和離線處理系統(tǒng)之間的緩存?？蛻舳撕头掌鞫说耐ㄐ牛腔诤唵?、高性能且與編程語言無關的TCP協(xié)議。
基本概念：
? Topic：特指Kafka處理的消息源（feeds of messages）的不同分類。
? Partition：Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。
? Message：消息，是通信的基本單位，每個producer可以向一個topic（主題）發(fā)布一些消息。
? Producers：消息和數(shù)據(jù)生產者，向Kafka的一個topic發(fā)布消息的過程叫做producers。
? Consumers：消息和數(shù)據(jù)消費者，訂閱topics并處理其發(fā)布的消息的過程叫做consumers。
? Broker：緩存代理，Kafka集群中的一臺或多臺服務器統(tǒng)稱為broker。
3.2.2 Kafka關鍵技術點
3.2.2.1 zero-copy
在Kafka上，有兩個原因可能導致低效：一是太多的網絡請求，二是過多的字節(jié)拷貝。為了提高效率，Kafka把message分成一組一組的，每次請求會把一組message發(fā)給相應的consumer。 此外，為了減少字節(jié)拷貝，采用了sendfile系統(tǒng)調用。
3.2.2.2 Exactly once message transfer
在Kafka中僅保存了每個consumer已經處理數(shù)據(jù)的offset。這樣有兩個好處：一是保存的數(shù)據(jù)量少；二是當consumer出錯時，重新啟動consumer處理數(shù)據(jù)時，只需從最近的offset開始處理數(shù)據(jù)即可。
3.2.2.3 Push/pull
Producer 向Kafka推（push）數(shù)據(jù)，consumer 從kafka 拉（pull）數(shù)據(jù)。
3.2.2.4 負載均衡和容錯
Producer和broker之間沒有負載均衡機制。broker和consumer之間利用zookeeper進行負載均衡。所有broker和consumer都會在zookeeper中進行注冊，且zookeeper會保存他們的一些元數(shù)據(jù)信息。如果某個broker和consumer發(fā)生了變化，所有其他的broker和consumer都會得到通知。
3.2.2.5 分區(qū)
Kafka可以將主題劃分為多個分區(qū)（Partition），會根據(jù)分區(qū)規(guī)則選擇把消息均勻的分布到不同的分區(qū)中，這樣就實現(xiàn)了負載均衡和水平擴展。多個訂閱者可以從一個或者多個分區(qū)中同時消費數(shù)據(jù)，以支撐海量數(shù)據(jù)處理能力。由于消息是以追加到分區(qū)中的，多個分區(qū)順序寫磁盤的總效率要比隨機寫內存還要高，是Kafka高吞吐率的重要保證之一。
Kafka分區(qū)實現(xiàn)負載均衡，水平拓展，高吞吐率
為了保證數(shù)據(jù)的可靠性，每個分區(qū)節(jié)點都會設置一個Leader，以及若干節(jié)點當Follower。數(shù)據(jù)寫入分區(qū)時，Leader除了自己復制一份，還會將數(shù)據(jù)復制到每個Follower上。若任一follower掛了，Kafka會再找一個follower從leader獲取數(shù)據(jù)。若Leader掛了，則從Follower中抽取一個當Leader。
Kafka分區(qū)實現(xiàn)數(shù)據(jù)的可靠性
3.3 Kafka的技術選型
3.3.1 Confluent Platform概述
Confluent Platform 是一個流數(shù)據(jù)平臺，能夠組織管理來自不同數(shù)據(jù)源的數(shù)據(jù)，擁有穩(wěn)定高效的系統(tǒng)。Confluent Platform 很容易的建立實時數(shù)據(jù)管道和流應用。通過將多個來源和位置的數(shù)據(jù)集成到一個中央數(shù)據(jù)流平臺。Confluent Platform簡化了連接數(shù)據(jù)源到Kafka、Kafka構建應用程序，以及安全、監(jiān)控和管理Kafka的基礎設施。
Confluent Platform架構
3.3.2 Kafka Connect
Kafka Connect，可以更方便的創(chuàng)建和管理數(shù)據(jù)流管道。它為Kafka和其它系統(tǒng)創(chuàng)建規(guī)?？蓴U展的、可信賴的流數(shù)據(jù)提供了一個簡單的模型，通過connectors可以將大數(shù)據(jù)從其它系統(tǒng)導入到Kafka中，也可以從Kafka中導出到其它系統(tǒng)。Kafka Connect可以將完整的數(shù)據(jù)庫注入到Kafka的Topic中，或者將服務器的系統(tǒng)監(jiān)控指標注入到Kafka，然后像正常的Kafka流處理機制一樣進行數(shù)據(jù)流處理。而導出工作則是將數(shù)據(jù)從Kafka Topic中導出到其它數(shù)據(jù)存儲系統(tǒng)、查詢系統(tǒng)或者離線分析系統(tǒng)等。
Kafka Connect特性包括：
? Kafka connector通用框架,提供統(tǒng)一的集成API
? 同時支持分布式模式和單機模式
? REST 接口，用來查看和管理Kafka connectors
? 自動化的offset管理，開發(fā)人員不必擔心錯誤處理的影響
? 分布式、可擴展
? 流/批處理集成
Kafka connect工作原理
3.4 Kafka端到端審計
采用開源的Chaperone技術框架來實現(xiàn)對kafka的端到端審計。其目標是在數(shù)據(jù)流經數(shù)據(jù)管道的每個階段，能夠抓住每個消息，統(tǒng)計一定時間段內的數(shù)據(jù)量，并盡早準確地檢測出數(shù)據(jù)的丟失、延遲和重復情況。
? 是否有數(shù)據(jù)丟失？是，那么丟失了多少數(shù)據(jù)？它們是在數(shù)據(jù)管道的哪個地方丟失的？
? 端到端的延遲是多少？如果有消息延遲，是從哪里開始的？
? 是否有數(shù)據(jù)重復？
Chaperone架構
Chaperone架構：AuditLibrary、ChaperoneService、ChaperoneCollector和WebService，它們會收集數(shù)據(jù)，并進行相關計算，自動檢測出丟失和延遲的數(shù)據(jù)，并展示審計結果。在審計過程中保證每個消息只被審計一次，在層間使用一致性的時間戳。
Chaperone模塊審計流程如下：
生成審計消息：ChaperoneService通過定時向特定的Kafka主題生成審計消息來記錄狀態(tài)
審計算法：AuditLibrary實現(xiàn)了審計算法，它會定時收集并打印統(tǒng)計時間窗
獲取審計結果：ChaperoneCollector監(jiān)聽特定的Kafka主題，并獲取所有的審計消息，存到數(shù)據(jù)庫，生成儀表盤。儀表盤展示：數(shù)據(jù)的丟失情況、消息的延遲情況、查看每個主題中心的主題狀態(tài)
準確展示結果：WebService提供了REST接口來查詢Chaperone收集到的度量指標。通過這些接口，我們可以準確地計算出數(shù)據(jù)丟失的數(shù)量。
四、Kafka應用成果介紹
基于Kafka的技術特性，Kafka已成熟運用于某省廳的資源服務平臺項目，主要用于收集日志、海量數(shù)據(jù)的微ETL，為各業(yè)務系統(tǒng)之間的數(shù)據(jù)共享提供一個大規(guī)模消息處理平臺，以及在各地市與省廳之間形成一個數(shù)據(jù)管道。
結合對Kafka和Kafka插件的深入研究，新德匯大數(shù)據(jù)研究院自主研發(fā)了輕量級的FSP流處理引擎，用于輕便對接流數(shù)據(jù)，高效處理和實現(xiàn)各類流數(shù)據(jù)延展應用。
4.1 日志聚合
多個系統(tǒng)之間的日志通過kafka匯聚，提供審計或其他監(jiān)控系統(tǒng)進行消費。日志聚合一般來說是從服務器上收集日志文件，然后放到一個集中的位置（文件服務器或HDFS）進行處理。然而Kafka忽略掉文件的細節(jié)，將其更清晰地抽象成一個個日志或事件的消息流。這就讓Kafka處理過程延遲更低，更容易支持多數(shù)據(jù)源和分布式數(shù)據(jù)處理。比起以日志為中心的系統(tǒng)比如Scribe或者Flume來說，Kafka提供同樣高效的性能和因為復制導致的更高的耐用性保證，以及更低的端到端延遲。
4.2 消息系統(tǒng)
系統(tǒng)之間解耦，通過kafka驅動各業(yè)務系統(tǒng)之間的數(shù)據(jù)共享與業(yè)務流程驅動。
比起大多數(shù)的消息系統(tǒng)來說，Kafka有更好的吞吐量，內置的分區(qū)、冗余及容錯性，讓Kafka成為了一個很好的大規(guī)模消息處理應用的解決方案。消息系統(tǒng)一般吞吐量相對較低，但是需要更小的端到端延時，并常常依賴于Kafka提供的強大的持久性保障。在這個領域，Kafka足以媲美傳統(tǒng)消息系統(tǒng)，如ActiveMR或RabbitMQ。
4.3 數(shù)據(jù)管道
Kafka讓集成工作只需連接到一個單獨的管道，而無需連接到每個數(shù)據(jù)生產方與消費方。
Kafka提供數(shù)據(jù)管道，讓多個地市各種類型的數(shù)據(jù)資源，集成時不需要知道原始數(shù)據(jù)源的細節(jié)，發(fā)布數(shù)據(jù)時也不需要知道哪個應用程序會消費和加載這些數(shù)據(jù)，增加新系統(tǒng)，也只需要接入現(xiàn)有的Kafka流數(shù)據(jù)平臺就可以。
某省廳Kafka數(shù)據(jù)管道案例
4.4 ETL流水線
未引入kafka時，數(shù)據(jù)的ETL過程需生成臨時數(shù)據(jù)庫，多次產生落地的文件，耗費內存，而且在再調用臨時數(shù)據(jù)庫時，會耗用內存。這樣厚重的架構也不具備流數(shù)據(jù)處理能力。
引入kafka后，實現(xiàn)微ETL。通過Kafka對接流處理引擎，簡化ELT流程，細化數(shù)據(jù)處理層次，低延時獲取目標數(shù)據(jù)。
微ETL優(yōu)點：
? 無縫銜接流處理引擎，完成數(shù)據(jù)快速ETL
? kafka構建一個可伸縮的，可靠的數(shù)據(jù)流通道
? 交互低延遲
? 微ETL實現(xiàn)輕便的數(shù)據(jù)處理流程
傳統(tǒng)ETL與微ETL的對比
4.5 FSP流處理引擎
4.5.1 FSP架構
FSP架構
流處理平臺：對流數(shù)據(jù)，提供核心處理引擎，流采集工具的可配置化管理平臺
核心處理引擎：PIPELINEDB允許我們通過sql的方式，對數(shù)據(jù)流做操作，并把操作結果儲存起來；Kafka插件可擴展kafka功能，實現(xiàn)SQL on kafka的各類流數(shù)據(jù)的延展應用
流采集工具集：Kafkacat實現(xiàn)Kafka與 sqluldr、copy收集的數(shù)據(jù)的對接，實現(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 通過kafkacat命令加載數(shù)據(jù)生成GP外部表
通過Kafkacat實現(xiàn)GP與kafka的數(shù)據(jù)對接：kafkacat工具根據(jù)外部表協(xié)議可以獲取GP和kafka的數(shù)據(jù)，并生成外部表，實現(xiàn)數(shù)據(jù)的并行加載。以外部表的形式實現(xiàn)數(shù)據(jù)格式錯誤行的容錯處理
Kafkacat 加載GP外部表
五、Kafka延展應用展望
整合NiFi與kafka，并將MiNiFi作為數(shù)據(jù)采集器布放到對端數(shù)據(jù)源，形成一條可拓展并流動的流式數(shù)據(jù)處理生產線。
Kafka與NiFi結合
5.1 NiFi介紹
NiFi是一個易用、強大、可靠的數(shù)據(jù)處理與分發(fā)系統(tǒng)。簡單來說，NiFi是用于自動化管理系統(tǒng)之間的數(shù)據(jù)流。通過與Kafka的對接，提供可視化命令與控制，實現(xiàn)數(shù)據(jù)流的展示與編輯處理功能，實現(xiàn)數(shù)據(jù)流的全程追蹤。
NiFi特點：
1.可視化命令與控制
基于Web的用戶界面，無縫體驗設計，監(jiān)視，控制數(shù)據(jù)流。
高擴展性
NiFi通過提供自定義類裝載器模型，來確保每個擴展組件之間的約束關系被限制在非常有限的程度。因此，在創(chuàng)建擴展組件時，就不用再過多關注其是否會與其他組件產生沖突。數(shù)據(jù)流處理程序能夠以可預測和可重復的模式執(zhí)行。
數(shù)據(jù)回壓
NiFi提供所有隊列數(shù)據(jù)的緩存，并且在隊列達到指定限制或者超時的時候，能夠提供數(shù)據(jù)回壓。
高度可配置
數(shù)據(jù)丟失容錯和保證交付，低延遲和高吞吐量，動態(tài)優(yōu)先級，流可以在運行時修改。
安全性
系統(tǒng)間，NiFi可以通過雙向SSL進行數(shù)據(jù)加密。并且可以允許在發(fā)送與接收端使用共享密鑰，及其他機制對數(shù)據(jù)流進行加密與解密。
用戶與系統(tǒng)間，NiFi允許雙向SSL鑒定，并且提供可插入授權模式，因此可以控制用戶的登錄權限（例如：只讀權限、數(shù)據(jù)流管理者、系統(tǒng)管理員）。
5.2 NiFi實現(xiàn)統(tǒng)一實時采集數(shù)據(jù)的分布式流平臺
數(shù)據(jù)實時采集器MiNiFi：
? 實現(xiàn)增量數(shù)據(jù)和流數(shù)據(jù)的實時采集，而不是傳統(tǒng)的定時采集，實現(xiàn)了更細致化的數(shù)據(jù)獲取
? 可支持多種數(shù)據(jù)源，適用性強
? 實現(xiàn)端到端的數(shù)據(jù)采集
分布式流平臺NiFi：
? 采集而來的數(shù)據(jù)，形成數(shù)據(jù)流，并對數(shù)據(jù)源進行自動記錄，索引，跟蹤
? 精確控制數(shù)據(jù)流
? NIFI單節(jié)點的性能是每秒處理百兆級數(shù)據(jù)，搭建NIFI集群可以提升到每秒處理G級別數(shù)據(jù)
NiFi分布式流平臺
上述就是小編為大家分享的公共安全領域 Kafka 應用實踐是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
