【譯】Kafka學習之路

　　一直在思考寫一些什麼東西做爲2017年開篇博客。忽然看到一篇《Kafka學習之路》的博文，以爲十分應景，因而決定搬來這「他山之石」。雖然對於Kafka博客我一貫堅持原創，不過這篇來自Confluent團隊Gwen Shapira女士的博文實在精彩，因此仍是翻譯給你們，原文參見這裏。

~~~~~~~~~~~~

Kafka學習之路

　　看上去不少工程師都已經把「學習Kafka」加到了2017年的to-do列表中。這沒什麼驚訝的，畢竟Apache Kafka已是一個很火的框架了。只需瞭解一些基本的Kafka技能咱們即可以把消息隊列應用到實際的業務系統中，集成應用程序和數據存儲，構建流式處理系統而且着手搭建高伸縮性高容錯性的微服務架構。全部的這些只須要學習Kafka這一個框架就足夠了， 聽起來還不錯吧？ 這篇報道中Kafka上榜當選了當前最須要掌握的十大大數據技能之一(譯者：好吧， 這麼吹我都有點受不了了，這篇報道中提到的技能幾乎都是Amazon的，很難讓人相信這不是Amazon的軟文)，因此若是你想在本身的領域內出人頭地，Kafka值得一試！

　　好了，那麼該如何開始學習Apache Kafka呢？一言以蔽之：因人而異！這取決於你的職業特色。學習Kafka可能有不少種方式，稍後我會詳細向你介紹，不過這些方法都有相通的部分，因此讓咱們先從這些地方開始吧：

　　第一步就是要下載Kafka。Confluent提供了免費的Confluent下載(譯者：Confluent.io是Kafka團隊獨立出來成立的一個創業公司，該公司開發的Confluent是一個基於kafka的流式處理平臺，提供了一些社區版Kafka沒有的功能)。Confluent不只擁有Apache Kafka提供的全部功能，同時還提供了一些額外的開源插件(好比REST proxy，超多種類的Connector和一個schema registry)

　　Kafka的安裝主要就是解壓下載的.tar.gz文件。固然你也能夠經過RPM或DEB文件的方式進行安裝，教程在這裏。

　　Apache Kafka是一個流式數據處理平臺，其本質就是一個發佈/訂閱模式的消息隊列，所以在安裝以後你能夠嘗試建立一些話題(topic)，而後往話題中生產一些消息，以後再訂閱這些話題進行消費。最好的方式就是參照quick start文檔——注意，從第二步開始作就行了，第一步的下載咱們已經完成了：）

　　恭喜你！ 你已經成功地對Kafka進行了消息的發佈與訂閱。不過在繼續以前，我建議你花一些時間去讀一下Kafka的設計文檔——這會極大地幫助你理解不少Kafka的術語與核心概念。

　　okay，你已經能夠簡單地往kafka發送和消費消息了，不過真實系統中咱們可不會這樣用。首先，在quick start中咱們只配置了一個Kafka服務器(Kafka broker)——生產環境中咱們至少要配置3臺以實現高可用；其次，教程中使用了命令行工具進行消息的發佈與訂閱。而實際線上環境一般都要求在業務系統中來作或者是使用connector實現與外部系統的集成。

　　下面咱們就根據每一個人的實際狀況具體給出學習Kafka的路線圖。

~~~我是軟件工程師~~~

　　軟件工程師一般都有一門熟練掌握的編程語言，所以做爲軟件工程師的你第一步就要根據你掌握的編程語言尋找對應的Kafka客戶端。Apache Kafka支持的客戶端列表在此，趕忙去找一下吧。

　　挑選合適本身的客戶端自己就是一門技術活，有不少注意事項。不過我推薦你們使用這兩種客戶端：Java客戶端和libkafka。這兩個客戶端支持絕大多數的Kafka協議，也更加的標準化，同時有很好的性能以及可靠性(畢竟通過了大量的測試)。可是，不管你選擇了上述列表中的哪一個客戶端，咱們都推薦你要確認它至少是有活躍社區維護的——Kafka版本迭代速度很快，客戶端版本更新太慢會致使不少新功能沒法使用的。如何判斷客戶端更新速度呢？ 答案就是查看對應的github上面的commit數和issue數，它們一般均可以幫助識別是否有活躍社區在維護它(譯者：KafkaOffsetsMonitor更新速度就很慢，彷佛到目前爲止還不支持對於Kafka保存offset的監控)

