趙 哲，譚光林

（國家無線電監(jiān)測中心，北京 100037）

1 引言

根據(jù)我中心現(xiàn)有的大數(shù)據(jù)平臺技術(shù)架構(gòu)，基于2016年頻率使用評估工作中出現(xiàn)的系統(tǒng)響應(yīng)速度較慢、存儲空間不足等問題，我們希望通過對Hadoop 以及其他大數(shù)據(jù)生態(tài)環(huán)境中的最新技術(shù)進(jìn)行研究，結(jié)合現(xiàn)存的體系架構(gòu)，對系統(tǒng)就行改進(jìn)，從而提高系統(tǒng)運(yùn)行效率，改善系統(tǒng)計(jì)算性能。

2 目前架構(gòu)

現(xiàn)有的頻率使用評估平臺主要采用了Hadoop2.0 大數(shù)據(jù)平臺生態(tài)系統(tǒng)中的組件。數(shù)據(jù)存儲方面采用HDFS+Kudu，系統(tǒng)管理和調(diào)度采用YARN，實(shí)時計(jì)算方面采用Spark+Kaf ka，數(shù)據(jù)查詢采用Impala 等，相關(guān)的模塊都是較為穩(wěn)定的正式版本。隨著Hadoop2.0的進(jìn)一步發(fā)展，Hadoop3.0版本的推出，在數(shù)據(jù)的存儲，資源調(diào)度等方面陸續(xù)出現(xiàn)了一些更加先進(jìn)的模塊，如用于進(jìn)行數(shù)據(jù)存儲的ORC和Parquet等。

除大數(shù)據(jù)平臺的處理模塊外，頻率使用評估本身數(shù)據(jù)處理的過程中涉及到信道占用度、頻段占用度、信號覆蓋率等性能指標(biāo)的計(jì)算和查詢，涉及到大量和SQL相關(guān)的操作。從平臺優(yōu)化的角度出發(fā)，我們也在考慮是否可以對這些相關(guān)的數(shù)據(jù)操作進(jìn)行一定程度的優(yōu)化，從而提高系統(tǒng)的響應(yīng)速度。

3 現(xiàn)狀分析

鑒于本身平臺的硬件構(gòu)架方式和硬件采購成本已經(jīng)決定了當(dāng)前的硬件能夠繼續(xù)升級，但系統(tǒng)處理能力無法持續(xù)線性增加，所以平臺優(yōu)化的主要集中在對大數(shù)據(jù)平臺的模塊和相關(guān)指標(biāo)算法方面。

對于大數(shù)據(jù)平臺的模塊，目前的工作思路是考慮對相關(guān)的模塊進(jìn)行替換，搭建實(shí)驗(yàn)環(huán)境，進(jìn)行樣本數(shù)據(jù)運(yùn)算，得出實(shí)驗(yàn)結(jié)果，從而得出是否有更適合頻率使用評估工作采用的數(shù)據(jù)處理模塊。如當(dāng)前的存儲模塊采用的是Kudu，可通過使用ORC和Parquet進(jìn)行相應(yīng)的替換。

對于相關(guān)性能指標(biāo)的算法，可以考慮通過對SQL語句和優(yōu)化，以及對于算法本身的相關(guān)研究，實(shí)現(xiàn)性能的提高，具體需要研究的算法，會在隨后的工作中具體明確的提出。

4 最新技術(shù)

頻譜使用評估分析與應(yīng)用系統(tǒng)現(xiàn)由6臺服務(wù)器組成計(jì)算機(jī)集群，提供共計(jì)84T的存儲容量。通過2016年頻譜評估專項(xiàng)活動，各省上報(bào)原始監(jiān)測數(shù)據(jù)約31T，入庫后數(shù)據(jù)量約為62T，大約2億條記錄。采用分布式存儲技術(shù)、海量數(shù)據(jù)傳輸處理技術(shù)、海量數(shù)據(jù)交互式查詢技術(shù)等構(gòu)建系統(tǒng)的大數(shù)據(jù)支撐平臺及各種業(yè)務(wù)應(yīng)用。

通過數(shù)據(jù)校驗(yàn)、數(shù)據(jù)處理、數(shù)據(jù)分析以及數(shù)據(jù)應(yīng)用及展示這四大子系統(tǒng)，實(shí)現(xiàn)原始監(jiān)測數(shù)據(jù)從上報(bào)到入庫，到計(jì)算、分析，再到數(shù)據(jù)展現(xiàn)全過程的信息化，同時根據(jù)專項(xiàng)活動中對公眾移動通信頻段的評估工作的要求，通過統(tǒng)計(jì)圖表等方式，直觀、準(zhǔn)確地反映了頻譜使用的實(shí)際情況，為頻譜管理精細(xì)化提供決策支持。

