Kafka實戰－實時日誌統計流程

1.概述

　　在《Kafka實戰－簡單示例》一文中給你們介紹來Kafka的簡單示例，演示瞭如何編寫Kafka的代碼去生產數據和消費數據，今天給你們介紹如何去整合一個完整的項目，本篇博客我打算爲你們介紹Flume＋Kafka＋Storm的實時日誌統計，因爲涉及的內容較多，這裏先給你們梳理一個項目的運用這些技術的流程。下面是今天的內容目錄：

• 項目流程
• Flume
• Kafka
• Storm

　　下面開始今天的內容分享。

2.項目流程

　　在整合這套方案的時候，項目組也是通過一番討論，在討論中，觀點不少，有人認爲直接使用Storm進行實時處理，去掉Kafka環節；也有認爲直接使用Kafka的API去消費，去掉Storm的消費環節等等，可是最終組內仍是一致決定使用這套方案，緣由有以下幾點：

• 業務模塊化
• 功能組件化

　　咱們認爲，Kafka在整個環節中充當的職責應該單一，這項目的整個環節她就是一箇中間件，下面用一個圖來講明這個緣由，以下圖所示：

　　整個項目流程如上圖所示，這樣劃分使得各個業務模塊化，功能更加的清晰明瞭。

• Data Collection

　　負責從各個節點上實時收集用戶上報的日誌數據，咱們選用的是Apache的Flume NG來實現。

• Data Access

　　因爲收集的數據的速度和數據處理的速度不必定是一致的，所以，這裏添加了一箇中間件來作處理，所使用的是Apache的Kafka，關於Kafka集羣部署，你們能夠參考我寫的《Kafka實戰－Kafka Cluster》。另外，有一部分數據是流向HDFS分佈式文件系統了的，方便於爲離線統計業務提供數據源。

• Stream Computing

　　在收集到數據後，咱們須要對這些數據作實時處理，所選用的是Apache的Storm。關於Storm的集羣搭建部署博客後面補上，較爲簡單。

• Data Output

　　在使用Storm對數據作處理後，咱們須要將處理後的結果作持久化，因爲對響應速度要求較高，這裏採用Redis＋MySQL來作持久化。整個項目的流程架構圖，以下圖所示：

3.Flume

　　Flume是一個分佈式的、高可用的海量日誌收集、聚合和傳輸日誌收集系統，支持在日誌系統中定製各種數據發送方（如：Kafka，HDFS等），便於收集數據。Flume提供了豐富的日誌源收集類型，有：Console、RPC、Text、Tail、Syslog、Exec等數據源的收集，在咱們的日誌系統中目前咱們所使用的是spooldir方式進行日誌文件採集，配置內容信息以下所示：

producer.sources.s.type = spooldir
producer.sources.s.spoolDir = /home/hadoop/dir/logdfs

　　固然，Flume的數據發送方類型也是多種類型的，有：Console、Text、HDFS、RPC等，這裏咱們系統所使用的是Kafka中間件來接收，配置內容以下所示：

producer.sinks.r.type = org.apache.flume.plugins.KafkaSink
producer.sinks.r.metadata.broker.list=dn1:9092,dn2:9092,dn3:9092
producer.sinks.r.partition.key=0
producer.sinks.r.partitioner.class=org.apache.flume.plugins.SinglePartition
producer.sinks.r.serializer.class=kafka.serializer.StringEncoder
producer.sinks.r.request.required.acks=0
producer.sinks.r.max.message.size=1000000
producer.sinks.r.producer.type=sync
producer.sinks.r.custom.encoding=UTF-8
producer.sinks.r.custom.topic.name=test

　　關於，Flume的詳細搭建部署，你們能夠參考我寫的《高可用Hadoop平臺－Flume NG實戰圖解篇》。這裏就很少作贅述了。

4.Kafka

　　Kafka是一種提供高吞吐量的分佈式發佈訂閱消息系統，她的特性以下所示：

