本文來自攜程技術中心基礎業(yè)務研發(fā)部的《應用架構涅槃》系列分享。據(jù)基礎業(yè)務研發(fā)部負責人李小林介紹，互聯(lián)網(wǎng)二次革命的移動互聯(lián)網(wǎng)時代，如何吸引用戶、留住用戶并深入挖掘用戶價值，在激烈的競爭中脫穎而出，是各大電商的重要課題。通過各類大數(shù)據(jù)對用戶進行研究，以數(shù)據(jù)驅動產品是解決這個課題的主要手段，攜程的大數(shù)據(jù)團隊也由此應運而生；經過幾年的努力，大數(shù)據(jù)的相關技術為業(yè)務帶來了驚人的提升與幫助。以基礎大數(shù)據(jù)的用戶意圖服務為例，通過將廣告和欄位的“千人一面”變?yōu)?ldquo;千人千面”，在提升用戶便捷性，可用性，降低費力度的同時，其轉化率也得到了數(shù)倍的提升，體現(xiàn)了大數(shù)據(jù)服務的真正價值。
在李小林看來，大數(shù)據(jù)是互聯(lián)網(wǎng)行業(yè)發(fā)展的趨勢，互聯(lián)網(wǎng)的從業(yè)人員需要高度關注大數(shù)據(jù)相關的技術及應用，也希望通過這一系列大數(shù)據(jù)相關的講座，讓各位同學有所收獲。
首場《應用架構涅磐》分享來自基礎業(yè)務研發(fā)部的董銳，包括業(yè)務高速發(fā)展帶來的應用架構挑戰(zhàn)、應對挑戰(zhàn)的架構涅磐、應用系統(tǒng)整體架構和推薦系統(tǒng)案例等四個部分。
一、業(yè)務高速發(fā)展帶來的應用架構挑戰(zhàn)
公司業(yè)務高速發(fā)展帶來哪些主要的變化，以及給我們的系統(tǒng)帶來了哪些挑戰(zhàn)？
業(yè)務需求的急速增長，訪問請求的并發(fā)量激增，2016年1月份以來，業(yè)務部門的服務日均請求量激增了5.5倍。
業(yè)務邏輯日益復雜化，基礎業(yè)務研發(fā)部需要支撐起OTA數(shù)十個業(yè)務線，業(yè)務邏輯日趨復雜和繁多。
業(yè)務數(shù)據(jù)源多樣化，異構化，接入的業(yè)務線、合作公司的數(shù)據(jù)源越來越多；接入的數(shù)據(jù)結構由以前的數(shù)據(jù)庫結構化數(shù)據(jù)整合轉為Hive表、評論文本數(shù)據(jù)、日志數(shù)據(jù)、天氣數(shù)據(jù)、網(wǎng)頁數(shù)據(jù)等多元化異構數(shù)據(jù)整合。
業(yè)務的高速發(fā)展和迭代，部門一直以追求以最少的開發(fā)人力，以架構和系統(tǒng)的技術優(yōu)化，支撐起攜程各業(yè)務線高速發(fā)展和迭代的需要。
在這種新形勢下，傳統(tǒng)應用架構不得不變，做為工程師也必然要自我涅槃，改為大數(shù)據(jù)及新的高并發(fā)架構，來應對業(yè)務需求激增及高速迭代的需要。計算分層分解、去SQL、去數(shù)據(jù)庫化、模塊化拆解的相關技改工作已經刻不容緩。
以用戶意圖(AI 點金杖)的個性化服務為例， 面對BU業(yè)務線的全面支持的迫切需要，其應用架構必須解決如下技術難點：
高訪問并發(fā)：每天近億次的訪問請求；
數(shù)據(jù)量大：每天TB級的增量數(shù)據(jù)，近百億條的用戶數(shù)據(jù)，上百萬的產品數(shù)據(jù)；
業(yè)務邏輯復雜：復雜個性化算法和LBS算法；例如：滿足一個復雜用戶請求需要大量計算和30次左右的SQL數(shù)據(jù)查詢，服務延時越來越長；
高速迭代上線：面對OTA多業(yè)務線的個性化、Cross-saling、Up-saling、需滿足提升轉化率的迫切需求，迭代欄位或場景要快速，同時減少研發(fā)成本。
二、應對挑戰(zhàn)的架構涅磐
面對這些挑戰(zhàn)，我們的應用系統(tǒng)架構應該如何涅磐？主要分如下三大方面系統(tǒng)詳解：
存儲的涅磐，這一點對于整個系統(tǒng)的吞吐量和并發(fā)量的提升起到最關鍵的作用，需要結合數(shù)據(jù)存儲模型和具體應用的場景。
計算的涅磐，可以從橫向和縱向考慮：橫向主要是增加并發(fā)度，首先想到的是分布式。縱向拆分就是要求我們找到計算的結合點從而進行分層，針對不同的層次選擇不同的計算地點。然后再將各層次計算完后的結果相結合，盡可能最大化系統(tǒng)整體的處理能力。
業(yè)務層架構的涅磐，要求系統(tǒng)的良好的模塊化設計，清楚的定義模塊的邊界，模塊自升級和可配置化。
三、應用系統(tǒng)的整體架構
認識到需要應對的挑戰(zhàn)，我們應該如何設計我們的系統(tǒng)呢，下面將全面的介紹下我們的應用系統(tǒng)整體架構。
下圖就是我們應用系統(tǒng)整體架構以及系統(tǒng)層次的模塊構成。
數(shù)據(jù)源部分，Hermes是攜程框架部門提供的消息隊列，基于Kafka和MySQL做為底層實現(xiàn)的封裝，應用于系統(tǒng)間實時數(shù)據(jù)傳輸交互通道。Hive和HDFS是攜程海量數(shù)據(jù)的主要存儲，兩者來自Hadoop生態(tài)體系。Hadoop大家已經很熟悉，如果不熟悉的同學只要知道Hadoop主要用于大數(shù)據(jù)量存儲和并行計算批處理工作。
Hive是基于Hadoop平臺的數(shù)據(jù)倉庫，沿用了關系型數(shù)據(jù)庫的很多概念。比如說數(shù)據(jù)庫和表，還有一套近似于SQL的查詢接口的支持，在Hive里叫做HQL，但是其底層的實現(xiàn)細節(jié)和關系型數(shù)據(jù)庫完全不一樣，Hive底層所有的計算都是基于MR來完成，我們的數(shù)據(jù)工程師90%都數(shù)據(jù)處理工作都基于它來完成。
離線部分，包含的模塊有MR、Hive、Mahout、SparkQL/MLLib。Hive上面已經介紹過，Mahout簡單理解提供基于Hadoop平臺進行數(shù)據(jù)挖掘的一些機器學習的算法包。Spark類似hadoop也是提供大數(shù)據(jù)并行批量處理平臺，但是它是基于內存的。SparkQL 和Spark MLLib是基于Spark平臺的SQL查詢引擎和數(shù)據(jù)挖掘相關算法框架。我們主要用Mahout和Spark MLLib進行數(shù)據(jù)挖掘工作。
調度系統(tǒng)zeus，是淘寶開源大數(shù)據(jù)平臺調度系統(tǒng)，于2015年引進到攜程，之后我們進行了重構和功能升級，做為攜程大數(shù)據(jù)平臺的作業(yè)調度平臺。
近線部分，是基于Muise來實現(xiàn)我們的近實時的計算場景，Muise是也是攜程OPS提供的實時計算流處理平臺，內部是基于Storm實現(xiàn)與HERMES消息隊列搭配起來使用。例如，我們使用MUSIE通過消費來自消息隊列里的用戶實時行為，訂單記錄，結合畫像等一起基礎數(shù)據(jù)，經一系列復雜的規(guī)則和算法，實時的識別出用戶的行程意圖。
后臺/線上應用部分，MySQL用于支撐后臺系統(tǒng)的數(shù)據(jù)庫。ElasticSearch是基于Lucene實現(xiàn)的分布式搜索引擎，用于索引用戶畫像的數(shù)據(jù)，支持離線精準營銷的用戶篩選，同時支持線上應用推薦系統(tǒng)的選品功能。HBase 基于Hadoop的HDFS 上的列存儲NoSQL數(shù)據(jù)庫，用于后臺報表可視化系統(tǒng)和線上服務的數(shù)據(jù)存儲。
這里說明一下， 在線和后臺應用使用的ElasticSearch和HBase集群是分開的，互不影響。Redis支持在線服務的高速緩存，用于緩存統(tǒng)計分析出來的熱點數(shù)據(jù)。
四、推薦系統(tǒng)案例
介紹完我們應用系統(tǒng)的整體構成，接下來分享基于這套系統(tǒng)架構實現(xiàn)的一個實例——攜程個性化推薦系統(tǒng)。
推薦系統(tǒng)的架構圖：
1、存儲的涅磐
1)NoSQL (HBase+Redis)
我們之前存儲使用的是MySQL，一般關系型數(shù)據(jù)庫會做為應用系統(tǒng)存儲的首選。大家知道MySQL非商業(yè)版對分布式支持不夠，在存儲數(shù)據(jù)量不高，查詢量和計算復雜度不是很大的情況下，可以滿足應用系統(tǒng)絕大部分的功能需求。
我們現(xiàn)狀是需要安全存儲海量的數(shù)據(jù)，高吞吐，并發(fā)能力強，同時隨著數(shù)據(jù)量和請求量的快速增加，能夠通過加節(jié)點來擴容。另外還需要支持故障轉移，自動恢復，無需額外的運維成本。綜上幾個主要因素，我們進行了大量的調研和測試，最終我們選用HBase和Redis兩個NoSQL數(shù)據(jù)庫來取代以往使用的MySQL。我們把用戶意圖以及推薦產品數(shù)據(jù)以KV的形式存儲在HBase中，我對操作HBase進行一些優(yōu)化，其中包括rowkey的設計，預分配，數(shù)據(jù)壓縮等，同時針對我們的使用場景對HBase本身配置方面的也進行了調優(yōu)。目前存儲的數(shù)據(jù)量已經達到TB級別，支持每天千萬次請求，同時保證99%在50毫秒內返回。
Redis和多數(shù)應用系統(tǒng)使用方式一樣，主要用于緩存熱點數(shù)據(jù)，這里就不多說了。
2)搜索引擎 (ElasticSearch)
ES索引各業(yè)務線產品特征數(shù)據(jù)，提供基于用戶的意圖特征和產品特征復雜的多維檢索和排序功能，當前集群由4臺大內存物理機器構成，采用全內存索引。對比某一個復雜的查詢場景，之前用MySQL將近需要30次查詢，使用ES只需要一次組合查詢且在100毫秒內返回。目前每天千萬次搜索，99%以上在300毫秒以內返回。
2、計算的涅磐
1)數(shù)據(jù)源，我們的數(shù)據(jù)源分結構化和半結構化數(shù)據(jù)以及非結構化數(shù)據(jù)。
結構化數(shù)據(jù)主要是指攜程各產線的產品維表和訂單數(shù)據(jù)，有酒店、景酒、團隊游、門票、景點等，還有一些基礎數(shù)據(jù)，比如城市表、車站等，這類數(shù)據(jù)基本上都是T+1，每天會有流程去各BU的生產表拉取數(shù)據(jù)。
半結構化數(shù)據(jù)是指，攜程用戶的訪問行為數(shù)據(jù)，例如瀏覽、搜索、預訂、反饋等，這邊順便提一下，這些數(shù)據(jù)這些是由前端采集框架實時采集，然后下發(fā)到后端的收集服務，由收集服務在寫入到Hermes消息隊列，一路會落地到Hadoop上面做長期存儲，另一路近線層可以通過訂閱Hermes此類數(shù)據(jù)Topic進行近實時的計算工作。
我們還用到外部合作渠道的數(shù)據(jù)，還有一些評論數(shù)據(jù)，評論屬于非結構化的，也是T+1更新。
2)離線計算，主要分三個處理階段。
預處理階段，這塊主要為后續(xù)數(shù)據(jù)挖掘做一些數(shù)據(jù)的準備工作，數(shù)據(jù)去重，過濾，對缺失信息的補足。舉例來說采集下來的用戶行為數(shù)據(jù)，所含有的產品信息很少，我們會使用產品表的數(shù)據(jù)進行一些補足，確保給后續(xù)的數(shù)據(jù)挖掘使用時候盡量完整的。
數(shù)據(jù)挖掘階段，主要運用一些常用的數(shù)據(jù)挖掘算法進行模型訓練和推薦數(shù)據(jù)的輸出(分類、聚類、回歸、CF等)。
結果導入階段，我們通過可配置的數(shù)據(jù)導入工具將推薦數(shù)據(jù)，進行一系列轉換后，導入到HBase、Redis以及建立ES索引，Redis存儲的是經統(tǒng)計計算出的熱點數(shù)據(jù)。
3)近線計算(用戶意圖、產品緩存)
當用戶沒有明確的目的性情況下，很難找到滿足興趣的產品，我們不僅需要了解用戶的歷史興趣，用戶實時行為特征的抽取和理解更加重要，以便快速的推薦出符合用戶當前興趣的產品，這就是用戶意圖服務需要實現(xiàn)的功能。
一般來說用戶特征分成兩大類：一種是穩(wěn)定的特征(用戶畫像)，如用戶性別、常住地、主題偏好等特征；另一類是根據(jù)用戶行為計算獲取的特征，如用戶對酒店星級的偏好、目的地偏好、跟團游/自由行偏好等。基于前面所述的計算的特點，我們使用近在線計算來獲取第二類用戶特征，整體框圖如下。從圖中可以看出它的輸入數(shù)據(jù)源包括兩大類：第一類是實時的用戶行為；第二類是用戶畫像，歷史交易以及情景等離線模塊提供的數(shù)據(jù)。結合這兩類數(shù)據(jù)，經一些列復雜的近線學習算法和規(guī)則引擎，計算得出用戶當前實時意圖列表存儲到HBase和Redis中。
近線另一個工作是產品數(shù)據(jù)緩存，攜程的業(yè)務線很多，而我們的推薦系統(tǒng)會推各個業(yè)務線的產品，因此我們需要調用所有業(yè)務線的產品服務接口，但隨著我們上線的場景的增加，這樣無形的增加了對業(yè)務方接口的調用壓力。而且業(yè)務線產品接口服務主要應用于業(yè)務的主流程或關鍵型應用，比較重，且SLA服務等級層次不齊，可能會影響到整個推薦系統(tǒng)的響應時間。
為了解決這兩個問題，我們設計了近在線計算來進行業(yè)務的產品信息異步緩存策略，具體的流程如下。
我們會將待推薦的產品Id全部通過Kafka異步下發(fā)，在Storm中我們會對各業(yè)務方的產品首先進行聚合，達到批處理個數(shù)或者時間gap時，再調用各業(yè)務方的接口，這樣減少對業(yè)務方接口的壓力。通過調用業(yè)務方接口更新的產品狀態(tài)臨時緩存起來(根據(jù)各業(yè)務產品信息更新周期分別設置緩存失效時間)，在線計算的時候直接先讀取臨時緩存數(shù)據(jù)，緩存不存在的情況下，再擊穿到業(yè)務的接口服務。
產品異步緩存框架
4)在線計算(2個關鍵業(yè)務層架構模塊介紹)
①業(yè)務層架構-數(shù)據(jù)治理和訪問模塊，支持的存儲介質，目前支持的存儲介質有Localcache、Redis、HBase、MySQL可以支持橫向擴展。統(tǒng)一配置，對同一份數(shù)據(jù)，采用統(tǒng)一配置，可以隨意存儲在任意介質，根據(jù)id查詢返回統(tǒng)一格式的數(shù)據(jù)，對查詢接口完全透明。
穿透策略和容災策略，Redis只存儲了熱數(shù)據(jù)，當需要查詢冷數(shù)據(jù)則可以自動到下一級存儲如HBase查詢，避免緩存資源浪費。當Redis出現(xiàn)故障時或請求數(shù)異常上漲，超過整體承受能力，此時服務降級自動生效，并可配置化。
②業(yè)務層架構-推薦策略模塊，整個流程是先將用戶意圖、用戶瀏覽，相關推薦策略生成的產品集合等做為數(shù)據(jù)輸入，接著按照場景規(guī)則，業(yè)務邏輯重新過濾，聚合、排序。最后驗證和拼裝業(yè)務線產品信息后輸出推薦結果；
我們對此流程每一步進行了一些模塊化的抽象，將重排序邏輯按步驟抽象解耦，抽象如右圖所示的多個組件，開發(fā)新接口時僅需要將內部DSL拼裝便可以得到滿足業(yè)務需求的推薦服務；提高了代碼的復用率和可讀性，減少了超過50%的開發(fā)時間；對于充分驗證的模塊的復用，有效保證了服務的質量。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.vmgcyvh.cn/
相關文章
