基于Hadoop的電商大數(shù)據(jù)平臺性能調(diào)優(yōu)

馬亞銘 陶利民 劉子琦

摘 要：為了提升電商大數(shù)據(jù)平臺復(fù)雜數(shù)據(jù)操作性能，通過分析電商業(yè)務(wù)特點，從數(shù)據(jù)重新組織與平臺參數(shù)調(diào)優(yōu)兩個方面對數(shù)據(jù)平臺進行優(yōu)化。在數(shù)據(jù)重新組織方面，使用ORC數(shù)據(jù)格式存儲數(shù)據(jù)，并對數(shù)據(jù)表進行合理的分區(qū)、分桶;在平臺參數(shù)調(diào)優(yōu)方面，對業(yè)務(wù)涉及到的主要組件參數(shù)進行針對性調(diào)節(jié)。最后，通過搭建具有32個節(jié)點的Hadoop集群，并使用TPC-DS測試集進行仿真實驗，驗證調(diào)優(yōu)思路及方法的有效性。結(jié)果表明，調(diào)優(yōu)之后的平臺性能大約是未進行任何優(yōu)化平臺的7.5倍，優(yōu)化效果顯著。

關(guān)鍵詞：大數(shù)據(jù)平臺;電子商務(wù);Hadoop;性能調(diào)優(yōu)

DOI：10. 11907/rjdk. 192524 開放科學（資源服務(wù)）標識碼（OSID）：

中圖分類號：TP391文獻標識碼：A 文章編號：1672-7800（2020）005-0186-04

0 引言

電子商務(wù)的誕生及發(fā)展給人們生活帶來了巨大便利，隨著電商規(guī)模的進一步擴大，電商平臺每日會產(chǎn)生海量數(shù)據(jù)。如何對這些數(shù)據(jù)進行快速、有效的存儲與處理，是保障電商業(yè)務(wù)順利開展以及推動其發(fā)展的必備條件。Hadoop作為一款優(yōu)秀的開源大數(shù)據(jù)平臺，被大多數(shù)電子商務(wù)企業(yè)所采用。為了獲得更好的數(shù)據(jù)處理性能，需要根據(jù)電子商務(wù)業(yè)務(wù)特點，對該平臺進行針對性的性能調(diào)優(yōu)。由于Hadoop的廣泛應(yīng)用，學者們對其調(diào)優(yōu)方法已進行了較多研究。如王康等[1]闡述針對Hive數(shù)據(jù)倉庫的通用調(diào)優(yōu)方法，即對Hive與MapReduce相關(guān)參數(shù)進行調(diào)優(yōu);王勇等[2]總結(jié)了基于HBase健康大數(shù)據(jù)平臺的多種調(diào)優(yōu)方法等。綜合這些調(diào)優(yōu)方法，將其歸納為以下4個方面：①數(shù)據(jù)重新組織，如數(shù)據(jù)分區(qū)、分桶等;②調(diào)節(jié)Hadoop平臺自身參數(shù)，如設(shè)置HDFS讀寫緩存大小等;③采用輔助技術(shù)，如數(shù)據(jù)壓縮等;④Hadoop源碼調(diào)優(yōu)，可以是改進某種算法或策略等。

然而，針對性能調(diào)優(yōu)的已有研究多為一些通用的或其它場景下的調(diào)優(yōu)，尚沒有針對電商平臺的調(diào)優(yōu)方法總結(jié)。本文根據(jù)對工程實踐的總結(jié)，闡述針對電商大數(shù)據(jù)平臺的性能調(diào)優(yōu)方法。

1 Hadoop平臺基本框架

Hadoop是一款基于Java分布式大數(shù)據(jù)處理與分析的軟件框架。用戶可在不了解分布式底層細節(jié)的情況下開發(fā)分布式程序，充分利用集群進行高速運算與存儲，解決了大數(shù)據(jù)的可靠存儲與處理問題[3]。Hadoop經(jīng)過多年發(fā)展已演化成一個生態(tài)系統(tǒng)，其基本框架如圖1所示。