綜合頻率評估平臺軟硬件構(gòu)建方式，平臺的優(yōu)化可以從硬件配置、處理模塊和相關(guān)算法等三個方面進(jìn)行入手。

圖1 Hadoop3.0生態(tài)系統(tǒng)

從數(shù)據(jù)存儲和數(shù)據(jù)計(jì)算兩個方面入手，我們對Hadoop3.0生態(tài)圈中的最新技術(shù)進(jìn)行了篩選和考察，從中挑選出了部分適合現(xiàn)有平臺采用的技術(shù)。接下來重點(diǎn)介紹我們實(shí)驗(yàn)環(huán)境中會用到的相關(guān)技術(shù)手段，并進(jìn)行初步的對比。

⊙ 在Hadoop3.0中實(shí)現(xiàn)的Integrating Erasure Coding備份方式在實(shí)現(xiàn)了傳統(tǒng)Erasure Coding 備份的基礎(chǔ)上，提高了磁盤空間的利用率。例如：一個提供3倍冗余的的文件備份，假如每個文件需要6個數(shù)據(jù)塊進(jìn)行存儲的話，那么需要6*3=18個磁盤塊，而如果采用Interating EC的方式，實(shí)現(xiàn)相同3倍冗余備份，只需要9個磁盤塊。

⊙ Kudu是Cloudera開發(fā)的存儲系統(tǒng)，其整體應(yīng)用模式和HBase比較接近，即支持行級別的隨機(jī)讀寫，并支持批量順序檢索功能。

⊙ Parquet是面向分析型業(yè)務(wù)的列式存儲格式。列存儲可以跳過不符合條件的數(shù)據(jù)，只讀取需要的數(shù)據(jù)，降低IO數(shù)據(jù)量。壓縮編碼可以降低磁盤存儲空間。

⊙ ORC（OptimizedRC File）存儲源自于RC（Record Columnar File）這種存儲格式，RC是一種列式存儲引擎，對schema演化（修改schema需要重新生成數(shù)據(jù)）支持較差，而ORC是對RC改進(jìn)，但它仍對schema 演化支持較差，主要是在壓縮編碼，查詢性能方面做了優(yōu)化。

⊙ Storm是一個免費(fèi)并開源的分布式實(shí)時計(jì)算系統(tǒng)。利用Storm可以很容易做到可靠地處理無限的數(shù)據(jù)流，像Hadoop批量處理大數(shù)據(jù)一樣，Storm可以實(shí)時處理數(shù)據(jù)。

⊙ Spark是一個基于內(nèi)存計(jì)算的開源的集群計(jì)算系統(tǒng)，目的是讓數(shù)據(jù)分析更加快速。Spark 是一種與 Hadoop 相似的開源集群計(jì)算環(huán)境，但是兩者之間還存在一些不同之處，這些有用的不同之處使 Spark 在某些工作負(fù)載方面表現(xiàn)得更加優(yōu)越。換句話說，Spark 啟用了內(nèi)存分布數(shù)據(jù)集，除了能夠提供交互式查詢外，它還可以優(yōu)化迭代工作負(fù)載。

5 優(yōu)化實(shí)驗(yàn)

接下來我們進(jìn)行了三次模擬環(huán)境下的數(shù)據(jù)存儲和計(jì)算實(shí)驗(yàn)。實(shí)驗(yàn)環(huán)境和實(shí)驗(yàn)流程如下：

實(shí)驗(yàn)環(huán)境：

⊙ 主機(jī)數(shù)量 10臺，其中臺式電腦8臺，筆記本2臺。

⊙ 所有主機(jī)統(tǒng)一接入到一臺路由器，配置相應(yīng)的IP網(wǎng)段，進(jìn)行互聯(lián)互通。

實(shí)驗(yàn)流程：

⊙ 試驗(yàn)環(huán)境搭建。

⊙ 相應(yīng)組件安裝。

⊙ 測試數(shù)據(jù)導(dǎo)入。

⊙ 測試?yán)龍?zhí)行。

⊙ 實(shí)驗(yàn)結(jié)果采集。

5.1 EC校驗(yàn)

目前我們的頻率評估系統(tǒng)采用了主流的Hadoop2.0中RAID存儲和備份方式，也就是在數(shù)據(jù)保護(hù)方面采取了傳統(tǒng)的Erasure Coding的方式，我們希望通過本實(shí)驗(yàn)，可以達(dá)到未來能夠?qū)⑾到y(tǒng)的存儲備份方式升級提高到Integrat ing Erasure Coding的模式下，從而提高系統(tǒng)的存儲備份率。

