基于Hadoop的電子商務推薦系統的設計與實現

李文海，許舒人

（1.中國科學院軟件研究所 軟件工程技術研究開發中心，北京100190；2.中國科學院研究生院，北京100190）

0 引 言

隨著用戶規模的擴大和業務的發展，大型電子商務系統中的用戶數和產品種類越來越多，數據規模正爆炸式地增長。然而，能夠有效利用的展示區域是有限的，大量的信息資源由于成為長尾被淹沒而得不到展示，信息過載問題［1］日益突出。

推薦系統［2］是一種重要的信息過濾機制，它能有效地解決信息過載問題。通過挖掘用戶和信息資源之間的聯系規律，它能幫助用戶從網絡中的大量信息里找到甚至發現他們需要的以及可能會感興趣的信息資源。它以主動服務的方式，通過利用挖掘和分析技術，實現自動化、智能化和個性化的信息過濾服務，幫助用戶發現所需。因此，它被廣泛地應用于電子商務和社交網絡等典型現代互聯網領域。

電子商務推薦系統［3］通過模擬智能銷售導購的角色，能夠為電子商務網站的用戶提供產品信息和相關的建議以幫助用戶進行購買決策，完成購物過程。它能促進一對一的銷售，可以為電子商務系統提供更加智能化和個性化的購物體驗，最終提升用戶滿意度。電子商務的發展趨勢是針對不同的用戶提供個性化的購物體驗，通過準確地預測用戶的偏好、口味和潛在的需求，以此來提高網站的營業額，而這個目標正是通過推薦系統來實現的。

對于電子商務系統來說，推薦系統的作用主要體現在以下幾方面［4］：提升購物體驗，提高用戶的忠誠度；增強交叉銷售能力，提高整體交易量；挖掘潛在的客戶資源，利用推薦激發用戶的購買欲望，將用戶由普通的瀏覽者轉變為消費者。因此，可以認為電子商務推薦系統是一種集成了諸多不同種類的發現新事物的方法、技術和策略的信息過濾機制，其核心任務是通過發掘用戶和商品之間的聯系來向用戶提供個性化的產品推薦服務，最終實現用戶和系統所有者的雙贏。

現代互聯網應用背景下的大型電子商務推薦系統正面臨著以下幾個方面的挑戰［5，6］：

（1）采用集中式架構的推薦系統數據處理能力有限。單機推薦算法存在數據處理規模的限制和處理效率的問題。

（2）大型電子商務系統中除了用戶和產品數目龐大之外，用戶和產品的自然屬性也多，要對高維度的用戶和產品建立準確有效的模型十分困難。

（3）商業應用需求通常復雜多變，同時對于不同的應用場景用戶的關注點也不同，基于固定的模型和參數的推薦系統通常缺乏靈活性。

（4）推薦模型通常和數據特性以及應用場景有很強的相關性，這決定了推薦系統必須要綜合多種互補性強的推薦技術。而現有的方案中算法和模型比較單一，難以滿足主流用戶的主流需求的同時兼顧用戶的個性化需求。

基于Hadoop平臺和混合推薦策略，設計了一種面向大型電子商務系統的混合推薦系統，運用基于MapReduce框架的算法的伸縮性和分布式并行計算能力，使系統能對大規模的數據進行高效的分析；通過結合不同的推薦引擎來解決冷啟動和數據稀疏引起的推薦效果不佳的問題。系統主要解決如下3個方面的問題：

（1）伸縮性?，F代互聯網應用中數據規模已經取代了業務邏輯的復雜性而成為主要矛盾，伸縮性是現代互聯網應用的關鍵需求，針對持續增長的數據實現伸縮對任何數據分析系統都十分重要。采用基于MapReduce框架的算法提高數據分析的能力，通過Hadoop平臺實現橫向擴展，能夠針對不同規模的數據實現理想伸縮。

（2）靈活性。由于商業應用需求復雜多變，允許用戶通過配置模型參數，以參數化運行的方式，實現不同的推薦模型以適合不同的應用場景。

（3）多樣性。非個性化的推薦能夠很好地反映大眾的流行趨勢，而個性化的推薦能夠更好地滿足用戶的個人興趣和偏好，將兩者進行結合能充分滿足不同群體的多樣化的口味。此外，采用混合推薦策略也能提高推薦結果的多樣性。

1 相關技術分析

1.1 主要推薦技術的比較