• 經過磁盤數據結構提供消息的持久化，這種結構對於即便數據達到TB+級別的消息，存儲也可以保持長時間的穩定。
• 搞吞吐特性使得Kafka即便使用普通的機器硬件，也能夠支持每秒數10W的消息。
• 可以經過Kafka Cluster和Consumer Cluster來Partition消息。

　　Kafka的目的是提供一個發佈訂閱解決方案，他能夠處理Consumer網站中的全部流動數據，在網頁瀏覽，搜索以及用戶的一些行爲，這些動做是較爲關鍵的因素。這些數據一般是因爲吞吐量的要求而經過處理日誌和日誌聚合來解決。對於Hadoop這樣的日誌數據和離線計算系統，這樣的方案是一個解決實時處理較好的一種方案。

　　關於Kafka集羣的搭建部署和使用，你們能夠參考我寫的：《Kafka實戰－Kafka Cluster》，這裏就很少作贅述了。

5.Storm

　　Twitter將Storm開源了，這是一個分佈式的、容錯的實時計算系統，已被貢獻到Apache基金會，下載地址以下所示：

http://storm.apache.org/downloads.html

　　Storm的主要特色以下：

• 簡單的編程模型。相似於MapReduce下降了並行批處理複雜性，Storm下降了進行實時處理的複雜性。
• 可使用各類編程語言。你能夠在Storm之上使用各類編程語言。默認支持Clojure、Java、Ruby和Python。要增長對其餘語言的支持，只需實現一個簡單的Storm通訊協議便可。
• 容錯性。Storm會管理工做進程和節點的故障。
• 水平擴展。計算是在多個線程、進程和服務器之間並行進行的。
• 可靠的消息處理。Storm保證每一個消息至少能獲得一次完整處理。任務失敗時，它會負責從消息源重試消息。
• 快速。系統的設計保證了消息能獲得快速的處理，使用ØMQ做爲其底層消息隊列。
• 本地模式。Storm有一個本地模式，能夠在處理過程當中徹底模擬Storm集羣。這讓你能夠快速進行開發和單元測試。

　　Storm集羣由一個主節點和多個工做節點組成。主節點運行了一個名爲「Nimbus」的守護進程，用於分配代碼、佈置任務及故障檢測。每一個工做節 點都運行了一個名爲「Supervisor」的守護進程，用於監聽工做，開始並終止工做進程。Nimbus和Supervisor都能快速失敗，並且是無 狀態的，這樣一來它們就變得十分健壯，二者的協調工做是由Apache的ZooKeeper來完成的。

　　Storm的術語包括Stream、Spout、Bolt、Task、Worker、Stream Grouping和Topology。Stream是被處理的數據。Spout是數據源。Bolt處理數據。Task是運行於Spout或Bolt中的 線程。Worker是運行這些線程的進程。Stream Grouping規定了Bolt接收什麼東西做爲輸入數據。數據能夠隨機分配（術語爲Shuffle），或者根據字段值分配（術語爲Fields），或者廣播（術語爲All），或者老是發給一個Task（術語爲Global），也能夠不關心該數據（術語爲None），或者由自定義邏輯來決定（術語爲 Direct）。Topology是由Stream Grouping鏈接起來的Spout和Bolt節點網絡。在Storm Concepts頁面裏對這些術語有更詳細的描述。

　　關於Storm集羣的搭建部署，博客在下一篇中更新，到時候會將更新地址附在這裏，這裏就先不對Storm集羣的搭建部署作過多的贅述了。

6.總結

　　這裏就是爲你們介紹的Flume＋Kafka＋Storm的總體流程，後續會給你們用一個項目案例來實踐演示這個流程，包括具體的各個模塊的編碼實踐。今天你們能夠先熟悉下實時計算項目的流程開發。

7.結束語

　　這篇博客就和你們分享到這裏，若是你們在研究學習的過程中有什麼問題，能夠加羣進行討論或發送郵件給我，我會盡我所能爲您解答，與君共勉！