5.2 Parquet、Kudu和HBase等的對比實(shí)驗(yàn)

目前我們的頻率評估系統(tǒng)采用了Kudu作為數(shù)據(jù)的存儲系統(tǒng)，我們希望通過本實(shí)驗(yàn)，測試在相同數(shù)據(jù)條件下，是否可以通過ORC或者Parquet來進(jìn)一步提高數(shù)據(jù)的查找和計(jì)算速度，從而提高系統(tǒng)的整體性能。

5.3 Impala，Kudu，Presto和Spark的計(jì)算和對比

目前我們的頻率評估系統(tǒng)采用了Spark+Impala 的方式在進(jìn)行上層的數(shù)據(jù)處理和任務(wù)分解。希望通過本實(shí)驗(yàn)，測試在相同數(shù)據(jù)條件下，未來如果數(shù)據(jù)的采集方式發(fā)生改變，是否可以通過Stream組件提供流式計(jì)算處理能力。

6 實(shí)驗(yàn)結(jié)果

6.1 EC實(shí)驗(yàn)分析

經(jīng)過實(shí)驗(yàn)測試，我們得到實(shí)驗(yàn)結(jié)果見表1：

EC技術(shù)的優(yōu)勢確實(shí)明顯，但是它的使用也是需要一些代價的，一旦數(shù)據(jù)需要恢復(fù)，EC會造成兩大資源的消耗。

表1 存儲實(shí)驗(yàn)

⊙ 網(wǎng)絡(luò)帶寬的消耗，因?yàn)閿?shù)據(jù)恢復(fù)需要去讀其他的數(shù)據(jù)塊和校驗(yàn)塊。

⊙ 進(jìn)行編碼，解碼計(jì)算需要消耗CPU資源。

綜合考慮，在需要進(jìn)行數(shù)據(jù)恢復(fù)時，EC既耗網(wǎng)絡(luò)又耗CPU，從實(shí)際環(huán)境部署的角度來分析，代價也較高。所以將此技術(shù)用于線上服務(wù)可能會不夠穩(wěn)定，最好的選擇是用于冷數(shù)據(jù)集群：

⊙ 冷數(shù)據(jù)集群往往有大量的長期沒有被訪問的數(shù)據(jù)，體量確實(shí)很大，采用EC技術(shù)，可以大大減少副本數(shù)。

⊙ 冷數(shù)據(jù)集群基本穩(wěn)定，耗資源量少，所以一旦進(jìn)行數(shù)據(jù)恢復(fù)，將不會對集群造成大的影響。

出于上述二種原因，冷數(shù)據(jù)集群無非是一個很好的選擇。

6.2 Parquet、Kudu和HBase等的對比實(shí)驗(yàn)

6.2.1 空間利用

根據(jù)測量結(jié)果，利用Kudu和Parquet編碼的數(shù)據(jù)提供了最佳的壓縮率。與使用MapFiles的原始數(shù)據(jù)集編碼相比，使用類似Snappy或GZip之類的壓縮算法可以進(jìn)一步顯著減少數(shù)據(jù)量達(dá)10倍。由于HBase存儲數(shù)據(jù)的方式是一個空間效率較低的解決方案，雖然HBase塊的壓縮給出相當(dāng)好的比率，但是與Kudu和Parquet相比差距仍然較大。

6.2.2 提取速度

由于Apache Impala執(zhí)行數(shù)據(jù)重構(gòu)以串行寫入單個HDFS目錄（Hive分區(qū)），因此對于HDFS格式和HBase或Kudu的格式，可以直接比較單個數(shù)據(jù)分區(qū)擷取效率。使用Avro或Parquet編碼寫入的HDFS 文件比存儲引擎（如HBase和Kudu）提供了更好的結(jié)果（至少5倍）。

使用Avro或Parquet編碼寫入的HDFS文件比存儲引擎（例如HBase和Kudu）提供了更好的結(jié)果（至少5倍）。由于Avro具有最輕量的編碼器，因此其實(shí)現(xiàn)了最好的擷取性能。

另一方面，在這個測試中HBase非常慢（性能比Kudu差）。這很可能是由于行鍵的長度（6個并置列）引起的，其平均約為60個字節(jié)。HBase必須為一行中的每一列分別編碼一個鍵，這對于長記錄（包含許多列）可能不是最佳的方法。

6.2.3 隨機(jī)數(shù)據(jù)查找延遲

