摘要：Samza是由LinkedIn開源的一個分布式流處理系統。近日，LinkedInSRE Jon Bringhurst發表了一篇博文，揭秘LinkedIn是如何利用Samza與Yarn、Kafka進行擴展的。
【編者按】Samza是由LinkedIn開源的一個分布式流處理系統，與之配合使用的是開源分布式消息處理系統Apache Kafka。很多人會將Samza與Twitter Storm相媲美。近日，LinkedInSRE（網站可靠性工程師）Jon Bringhurst發表了這篇博文，闡述LinkedIn是如何利用Samza與Yarn、Kafka進行擴展的。
Samza是什么
Apache Samza是一個開源框架，可以幫助開發者進行高速消息處理同時具有良好的容錯能力。Samza可從Kafka中獲取消息并進行處理，處理完畢后把結果返回Kafka（LinkedIn自家的分布式消息系統Kafka）。一個簡易的Samza處理過程如下圖所示：
盡管Samza的設計初衷為不同類型的流處理系統服務，在LinkedIn中我們對消息流的處理主要使用的還是Kafka。所以接下來會先講述Kafka然后再探討Samza。
Kafka簡述
每天經由Kafka進行處理的數據量多達500TB。或許你會想象有個大規模集群來對付如此龐大的數據，實際上不是的。我們實際上使用的是集群圖，每個集群圖負責處理特定類型的消息。我們透過對不同集群圖進行消息鏡像處理從而控制集群到集群的消息流向。
針對數據中心可能出現的宕機情況，我們為集群提供了一個拓撲結構，以便數據中心出錯離線后繼續保持消息的正常流動。每一個數據中心里，我們都會配備一個本地的集群和一個聚合的Kafka集群。每個本地集群會穿越數據中心被鏡像復制到聚合集群。所以一旦某個數據中心出現異常，我們會轉移去另一個數據中心而不造成重大影響。
我們把拓撲結構中的每一個水平層叫做“tier(層)”，tier由各個不同數據中心具相同功能的集群組成。例如在上圖中，有一個本地tier和一個聚合tier。
本地tier是所有數據中心中的本地集群的集合，聚合tier是所有數據中心的聚合集群的集合。
此外還有一個離線聚合tier(offline aggregate tier)。Production聚合tier會被鏡像復制到離線聚合tier進行批處理作業(例如，在Hadoop上進行map-reduce作業)。我們可利用它來分離production集群并在不同數據中心里進行批處理作業。
若只配置單個本地集群或單個聚合集群，無疑會置整個集群結構于風險之中；所以我們會把本地集群分割為多個子集群，每個子集群承載不同類型的數據。例如，程序指標和事件追蹤數據會被放入不同的集群，不同集群都會有自己的本地集群和聚合集群。盡管Kafka能夠處理來自單個大型集群所有類型的消息，但是對此進行更細致的劃分無疑會減少差錯處理的復雜度。
我們還有“pipeline(管道)”的概念。一個pipeline表示的是一個消息從源地址到目的地傳輸的路徑。不同消息會共享公共的pipeline，所以很容易去找出消息的源地址和目的地址。
Samza在其中發揮什么作用呢？我們配置了另外的Kafka 集群集合為Samza作業服務，該集合是從聚合tier鏡像復制過來的。每個這樣的Kafka集群會與一個能運行Apache Yarn的集群相連以處理Samza作業。
從上圖可知Kafka和Samza使用的是不同的硬件。因為在過去嘗試使用同一硬件時，發現Samza作業會對Kafka的頁緩存造成影響。
資源管理
每執行作業時，每個Samza作業會連接到Yarn的Application Master API。透過該API，Samza可與Yarn一起申請資源(容器)為Samza作業服務。一旦任務失敗，Samza作業會與Yarn進行協商從而尋找其它的替代資源。
那么該如何在Yarn下開啟一個 Samza作業呢？
首先創建一個Samza工程。LinkedIn有一個對版本進行管理的倉庫工具。每當提交工程到該倉庫時，LinkedIn自動化工具會使用Hudson來創建新的工程并生成一個Samza作業包。一旦作業包在作業倉庫服務器工具Artifactory上就緒，其它工具會在 同一主機上進行Yarn 資源管理器安裝。安裝文件中的一個腳本會通知Yarn從Artifactory上下載作業包，并提取文件放入作業的工作目錄中，然后啟動Samza Application Master。
性能監控
我們使用inGraphs工具來進行性能監控。inGraphs與開源工具Graphite非常類似，它有個基于RRD，Whisper或InfluxDB的后端。其性能監視頁面如下所示：
由于Samza作業關聯的性能指標數量龐大，我們會在工具上進行指標的篩選，排除冗余的干擾信息，除非工程師有特殊要求。此外，我們還配有歷史數據訪問工具和指標警示工具。
多數警示信息都設有上限和下限閥值。如下圖所示，如果發現每秒消息數量低于下限100，會觸發相應的處理動作(自動調節或發出警示通知)。
我們針對不同的警示信息設定有相應的升級處理機制。例如針對非緊急情況會先通過郵件進行通知，針對重大問題會馬上通知網絡運營中心。除了Samza，我們對硬盤，CPU，內存，網絡使用情況都會進行監控。
硬件配置
當我們為Kafka代理加入新硬件時，我們會采用標準的LinkedIn Kafka配置進行設置。從目前來看，內存是作業運行中較易出問題的環節。所以對于執行Samza作業的服務器節點來說，我們主要關注的是根據核心頻率配備合適的RAM。下一步我們計劃會對網絡硬件進行升級。在存儲方面，我們基本上采用的是PCI-E接口、TB級別的SSD配置。app制作開發
下一步計劃
盡管目前Samza運作正常，我們仍不斷為規模與穩定兩者之間的平衡而努力。其中一個方向是如何對作業和任務進行更好的劃分。以上就是我們在LinkedIn中進行Samza部署的回顧與總結。將來我們會不斷深化Samza的應用，為用戶帶來更好的用戶體驗。
英文來自：Linkedin
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
