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