攜程大資料實踐：高併發應用架構及推薦系統案例

本文來自攜程技術中心基礎業務研發部的《應用架構涅槃》系列分享。據基礎業務研發部負責人李小林介紹，網際網路二次革命的移動網際網路時代，如何吸引使用者、留住使用者並深入挖掘使用者價值，在激烈的競爭中脫穎而出，是各大電商的重要課題。透過各類大資料對使用者進行研究，以資料驅動產品是解決這個課題的主要手段，攜程的大資料團隊也由此應運而生；經過幾年的努力，大資料的相關技術為業務帶來了驚人的提升與幫助。以基礎大資料的使用者意圖服務為例，透過將廣告和欄位的“千人一面”變為“千人千面”，在提升使用者便捷性，可用性，降低費力度的同時，其轉化率也得到了數倍的提升，體現了大資料服務的真正價值。

在李小林看來，大資料是網際網路行業發展的趨勢，網際網路的從業人員需要高度關注大資料相關的技術及應用，也希望透過這一系列大資料相關的講座，讓各位同學有所收穫。

首場《應用架構涅磐》分享來自基礎業務研發部的董銳，包括業務高速發展帶來的應用架構挑戰、應對挑戰的架構涅磐、應用系統整體架構和推薦系統案例等四個部分。

一、業務高速發展帶來的應用架構挑戰

公司業務高速發展帶來哪些主要的變化，以及給我們的系統帶來了哪些挑戰？

1.業務需求的急速增長，訪問請求的併發量激增，2016年1月份以來，業務部門的服務日均請求量激增了5.5倍。

2.業務邏輯日益複雜化，基礎業務研發部需要支撐起OTA數十個業務線，業務邏輯日趨複雜和繁多。

3.業務資料來源多樣化，異構化，接入的業務線、合作公司的資料來源越來越多；接入的資料結構由以前的資料庫結構化資料整合轉為Hive表、評論文字資料、日誌資料、天氣資料、網頁資料等多元化異構資料整合。

4.業務的高速發展和迭代，部門一直以追求以最少的開發人力，以架構和系統的技術最佳化，支撐起攜程各業務線高速發展和迭代的需要。

在這種新形勢下，傳統應用架構不得不變，做為工程師也必然要自我涅槃，改為及新的高併發架構，來應對業務需求激增及高速迭代的需要。計算分層分解、去SQL、去資料庫化、模組化拆解的相關技改工作已經刻不容緩。

以使用者意圖（AI 點金杖）的個性化服務為例， 面對BU業務線的全面支援的迫切需要，其應用架構必須解決如下技術難點：

1.高訪問併發：每天近億次的訪問請求；

2.資料量大：每天TB級的增量資料，近百億條的使用者資料，上百萬的產品資料；

3.業務邏輯複雜：複雜個性化演算法和LBS演算法；例如：滿足一個複雜使用者請求需要大量計算和30次左右的SQL資料查詢，服務延時越來越長；

4.高速迭代上線：面對OTA多業務線的個性化、Cross-saling、Up-saling、需滿足提升轉化率的迫切需求，迭代欄位或場景要快速，同時減少研發成本。

二、應對挑戰的架構涅磐

面對這些挑戰，我們的應用系統架構應該如何涅磐？主要分如下三大方面系統詳解：

?儲存的涅磐，這一點對於整個系統的吞吐量和併發量的提升起到最關鍵的作用，需要結合資料儲存模型和具體應用的場景。

?計算的涅磐，可以從橫向和縱向考慮：橫向主要是增加併發度，首先想到的是分散式。縱向拆分就是要求我們找到計算的結合點從而進行分層，針對不同的層次選擇不同的計算地點。然後再將各層次計算完後的結果相結合，儘可能最大化系統整體的處理能力。

?業務層架構的涅磐，要求系統的良好的模組化設計，清楚的定義模組的邊界，模組自升級和可配置化。

三、應用系統的整體架構

認識到需要應對的挑戰，我們應該如何設計我們的系統呢，下面將全面的介紹下我們的應用系統整體架構。

下圖就是我們應用系統整體架構以及系統層次的模組構成。

資料來源部分，Hermes是攜程框架部門提供的訊息佇列，基於Kafka和MySQL做為底層實現的封裝，應用於系統間實時資料傳輸互動通道。Hive和HDFS是攜程海量資料的主要儲存，兩者來自Hadoop生態體系。Hadoop大家已經很熟悉，如果不熟悉的同學只要知道Hadoop主要用於大資料量儲存和平行計算批處理工作。

