[轉]攜程大數據實踐：高併發應用架構及推薦系統案例

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

在李小林看來，大數據是互聯網行業發展的趨勢，互聯網的從業人員須要高度關注大數據相關的技術及應用，也但願經過這一系列大數據相關的講座，讓各位同窗有所收穫。

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

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

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

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、需知足提高轉化率的迫切需求，迭代欄位或場景要快速，同時減小研發成本。

2、應對挑戰的架構涅磐

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

• 存儲的涅磐，這一點對於整個系統的吞吐量和併發量的提高起到最關鍵的做用，須要結合數據存儲模型和具體應用的場景。

• 計算的涅磐，能夠從橫向和縱向考慮：橫向主要是增長併發度，首先想到的是分佈式。縱向拆分就是要求咱們找到計算的結合點從而進行分層，針對不一樣的層次選擇不一樣的計算地點。而後再將各層次計算完後的結果相結合，儘量最大化系統總體的處理能力。

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

3、應用系統的總體架構

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

下圖就是咱們應用系統總體架構以及系統層次的模塊構成。

數據源部分，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支持在線服務的高速緩存，用於緩存統計分析出來的熱點數據。

4、推薦系統案例

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

推薦系統的架構圖：

一、存儲的涅磐

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毫秒之內返回。

二、計算的涅磐

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%的開發時間；對於充分驗證的模塊的複用，有效保證了服務的質量。