本篇內(nèi)容介紹了“Kappa架構(gòu)原理是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

海曙網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、成都響應式網(wǎng)站建設公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站從2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)建站。

Lambda架構(gòu)回顧Lambda架構(gòu)的核心思想是把大數(shù)據(jù)系統(tǒng)拆分成三層：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer負責數(shù)據(jù)集存儲以及全量數(shù)據(jù)集的預查詢。Speed Layer主要負責對增量數(shù)據(jù)進行計算，生成Realtime Views。Serving Layer用于響應用戶的查詢請求，它將Batch Views和Realtime Views的結(jié)果進行合并，得到最后的結(jié)果，返回給用戶。圖1給出了Lambda的整體架構(gòu)圖：

Kappa架構(gòu)上述提到，為了將批處理和實時處理相結(jié)合，Lambda設計了Batch Layer和Speed Layer兩層結(jié)構(gòu)，分別用于批處理和實時計算，因此需要維護兩套分別跑在批處理和實時計算系統(tǒng)之上的代碼。面對這個問題，有人會有這樣的疑問，為什么不用流計算系統(tǒng)來進行全量數(shù)據(jù)處理從而去除Batch Layer這一層?

可能有這樣回答：流計算給人的印象是對一些流式的、臨時的數(shù)據(jù)進行計算，將結(jié)果保存后就將原始數(shù)據(jù)丟棄了，因此它不適合用來處理歷史數(shù)據(jù)。其實這種答案并不完全正確，對于基于Lambda架構(gòu)實現(xiàn)的Storm框架確實是這樣的，但對于后來出現(xiàn)的Spark并不是。

Storm是在2011年7月開源的，Spark是在2012年之后逐漸為人們所知的，因此在Nathan Marz設計Lambda架構(gòu)的時候，當時還并沒有一個框架既可以用于離線處理，又可以進行實時計算。但隨著Spark技術(shù)的發(fā)展，這一想法成為了可能，Spark本身可以用于批處理，而構(gòu)建在Spark之上的Spark Streaming又可以用于實時計算，因此利用一套系統(tǒng)來應對批處理和實時計算相結(jié)合的業(yè)務完全是可行的。

Kappa架構(gòu)的核心思想包括以下三點：

1. 用Kafka或者類似的分布式隊列系統(tǒng)保存數(shù)據(jù)，你需要幾天的數(shù)據(jù)量就保存幾天。

2. 當需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數(shù)據(jù)進行處理，并輸出到一個新的結(jié)果存儲中。

3. 當新的實例做完后，停止老的流計算實例，并把老的一些結(jié)果刪除。

Kappa的架構(gòu)圖如圖2所示：

和Lambda架構(gòu)相比，在Kappa架構(gòu)下，只有在有必要的時候才會對歷史數(shù)據(jù)進行重復計算，并且實時計算和批處理過程使用的是同一份代碼。或許有些人會質(zhì)疑流式處理對于歷史數(shù)據(jù)的高吞吐量會力不從心，但是這可以通過控制新實例的并發(fā)數(shù)進行改善。

上面架構(gòu)圖中，新老實例使用了各自的結(jié)果存儲，這便于隨時進行回滾，更進一步，假如我們產(chǎn)出的是一些算法模型之類的數(shù)據(jù)，用戶還可以同時對新老兩份數(shù)據(jù)進行效果驗證，做一些A/B test或者使用bandit算法來最大限度的使用這些數(shù)據(jù)。

優(yōu)缺點對比

對比項	Lambda架構(gòu)	Kappa架構(gòu)
數(shù)據(jù)處理能力	可以處理超大規(guī)模的歷史數(shù)據(jù)	歷史數(shù)據(jù)處理的能力有限
機器開銷	批處理和實時計算需一直運行，機器開銷大	必要時進行全量計算，機器開銷相對較小
存儲開銷	只需要保存一份查詢結(jié)果，存儲開銷較小	需要存儲新老實例結(jié)果，存儲開銷相對較大
開發(fā)、測試難易 程度	實現(xiàn)兩套代碼，開發(fā)、測試難度較大	只需面對一個框架，開發(fā)、測試難度相對較小
運維成本	維護兩套系統(tǒng)，運維成本大	只需維護一個框架，運維成本小

表1 Lambda架構(gòu)和Kappa架構(gòu)優(yōu)缺點對比

如上表所示，Kappa架構(gòu)相對來說有更多的優(yōu)點，目前也被更多的廠商用于構(gòu)建商業(yè)項目。

第一，Lambda架構(gòu)不僅需要維護兩套分別跑在批處理和實時計算系統(tǒng)上面的代碼，還需要批處理和全量計算長時間保持運行;而Kappa架構(gòu)只有在需要的時候才進行全量計算。

