馬 黎

(1.武漢大學(xué)計(jì)算機(jī)學(xué)院,湖北 武漢 430072;2.商丘職業(yè)技術(shù)學(xué)院學(xué)報(bào)編輯部, 河南 商丘 476000)

0 引 言

信息時(shí)代，數(shù)據(jù)呈幾何級(jí)增長。對(duì)這些大數(shù)據(jù)的存儲(chǔ)和處理需求也隨之增加。通常而言，大數(shù)據(jù)不僅包括大量的數(shù)據(jù)，同時(shí)還包括存儲(chǔ)和處理這些數(shù)據(jù)的新范式和各種技術(shù)。在這個(gè)背景下，催生了眾多處理框架，如MapReduce[1,2]、Apache Spark[3,4]和Apache Flink[5]等。對(duì)這些技術(shù)框架進(jìn)行研究具有較大意義，可直接指導(dǎo)項(xiàng)目開發(fā)和應(yīng)用。

自從Google公司在2003年推行MapReduce后，該框架已經(jīng)引發(fā)了一場技術(shù)革新[6]。該框架以并行化、分布式的方式處理和生成大型數(shù)據(jù)集。即MapReduce框架分割數(shù)據(jù)，且在集群之間對(duì)其進(jìn)行分發(fā)；然后，再以并行的方式對(duì)劃分出的數(shù)據(jù)片段執(zhí)行相同的操作；最后，對(duì)結(jié)果進(jìn)行聚合，并送回主節(jié)點(diǎn)。該框架對(duì)所有任務(wù)的調(diào)度和檢測進(jìn)行管理，并且在任務(wù)失敗的情況下重新執(zhí)行該任務(wù)。

通常來說，MapReduce及其開源版本Apache Hadoop[7]是首批面向大數(shù)據(jù)存儲(chǔ)和處理的分布式編程技術(shù)。自此之后，大數(shù)據(jù)的快速發(fā)展促使了一些新工具出現(xiàn)。Apache Spark正是這些框架中的一種，即一種基于內(nèi)存的大規(guī)模數(shù)據(jù)快速處理通用引擎。而Apache Flink是近兩年內(nèi)備受關(guān)注的新框架，可用于分布式流數(shù)據(jù)和批量數(shù)據(jù)處理。

簡單來說，Apache Spark是基于彈性分布式數(shù)據(jù)集(Resilient Distributed Datasets, RDD)的數(shù)據(jù)結(jié)構(gòu)[8]，其開發(fā)動(dòng)機(jī)是解決MapReduce/Hadoop范式中的局限性[9]。且Spark允許用戶程序?qū)?shù)據(jù)加載到內(nèi)存中，并反復(fù)進(jìn)行查詢，因此它是在線計(jì)算和迭代計(jì)算的合適工具。Apache Flink框架著眼于在分布式系統(tǒng)上，處理具有非常低的數(shù)據(jù)延遲和高容錯(cuò)性的數(shù)據(jù)。Flink的核心特征是能夠?qū)崟r(shí)處理數(shù)據(jù)流，提供了一個(gè)較高的容錯(cuò)機(jī)制，使數(shù)據(jù)流應(yīng)用可以持續(xù)地恢復(fù)狀態(tài)。這一機(jī)制持續(xù)地生成分布式數(shù)據(jù)流和操作符。Flink的兩個(gè)主要的API是DataStream和DataSet，它們支持流式數(shù)據(jù)和批量數(shù)據(jù)的處理。且這兩個(gè)API均建立于底層流式數(shù)據(jù)引擎之上。

本文對(duì)Apache Spark和Apache Flink框架的ML庫進(jìn)行了比較研究。主要目的是研究這兩個(gè)框架在進(jìn)行批量數(shù)據(jù)處理時(shí)的性能差異和相似性。主要比較了兩個(gè)框架的ML庫都具備的兩個(gè)算法，即支持向量機(jī)(Supported Vector Machine, SVM)算法和線性回歸(Linear Regression, LR)算法。此外，本文還實(shí)現(xiàn)了分布式信息理論的特征選擇(Feature Selection of Distributed Information Theory, FS-DIT)算法，以進(jìn)一步比較每個(gè)框架的不同功能。

1 Spark和Flink的比較

本節(jié)將介紹Spark和Flink兩個(gè)平臺(tái)的引擎間主要差異和相似性，以解釋兩個(gè)平臺(tái)分別適用的場景。然后，將重點(diǎn)介紹實(shí)施在這兩個(gè)平臺(tái)中的三個(gè)機(jī)器學(xué)習(xí)算法之間的主要差異，這三個(gè)算法分別為FS-DIT算法，SVM算法和LR算法。

