去哪兒網大資料流處理系統：如何使用Alluxio（前 Tachyon）實現300倍效能提升

標籤：

概述

互連網公司同質應用服務競爭日益激烈，業務部門亟需利用線上即時反饋資料輔助決策支援以提高服務水平。Alluxio（前Tachyon）作為一個以記憶體為中心的虛擬分布式儲存系統，在大資料系統效能提升以及生態系統多組件整合的進程中扮演著重要角色。本文將介紹去哪兒網（Qunar）的一個基於Alluxio的即時日誌流的處理系統，Alluxio在此系統中重點解決了異地資料存放區和訪問慢的問題，從而將生產環境中整個流處理流水線的效能總體提高了近10倍，而峰值時甚至達到300倍左右。

目前，去哪兒網的流處理流水線每天需要處理的業務日誌量大約60億條，總計約4.5TB的資料量。其中許多任務都需要保證在穩定的低延時情況下工作，快速迭代計算出結果並反饋到線上業務系統中。例如，無線應用的使用者點擊、搜尋等行為產生的日誌，會被即時抓取並寫入到流水線中分析出對應的推薦資訊，然後反饋給業務系統並展示在應用中。如何保證資料的可靠性以及低延時，就成了整個系統開發和營運工作中的重中之重。

Alluxio大資料存放區系統源自於UC Berkeley AMPLab，目前由Alluxio公司在開源社區主導開發。它是世界上第一個以記憶體為中心的虛擬分布式儲存系統，並將多樣化的上層計算架構和底層儲存系統串連起來，統一資料訪問方式。Alluxio以記憶體為中心的儲存特性使得上層應用的資料訪問速度比現有常規方案快幾個數量級。此外，Alluxio提供的層次化儲存、統一命名空間、世系關係、靈活的檔案API、網頁UI以及命令列工具等特性也方便了使用者在不同實際應用情境下的使用。在本文中，我們將結合具體案例做進一步地闡述。

在我們的案例中，整個流處理計算系統部署在一個物理叢集上，Mesos負責資源的管理和分配，Spark Streaming和Flink是主要的StreamCompute引擎；儲存系統HDFS位於另外一個遠端機房，用於備份儲存整個公司的日誌資訊；Alluxio則是作為核心儲存層，與計算系統部署在一起。業務流水線每天會產生4.5TB左右的資料寫入儲存層，同時通過Kafka消費大約60億條日誌與儲存層中的資料進行碰撞分析。Alluxio對整個流處理系統帶來的價值主要包括：

1. 利用Alluxio的階層式存放區特性，綜合使用了記憶體、SSD和磁碟多種儲存資源。通過Alluxio提供的LRU、LFU等緩衝策略可以保證熱資料一直保留在記憶體中，冷資料則被持久化到level 2甚至level 3的存放裝置上；而HDFS作為長期的檔案備份系統。
2. 利用Alluxio支援多個計算架構的特性，通過Alluxio實現Spark以及Zeppelin等計算架構之間的資料共用，並且達到記憶體級的檔案傳輸速率；此外，我們計劃將Flink和Presto業務遷移到Alluxio上。
3. 利用Alluxio的統一命名空間特性，便捷地管理遠端HDFS底層儲存系統，並向上層提供統一的命名空間，計算架構和應用能夠通過Alluxio統一訪問不同的資料來源的資料；
4. 利用Alluxio提供的多種便於使用的API，降低了使用者的學習成本，方便將原先的整個系統遷移至Alluxio，同時也使得調整的驗證過程變得輕鬆許多；
5. 利用Alluxio解決了原有系統中“Spark任務無法完成”的問題：原系統中當某個Spark executor失敗退出後，會被Mesos重新調度到叢集的任何一個節點上，即使設定了保留上下文，也會因為executor的“漂泊”而導致任務無法完成。新系統中Alluxio將資料的計算與儲存隔離開來，計算資料不會因executor的“漂泊”而丟失，從而解決了這一問題。

本文剩餘部分將詳細對比分析Qunar原有流處理系統以及引入Alluxio改進後的流處理系統，最後簡述我們下一步的規劃和對Alluxio未來方向的期待。

