京東 “賣家日誌” 系統的構建：流式計算日誌系統應用實踐
來這裡找志同道合的小夥伴！
引言
本文講述如何去構建一個日誌系統，用到了哪些技術？為什麼用這些技術？遇到的問題及優化的過程，希望給大家在實踐中提供一些參考。
這是一個有關於日誌的專案，負責收集、處理、儲存、查詢京東賣家相關操作的日誌，這裡就叫它“賣家日誌”。在日常的開發過程中，可能對日誌這個詞並不陌生，例如常接觸到的Log4j、slf4j等等，這些日誌工具通常用來記錄程式碼執行的情況，當系統出問題時，可以通過檢視日誌及時的定位問題所在，從而很快的解決問題。
今天所講的“ 賣家日誌 ”，與普通的日誌有些許的不同， “ 賣家日誌 ” 是用來記錄賣家對系統各個功能的操作情況，例如：張三這個商家對它的店鋪的某款商品進行了價格的修改，就會記錄下一條日誌在系統當中，系統中的部分資訊是可以提供給商家、運營人員看的，從而讓商家知道自己做了哪些操作，也讓運營人員更好的對商家進行管理。除此之外，也可以幫忙查詢從log中找不到的資訊，從而幫助開發人員解決問題。接下來就講一下業務場景。
業務場景
有許多的業務系統，如訂單、商品，還有一些其他的系統，之前大家都是各自記錄各自的日誌，而且記錄的方式五花八門，格式也獨具一格，這對於商家和運營人員來說是非常頭疼的一件事，沒有給運營人員提供一個可以查詢日誌的平臺，每次有問題的時候，只能耗費大半天的時間去找對應的開發團隊，請他們配合找出問題所在，而且有的時候效果也不是很好。
在這麼一種情況下，“賣家日誌”就誕生了，它給商家和運營以及開發提供了一個統一的日誌平臺，所有團隊的日誌都可以 通過申請許可權 接入這個平臺，並且運營和商家有問題可以第一時間自己去查詢日誌解決問題，而不是盲目的找人解決。
日誌總體設計
上圖是 “賣家日誌” 系統的整體流程圖，在對於處理日誌這一塊業務上，寫了一個日誌客戶端提供給各個組呼叫，還用到了kafka+Strom的流式計算，對於日誌查詢這一塊，首先想到了ES，因為ES是一個分散式的檔案檢索系統，它可以根據日誌的內容提供豐富的檢索功能。而對於冷日誌的儲存，用了一個能夠存更大量的工具—HBase，並且也可以根據一些基本的條件進行日誌的搜尋。
流程：日誌客戶端 - Kafka叢集 - Strom消費 - ES -HBase - ...
技術點
-
Kafka ：一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料，說淺顯易懂一點，可以將Kafka理解成為一個訊息佇列。
-
Storm ：Storm是開源的分散式實時大資料處理框架，它是實時的，可以將它理解為一個專門用來處理流式實時資料的東西。
-
ElasticSearch ：ES是一個基於Lucene的搜尋伺服器，它是一個分散式的檔案檢索系統，它提供了高效的檢索，以及支援多種檢索條件，用起來也十分方便。
-
HBase ：HBase是一個高可靠性、高效能、面向列、可伸縮的分散式儲存系統，適用於結構化的儲存，底層依賴於Hadoop的HDFS，利用HBase技術可在廉價PCServer上搭建起大規模結構化儲存叢集。
日誌客戶端
日誌客戶端給各個系統提供了一個統一的API，類似於Log4j這些日誌工具，這樣使得接入變得方便簡潔，和平常寫日誌沒什麼區別。這裡需要提到的一個點是客戶端對於日誌的處理過程，用 下 圖來進行說明：
大家可能會疑惑，為什麼不直接寫Kafka呢？接下來做個比較，直接寫入本地快，還是寫Kafka快呢？
很明顯，寫入本地快。因為寫日誌，想達到的效果是儘量不要影響業務，能夠以更快的方式處理，而對於日誌後期的處理，只需要在後臺開啟固定的幾個執行緒就可以了，這樣既使業務對此無感知，又不浪費資源，除此之外，落盤的方式還為日誌資料不丟提供了保障。
此外，這裡本地資料的落盤和讀取都用到了NIO的記憶體對映，寫入和讀取的資料又有了進一步的提升，使得業務日誌快速落盤，並且能夠快速的讀取出來傳送到Kafka，這也是一個優勢。
為什麼要用Kafka
首先介紹一下Kafka，Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料，可以將Kafka理解成為一個訊息佇列。具體的一些細節，大家可以上網搜尋。
Kafka主要應用場景：
-
持續的訊息：為了從大資料中派生出有用的資料，任何資料的丟失都會影響生成的結果，Kafka提供了一個複雜度為O(1)的磁碟結構儲存資料，即使是對於TB級別的資料都是提供了一個常量時間效能
-
高吞吐量：Kafka採用普通的硬體支援每秒百萬級別的吞吐量
-
分散式：明確支援訊息的分割槽，通過Kafka伺服器和消費者機器的叢集分散式消費，維持每一個分割槽是有序的
-
支援多種語言：Java、.net、PHP、ruby、Python
-
實時性：訊息被生成者執行緒生產就能馬上被消費者執行緒消費，這種特性和事件驅動的系統是相似的
Kafka的優勢：
-
主要用來解決百萬級別的資料中生產者和消費者之間資料傳輸的問題
-
可以將一條資料提供給多個接收這做不同的處理
-
當兩個系統是隔絕的，無法通訊的時候，如果想要他們通訊就需要重新構建其中的一個工程，而Kafka實現了生產者和消費者之間的無縫對接
通過上面對Kafka的應用場景和優勢的描述，再去理解“賣家日誌”的業務場景，就能理解為什麼採用的技術是Kafka了。因為Kafka快，並且適用於流式處理，它可以將突發的量轉換成為平穩的流，以便於Strom的處理。
因為日誌是不定時的，就像水流一樣，一直是不斷的，並且不一定是平穩的。而Kafka的一些特性，非常符合 “賣家日誌” 的業務，除此之外，Kafka作為一個高吞吐量的分散式釋出訂閱訊息系統，可以有多個生產者和消費者，這也為 “賣家日誌” 統一接入和後期的多元化處理提供了強有力的保障。如下圖：
Storm的應用
日誌是一個流式的資料，它是不定時的，而且是不平穩的，將這些不定時且不平穩的資料進行處理，用什麼方式更好呢？討論後最終採用了Kafka+Storm的方式來處理這些日誌資料。
為什麼要用Storm呢？Storm是一個免費開源、分散式、高容錯的實時計算系統。Storm令持續不斷的流計算變得容易，Kafka可以將突發的資料轉換成平穩的流，源源不斷的推向Storm，Storm進行消費，處理，最終落庫。Storm處理這一塊的流程，如下圖所示：
從上圖可以看到，Storm整個處理的流程，其中對日誌進行了兩次的處理，一次是校驗是否有效，並且封裝成物件交給下一個bolt，insertBolt負責將資料落庫，這麼一個流程看起來比較清晰明瞭。
關於資料儲存的處理
對於資料的儲存，採用ES對熱資料進行儲存，而對於冷資料，也就是很久之前的資料，採用HBase來進行儲存備份。為什麼要這樣做呢？
日誌資料使用什麼做儲存，直接影響查詢，前期的想法是直接把資料存到能夠抗量HBase上，但是對於多種條件的查詢，HBase顯然不符合要求，所以經過評審，決定用一個分散式檢索的系統來進行儲存，那就是ElasticSearch。
那大家可能會問到：為什麼還要用HBase呢？因為ES作為一個檢索的系統，它並不適用於大量的資料的儲存，隨著資料量的增大，ES的查詢效能會慢慢的降低，而日誌需要儲存的時間是一年，每天的量都是6、7億的資料，所以對於ES來說，很難抗住，不斷的加機器並不是很好的解決辦法。
經過討論，尋求一個更能夠存資料的東西來存很久不用的日誌資料，並且能夠提供簡單的檢索，最終選擇了HBase，將最近兩個月的資料放在ES中，給使用者提供多條件的檢索，兩個月之前的資料存放在HBase中，提供簡單的檢索功能，因為兩個多月前的日誌也沒有太大的量去查看了。具體的資料流轉如下圖：
遇到的問題
隨著資料量的增多，對服務的要求越來越高，即使是將儲存的資料做了冷熱分離，查詢也非常的忙，並且隨著資料量的增多，插入的效能也越來越慢了。而且，對於所申請的Kafka叢集，明顯也扛不住這麼多客戶端每天輸入這麼大的量，因此對日誌這一塊的業務流程進行了仔細的梳理。
解決方案
經過不斷的討論和架構的評審，想到了一個比較好的解決辦法，那就是對日誌資料進行業務分離。抽出了幾個日誌量比較大的業務，比如訂單和商品，新申請了訂單和商品的Kafka叢集和ES叢集，其他業務還是不變，訂單和商品的日誌和其他日誌都單獨開來，使用不同的Kafka和ES、HBase叢集。
通過對業務的抽離，效能得到了很明顯的提升，並且對資料進行業務的分類，也方便了對日誌資料的管理，達到互不影響的狀態。今後對於HBase的資料，也打算將它推入到大資料集市中，提供不同的部門做資料分析。
RECOMMEND