第二，Kappa架構(gòu)下可以啟動很多個實例進行重復計算，因此在需要對一些算法模型進行調(diào)優(yōu)時，Kappa架構(gòu)下只需要更改一套系統(tǒng)的參數(shù)即可，并且允許對新老數(shù)據(jù)進行效果比對;但是在Lambda架構(gòu)下，需要同時更改流計算系統(tǒng)算法模型和批處理系統(tǒng)算法模型，調(diào)參過程相對比較復雜。

第三，從用戶開發(fā)、測試和運維的角度來看，Kappa架構(gòu)下，開發(fā)人員只需要面對一個框架，開發(fā)、測試和運維的難度都會相對較小，這是個非常重要的優(yōu)點。

如何選擇

從上述的優(yōu)缺點對比來看，業(yè)務需求、開發(fā)測試難易程度和運維成本為三個主要的框架選擇考慮因素，而機器開銷和存儲開銷，雖然存在一定差別，但是差別不是很大，所以這里我們也主要從業(yè)務需求，開發(fā)測試難易程度和運維成本三方面來考慮如何對上述兩個架構(gòu)做出選擇。

業(yè)務需求

用戶需要根據(jù)自己的業(yè)務需求來選擇架構(gòu)，如果所需要處理的歷史數(shù)據(jù)規(guī)模較大，比如某省智慧交通系統(tǒng)幾年達TB級的數(shù)據(jù)，那么選擇Lambda架構(gòu)可能較為合適;如果處理的數(shù)據(jù)量較小，比如分析某電商網(wǎng)站近30天的數(shù)據(jù)，那么選擇Kappa架構(gòu)可能更為合適。

開發(fā)測試難易程度

如果項目中需要頻繁的對算法模型參數(shù)進行調(diào)優(yōu)，Kappa架構(gòu)要來的更為便捷;另外還有一個判定依據(jù)就是你設計的算法是否同時適合批處理和實時計算，如果同一份代碼可以很好地處理兩者，那么可以選擇Kappa架構(gòu);但是針對某些復雜的案例，其實時計算的結(jié)果和批處理的結(jié)果是不同的，比如某些機器學習的應用，由批處理生成預測模型，再交由實時計算系統(tǒng)進行實時分析，那么這種情況下，批處理層和實時計算層不能進行合并，因此應該選擇Lambda架構(gòu)。

運維成本

Kappa架構(gòu)的運維成本較低，比較適合技術(shù)人力資源有限的團隊或企業(yè)。

StreamSQL與Lambda架構(gòu)Transwarp StreamSQL是星環(huán)科技專門為企業(yè)級用戶打造的流計算引擎，主要應用于實時性較強的應用場景。比如，金融行業(yè)需要對市場波動進行實時預警;銀行業(yè)務需要在線分析業(yè)務等。它對于SQL和PL/SQL的支持使得用戶可以通過SQL的方式實現(xiàn)復雜業(yè)務邏輯，大大降低了流應用開發(fā)的門檻，也使得基于一套SQL程序開發(fā)離線和實時業(yè)務成為可能。

圖3為利用Kafka和StreamSQL搭建的一個Kappa架構(gòu)系統(tǒng)，并且對原有的Kappa架構(gòu)的缺點做了改進。

StreamSQL每隔100ms會從Kafka消息隊列中接收一批時序數(shù)據(jù)，如t0-tn時刻的數(shù)據(jù)，其中t0的數(shù)據(jù)為(0,1,2,3,4)，t1的數(shù)據(jù)為(5,6,7,8,9)…。當前批次的數(shù)據(jù)會被映射成一張二維關系表，通過SQL進行變換并轉(zhuǎn)成內(nèi)存列式存儲，變換后的數(shù)據(jù)會實時寫入Holodesk以持久化到SSD上，通過此方式永久保留或者保留最近一個月的數(shù)據(jù)。應用程序可以通過Inceptor SQL或者R語言對Holodesk中的列式數(shù)據(jù)進行統(tǒng)計分析。

StreamSQL對Kappa架構(gòu)的改進之處，包括如下：

上述提到，原本的Kappa架構(gòu)把歷史數(shù)據(jù)保存在Kafka或類似的分布式消息隊列，這樣的特性導致了一個缺點就是它只能保存幾天或幾個月的數(shù)據(jù)，并且只能以流的形式保存，因此對于歷史數(shù)據(jù)的處理能力有限;而StreamSQL支持輸出到多種格式，既允許輸出到Kafka，也可以將結(jié)果以各類格式(TEXT表、ORC表、Holodesk表、HBase表)保存在Inceptor，實現(xiàn)更長期的存儲，因此它可以應對更大數(shù)據(jù)規(guī)模的業(yè)務需求。