由組件的功能和層次結(jié)構(gòu)可知，對Hadoop的性能調(diào)優(yōu)涉及對各個組件的調(diào)優(yōu)，從底層HDFS到上層Hive都需要進行整體上的調(diào)優(yōu)，任何組件都可能成為系統(tǒng)瓶頸。

2 電商大數(shù)據(jù)平臺調(diào)優(yōu)

電子商務(wù)平臺是用于支撐商品在互聯(lián)網(wǎng)上進行交易的平臺。其涉及到的主要業(yè)務(wù)流程包括：①商品信息維護;②訂單管理;③銷售記錄（sales）和退貨記錄（returns）;④倉庫（warehouse）庫存記錄（inventory）維護;⑤CRM客戶關(guān)系管理（customer、customer_address）等。

在這些業(yè)務(wù)流程中會經(jīng)常對一些大表（如商品信息表），進行大量的CRUD（增刪改查）操作。針對電商業(yè)務(wù)流程的數(shù)據(jù)處理特點，一般從以下兩方面進行性能調(diào)優(yōu)，分別為數(shù)據(jù)重新組織與平臺參數(shù)調(diào)優(yōu)。

2.1 數(shù)據(jù)重新組織

對數(shù)據(jù)進行針對性的重新組織可以提高數(shù)據(jù)輸入的有效性，對數(shù)據(jù)進行更精準的處理，從而提升系統(tǒng)性能。針對電商大數(shù)據(jù)平臺，主要采取如下措施：

（1）使用ORC 格式。ORC文件格式是一種Hadoop生態(tài)圈中的列式存儲格式，有多種文件壓縮方式，并且有著很高的壓縮比。其提供row group index、bloom filter index等多種索引，而且文件是可切分（Split）的。因此，在Hive中使用ORC作為表的文件存儲格式，不僅可以節(jié)省HDFS存儲資源，查詢?nèi)蝿?wù)的輸入數(shù)據(jù)量也大幅減少[4]。同時ORC通過壓縮、分片并逐段記錄中間結(jié)果的方式提高數(shù)據(jù)塊管理能力，能有效提高數(shù)據(jù)讀取效率[4]。

在電商數(shù)據(jù)存儲中，如果繼續(xù)使用傳統(tǒng)行式存儲對諸如訂單表、商品表等這些龐大的數(shù)據(jù)表進行管理，查詢效率會非常低。若依靠索引優(yōu)化查詢，由于數(shù)據(jù)量的龐大，建立與維護索引的代價都非常大。由于ORC格式具有的上述特性，將電商平臺的相關(guān)數(shù)據(jù)以O(shè)RC格式加以組織，可大大提升數(shù)據(jù)操作速度。

（2）數(shù)據(jù)表分區(qū)分桶。分區(qū)、分桶可以減少掃描成本，在一定程度上提高查詢效率。由電商業(yè)務(wù)模型及數(shù)據(jù)模型可知，隨著交易規(guī)模的擴大，將會產(chǎn)生很多數(shù)據(jù)量龐大的大表（幾十個TB以上），而日常業(yè)務(wù)流程中又需要對這些大表進行頻繁的查詢操作。因此，針對業(yè)務(wù)的數(shù)據(jù)操作特點進行適當?shù)姆謪^(qū)、分桶，可提高數(shù)據(jù)操作速度。

在確定分區(qū)、分桶字段時，不僅要關(guān)注該字段是否常被用于查詢，還需要關(guān)注該字段值數(shù)量等綜合因素。例如，在電商業(yè)務(wù)流程中，經(jīng)常需要根據(jù)商品名稱進行商品信息查詢，但若根據(jù)商品名稱這一字段進行分桶，億級的商品數(shù)將會對應(yīng)億級數(shù)量的桶文件，顯然是不可行的。因此，根據(jù)商品分類或地區(qū)等信息進行分桶，也可以有效提高查詢效率。

2.2 平臺參數(shù)調(diào)優(yōu)