1.1 引擎間的比較

兩個(gè)引擎之間的第一個(gè)顯著區(qū)別在于攝取數(shù)據(jù)流的方式不同。Flink是一個(gè)native流式處理框架，即數(shù)據(jù)進(jìn)入后立即處理，可以處理批量數(shù)據(jù)；而Spark最初的設(shè)計(jì)理念則是通過彈性分布式數(shù)據(jù)集(Resilient Distributed Datasets, RDD)對(duì)靜態(tài)數(shù)據(jù)進(jìn)行處理，且Spark使用微批處理的方式處理流式數(shù)據(jù)。因此，Spark對(duì)輸入數(shù)據(jù)進(jìn)行分割，每次處理一個(gè)數(shù)據(jù)片段。其主要優(yōu)點(diǎn)在于Spark選擇的DStream結(jié)構(gòu)是一個(gè)簡單的RDD隊(duì)列，允許用戶在流處理和批處理之間切換。但當(dāng)系統(tǒng)要求非常低的延遲時(shí)，微批處理的執(zhí)行速度可能無法達(dá)到要求，而Flink在這些系統(tǒng)中有著極好的兼容性，這是因?yàn)镕link的特性是對(duì)于所有類型的工作負(fù)載均使用流式數(shù)據(jù)。

與Hadoop MapReduce不同，Spark和Flink支持?jǐn)?shù)據(jù)復(fù)用和迭代。Spark通過顯式緩存，在不同迭代間將數(shù)據(jù)保存在內(nèi)存中。然而，Spark采用無環(huán)圖執(zhí)行計(jì)劃，這意味著其需要在每次迭代時(shí)調(diào)度和運(yùn)行相同的指令集。反之，F(xiàn)link在其引擎中基于循環(huán)數(shù)據(jù)流(即一次迭代進(jìn)行一次調(diào)度)，實(shí)現(xiàn)了徹底的迭代處理。

早期Spark主要使用JVM的堆內(nèi)存[10]，對(duì)所有的內(nèi)存進(jìn)行管理。但這個(gè)解決方案可能會(huì)發(fā)生內(nèi)存溢出等問題。得益于新的Stungsten項(xiàng)目，這些問題得到了一定程度的解決。現(xiàn)在，Spark可以通過DataFrames管理自己的內(nèi)存棧，并充分利用了現(xiàn)代計(jì)算機(jī)中可用的內(nèi)存層次結(jié)構(gòu)(L1和L2 CPU緩存)。然而，F(xiàn)link的研究人員則在設(shè)計(jì)初始就考慮到了這些問題。由此，F(xiàn)link的設(shè)計(jì)團(tuán)隊(duì)提出了一個(gè)具有自調(diào)控能力的內(nèi)存棧，并采用二進(jìn)制格式的提取和序列化策略。這些設(shè)計(jì)好處很明顯，具有：內(nèi)存錯(cuò)誤少，垃圾收集壓力小，以及更好的空間數(shù)據(jù)表示等優(yōu)點(diǎn)。

在優(yōu)化方面，這兩個(gè)框架的機(jī)制都是通過分析用戶提交的代碼，產(chǎn)生一個(gè)給定執(zhí)行圖的最佳管道代碼。舉例來說，在Flink中，一個(gè)join操作可被規(guī)劃為兩個(gè)集合的一次置亂，或?qū)ψ钚≡氐囊淮螐V播。Apark也提供了手動(dòng)優(yōu)化，允許用戶控制分區(qū)和內(nèi)存緩存。本文省去了對(duì)編碼和調(diào)整的易用性，以及各種不同操作符的比較，因?yàn)檫@些因素不會(huì)對(duì)執(zhí)行性能造成影響。

1.2 算法運(yùn)行的細(xì)節(jié)比較

1.2.1 特征選擇算法

本文在兩個(gè)平臺(tái)上都實(shí)施了一個(gè)基于信息理論的特征選擇框架[11]，即在一個(gè)貪婪算法中集合多個(gè)信息論準(zhǔn)則。通過一些獨(dú)立性假設(shè)，允許將多個(gè)準(zhǔn)則變換為Shannon熵的線性組合項(xiàng)，即互信息(Mutual Information, MI)和條件互信息(Conditional Mutual Information, CMI)。該框架中包括了一些相關(guān)算法，例如最小冗余最大相關(guān)，信息增益等。該算法的主要目的是采用一個(gè)簡單的得分機(jī)制對(duì)特征進(jìn)行評(píng)價(jià)，并根據(jù)排名選擇相關(guān)性更高的特征。特征評(píng)分通用框架可被表示如下：