StreamSQL支持在實時計算時或歷史數(shù)據(jù)分析時將流數(shù)據(jù)和Inceptor表的數(shù)據(jù)做關聯(lián)，大大增強了它的歷史數(shù)據(jù)處理能力。

StreamSQL另一特色功能就是它可以完美兼容SQL標準和PL/SQL，使得用戶可以通過SQL的方式實現(xiàn)業(yè)務邏輯，極大降低了流應用開發(fā)的門檻。

StreamSQL還增加了Application管理的功能，運行時各個Application之間相互隔離并需要權(quán)限驗證，很大程度上提高了系統(tǒng)的安全性和可用性。

Kappa架構(gòu)案例分析下面我們以StreamSQL作為流處理引擎來搭建一個基于Kappa架構(gòu)的智慧交通系統(tǒng)，并對其中的套牌車輛實時預警業(yè)務場景進行詳細的數(shù)據(jù)流分析

當前端卡口將監(jiān)控到的車輛信息接入Kafka分布式消息隊列后，總線會對這些數(shù)據(jù)進行歸類分揀，分發(fā)給不同的服務集群，比如實時入庫服務集群、未年檢車監(jiān)控服務集群等。

假設部分數(shù)據(jù)被送入到了違法車輛監(jiān)控服務集群中，該集群其中一個業(yè)務是對車輛進行套牌分析。前面的章節(jié)提到Kappa架構(gòu)方便進行算法模型的調(diào)優(yōu)，下面我們來看一下具體是怎么做的。

首先，假如我們創(chuàng)建了一個UDF函數(shù)DectectCloneVehicle(param1, param2)，用于檢查待檢測牌照是否為套牌車輛。該UDF接收兩個輸入?yún)?shù)：當兩輛相同牌照的車直線距離超過param1公里且出現(xiàn)時間低于param2分鐘時，則被視為套牌車。該函數(shù)有兩種返回結(jié)果：如果是套牌車則輸出1，否則輸出0。

假設我們起初設定的套牌分析策略是，如果某兩輛相同牌照的車直線距離超過20公里，出現(xiàn)時間小于2分鐘, 那么判定該車牌被套牌。啟動一個Stream Job實例，并按照該策略進行分析的StreamSQL語句如下：

CREATE STREAM vehicle_stream1(license STRING, location STRING, time TIMESTAMP)  ROW FORMAT DELIMITED FIELDS TERMINATED BY ','  TBLPROPERTIES ("topic"=fakeLicense", kafka.zookeeper"="172.16.1.128:2181",  "timefield"="time", "timeformat"="yyyy-MM-dd HH-mm-ss.SSS);  CREATE TABLE clone_vehicle_result_app1(license STRING,location STRING, time TIMESTAMP);  INSERT INTO clone_vehicle_result_app1  SELECT DetectCloneVehicle(20, 2) as cloned  FROM vehicle_stream1  HAVING cloned>0;

但是通過實踐并且考慮到一些現(xiàn)實情況(如直線距離是否合理，當前路段高速類路段多還是低速路段多等)，我們發(fā)現(xiàn)如果按照此參數(shù)執(zhí)行檢測，套牌排查效率會很低。假如把套牌車輛的判定標準調(diào)整為：直線距離超過10公里，出現(xiàn)時間小于5分鐘的兩輛相同牌照的車，效率就會有極大幅度的提升?，F(xiàn)在重新啟動一個Stream Job實例，執(zhí)行如下的StreamSQL語句：

CREATE STREAM vehicle_stream2(license STRING, location STRING, time TIMESTAMP) 
 
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' 
 
TBLPROPERTIES ("topic"=fakeLicense", kafka.zookeeper"="172.16.1.128:2181", 
 
"timefield"="time", "timeformat"="yyyy-MM-dd HH-mm-ss.SSS); 
 
CREATE TABLE clone_vehicle_result_app2(license STRING,location STRING, time TIMESTAMP); 
 
INSERT INTO clone_vehicle_result_app2 
 
SELECT DetectCloneVehicle(10, 5) as cloned 
 
FROM vehicle_stream2 
 
HAVING cloned>; 

該Stream Job的效率高于之前所選用的參數(shù)，這樣我們就進行了一步UDF模型參數(shù)的調(diào)優(yōu)。所以在做實際分析時，業(yè)務執(zhí)行效率的提升不能單純的依靠系統(tǒng)提供的優(yōu)化幫助，用戶需要能夠根據(jù)所采用的架構(gòu)和所處理的問題、應用的模型方法，結(jié)合實際外部限制選擇最有效的模型參數(shù)。

“Kappa架構(gòu)原理是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

分享題目：Kappa架構(gòu)原理是什么
分享URL：http://www.rwnh.cn/article38/jipjsp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信小程序、標簽優(yōu)化、電子商務、軟件開發(fā)、用戶體驗、品牌網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)