當(dāng)通過記錄鍵訪問數(shù)據(jù)時，因?yàn)槭褂昧藘?nèi)置索引，Kudu和HBase的訪問速度是最快的。圖上的值都是基于冷緩存（cold cache）進(jìn)行測量。

使用Apache Impala進(jìn)行隨機(jī)查找測試對于Kudu和HBase來說是次優(yōu)選擇，因?yàn)樵谡嬲龍?zhí)行查詢（計(jì)劃、代碼生成等）之前耗費(fèi)了大量的時間—通常大約是200ms。因此，對于低延遲數(shù)據(jù)訪問，建議跳過Impala并使用專用API（我們也嘗試過這種方法，Kudu和HBase的結(jié)果類似：冷緩存小于200ms，預(yù)熱緩存小于80ms）。

與Kudu和HBase相反，檢索以Avro格式存儲的單個記錄中的數(shù)據(jù)只能在對整個數(shù)據(jù)分區(qū)的強(qiáng)力掃描中完成（需要注意的是 – 數(shù)據(jù)由記錄鍵的一部分進(jìn)行分區(qū)，因此針對這種情況應(yīng)用分區(qū)修剪技術(shù)）。平均分區(qū)的大小為GB級，因此獲取所需的記錄需要耗費(fèi)幾秒鐘的時間（取決于IO吞吐量），并使用大量的集群資源。這最終減少了必須在集群上全速執(zhí)行的并發(fā)查詢的數(shù)量。

同樣的問題也適用于Parquet，然而，Parquet格式的柱狀特性允許相對快速地執(zhí)行分區(qū)掃描。由于列投影和列謂詞的下推，掃描輸入集的大小最終從數(shù)GB減少到只有幾MB（非常高效，56列經(jīng)過掃描后只剩下3列）。

6.2.4 數(shù)據(jù)掃描速率

由于通過應(yīng)用列投影輸入集數(shù)量減少，Parquet 在此測試中勝過了Avro。Parquet不僅在每內(nèi)核處理速率方面保持了最高效率，同時也在完成處理方面保持最快速度。在Parquet和Avro的情況下，數(shù)據(jù)訪問并行化的單位是HDFS文件塊，其很容易在Hadoop集群上的所有可用資源上均勻分布處理。

在掃描效率方面，Kudu（采用Snappy壓縮）與Parquet相差不大。因?yàn)榱型队?，其受益匪淺。

由于數(shù)據(jù)訪問并行化的單位是表分區(qū)，掃描存儲在Kudu和HBase中的數(shù)據(jù)可能不平衡。因此，掃描中涉及的資源量取決于給定表分區(qū)的數(shù)量及其在集群中的分布。

在這個測試案例中，因?yàn)镵udu不支持謂詞，所以不可能使用Kudu的本地謂詞下推功能。附加測試結(jié)果證明，當(dāng)使用支持的謂詞時，Kudu掃描速度比Parquet更快。

在使用HBase進(jìn)行測試之前，掃描的列在專用HBase列族中被分離，這就提高了5倍的掃描效率。但仍然與Parquet或Kudu存在較大差距。

6.3 Impala，Kudu，Presto和Spark的計(jì)算和對比實(shí)驗(yàn)分析

6.3.1 計(jì)算引擎速度對比

表2 計(jì)算速度實(shí)驗(yàn)一

表3 計(jì)算速度實(shí)驗(yàn)二

表4 計(jì)算速度實(shí)驗(yàn)三

表5 計(jì)算速度實(shí)驗(yàn)五

表6 計(jì)算速度實(shí)驗(yàn)六

6.3.2 存儲格式速度對比

表7 存儲速度實(shí)驗(yàn)一

表8 存儲速度實(shí)驗(yàn)二

表9 存儲速度實(shí)驗(yàn)三

[1] Zikopoulos，Paul，and Chris Eaton.Understanding big data：Analytics for enterprise class hadoop and streaming data.McGraw-Hill Osborne Media，2011.

[2] White，Tom.Hadoop ：The definitive guide.” O’Reilly Media，Inc.”，2012.

[3] Gray，S.，et al.”IBM Big SQL 3.0 ：SQL-on-Hadoop without compromise.”（2014）.

[4] Masur，Rohit G.，and Suzanne K.Mcintosh.”Preliminary performance analysis of Hadoop 3.0.0-alpha3.” Scientific Data Summit（NYSDS），2017 New York.IEEE，2017.

[5] Vidhyavathi，P.“A Review On Hadoop ：Privacy For A Multi-Skyline Queries With Map Reduce.” IJSEAT 5.10（2017）：1004-1007.