Hive是基於Hadoop平臺的資料倉儲，沿用了關係型資料庫的很多概念。比如說資料庫和表，還有一套近似於SQL的查詢介面的支援，在Hive裡叫做HQL，但是其底層的實現細節和關係型資料庫完全不一樣，Hive底層所有的計算都是基於MR來完成，我們的資料工程師90%都資料處理工作都基於它來完成。

離線部分，包含的模組有MR、Hive、Mahout、SparkQL/MLLib。Hive上面已經介紹過，Mahout簡單理解提供基於Hadoop平臺進行的一些機器學習的演算法包。Spark類似hadoop也是提供大資料並行批次處理平臺，但是它是基於記憶體的。SparkQL 和Spark MLLib是基於Spark平臺的SQL查詢引擎和資料探勘相關演算法框架。我們主要用Mahout和Spark MLLib進行資料探勘工作。

排程系統zeus，是淘寶開源大資料平臺排程系統，於2015年引進到攜程，之後我們進行了重構和功能升級，做為攜程大資料平臺的作業排程平臺。

近線部分，是基於Muise來實現我們的近實時的計算場景，Muise是也是攜程OPS提供的實時計算流處理平臺，內部是基於Storm實現與HERMES訊息佇列搭配起來使用。例如，我們使用MUSIE透過消費來自訊息佇列裡的使用者實時行為，訂單記錄，結合畫像等一起基礎資料，經一系列複雜的規則和演算法，實時的識別出使用者的行程意圖。

後臺/線上應用部分，MySQL用於支撐後臺系統的資料庫。ElasticSearch是基於Lucene實現的分散式搜尋引擎，用於索引使用者畫像的資料，支援離線精準營銷的使用者篩選，同時支援線上應用推薦系統的選品功能。HBase 基於Hadoop的HDFS 上的列儲存NoSQL資料庫，用於後臺報表視覺化系統和線上服務的資料儲存。

這裡說明一下, 線上和後臺應用使用的ElasticSearch和HBase叢集是分開的，互不影響。Redis支援線上服務的快取記憶體，用於快取統計分析出來的熱點資料。

四、推薦系統案例

介紹完我們應用系統的整體構成，接下來分享基於這套系統架構實現的一個例項——攜程個性化推薦系統。

推薦系統的架構圖：

1、儲存的涅磐

1）NoSQL (HBase+Redis)

我們之前儲存使用的是MySQL，一般關係型資料庫會做為應用系統儲存的首選。大家知道MySQL非商業版對分散式支援不夠，在儲存資料量不高，查詢量和計算複雜度不是很大的情況下，可以滿足應用系統絕大部分的功能需求。

我們現狀是需要安全儲存海量的資料，高吞吐，併發能力強，同時隨著資料量和請求量的快速增加，能夠透過加節點來擴容。另外還需要支援故障轉移，自動恢復，無需額外的運維成本。綜上幾個主要因素，我們進行了大量的調研和測試，最終我們選用HBase和Redis兩個NoSQL資料庫來取代以往使用的MySQL。我們把使用者意圖以及推薦產品資料以KV的形式儲存在HBase中，我對操作HBase進行一些最佳化，其中包括rowkey的設計，預分配，資料壓縮等，同時針對我們的使用場景對HBase本身配置方面的也進行了調優。目前儲存的資料量已經達到TB級別，支援每天千萬次請求，同時保證99%在50毫秒內返回。

Redis和多數應用系統使用方式一樣，主要用於快取熱點資料，這裡就不多說了。

2）搜尋引擎 (ElasticSearch)

ES索引各業務線產品特徵資料，提供基於使用者的意圖特徵和產品特徵複雜的多維檢索和排序功能，當前叢集由4臺大記憶體物理機器構成，採用全記憶體索引。對比某一個複雜的查詢場景，之前用MySQL將近需要30次查詢，使用ES只需要一次組合查詢且在100毫秒內返回。目前每天千萬次搜尋，99%以上在300毫秒以內返回。

2、計算的涅磐

1）資料來源，我們的資料來源分結構化和半結構化資料以及非結構化資料。

結構化資料主要是指攜程各產線的產品維表和訂單資料，有酒店、景酒、團隊遊、門票、景點等，還有一些基礎資料，比如城市表、車站等，這類資料基本上都是T+1，每天會有流程去各BU的生產表拉取資料。