電商平臺管理的數(shù)據(jù)類型主要是一些結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)操作大多是SQL型操作，因此調(diào)節(jié)參數(shù)主要涉及到的Hadoop平臺組件有Yarn、Hive和Spark。其中每一個組件都有大量系統(tǒng)參數(shù)，本文只列舉一些重要的、對電商數(shù)據(jù)平臺性能有較大影響的參數(shù)，并對這些參數(shù)進行分析與調(diào)優(yōu)。

2.2.1 Yarn

（1）yarn.nodemanager.vmem-pmem-ratio：該參數(shù)是虛擬內(nèi)存與物理內(nèi)存的比率，默認值為2.1。增大該參數(shù)可以起到增大虛擬內(nèi)存的作用，以避免Yarn的Container內(nèi)存不足。因此，在存儲空間足夠的情況下，可根據(jù)實際物理資源及任務(wù)特點適當增大該參數(shù)的值，以保證yarn有足夠的內(nèi)存空間可以使用。

（2）yarn.nodemanager.resource.percentage-physical-cpu

-limit：該參數(shù)是對NodeManager管理下所有Container可使用CPU資源的限制。在電商數(shù)據(jù)平臺場景下，本文僅考慮怎樣達到最優(yōu)性能。一般允許yarn完全使用CPU資源，即該參數(shù)值為100%。

（3）yarn.nodemanager.resource.memory-mb：該參數(shù)用于指定yarn可以管理的最大內(nèi)存容量。在電商場景下，除預(yù)留給系統(tǒng)其它進程的內(nèi)存外，應(yīng)盡量多地將內(nèi)存交給yarn進行管理，使yarn可用內(nèi)存資源最大化。

2.2.2 Hive

（1）hive.exec.dynamic.partition.mode：該參數(shù)表示是否允許自動分區(qū)。自動分區(qū)會自動根據(jù)分區(qū)字段所有值進行分區(qū)。在電商場景下會對多個大表進行分區(qū)，并且隨著系統(tǒng)的使用，多數(shù)分區(qū)字段的值會增加或減少。如以商品表的類別字段進行分區(qū)，隨著業(yè)務(wù)的擴展與變化，商品類別會增多或減少。采用手動分區(qū)方法會非常低效，因此在電商場景下，該字段一般設(shè)為nonstrict，表示允許自動分區(qū)。

（2）hive.exec.max.dynamic.partitions：該參數(shù)表示動態(tài)分區(qū)的上限。雖然可以利用該參數(shù)解決在動態(tài)分區(qū)時因分區(qū)過多造成系統(tǒng)奔潰的情況，但考慮到分區(qū)目的是為了加快數(shù)據(jù)讀寫，不應(yīng)該讓最大分區(qū)數(shù)限制實際需要進行的分區(qū)，因此一般設(shè)置一個足夠滿足分區(qū)要求的數(shù)量，并要求選擇合理的字段進行分區(qū)。

（3）hive.exec.max.created.files：該參數(shù)表示一個MapReduce作業(yè)能創(chuàng)建的HDFS文件最大數(shù)，一般不會讓其成為MR作業(yè)的限制，而是要讓作業(yè)本身在系統(tǒng)能力范圍內(nèi)。因此，會設(shè)置一個較大的值，默認為100 000。

（4）hive.optimize.sort.dynamic.partition：該參數(shù)會對需要寫入的數(shù)據(jù)進行排序，目的是使每次只對一個分區(qū)進行寫入操作，寫入完畢后，再打開下一個分區(qū)進行集中寫入。

由于在電商業(yè)務(wù)場景中分區(qū)數(shù)較多，如果對某個表進行寫入時，同時打開這些分區(qū)，將占用過多內(nèi)存，因此該參數(shù)一般設(shè)為true。

2.2.3 Spark

（1）spark.serializer：spark在進行內(nèi)存計算時，需要對一些中間結(jié)果進行序列化與反序列化，此時需要用到序列化框架。KryoSerializer具有速度快、序列化后體積小等優(yōu)點，故序列化器一般配置為KryoSerializer。