常用的推薦技術有協同過濾技術、關聯規則挖掘和基于知識經驗的方法等，其優缺點綜合比較見表1。因此，采用可以靈活配置管理的混合推薦模型綜合多種不同的推薦技術以彌補單一推薦技術的不足，可以滿足靈活性和多樣性的推薦需求，在滿足非個性化推薦需求的同時兼顧個性化推薦需求。

表1 主要推薦技術的比較

1.2 分布式計算與存儲技術

Google發布的關于分布式基礎設施的論文對業界產生了巨大的影響，其中的MapReduce和GFS等思想為分布式計算與存儲提供了關鍵參考，Hadoop是其開源實現［7］。

Hadoop是一個針對大規模數據處理與分析的用于構建分布式系統的基礎框架，它方便易用，用戶可以在不必充分關注分布式底層細節的情況下，方便地開發分布式應用，充分利用集群進行協同計算與協同存儲，實現橫向擴展的目標［8］。

Hadoop通過采用數據分布式存儲、遷移代碼而非遷移數據的機制，在處理大規模數據時避免了耗時的數據傳輸問題；利用數據適度冗余機制，允許系統從節點失效中恢復?；贖adoop平臺開發分布式應用，用戶不用關心如何分割數據、任務如何調度和分配以及如何管理集群的拓撲結構和節點之間的通信這些和分布式系統開發相關的復雜事務，而只需要專注于應用邏輯的開發。

Hadoop平臺具有高可伸縮、低成本、高可靠、方便易用等特點［9］，其核心是 HDFS分布式文件系統和 MapReduce框架。前者使得在成本可控的情況下處理海量數據成為可能；后者則是一種采用分治策略、專為大規模分布式并行數據處理設計的簡化編程模型，它借鑒了函數式編程的思想，將針對大規模數據的處理任務統一地抽象為Map（映射）和Reduce（規約）兩種操作。研究表明，大多數針對大規模數據的分布式處理任務都可以通過該模型進行表達，它允許編程人員以直接調用相關編程接口的方式方便地將自己的程序運行于分布式集群系統上。這樣，通過在應用程序和平臺之間進行職責的重新劃分，讓平臺框架來處理諸如底層存儲、節點通信等復雜的分布式處理細節，應用程序可以專注于業務邏輯以面向更加復雜的業務需求。

由于Hadoop集群可以按需橫向動態擴展，利用Hadoop平臺可以突破數據規模給推薦系統帶來的大數據分析的瓶頸，滿足高性能、高伸縮性計算的需求。

2 混合推薦系統的設計

本節將給出支持混合推薦模型的推薦流程和系統架構的詳細設計。

2.1 推薦的流程

系統采用如圖1所示的多階段推薦流程。首先經過數據的抽取、轉換、清洗、裝載等操作，從異構、多源、含噪聲的原始業務數據中提取用戶信息、產品信息和偏好信息，建立用戶模型和產品模型。然后利用多種不同的算法與策略構建多個相互獨立的推薦引擎，通過不同的引擎產生獨立的推薦結果集，再將這些推薦結果以一定的策略進行混合從而形成初始推薦集。

圖1 推薦系統工作流程

基于商業業務需求，有時希望將若干指定的產品推薦給用戶，如通常需要在首頁優先展示新加入的產品，這時需要構建一個包含此類產品的候選推薦集，在過濾階段之后同經過篩選的初始推薦集進行合并。過濾階段主要過濾掉以下的幾類產品：

（1）用戶已經購買過的產品。因為推薦系統的主要目的是幫助用戶發現新產品，給用戶推薦已經購買過的產品沒有多大意義。然而，這也不是絕對的：對于一次消費品來說必須要被過濾，而對于可重復消費品來說可以選擇不過濾。

（2）質量較差的產品。推薦系統的終極目標是提高用戶體驗和提升服務品質，將來自評價非常差的供應商的產品以及品質不夠優良的產品推薦給用戶有損用戶對推薦系統的信任。

（3）具有顯著的季節性特征的產品。將當前季節未供應的或者當前季節中用戶不需要的產品推薦給用戶也不合理。

經過過濾后的推薦結果通?？梢灾苯诱故窘o用戶，但如果綜合考慮新穎性、多樣性、時間等因素對它們進行排名，則可以更好地提升用戶滿意度。應用協同過濾引擎，推薦結果天然地具有了排名的依據，可直接根據用戶推薦向量中各個分量的取值大小進行排名。而利用靜態規則引擎和關聯規則引擎推薦的結果需要依據產品的其它屬性。依據產品的popularity（流行度）屬性，即選取popularity的倒數值來為產品進行降序排列。通過將熱門的暢銷品降低權重，可以解決著名的哈利波特問題。經過排名階段后的推薦結果列表便可以用富有表現力的形式展示給用戶。