(1)

式中，第一項(xiàng)表示候選輸入特征Xi和類Y之間的相關(guān)性(互信息)，第二項(xiàng)表示已經(jīng)選擇的特征(在集合Set中)和候選特征之間的冗余(互信息)，第三項(xiàng)表示兩個(gè)集合Xj和Xi與類Y之間的條件冗余(條件互信息)。η表示條件互信息的權(quán)重因子，α表示互信息的權(quán)重因子。

本文對(duì)已有的框架重新進(jìn)行設(shè)計(jì)，以期達(dá)到在分布式環(huán)境中更好的表現(xiàn)。實(shí)施的主要改動(dòng)如下：

(1)逐列轉(zhuǎn)換：大部分特征選擇算法按列進(jìn)行計(jì)算。這意味著以往將數(shù)據(jù)轉(zhuǎn)換為縱列格式或許能提高計(jì)算性能，例如當(dāng)對(duì)相關(guān)性或冗余進(jìn)行計(jì)算的時(shí)候。相應(yīng)地，本文提出的程序的第一步旨在將原始集合轉(zhuǎn)換到列中，其中每個(gè)新實(shí)例包含著原始集合中每個(gè)特征和分區(qū)數(shù)值。

(2)保留重要信息：一些預(yù)計(jì)算的數(shù)據(jù)，例如轉(zhuǎn)換輸入或者初始相關(guān)性，被緩存放在內(nèi)存中，以避免下個(gè)階段對(duì)其進(jìn)行重復(fù)計(jì)算。如果該信息在開始的時(shí)候被計(jì)算過一次，那么該信息的保留在內(nèi)存能夠顯著加快算法性能。

(3)變量的廣播：為了避免在每次迭代中對(duì)轉(zhuǎn)換后的數(shù)據(jù)進(jìn)行移動(dòng)，本文保留了這個(gè)設(shè)置，并且對(duì)當(dāng)前迭代中涉及到的列(特征)進(jìn)行廣播。例如，在第一次迭代中對(duì)類特征進(jìn)行廣播，以計(jì)算每個(gè)分區(qū)中的初始相關(guān)性。

在Flink的實(shí)現(xiàn)中，本文使用了批量迭代過程，以處理貪婪程序。在Spark的實(shí)現(xiàn)中，本文使用了帶緩存和重復(fù)任務(wù)的典型迭代過程。

Flink代碼在GitHub庫中，具體網(wǎng)址如下：https://github.com/sramirez/flink-infotheoretic-feature-selection。

Spark代碼被匯集到一個(gè)包，已經(jīng)傳到了Spark的第三方庫中，網(wǎng)址如下：https://spark-packages.org/package/sramirez/spark-infotheoretic-feature-selection.。

1.2.2 支持向量機(jī)分類算法

Spark和Flink都使用一個(gè)線性優(yōu)化器，實(shí)施SVM分類器。即待求解的最小化問題如下：

(2)

式中，q為權(quán)重向量;xi∈Rb為數(shù)據(jù)實(shí)例;β為正則化常數(shù);fi為凸損失函數(shù)。默認(rèn)正則化項(xiàng)均為L2范式，損失函數(shù)均為：

fi=max(0,1-yiqTxi)

(3)

高效通信的分布式雙坐標(biāo)上升算法(Distributed Dual Coordinate Ascent Algorithm, DDCAA)[12]和隨機(jī)雙坐標(biāo)上升(Stochastic Dual Coordinate Ascent, SDCA)[13]算法被用在Flink中，以求解先前定義的最小化問題(即式(2))。DDCAA包括每個(gè)分區(qū)上SDCA的一些迭代和部分結(jié)果的聚合。

Spark采用了分布式隨機(jī)梯度下降(Stochastic Gradient Descent, SGD)算法。在SGD中，數(shù)據(jù)的一個(gè)樣本被用于在每個(gè)階段中計(jì)算次梯度。僅對(duì)來自每個(gè)工作節(jié)點(diǎn)的部分結(jié)果在網(wǎng)絡(luò)上進(jìn)行發(fā)送，以更新全局梯度。