（2）spark.memory.fraction：調(diào)整該參數(shù)可以控制spark的shuffle內(nèi)存和storage內(nèi)存總量占總內(nèi)存的比例。需要根據(jù)任務(wù)類型保證shuffle過程有足夠的內(nèi)存， 同時也要預(yù)留一些內(nèi)存給spark其它功能以及系統(tǒng)軟件使用。

（3）spark.memory.storageFraction：該參數(shù)調(diào)節(jié)storage內(nèi)存所占比例，與參數(shù)（2）一起確定shuffle和storage各占內(nèi)存的比例?？梢愿鶕?jù)任務(wù)類型及表的多少，合理調(diào)整該值，增大shuffle內(nèi)存比例，縮小storage內(nèi)存比例。因為shuffle過程直接影響計算任務(wù)完成速度，shuffle內(nèi)存應(yīng)盡量保證每個任務(wù)的使用。可以通過監(jiān)控日志及運行結(jié)果發(fā)現(xiàn)shuffle過程所需內(nèi)存，從而對該參數(shù)進行調(diào)節(jié)。

（4）spark.sql.shuffle.partitions：該參數(shù)用于確定shuffle過程的partition個數(shù)。適當增加partition個數(shù)可以增大并行度，提高系統(tǒng)運行效率。

3 實驗驗證

3.1 實驗環(huán)境與方法

為了驗證針對電商大數(shù)據(jù)平臺性能調(diào)優(yōu)的有效性，本文搭建了Hadoop集群。實驗環(huán)境共有32個節(jié)點，詳細配置如表2所示。

為了模擬電商日常業(yè)務(wù)，本文采用TPC-DS相關(guān)數(shù)據(jù)集[5]。該數(shù)據(jù)集可模擬某在線零售商日常業(yè)務(wù)數(shù)據(jù)，基本符合電商業(yè)務(wù)場景。數(shù)據(jù)集共包含24張表，這里只列舉主要的7張大表，如表4所示。

同時TPC-DS使用99個SQL語句，以模擬零售商日常各種業(yè)務(wù)流程，本文從中選取10個有代表性的SQL測試平臺性能。這10個SQL包含了復(fù)雜條件下的庫存查詢與銷售記錄查詢、銷售總額與平均銷售額統(tǒng)計計算等，基本涵蓋了電商主要業(yè)務(wù)流程。

3.2 實驗過程及結(jié)果分析

首先在平臺中生成TPC-DS數(shù)據(jù)集中的數(shù)據(jù)（本次實驗數(shù)據(jù)總量共30TB），在不進行調(diào)優(yōu)的情況下（在系統(tǒng)默認配置下）使用選擇的10個SQL進行數(shù)據(jù)操作，接著對系統(tǒng)按上文方法進行調(diào)優(yōu)，即數(shù)據(jù)重新組織與平臺參數(shù)調(diào)節(jié)。

將數(shù)據(jù)格式重新組織成ORC格式，然后進行分區(qū)、分桶。根據(jù)分析，主要針對幾個大表（store_sales、catalog_sales、web_sales、inventory）進行數(shù)據(jù)組織的優(yōu)化，根據(jù)產(chǎn)品經(jīng)銷存的日常模型綜合評估可行性，最終分區(qū)分桶方案如表5所示。

從實驗結(jié)果綜合來看，按照本文描述的針對電商大數(shù)據(jù)平臺的調(diào)優(yōu)思路與方法，大大減少了對海量數(shù)據(jù)的操作與分析時間，顯著提升了數(shù)據(jù)平臺性能。

4 結(jié)語

本文總結(jié)了針對基于Hadoop的電商大數(shù)據(jù)平臺的一般調(diào)優(yōu)思路與方法。系統(tǒng)調(diào)優(yōu)是對系統(tǒng)各方面進行優(yōu)化的過程，本文僅總結(jié)了基礎(chǔ)的、有明顯提升效果的兩種調(diào)優(yōu)方法：數(shù)據(jù)重新組織和平臺參數(shù)調(diào)優(yōu)，并通過搭建Hadoop集群，以及使用TPC-DS標準測試集進行仿真實驗，結(jié)果驗證了調(diào)優(yōu)的有效性，調(diào)優(yōu)后的平臺性能得到顯著提升。本文平臺參數(shù)主要是依據(jù)參數(shù)本身的作用，以及結(jié)合實踐經(jīng)驗，通過手動調(diào)節(jié)及試驗完成調(diào)優(yōu)的。尋求參數(shù)最優(yōu)化有很多算法可以實現(xiàn)，如遺傳算法、粒子群算法（PSO）等，可幫助人們尋找參數(shù)最優(yōu)解，避免手動調(diào)優(yōu)的盲目性。