2.2 推薦系統的架構

基于Hadoop的混合電子商務推薦系統采用分層架構來實現：各層承擔不同的職責，各層之間通過接口進行交互，各層之內采用模塊化思想設計。這樣保證了系統架構具有高內聚、低耦合和易擴展的特點。系統的分層架構如圖2所示，自下而上依次包括以下五層：

圖2 推薦系統架構

數據訪問層：數據是電子商務系統中的寶貴資產，同時也是算法和模型的處理對象。整合異構、多源、多類型的原始業務數據，并從中抽取用戶和產品特征，能有效地提高推薦的準確性。同時，該層還需要負責對來自Hadoop集群的大規模數據分析后得到的結果進行解析。因此，該層實現了業務計算環境和集群計算環境之間的數據遷移。

數據模型層：數據模型層包括用戶模型和產品模型，其中用戶模型由用戶基礎資料、用戶行為和用戶信用等內容構成；產品模型包括產品元數據和反饋評價信息等。通過數據訪問層對原始數據進行抽取和解析，可以獲得用戶屬性集和產品屬性集，進而生成用戶特征向量和產品特征向量。

算法策略層：通用的、經典的算法通常都比較抽象，較少考慮實際的系統需求和業務需求，例如它對魯棒性和基于應用特性或數據特性的性能調優等方面的關注較少，因此它們和具體的產品形態之間的差距較大。策略主要體現業務需求，它充當驅動器的角色，能夠把業務規則封裝起來提供給上層。該層包括常見的數據挖掘算法和機器學習算法，包括相似度計算、關聯規則挖掘、聚類和協同過濾等算法。算法策略層處于數據模型和推薦引擎層之間，以獨立層的形式存在，這樣允許整合更多數據分析算法。

推薦引擎層：該層是整個系統的核心，它將算法和策略包裝成功能獨立的推薦引擎，通過調用算法策略層的算法對數據模型完成相似度計算、偏好預測和關聯分析等計算任務。由于電子商務系統中的推薦需求通常是多樣化的，每一種推薦需求通?？梢允褂靡环N引擎來實現。設計獨立的推薦引擎層允許整合更多的推薦引擎，從而實現功能上的擴展。

該層基于協同過濾技術來實現個性化推薦引擎，通過進行長尾挖掘來滿足個性化推薦的需求。在非個性化推薦引擎方面，實現了靜態規則推薦引擎和關聯規則推薦引擎。

靜態規則推薦引擎是以靜態的邏輯規則的形式向用戶推薦產品。與其它的引擎不同，它的規則不需要經過復雜的推薦算法計算過程，而是直接以靜態的映射規則的形式來實現的。靜態規則主要有4個方面的來源：專家經驗、領域知識、商業應用需求和其它途徑獲得的知識與結論。這里的專家可以是一些有經驗的領域資深專家，也可以是社區中的意見領袖等。由于推薦技術最根本還是一種信息過濾的機制，如果能夠建立比較理想的推薦模型，同時數據質量較高且擁有大量的數據的話，推薦的效果也會比較理想，然而要獲取高質量的大量數據和實現好的推薦模型都非常難，在大多數情況下，這些靜態推薦規則可以在很多實際應用場合中為其它推薦技術提供有益的補充。

購物籃分析是電子商務領域中最經典的數據挖掘應用場景，關聯規則推薦引擎集中關注針對交易數據庫的購物籃分析。通過關聯規則挖掘可以得知哪些產品經常被一同購買，從而導出基于關聯規則的推薦列表。

上述3種推薦引擎各具特色。其中協同過濾推薦引擎實現了個性化推薦，它充分考慮用戶的個人偏好。但是用戶的個性化需求通常不穩定，可能會隨著時間推移發生變化，僅依賴個性化引擎通常并不能得到非常令人滿意的效果。此外，用戶還具有關注哪些產品是熱門產品、哪些產品在整體消費趨勢中經常一同被購買等非個性化的需求。非個性化推薦反映群體的總體消費趨勢，代表大眾的喜好。結合個性化需求和非個性化需求可以更全面地滿足用戶的需求，實現熱門資源和長尾資源之間的平衡。此外，關聯規則推薦關注的是產品之間的相關性，但是只能提供非個性化的推薦；而協同過濾推薦能夠實現個性化的推薦，其自動化、智能化和個性化的程度都很高，但是其也存在伸縮性、稀疏性和冷啟動等問題。因此，采用具有互補意義的3種不同推薦引擎可以充分滿足用戶的各種需求，同時也能克服單個引擎的不足。最后通過混合推薦模型將3個不同推薦引擎的推薦結果進行組合。