1.2.3 線性回歸

線性最小二乘法是Spark中實(shí)施的另一個(gè)簡單的線性方法。盡管針對(duì)回歸而設(shè)計(jì)，但其輸出可適用于二元分類問題。線性最小二乘遵循如式(2)所示的最小化公式和優(yōu)化方法(基于隨機(jī)梯度下降算法)，但使用了平方損失函數(shù)，且無正則化，即：

(4)

該算法的Flink版本與Spark的開發(fā)人員創(chuàng)建的算法非常相似。Flink使用隨機(jī)梯度下降來逼近梯度解。然而，F(xiàn)link只提供了平方損失，而Spark則提供了許多選項(xiàng)，例如logistic函數(shù)損失等。

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

本節(jié)將在相同數(shù)據(jù)集上，使用上述三種機(jī)器學(xué)習(xí)算法的實(shí)驗(yàn)，以比較Spark和Flink的性能。

2.1 數(shù)據(jù)集

實(shí)驗(yàn)中使用的數(shù)據(jù)集為ECBDL14數(shù)據(jù)集[14]，該數(shù)據(jù)集曾被用于大數(shù)據(jù)的機(jī)器學(xué)習(xí)競賽。ECBDL14數(shù)據(jù)集中包括631個(gè)特征(包括數(shù)字和分類屬性)和3200萬個(gè)實(shí)例。同時(shí)該數(shù)據(jù)集涉及一個(gè)類分布高度不均衡的二元分類問題：正相關(guān)實(shí)例僅占2%。針對(duì)這一問題，本文應(yīng)用了兩個(gè)預(yù)處理算法。首先對(duì)原始數(shù)據(jù)中少數(shù)類的實(shí)例進(jìn)行復(fù)制，直到兩個(gè)分類的實(shí)例數(shù)量達(dá)到平衡。最后，對(duì)于FS-DIT算法，使用對(duì)數(shù)據(jù)集進(jìn)行離散化。

實(shí)驗(yàn)中使用5個(gè)不同的百分比對(duì)原始數(shù)據(jù)集進(jìn)行隨機(jī)采樣，以測量兩個(gè)框架可擴(kuò)展性的性能，使用的預(yù)處理數(shù)據(jù)集百分比分別為10%、30%、50%、75%和100%。由于當(dāng)前Flink的限制，每個(gè)ECBDL14數(shù)據(jù)集樣本的150個(gè)特征子集用于SVM算法。上述數(shù)據(jù)集的基本情況如表1所示。

表1 ECBDL14數(shù)據(jù)集的基本描述

2.2 結(jié)果比較

實(shí)驗(yàn)中，對(duì)SVM算法進(jìn)行100次迭代，其中步長為0.01，正則化參數(shù)為0.01。對(duì)于LR算法，也使用100次迭代，步長為0.00001。最后，對(duì)于FS-DIT算法，使用最小冗余最大相關(guān)算法[15]選擇出10個(gè)特征。

本文將總學(xué)習(xí)時(shí)長(秒)作為SVM和LR算法的評(píng)價(jià)標(biāo)準(zhǔn)，將總運(yùn)行時(shí)長(秒)作為FS-DIT的評(píng)價(jià)標(biāo)準(zhǔn)。在所有的實(shí)驗(yàn)中，使用了9個(gè)計(jì)算節(jié)點(diǎn)和一個(gè)主節(jié)點(diǎn)組成的集群。計(jì)算節(jié)點(diǎn)的硬件配置如下：兩個(gè)Intel Xeon CPU E5-2630 v3處理器，每個(gè)處理器8個(gè)核，主頻均為2.40 GHz，20 MB緩存；2個(gè)2 TB的HDD，128 GB的RAM。在軟件方面，本文使用了以下配置：來自Cloudera的開源Apache Hadoop分布式系統(tǒng)的Hadoop 2.6.0-cdh5.5.1；Apache Spark和MLlib 1.6.0，279個(gè)核心(每個(gè)節(jié)點(diǎn)31個(gè)核心)，900GB RAM(每個(gè)節(jié)點(diǎn)100 GB)；Apache Flink 1.0.3，270個(gè)任務(wù)管理器(每個(gè)核心30個(gè)任務(wù)管理器)，每個(gè)節(jié)點(diǎn)100 GB RAM。