參考文獻：

[1] 王康，陳海光，李東靜. 基于Hive的性能優(yōu)化研究[J]. 上海師范大學學報（自然科學版），2017（46）：534.

[2] 王勇，尹鵬飛，李娟. 基于HBase的健康大數(shù)據(jù)平臺性能優(yōu)化及應(yīng)用[J]. 軟件導(dǎo)刊，2017（10）：150-153，162.

[3] 許吳環(huán)，顧瀟華. 大數(shù)據(jù)處理平臺比較研究[J]. 軟件導(dǎo)刊，2017（4）：212-214.

[4] 曹英. 大數(shù)據(jù)環(huán)境下Hadoop性能優(yōu)化的研究[D]. 大連：大連海事大學， 2013.

[5] YERUVA S，KUMAR P V，PADMANABHAM P. Distributed data warehouse-experimentation with TPC-DS[C].2015 IEEE International Conference on Computational Intelligence and Computing Research （ICCIC）. IEEE， 2015.

[6] 姜春宇，魏凱. 大數(shù)據(jù)平臺的基礎(chǔ)能力和性能測試[J]. 大數(shù)據(jù)， 2017（4）：43-51.

[7] 詹劍鋒，高婉鈴，王磊，等. BigDataBench：開源的大數(shù)據(jù)系統(tǒng)評測基準[J]. 計算機學報，2016（1）：196-211.

[8] 倪寧. 大數(shù)據(jù)時代下電子商務(wù)平臺的探索和研究——以淘寶網(wǎng)為例[J]. 江蘇商論，2014（5）：13-14.

[9] LIU B，MENG X，SHI Y. CloudBM： a benchmark for cloud data management systems[J]. Journal of Frontiers of Computer Science and Technology， 2012， 6（6）： 504-512.

[10] 陳娜，張金娟，劉智瓊，等. 基于Hadoop平臺的電信大數(shù)據(jù)入庫及查詢性能優(yōu)化研究[J]. 移動通信， 2014（7）：58-63.

[11] 楊浩. Hadoop平臺性能優(yōu)化的研究與實現(xiàn)[D].成都：西南交通大學，2015.

[12] 張新玲， 顏秉珩. Hadoop平臺基準性能測試研究[J]. 軟件導(dǎo)刊， 2015（1）：30-32.

[13] SINGH S，GARG R，MISHRA P K. Performance optimization of MapReduce-based apriori algorithm on Hadoop cluster[J]. Computers & Electrical Engineering， 2017：S0045790617308534.

[14] 劉娟， 豆育升， 何晨， 等. 基于調(diào)度器的Hadoop性能優(yōu)化方法研究[J]. 計算機工程與設(shè)計，2013（1）：198-202.

[15] 連加典，劉宏立， 謝海波，等. 基于預(yù)測機制的分級負載均衡算法[J]. 計算機工程與應(yīng)用，2015，51（11）：67-71.

[16] 董新華，李瑞軒，周灣灣，等. Hadoop系統(tǒng)性能優(yōu)化與功能增強綜述[J]. 計算機研究與發(fā)展， 2013， 50（S2）：1-15.

[17] 高莉莎， 劉正濤， 應(yīng)毅. 基于應(yīng)用程序的MapReduce性能優(yōu)化[J]. 計算機技術(shù)與發(fā)展， 2015（7）：102-105，112.

[18] TOM W. Hadoop權(quán)威指南（中文版）[M].北京：清華大學出版社， 2010.

（責任編輯：黃 ?。?/p>