　　一旦肯定了要使用的客戶端，立刻去它的官網上學習一下代碼示例(好吧，若是都沒有樣例，你要從新思考一下它是否合適了？)——確認你可以正確編譯和運行這些樣例，這樣你就有把握可以駕馭該客戶端了。下一步你能夠稍微修改一下樣例代碼嘗試去理解並使用其餘的API，而後觀察結果。

　　這些都作完以後你能夠本身編寫一個小項目來進行驗證了。第一個項目一般都是一個生產者程序(下稱producer)，好比它負責發送/生產一些整數到一個話題的某個分區(partition)中，而後再寫一個消費者程序(下稱consumer)來獲取這些整數。做爲你的第一個項目，它教會了你大多數Kafka API的使用，你必定會印象深入的。另外客戶端的文檔一般都是十分齊全的，但若是你仍有疑問而無處解答，那麼給郵件組或StackOverflow發問題吧，會有大神回答你的(譯者：作個廣告，我在StackOverflow的名字是amethystic，一般都會看到你的問題的)。

　　作完了這些，下面就是要提高客戶端的可靠性與性能了。再去複習一遍Kafka的文檔吧，確保你真的理解了不一樣客戶端之間那些影響可靠性和性能的參數，而後去作一些實驗來鞏固你的理解。舉個例子，給producer配置acks=0， 重啓服務器而後去看看吞吐率有什麼變化？ 而後再試試acks=1。另外注意一下在重啓的過程當中是否出現消息丟失？你是否能說清楚爲何(不)會丟失嗎？若是acks=-1的話還會有消息丟失嗎？這些配置下的性能都是怎麼樣的？若是你增長batch.size和linger.ms會發生什麼？ Kafka提供了不少的參數，若是你以爲目不暇接，那麼先從「高重要度」(high importance)的那些開始學起吧。

　　學完了client及其API的使用，也嘗試了一些配置修改和樣例運行，下面你就能夠真正地開始進行Kafka應用的開發了。

　　若是你使用Java，只須要繼續學習高級流式處理API就能夠了。這些API不只生產/消費消息，還可以執行更爲高級的流式處理操做(好比時間窗口聚合以及流鏈接stream joining等)。文檔在這裏，例子在這裏，不用客氣 :-)

~~~我是系統管理員/運維工程師~~~

     和開發工程師不一樣，你的目標是學習如何管理Kafka線上生產環境。所以，從一開始你就須要一個真實的Kafka集羣環境，即3節點集羣(推薦的線上生產環境配置)。

     若是不知道怎麼搭建請參考上面quick start中提到的第6步：安裝多節點集羣。你也可使用Docker來直接配置出多節點Kafka集羣(譯者：這是Confluent本身製做的鏡像，不是目前STAR數最多的那個)。這些鏡像都是咱們在生產環境中用到的，因此請放心地做爲基礎鏡像來使用~~

     有了這個環境，你可使用quick-start中提到的bin/kafka-topics.sh腳本建立多個分區多個副本(replica)的topic了，去試試吧。

     俗話說的好，作好監控生產環境的部署就成功了一半，因此我推薦你及時地作好對於Kafka的監控。Kafka默認提供了超多的JMX監控指標。咱們能夠用不少種方式對其進行收集，可是你必定要保證Kafka啓動時配置了JMX_PORT環境變量(譯者：最簡單地方式就是修改bin/kafka-server-start.sh腳本)！ 不知道你習慣使用什麼監控工具，反正我是用JMXTrans和Graphite進行收集和監控的。若是你也使用Graphite，別客氣，個人配置你就拿去用吧：） (譯者： 我一直使用JConsole來進行監控，其實也挺好的) 總之使用你習慣的工具就好，另外這裏列出了一些經常使用的監控指標，給你作個參考吧~

     做爲系統運維管理員，下一步你要觀察在必定負載狀況下你的Kafka的集羣表現。Apache Kafka提供了不少命令行工具用於模擬運行負載：bin/kafka-producer-perf-test和bin/kafka-consumer-perf-test。去學習一下這些工具的使用方法吧，在你的系統中模擬一些負載出來而後觀察剛纔提到的監控指標。好比producer/consumer可以達到的最大吞吐量是多少？ 你是否可以找到整個集羣的瓶頸所在？

     哦，對了，Kafka的日誌也不容忽視。默認狀況下它們保存在logs/或/var/log下——取決於你的設置了。你須要仔細地查看server.log，保證沒有重大的錯誤。若是不理解出現錯誤的含義，發信給郵件組或StackOverflow吧。

     咱們剛剛所作的都是正常的Kafka操做，去搞些異常出來吧！ 好比停掉集羣中的一臺服務器，而後去查看監控指標——你應該能夠發現leader數會降低而後恢復，leader選舉數攀升而under-replicated分區數也增長了(譯者：under-replicated分區指備份不充分的分區，好比正常狀況下我設置該分區有3個副本，但實際中只有2個副本，那麼此時該分區就是備份不充分的)。你也能夠去查看服務器日誌(包括你停掉的那臺)——日誌應該標明瞭有新的leader選舉發生。

     我推薦你在調優producer/consumer性能的時候嘗試不斷地關閉/啓動服務器，甚至直接kill -9也行，而後查看日誌和監控指標，搞明白這其中到底發生了什麼以及系統是怎麼恢復整個過程的。

     做爲系統管理員的最後一個重要的事情就是學習Kafka的管理工具，好比：