表2給出了使用簡化版本數(shù)據(jù)集的實(shí)驗(yàn)結(jié)果。共有150個(gè)特征，對(duì)SVM進(jìn)行100次迭代。由于當(dāng)前的Spark的ML庫中沒有SVM算法，故沒有比較Spark ML。從該表中可以觀察到，Spark的性能大幅優(yōu)于Flink。當(dāng)數(shù)據(jù)集的規(guī)模增長時(shí)，Spark和Flink之間的時(shí)長差異也隨之變大，實(shí)驗(yàn)開始階段，F(xiàn)link的耗時(shí)約為Spark的2.5倍，而使用完整的數(shù)據(jù)集時(shí)Flink的耗時(shí)為Spark的4.5倍。

圖1是表2的曲線形式，可以看出隨著預(yù)處理百分比數(shù)據(jù)越高，Spark MLlib與Flink的差距越大，差距最大可以達(dá)到625秒左右。

表2 支持向量機(jī)的學(xué)習(xí)時(shí)長(s)

圖1 SVM算法在不同平臺(tái)上的性能比較

表3比較了LR算法，進(jìn)行100次迭代所得的學(xué)習(xí)時(shí)長。Spark MLlib(API接口基于RDD)和Spark ML(API接口基于DataFrame)之間的時(shí)長差異主要是由于ML運(yùn)行時(shí)，對(duì)數(shù)據(jù)集從DataFrame到RDD進(jìn)行內(nèi)部轉(zhuǎn)換(但對(duì)于用戶來說，DataFrame的API接口比RDD接口更加友好，實(shí)際使用中，推薦使用Spark ML。因?yàn)榻⒃贒ataFrame基礎(chǔ)上的Spark ML中的一系列算法更加適合創(chuàng)建包含“數(shù)據(jù)清洗—特征工程—模型訓(xùn)練”等一系列工作的ML管道)。Flink的耗時(shí)大約為Spark ML的8倍。因此，與Flink相比，Spark MLlib和Spark ML版本的性能優(yōu)于Flink。從本文的學(xué)習(xí)時(shí)長來看，Spark MLlib稍微優(yōu)于Flink ML。

圖2是表3的曲線形式，可以看出，對(duì)于LR算法來說，Spark MLlib的學(xué)習(xí)時(shí)長沒怎么增加，說明了LR算法在Spark MLlib平臺(tái)上非常穩(wěn)定，不隨預(yù)處理數(shù)據(jù)集的多少變化而變化，而且學(xué)習(xí)時(shí)長最少。而Spark ML和Flink會(huì)隨著數(shù)據(jù)集的大小起伏變化。預(yù)處理數(shù)據(jù)集越大，學(xué)習(xí)時(shí)長越大。

表3 線性回歸的學(xué)習(xí)時(shí)長(s)

圖2 LR算法在不同平臺(tái)上的性能比較

表4比較了FS-DIT算法的總運(yùn)行時(shí)長。其中，從離散后的數(shù)據(jù)集中選擇了前10個(gè)特征。如前面所述，Spark MLlib和Spark ML之間的時(shí)長差異來自于所面向的數(shù)據(jù)類型不一樣。從表4可以觀察到，當(dāng)使用10%，30%和50%的數(shù)據(jù)集時(shí)，F(xiàn)link的運(yùn)行時(shí)長約為Spark的9-10倍；當(dāng)使用75%的數(shù)據(jù)集時(shí)，F(xiàn)link的時(shí)長約為Spark的7-8倍；當(dāng)使用完整數(shù)據(jù)集時(shí)，F(xiàn)link的時(shí)長約為Spark的4倍。

圖3是表4的曲線形式，對(duì)于FS-DIT算法，Spark ML和Spark MLlib表現(xiàn)出了相似的性能，其細(xì)微區(qū)別表現(xiàn)在它們所面向的數(shù)據(jù)類型不一樣。在運(yùn)行總時(shí)長方面，它們均優(yōu)于Flink，在數(shù)據(jù)集較少的時(shí)候，其時(shí)長差異最大。從這方面看，Spark更加成熟。這印證了在批處理方面，Spark的確具有比Flink更好的適應(yīng)性。

表4 FS-DIT的運(yùn)行時(shí)長(s)

圖3 FS-DIT算法在不同平臺(tái)上的性能比較

Flink是一個(gè)新框架，而Spark則正成為大數(shù)據(jù)環(huán)境中的參考工具。Spark通過版本不斷的更新，實(shí)現(xiàn)了不少的性能改進(jìn)，而Flink則剛給出了第一個(gè)較為穩(wěn)定的版本。雖然Spark的一些性能改進(jìn)在Flink設(shè)計(jì)之初就考慮過(當(dāng)然兩者之間也相互學(xué)習(xí)借鑒)。但從實(shí)驗(yàn)結(jié)果來看，Spark依然是一個(gè)比Flink成熟得多的框架。