應用層：位于最頂層，是用戶與系統交互的接口，包含常見的配置、管理、交互和展示功能。其允許配置混合模型的參數和混合方式，保證了推薦系統的靈活性。

綜上所述，設計思想可以總結為如下四點：第一，采用Terminal／Cluster模式的架構來滿足現代互聯網應用的面向海量數據分析的需要；第二，采用多階段的推薦流程能支持混合推薦，并容易實現推薦解釋的功能；第三，采用縱向分層、橫向模塊化、基礎通用功能組件化的推薦系統架構，容易集成更多的算法、策略和引擎從而實現功能上的擴展；第四，通過應用層的配置和管理能夠靈活地定義引擎方案。第一點可以實現伸縮性的目標，第二點和第三點對多樣性的目標提供了支持，第四點滿足了靈活性的需求。這樣無論是流程還是架構都能靈活地滿足大型電子商務系統多樣化的推薦需求。

3 基于Hadoop的混合推薦系統的實現

基于Hadoop的混合電子商務推薦系統采用適合現代互聯網應用的T／C （Terminal／Cluster）形式架構來實現，其架構圖如圖3所示。系統包括兩部分：WebTerminal終端和Hadoop集群。前者是瘦客戶端，只擁有少量的業務邏輯，它實現了推薦系統的配置、管理、交互和展示功能，同時能將業務系統中產生的大規模數據經過一系列的處理后作為Hadoop集群的輸入提交到平臺，以驅動基于Hadoop集群的大規模數據分析；后者是用于實現大規模數據分析的基礎設施，它是由許多節點按照一定的拓撲結構組織而成的集群，能夠提供高性能、按需、無限量的計算與存儲服務。經過集群分析得到的結果再導出到WebTerminal終端，最終反饋并展示給用戶。

圖3 基于Hadoop的混合推薦系統架構

3.1 WebTerminal端

WebTerminal端包含數據訪問層、應用層的全部功能和用戶字典、產品字典、靜態規則引擎和混合模型部分的實現。

原始業務數據存儲在業務系統中，通常無法直接用于推薦分析，其中含有大量的臟數據、噪音數據和缺失值，為了進行有效的分析和處理，需要進行抽取、清洗、轉換和裝載。數據抽取模塊用于實現上述過程，從而將數據從存儲系統中抽取到Hadoop計算平臺，如圖4所示。針對數據的異構性和多樣性，定義了一個公共抽取接口DataExtractor來抽象不同的數據抽取邏輯實現。

圖4 數據抽取模塊

同時，利用結果解析模塊可以實現將大數據分析處理的結果導回到關系數據庫的功能，該模塊的實現如圖5所示。

圖5 結果解析模塊

Sqoop可以通過MapReduce框架運行任務，實現關系型數據庫和HDFS之間的數據導入導出［10］。這種方法簡單方便，但是抽取過程不夠靈活，因此數據抽取模塊和結果解析模塊可以作為它的有益補充，實現更細粒度、更靈活的數據遷移功能。

采用了分區混合、加權混合和隨機混合3種不同的混合策略來實現混合推薦模型，其中利用設計模式中的策略模式來實現3種不同的混合策略之間的靈活切換?；旌贤扑]模型的時序圖如圖6所示，首先是加載混合策略以及相應的配置參數，然后依次經過結果的過濾、排序、解釋等過程最終為用戶產生推薦列表。

圖6 混合推薦模型時序

3.2 數據模型

推薦系統的數據資源主要包括三類：用戶數據、產品數據和用戶偏好數據。前兩種數據分別充當用戶和產品的數據字典，第三種數據是用戶和產品之間的關聯關系的體現。在推薦計算過程中，分別使用用戶編號和產品編號來唯一索引用戶與產品，利用數據字典可以獲得它們的詳細信息，這對產生推薦解釋十分重要。在推薦計算過程中，使用產品－用戶偏好矩陣來抽象用戶偏好數據，該矩陣每個行向量分別對應同一種產品，每個列向量分別對應同一個用戶，每個矩陣單元格分別表示一個用戶對一種產品的偏好取值。