原有系統架構以及相關問題分析

我們的即時資料流處理系統選擇了Mesos作為基礎架構層（Infrastructure Layer）。在原先的系統中，其餘組件都運行在Mesos之上，包括Spark、Flink、Logstash以及Kibana等。其中主要用於流式計算的組件為Spark Streaming，在運行時Spark Streaming向Mesos申請資源，成為一個Mesos Framework，並通過Mesos調度任務。

如所示，在該流處理系統中，待處理的日誌資料來自於多個資料來源，由Kafka進行匯總，資料流在經過了Logstash叢集清洗後再次寫入Kafka暫存，後續由Spark Streaming和Flink等流式計算架構消費這些資料，計算的結果寫入HDFS。在原先的資料處理過程中，主要存在著以下效能瓶頸：

1. 用於存放輸入和輸出資料的HDFS位於一個遠程儲存叢集中（物理位置上位於另一個機房）。本地計算叢集與遠程儲存叢集存在較高的網路延遲，頻繁的遠端資料交換成為整個流處理過程的一大瓶頸；
2. HDFS的設計是基於磁碟的，其I/O效能，尤其是寫資料效能難以滿足流式計算所要求的延時；Spark Streaming在進行計算時，每個Spark executor都要從HDFS中讀取資料，重複的跨機房讀檔案操作進一步地的拖慢了流式計算的整體效率；
3. 由於Spark Streaming被部署在Mesos之上，當某個executor失效時，Mesos可能會在另一個節點重啟這個executor，但是之前失效節點的checkpoint資訊不能再被重複利用，計算任務無法順利完成。而即便executor被重啟在同一節點上，任務可以完成時，完成的速度也無法滿足流式計算的要求。
4. 在Spark Streaming中，若使用MEMORY_ONLY方式管理資料區塊，則會有大量甚至重複的資料位元於Spark executor的JVM中，不僅增大了GC開銷，還可能導致記憶體溢出；而如果採用MEMORY_TO_DISK或者DISK_ONLY的方式，則整體的流處理速度會受限於緩慢的磁碟I/O。

改進後的系統架構及解決方案

在引入Alluxio之後，我們很好地解決上述問題。在新的系統架構中，整個串流的邏輯基本不變。唯一變化的地方在於使用Alluxio代替原先的HDFS作為核心儲存系統，而將原來的HDFS作為Alluxio的底層儲存系統，用於備份。Alluxio同樣運行在Mesos之上，各個計算架構和應用都通過Alluxio進行資料交換，由Alluxio提供高速的資料訪問服務並維護資料的可靠性，僅將最終輸出結果備份至遠程HDFS儲存叢集中。

在新的系統架構中，最初的輸入資料仍然經過Kafka過濾，交由Spark Streaming消費，不同的是，Spark Streaming在計算時產生的大量中間結果以及最終的輸出都存放在Alluxio中，避免與較慢的遠程HDFS叢集進行互動，同時，存放在Alluxio中的資料也能夠很方便地與上層組件，如Flink、Zeppelin進行共用。在整個過程中，Alluxio的一些重要特性對整個流水線的效能提升起到了重要的作用：