3 結(jié) 語

本文對(duì)兩個(gè)流行的大數(shù)據(jù)處理和存儲(chǔ)的框架Spark和Flink可擴(kuò)展性進(jìn)行了比較研究。使用了這兩個(gè)框架庫中都具有的SVM算法和LR算法。本文還在兩個(gè)平臺(tái)上實(shí)施并測試了特征選擇算法。得出結(jié)論：Spark的可擴(kuò)展性更佳，總運(yùn)行時(shí)長更短。其次，雖然Spark MLlib和Spark ML之間的性能差異很小，但前者還是略微優(yōu)于后者。

總體來說，在批處理方面，Spark優(yōu)于Flink，Spark獲得的業(yè)內(nèi)認(rèn)可度也更高。但Flink商業(yè)應(yīng)用的吸引力巨大，已經(jīng)有一些研究表明Flink的流處理比Spark更好(本文研究的是批處理)。經(jīng)過必要的改進(jìn)后，會(huì)成為分布式數(shù)據(jù)流分析的重要參考工具。這可能也是華為戰(zhàn)略投資Flink的原因之一。

：

[1] Vaidya M. MapReduce: a flexible Data Processing Tool[J]. Communications of the Acm, 2010, 53(1): 72-77.

[2] 王加亮, 秦勃, 劉健健,等. 基于MapReduce的交互可視化平臺(tái)[J]. 電信科學(xué), 2012, 28(9): 22-27.

[3] 彭特里思. Spark機(jī)器學(xué)習(xí)[M]. 南京：東南大學(xué)出版社, 2016.

[4] 孫科. 基于Spark的機(jī)器學(xué)習(xí)應(yīng)用框架研究與實(shí)現(xiàn)[D].上海：上海交通大學(xué), 2015.

[5] Rabl T, Traub J, Katsifodimos A, et al. Apache Flink in current research[J]. it - Information Technology, 2016, 58(4): 157-165.

[6] Dean J, Ghemawat S. Simplified data processing on large clusters[J]. In Proceedings of Operating Systems Design and Implementation, 2004, 51(1): 107-113.

[7] 肖強(qiáng), 朱慶華, 鄭華. Hadoop環(huán)境下的分布式協(xié)同過濾算法設(shè)計(jì)與實(shí)現(xiàn)[J]. 現(xiàn)代圖書情報(bào)技術(shù), 2013, 29(1): 83-89.

[8] Zaharia M, Chowdhury M, Das T, et al. Resilient distributed datasets: a fault-tolerant abstraction for in-memory cluster computing[C]// Usenix Conference on Networked Systems Design and Implementation. 2012: 112-122.

[9] Junqueira B F, Reed B. Hadoop: The Definitive Guide[J]. Journal of Computing in Higher Education, 2001, 12(2): 94-97.

[10] 羅永剛, 陳興蜀, 楊露. 一種Mapreduce作業(yè)內(nèi)存精確預(yù)測方法[J]. 電子科技大學(xué)學(xué)報(bào), 2016, 46(6): 986-991.

[11] 張躒. 基于信息論的特征選擇算法研究[D]. 哈爾濱：哈爾濱理工大學(xué), 2013.

[12] Jaggi M, Smith V, Taká?倣 M, et al. Communication-Efficient Distributed Dual Coordinate Ascent[J]. Advances in Neural Information Processing Systems, 2014, 31(4): 3068-3076.

[13] Shalev-Shwartz S, Zhang T. Stochastic Dual Coordinate Ascent Methods for Regularized Loss Minimization[J]. Journal of Machine Learning Research, 2012, 14(1): 201-213.

[14] Triguero I, Río S D, López V, et al. ROSEFW-RF: The winner algorithm for the ECBDL’14 big data competition: An extremely imbalanced big data bioinformatics problem[J]. Knowledge-Based Systems, 2015, 87(14): 69-79.

[15] 張新靜, 徐欣, 凌至培,等. 基于最大相關(guān)和最小冗余準(zhǔn)則及極限學(xué)習(xí)機(jī)的癲癇發(fā)作檢測方法[J]. 計(jì)算機(jī)應(yīng)用, 2014, 34(12): 3614-3617.