3.3 基于Hadoop的協同過濾推薦引擎

由于篇幅限制，這里以基于Hadoop的協同過濾推薦引擎為例介紹基于Hadoop的推薦引擎的實現。協同過濾引擎的核心包括兩個部分：相似度計算組件和協同過濾算法。

協同過濾技術一般都是基于相似性來產生推薦結果，如何定義和度量實體之間的距離是其關鍵，采用不同的距離計算方式無論是對算法的效率還是對推薦結果的精度都有影響。系統中共實現了6種不同的分布式相似度計算組件：歐式距離相似度 （EuclideanSimilarity）、余弦相似度（CosineSimilarity）、 皮 爾 森 相 關 度 （PearsonSimilarity）、Jaccard系數 （JaccardSimilarity）、對數似然相似度 （LoglikelihoodSimilarity）和共現相似度 （CooccurrenceSimilarity）。它們都是針對向量實現的適合分布式計算環境下的相似度計算組件，是實現分布式協同過濾的基礎。

采用了基于MapReduce的Item－basedCF算法來實現協同過濾，該算法包含三步計算任務：第一步，根據交易數據庫計算產品－產品協同矩陣；第二步，計算用戶的偏好向量。該向量是偏好矩陣的列向量，向量的每個分量對應用戶對每項產品的偏好值；第三步，計算協同矩陣和偏好向量的點積，產生該用戶的推薦向量，這也是為該用戶輸出的候選推薦列表。為了基于MapReduce實現以上計算任務，需要將其拆分為6個具體步驟，詳細的作業流如圖7所示。這些計算步驟需要使用總共12個MapReduceJob來實現，其算法架構圖如圖8所示。這一系列作業流統一地由RecommenderJob驅動器程序進行驅動。

4 實驗與分析

實驗與分析通過基于Hadoop的混合電子商務推薦系統中的協同過濾引擎產生個性化推薦過程來說明系統的功能有效性和面對大規模數據的伸縮性。

4.1 實驗設置

圖7 分布式協同過濾算法流程

實驗中采用的Hadoop集群由5個節點組成，其中包括1個Master節點，4個Slave節點。每個節點的具體配置信息 如 下 ：Intel（R）Xeon CPU E 5 6 4 5，1GRAM，1 5G硬盤，操作系統為Cent OS 5.3，Hadoop版本為1.0.4，節點之間通過100Mbps的網絡進行連接。加速比實驗中，每個Slave節點設置的最大map和reduce任務支持數都各為2。此時，測試集群可以并行支持8個map任務和8個reduce任務。在此，將map任務數或reduce任務數視為計算節點的數量。通過調節每個Slave節點設置的最大map和reduce任務支持數來獲得不同數量的計算節點。實驗中采用評測協同過濾算法的經典數據集MovieLens，其中包含6040位用戶、3706部電影和1000209條評分記錄，數據的整體稀疏程度為95.53%。

4.2 性能評估

加速比［11］（speedup） 和恒等效率伸縮性［12］（isoefficiency）是評估并行系統的效率和伸縮性的兩個重要的定量分析指標。前者評估固定問題規模下隨著計算節點數增加運行性能的變化情況；后者使用恒等效率函數來評估評估當問題規模增大時算法的性能。

（1）加速比性能分析：Amdahl定律是一種常用的固定規模加速比性能模型。它采用如下的公式計算加速比Sp，其中T表示使用單個計算節點時的算法執行時1間，Tp表示使用p個計算節點時的并行執行時間。

圖8 分布式協同過濾算法架構

若算法具有伸縮性，則當問題規模固定時，加速比與計算節點數存在線性關系。從圖9可看出，在4種不同的數據集大小 （10K、100K、1M、10M）下，加速比與計算節點個數的增加近似成正比。同時，還可發現當數據集更大時可以獲得更好的加速比。由此可見，基于Hadoop的協同過濾算法在處理更大規模的數據集的時候有更好的加速比。

圖9 Item－basedCF算法的加速比

（2）伸縮性分析：Isoefficiency指標可以通過如下的公式來計算

式中：T0——并行執行過程中的通信代價。