1. 支援階層式存放區——我們在每個計算節點上都部署了Alluxio Worker，管理了本地的儲存介質，包括記憶體、SSD和磁碟，構成了層次化的儲存層。每個節點上StreamCompute相關的資料會被儘可能的存放在本地，避免消耗網路資源。同時，Alluxio自身提供了LRU、LFU等高效的替換策略，能夠保證熱資料位元於速度較快的記憶體層中，提高了資料訪問速率；即便是冷資料也是存放在本地磁碟中，不會直接輸出到遠程HDFS儲存叢集；
2. 跨計算架構資料共用——在新的系統架構中，除了Spark Streaming本身以外，其他組件如Zeppelin等也需要使用Alluxio中存放的資料。另外，Spark Streaming和Spark batch job可以通過Alluxio相連並從中讀取或寫入資料，來實現記憶體層級的資料轉送。另外，我們還在將Flink相關的業務與邏輯遷移到Alluxio上，來實現計算架構間的高效資料共用；
3. 統一命名空間——通過使用Alluxio階層式存放區中HDD層，來管理計算叢集本地的持久儲存，同時使用Alluxio的mount功能來管理遠端HDFS儲存叢集。Alluxio很自然地將HDFS以及Alluxio自身的儲存空間統一管理起來。這些儲存資源對於上層應用和計算架構透明的，只呈現了一個統一的命名空間，避免了複雜的輸入輸出邏輯；
4. 簡潔易用的API——Alluxio提供了多套易用的API，它的原生API是一套類似java.io的檔案輸入輸出介面，使用其開發應用不需要繁雜的使用者學習曲線；Alluxio提供了一套HDFS相容的介面，即原先以HDFS作為目標儲存的應用程式能夠隨即轉移至Alluxio，應用程式僅僅需要將原有的hdfs://替換成alluxio://就能正常工作，遷移的成本幾乎是零。此外，Alluxio的命令列工具以及網頁UI方便了開發過程中的驗證和調試步驟，縮短了整個系統的開發週期。例如我們使用Chronos（一個Mesos的Framework，用來執行定時任務）在每天的淩晨通過Alluxio loadufs命令提前載入前一天由MapReduce計算好的資料到Alluxio中，以便後續的操作可以直接讀取這些檔案。
5. Alluxio與Spark有著緊密的結合，我們在Spark Streaming將主要資料存放在Alluxio中而不是Spark executor的JVM中，由於儲存位置同樣是本地記憶體，因此不會拖慢資料處理的效能，反而能夠降低Java GC的開銷。同時，這一做法也避免了因同一節點上資料區塊的冗餘而造成的記憶體溢出。我們還將SparkSteaming計算的中間結果即對RDD的checkpoint儲存在Alluxio上。

通過利用Alluxio眾多特性以及將資料從遠程HDFS儲存叢集預取至本地Alluxio等最佳化方式，整個流處理流水線中的資料互動過程大量轉移到本地叢集的記憶體中，從而極大地提升了資料處理的整體吞吐率，降低了響應延時，滿足了流處理的需求。從我們的線上即時監控的每次micro batch（間隔10分鐘）的監控圖中，可以看到平均處理輸送量從由以前單個mirco batch周期內20至300的eps，提升到較為穩定的7800eps，平均的處理時間從8分鐘左右降低到30至40秒以內，整個流處理加速16-300倍。尤其是在網路繁忙擁擠時，上百倍的加速效果尤為明顯。

而對Kafka的消費指標來看，消費速度也從以前的200K條訊息穩定提升到將近1200K。

此外，我們利用Alluxio內建的metrics組件將監控資料發送到graphite，以方便來監控Alluxio的JVM以及Alluxio的FileSystem狀態。可以看到Alluxio Master對Heap記憶體佔用率維持在低水平。

同期的檔案數量和操作統計為所示。

未來展望

本文介紹的最佳化方法主要是針對利用Alluxio來解決異地儲存訪問慢的問題。效能提升的工作是永無止境的，最後我們也總結了一些未來的工作：

• 我們線上環境中目前使用的Alluxio的版本是0.8.2，Spark Streaming計算的結果目前只能同步寫入底層儲存系統（在我們的案例中即為HDFS），我們已經測試了Alluxio 1.0.1 並準備上線新版本，得益於Alluxio社區活躍的開發，新版本的效能在很多方面都有更大的提升。
• 我們計劃將Flink的計算任務也遷移至Alluxio，同時我們也在計劃修改Presto，令其可以同樣享受Alluxio帶來的跨計算引擎高速資料共用的功能；
• 由於Alluxio能夠很容易於現有儲存系統進行整合并提升上層業務的效能，因此我們也將推廣Alluxio到更多的業務線中，例如用於分析日誌資料的批處理任務等。

　　原文連結：http://geek.csdn.net/news/detail/77491

去哪兒網大資料流處理系統：如何使用Alluxio（前 Tachyon）實現300倍效能提升