半結構化資料是指，攜程使用者的訪問行為資料，例如瀏覽、搜尋、預訂、反饋等，這邊順便提一下，這些資料這些是由前端採集框架實時採集，然後下發到後端的收集服務，由收集服務在寫入到Hermes訊息佇列，一路會落地到Hadoop上面做長期儲存，另一路近線層可以透過訂閱Hermes此類資料Topic進行近實時的計算工作。

我們還用到外部合作渠道的資料，還有一些評論資料，評論屬於非結構化的，也是T+1更新。

2）離線計算，主要分三個處理階段。

預處理階段，這塊主要為後續資料探勘做一些資料的準備工作，資料去重，過濾，對缺失資訊的補足。舉例來說採集下來的使用者行為資料，所含有的產品資訊很少，我們會使用產品表的資料進行一些補足，確保給後續的資料探勘使用時候儘量完整的。

資料探勘階段，主要運用一些常用的資料探勘演算法進行模型訓練和推薦資料的輸出(分類、聚類、迴歸、CF等)。

結果匯入階段，我們透過可配置的資料匯入工具將推薦資料，進行一系列轉換後，匯入到HBase、Redis以及建立ES索引，Redis儲存的是經統計計算出的熱點資料。

3）近線計算（使用者意圖、產品快取）

當使用者沒有明確的目的性情況下，很難找到滿足興趣的產品，我們不僅需要了解使用者的歷史興趣，使用者實時行為特徵的抽取和理解更加重要，以便快速的推薦出符合使用者當前興趣的產品，這就是使用者意圖服務需要實現的功能。

一般來說使用者特徵分成兩大類：一種是穩定的特徵（使用者畫像），如使用者性別、常住地、主題偏好等特徵；另一類是根據使用者行為計算獲取的特徵，如使用者對酒店星級的偏好、目的地偏好、跟團遊/自由行偏好等。基於前面所述的計算的特點，我們使用近線上計算來獲取第二類使用者特徵，整體框圖如下。從圖中可以看出它的輸入資料來源包括兩大類：第一類是實時的使用者行為；第二類是使用者畫像，歷史交易以及情景等離線模組提供的資料。結合這兩類資料，經一些列複雜的近線學習演算法和規則引擎，計算得出使用者當前實時意圖列表儲存到HBase和Redis中。

攜程使用者意圖框架

近線另一個工作是產品資料快取，攜程的業務線很多，而我們的推薦系統會推各個業務線的產品，因此我們需要呼叫所有業務線的產品服務介面，但隨著我們上線的場景的增加，這樣無形的增加了對業務方介面的呼叫壓力。而且業務線產品介面服務主要應用於業務的主流程或關鍵型應用，比較重，且SLA服務等級層次不齊，可能會影響到整個推薦系統的響應時間。

為了解決這兩個問題，我們設計了近線上計算來進行業務的產品資訊非同步快取策略，具體的流程如下。

我們會將待推薦的產品Id全部透過Kafka非同步下發，在Storm中我們會對各業務方的產品首先進行聚合，達到批處理個數或者時間gap時，再呼叫各業務方的介面，這樣減少對業務方介面的壓力。透過呼叫業務方介面更新的產品狀態臨時快取起來（根據各業務產品資訊更新週期分別設定快取失效時間），線上計算的時候直接先讀取臨時快取資料，快取不存在的情況下，再擊穿到業務的介面服務。

產品非同步快取框架

4）線上計算（2個關鍵業務層架構模組介紹）

①業務層架構-資料治理和訪問模組，支援的儲存介質，目前支援的儲存介質有Localcache、Redis、HBase、MySQL可以支援橫向擴充套件。統一配置，對同一份資料，採用統一配置，可以隨意儲存在任意介質，根據id查詢返回統一格式的資料，對查詢介面完全透明。

穿透策略和容災策略，Redis只儲存了熱資料，當需要查詢冷資料則可以自動到下一級儲存如HBase查詢，避免快取資源浪費。當Redis出現故障時或請求數異常上漲，超過整體承受能力，此時服務降級自動生效，並可配置化。

②業務層架構-推薦策略模組，整個流程是先將使用者意圖、使用者瀏覽，相關推薦策略生成的產品集合等做為資料輸入，接著按照場景規則，業務邏輯重新過濾，聚合、排序。最後驗證和拼裝業務線產品資訊後輸出推薦結果；

我們對此流程每一步進行了一些模組化的抽象，將重排序邏輯按步驟抽象解耦，抽象如右圖所示的多個元件，開發新介面時僅需要將內部DSL拼裝便可以得到滿足業務需求的推薦服務；提高了程式碼的複用率和可讀性，減少了超過50%的開發時間；對於充分驗證的模組的複用，有效保證了服務的質量。