如果算法具有伸縮性，運行結果能保持Ep為常量。當Ep為常量時，T1＝fE（P）＝kP，其中P表示計算節點數，因此fE（P）是一個線性函數。T1＝T（m）＝lm，其中m表示數據量的大小，由此可得，m與P線性相關，即P＝因此如果計算節點P和數據規模大小m線性相關，則也意味著算法具有伸縮性。如圖10所示，當設置了3個不同的固定計算時間 （10min、20min、30min）時，計算節點數隨著數據規模增長同步線性增長。同時，還可以發現，當設置的運行時間越長，算法具有越好的伸縮性能。

綜上所述，實驗表明基于Hadoop的電子商務推薦系統在執行協同過濾時具有較好的伸縮性和性能。

5 相關工作

Gong［13］針對協同過濾推薦技術存在的數據稀疏性問題，采用了關聯規則挖掘和User－based協同過濾兩種技術實現個性化的推薦系統，該研究表明利用不同的推薦技術可以互補各自的不足之處。

圖10 時間固定時，節點個數與數據規模的效率函數

Zhao［14］針對 User－based協同過濾算法的伸縮性問題，實現了基于Hadoop平臺的User－based協同過濾算法，從而實現算法的線性伸縮。

MyMediaLite［15］作為一個輕量級多功能的推薦系統算法庫，它解決了兩種最常見的協同過濾場景：評分預測和基于隱式反饋的預測，提供了常見推薦算法的高效和易伸縮的版本實現。

提出的基于Hadoop的電子商務推薦系統從伸縮性、靈活性和多樣性出發，運用基于MapReduce的算法和易于配置的混合推薦模型，實現面向大型電子商務的推薦系統，突破了集中式推薦系統架構的瓶頸。

6 結束語

提出了一種基于Hadoop的混合電子商務推薦系統的設計與實現，為使用Hadoop構建可伸縮、高性能的分布式電子商務推薦系統提供了參考。系統以基于MapReduce的推薦算法為核心，采用易于擴展的開放式推薦流程和架構，利用混合推薦模型，允許用戶在應用層靈活配置引擎方案，同時易于擴展以支持更多的算法、策略和引擎。結合Hadoop的分布式計算的潛力和混合推薦的優勢，構建具有高伸縮性、靈活性和多樣性的推薦系統，能夠有效地解決大型電子商務系統中的信息過載問題，為電子商務企業在數據驅動的個性化消費時代產生持續的競爭優勢。

［1］Information overload ［EB／OL］.［2013－04－20.］http：／／en.wikipedia.org／wiki／Information＿overload.

［2］Ricci F，Shapira B.Recommender systems handbook ［M］.Springer，2011.

［3］Pu P，Chen L，Kumar P.Evaluating product search and recommender systems for E－commerce environments ［J］.Electronic Commerce Research，2008，8 （1－2）：1－27.

［4］Ricci F，Rokach L，Shapira B.Introduction to recommender systems handbook ［M］.Recommender Systems Handbook.Springer US，2011：1－35.

［5］Wang H F，Wu C T.A strategy－oriented operation module for recommender systems in E－commerce ［J］.Computers ＆ Operations Research，2012，39 （8）：1837－1849.

［6］Wei K，Huang J，Fu S.A survey of e－commerce recommender systems ［C］／／International Conference on Service Systems and Service Management.IEEE，2007：1－5.

［7］Hadoop ［EB／OL］.［2013－04－20.］http：／／hadoop.apache.org.

［8］Chuck Lam.Hadoop in action ［M］.Manning Publications，2011：15－16.

［9］White T.Hadoop：The definitive guide ［M］.2nd ed.O′Reilly Media.Yahoo Press，2010：165.

［10］Sqoop ［EB／OL］.［2013－04－20.］https：／／github.com／cloudera／sqoop／wiki.

［11］Hill M D，Marty M R.Amdahl’s law in the multicore era［J］.Computer，2008，41 （7）：33－38.

［12］Hanuliak P.Analytical method of performance prediction in parallel algorithms ［J］.Open Cybernetics ＆ Systemics Journal，2012，6：38－47.

［13］Gong S J.Personalized recommendation system based on association rules mining and collaborative filtering ［J］.Applied Mechanics and Materials，2011，39：540－544.

［14］Zhao Z D，Shang M.User－based collaborative－filtering recommendation algorithms on Hadoop ［C］／／Third International Conference on Knowledge Discovery and Data Mining.IEEE，2010：478－481.

［15］Gantner Z，Rendle S，Freudenthaler C，et al.MyMediaLite：A free recommender system library ［C］／／Proceedings of the Fifth ACM Conference on Recommender Systems.ACM，2011：305－308.