• kafka-topics.sh：修改分區數，副本數以及分配新的分區和副本到指定broker上
• kafka-topics.sh：刪除topic
• kafka-config.sh：修改topic配置，好比topic日誌留存時間
• kafka-consumer-groups.sh：開發人員一般都要求運維人員幫忙查看consumer消費狀況(是否滯後太多)，那麼使用這個腳本去查看consumer group的消費狀況
• kafka-reassign-partitions.sh：從新在各個服務器之間分配分區和副本
• 若是安裝的是Confluent Kafka，你可使用Confluent Rebalancer去檢查每一個服務器上的負載狀況並自動地進行分區再平衡

~~~我是ETL工程師/數據倉庫工程師~~~

　　做爲一個ETL或數倉工程師，你更在乎數據如何在Kafka與外部系統間進行可靠地傳輸，而且儘可能不修改模式信息。不用擔憂，Kafka提供了Kafka Connect組件用於企業級的數據管理。除此以外，你還能夠學習Confluent提供的模式 註冊中心的功能。

　　Kafka Connect是Kafka自己就提供的功能，不須要安裝Confluent也能使用。學習Kafka Connect的第一步就是在一個單機環境或分佈式環境中運行Connector而且在多個文件的內容導入到Kafka中——具體步驟參見文檔中的第7步。

　　聽上去還挺有意思吧，可是導入文件內容其實也沒什麼大不了的，咱們要操做真實的數據存儲設備。

　　首先，咱們先安裝模式註冊中心(下稱Schema Registry)，由於不少Kafka Connector都須要它的支持。若是你安裝的是Apache版的Kafka而不是Confluent，那麼很遺憾，你須要下載Confluent Kafka，要麼就是拉github代碼本身編譯。

　　Schema Registry會假定數據不是文本或JSON格式，而是Avro文件且包含了模式信息。當producer向Kafka發送消息時，數據模式保存在registry中，然後者會對模式進行驗證。Consumer使用registry中保存的模式來與不一樣版本的數據進行交互，從而實現版本兼容性。這樣用戶很方便識別數據與topic的對應關係。

　　若是你不想安裝Schema Registry也沒有問題。Kafka默認提供了大多數的Connector實現，可是你要確保在使用Connector時設置轉換器來把數據轉成JSON格式，方法以下：

key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter

假設你要導出MySQL數據到ElasticSearch中。Confluent安裝包中提供了JDBC Connector以及一個ElasticSearch Connector，你能夠直接使用它們，固然也能夠從github中編譯構建。具體使用方法請參考JDBC Source和ElasticSearch Sink。

　　最後，你還能夠學習Confluent控制中心，它可讓你配置connector以及監控端到端的數據流。

~~~~~~~~~~~~

　　好了，大部分我認爲值得翻譯的都在這裏了，後面那些關於各類博客和峯會宣傳的就不詳細列出了。總之，我但願本譯文可以對那些想要學習Kafka的人有所幫助~ 2017年，咱們再戰Kafka！