攜程機票日誌追蹤系統架構演進
作者簡介
許鵬，攜程高階研發經理，負責機票大資料基礎平臺的構建和運維。
機票業務看起來簡單，實際上整個流程的處理鏈條很長，呼叫關係也非常複雜，上下游涉及的各類日誌種類約60個，每種日誌都有獨立格式和請求/響應報文，日生產的日誌資料量約50-100億，如果時間範圍再擴大到15天，資料量輕鬆的達到千億級以上。
如何在海量的資料中提取想要的資料，這不是一件容易的事情。在大多數情況下，我們需要一種穩定而快速的架構，幫助我們 在資源和效能之間獲得平衡 ，於是我們開始了探索之旅。
一、初始架構
1.1 ElasticSearch
首先需要解決儲存和查詢的問題，海量的資料需要儲存起來，供查詢使用。如何有效的儲存和查詢這些日誌資料，是系統設計時要回答的首要問題。
日誌資料儲存的特點和要求：
-
支援海量寫入，TPS要能夠支撐>50K/s
-
支援靈活的schema
-
支援靈活的資料查詢，響應時間要儘可能短，時延<5s
-
對於過期的資料，支援海量刪除
按照以上指標，我們對市面上的產品進行摸底和預研，選定了三種儲存方式來進行對比：Cassandra、HBase、ElasticSearch。
1.1.1 Cassandra
Cassandra支援海量的資料寫入，但是查詢欄位單一，同時對於資料刪除不夠友好，不支援行級別的TTL。當有大量的cell過期後，很容易出現TombStone的問題，並且在資料定期清理的過程中，很容易出現數據寫入超時等現象。
1.1.2 HBase
1）HBase支援海量資料寫入，在過期資料處理層面，不容易產生Cassandra才有的TombStone現象。但在查詢介面層面，需要呼叫api才行，使用難度較高，儘管引入apache phoenix可以通過SQL來進行查詢，但這增強了系統解決方案的複雜度。
2）HBase對於Row Key的查詢能夠快速返回，如果變更查詢條件，響應會下降非常明顯。
1.1.3 Elasticsearch
在排除了Cassandra和HBase之後，開始嘗試Elasticsearch，通過研究發現，Elasticsearch可以很好的滿足我們的需求：
-
支援靈活的資料結構，支援schemaless
-
可以通過水平擴充套件來支援海量的資料寫入
-
查詢方式靈活，響應時間短，平均查詢響應低於<1s
-
結合別名和每天建立新索引，可以很好的移除過期資料，同時操作過程對使用者透明
1.2 Kafka
Kafka作為訊息佇列，在儲存日誌資料的同時，隔離開資料產生的應用和資料處理流程。
1.3 ETL
為了把海量日誌從Kafka近實時的匯入到Elasticsearch，我們採用spark來進行處理，當前資料匯入延遲不超過5s。
1.4 全域性ID
每一次使用者會話請求會被賦予一個單獨的全域性ID(TransactionID)，這個全域性ID會在各個模組之間的訊息傳遞中出現。通過這樣一個全域性ID，開發人員可以追蹤請求在整個鏈路中的處理情況。
各開發模組將含有全域性ID的日誌資訊儲存到Kafka叢集中。
二、架構演進
第一代架構採用Elasticsearch解決了日誌儲存的問題，單日誌查詢的表現令人滿意。
在實際系統使用過程中發現，由於機票日誌種類繁多， 同時對50個以上日誌並行查詢會導致ElasticSearch叢集整體狀態變黃甚至變紅，叢集變的不穩定，整體反應速度變得非常緩慢。
硬體擴容Or提升效能，在架構層次需要進行決策，擴容能夠解決一些問題，但是對於攜程機票而言，後續還會有更多的日誌接入，架構層面必須均衡資源和效能的平衡，而不是單純的硬體擴容，我們決定在架構層面進一步演進來提升效能。
2.1 增加二級索引
通過分析，發現由於Elasticsearch會儲存最近15天的日誌，如果針對每一個TransactionID，都去查詢15天的所有日誌，那麼查詢響應時間會變得緩慢。
實際上每一個TransactionID不可能都存在於60多種日誌中，做了很多多餘的查詢，如果能夠精確的查詢就好了。
為了增強查詢的精確性，我們採用只對存有TransactionID的索引進行查詢，我們建立了二級索引，通過二級索引，可以將TransactionID對映到一到多個具體的Elasticseaerch索引，然後對這些索引發起查詢請求，獲取詳情資訊。
也就是說，我們建立了索引，在查詢前能準確的知道一個TransactionID在哪些日誌、哪些日期中存在。
這樣可以準確的查詢這些日誌，去掉不需要查詢的日誌。
通過二級索引的設定，查詢速度獲得很大的提升，由原來的20-30秒提升到5秒以內。
2.2 冷熱資料分離
二級索引的建立解決了很大一部分問題，隨著而來又產生了新的問題。
每天的二級索引資料量高達5億條，隨著時間推移二級索引資料量迅速增長，查詢速度出現了抖動甚至大幅度下降，二級索引本身變成了瓶頸。
對二級索引我們再次做出了優化，對冷熱資料進行切割，當天的二級索引會儲存到redis中，因為系統使用中發現，使用者一般對於當天的請求處理情況關注的比較多。Redis可以在5ms以內返回二級索引結果。
對於歷史的二級索引，會將資訊從Redis匯入到Elasticsearch中。
三、小結
目前，機票日誌追蹤系統仍然在不斷的、持續的演進中，比如最新的二級索引中冷資料不再儲存到ElasticSearch，而是儲存在codis叢集中，ETL我們採用更快更好的批量灌入方式等等。
隨著大資料技術的不斷髮展和進步，相信我們的架構也會不斷的升級換代，架構的升級必然帶來效能的提升，這就是技術的魅力所在。
我們始終相信，架構沒有最好，只有更好。
【推薦閱讀】
-
ofollow,noindex"> 一文帶你瞭解攜程第四代全鏈路測試系統
