OSSData：面向開源社區(qū)的分布式數據采集框架

林維 陳曦 王松

摘要：近些年，開源軟件發(fā)展迅猛，其應用領域和適用范圍越來越廣泛;與此同時，開源軟件的成功也吸引了大量的開發(fā)者投入到開源軟件的開發(fā)。因此，開源軟件社區(qū)積累了大量的軟件應用和開發(fā)數據。這些豐富的數據逐步引起了研究人員的關注，已經有相關工作對開源軟件的群體開發(fā)模式和質量保證機制等展開了一系列研究。為了更好地支持此類研究工作的有效開展，面向開源社區(qū)提出了一個用戶可定制的數據采集框架，該框架具有較高的靈活性和魯棒性，能夠根據用戶的實際需求進行深度定制，并保持穩(wěn)定持續(xù)的工作狀態(tài)，從而提高數據采集的效率和質量。

關鍵詞：開源社區(qū);數據采集;網絡爬蟲;分布式框架

中圖分類號：TM773

文獻標識碼：A

歷經幾十年的發(fā)展，開源軟件已經取得相當矚目的成就，許多像Linux和Android這樣的優(yōu)秀開源軟件在各行各業(yè)發(fā)揮著重要的作用，他們的自由性、開放性以及較高的質量標準贏得了大量開發(fā)者和用戶的良好口碑。與此同時，伴隨著開源軟件的成功，越來越多的開發(fā)者逐步認同開源理念并開始致力于開源軟件開發(fā)。僅在GitHub社區(qū)，就已經有2400萬注冊用戶和6700萬版本庫，開發(fā)者在開源社區(qū)的貢獻熱情空前高漲。

開源軟件的快速發(fā)展同樣也吸引了學術界研究學者的目光，已經有相關工作對開源軟件和開源社區(qū)的演化模式[1，2]、群體協(xié)同貢獻的激發(fā)和匯聚機理[3，4]、代碼審查和質量保證機制[5，6]等問題進行了一系列研究。在這些研究中，有相當一部分工作是基于開源社區(qū)的歷史數據開展的，例如代碼實體、文本數據、開發(fā)行為數據、交互數據等。完整真實的數據源能夠為學術研究提供強有力的分析基礎和證據支持，使得研究成果更具說服力。因此，有效的數據獲取是研究工作開展的重要前提。

目前，研究者經常通過抽取原始頁面和訪問網站官方API的方式采集數據，而無論哪一種方式都需要開發(fā)者在進行正式的數據分析前先編程實現數據采集系統(tǒng)，通常開發(fā)者要耗費相當一部分的精力用于處理網絡訪問、異常處理、數據庫操作等復雜操作。因此，為支持研究人員更方便快速地開展學術研究，已經有相關工作嘗試提供公開的數據源，供相關研究者直接應用，從而節(jié)省了重復編寫程序采集數據的時間，加快了學術研究進展。例如Geogious[7]發(fā)布了GHTorrent系統(tǒng)，他設計了數據結構模式，通過GitHub官方API進行采集。較多研究[8，9，10]都引用了該數據集，但是它的數據量太大，使用其中一部分數據就需要下載完整的數據，并且其定義的數據模式有時并不能滿足所有研究人員的實際需求，因為某些研究人員可能在GhTorrent中不能找到他所需要的字段。

為解決上述問題，面向GitHub社區(qū)提出了一個用戶可定制的數據采集框架，該框架具有以下特點：

1.用戶可定制性：用戶可根據自己的實際需求進行精準的定向采集，在明確所需的數據后，結合官網提供的數據API接口，用戶只需做簡單配置即可方便地采集目標數據。

2.可擴展性：把數據采集流程分解為任務生成與任務執(zhí)行兩個模塊，從而把耗時的任務執(zhí)行過程剝離開來，便于利用分布式技術加速，提高數據采集效率。

3.魯棒性：利用消息隊列和數據庫封裝數據中間層，把業(yè)務邏輯所涉及到的各模塊切分得更獨立，從而使得系統(tǒng)擁有更強的容錯能力和恢復能力。

剩余內容結構如下：論文第2節(jié)介紹相關工作，對基于GitHub社區(qū)的數據挖掘工作以及數據采集系統(tǒng)相關工作進行介紹;第3節(jié)介紹系統(tǒng)設計和實現，具體包括系統(tǒng)各模塊的設計思路和功能作用;第4節(jié)報告系統(tǒng)評估結果，我們利用系統(tǒng)對幾種常用的數據類型進行采集，并對采集效果進行了實際評估;第5節(jié)對本文進行總結，并展望了未來工作。

1 相關工作

本節(jié)將從兩個角度出發(fā)，對已有研究工作進行系統(tǒng)總結。

1.1 GitHub數據挖掘相關研究

GitHub是眾多開源社區(qū)中影響力最高、參與者最廣泛、資源最豐富的一個，它在允許個人與組織創(chuàng)建、瀏覽公開的版本庫的同時，還提供社區(qū)化的軟件開發(fā)服務，這些服務包括允許用戶關注其他用戶，查看版本庫的改動、issue和評論等;除此之外，GitHub也提供供版本庫使用Wiki功能以及使用Git進行協(xié)同開發(fā)的功能。

由此可見，GitHub提供了一系列基于軟件開發(fā)的用戶行為數據以及軟件開發(fā)的數據，研究人員可以充分利用GitHub的數據進行一些數據分析;楊波等通過對GitHub上的開源軟件的開發(fā)過程進行分析，發(fā)現了開發(fā)過程中issue解決速度、issue增加速度等影響因素，并通過對這些影響因素關聯(lián)性進行分析，證明了某些影響因素之間確實存在了一定的關聯(lián)性，最后為基于GitHub的開源軟件的開發(fā)過程提出了一些建議[11];

葉培根等通過對GitHub開源項目開發(fā)過程的數據進行挖掘，對軟件開發(fā)團隊當前進展進行量化分析，從而能夠讓管理者通過量化分析結果動態(tài)掌握開發(fā)團隊的詳細情況，從而合理分批資源、安排開發(fā)任務，最終達到提高開發(fā)效率的目的[12];

楊春花等通過對GitHub上的項目的缺陷數據進行分析，設計了一套軟件缺陷數據預處理系統(tǒng)，通過使用該系統(tǒng)，用戶可以簡單方便的獲取GitHub上自己想要分析的項目等缺陷數據集[13];

盧松等通過對GitHub中的Pull Request數據進行分析，實現了一種基于信息檢索的代碼審閱人推薦的方法，達到了優(yōu)秀的結果，從而減少了大量的人力損耗[14];

Laura等通過對GitHub用戶的社交網絡進行分析發(fā)現，大規(guī)模分布式協(xié)作和開源社區(qū)的透明度具有非常高的價值，人們可以利用分布式協(xié)作提高自己的技術技能等[15];

Baishakhi等通過對GitHub上的軟件項目分析編程語言對軟件質量的影響，他們使用多元回歸建模和可視化文本分析，來研究語言特性軟件質量的影響，最終他們認為變成語言對軟件質量有一定對影響，同時這些影響主要是由項目大小、團隊規(guī)模和commit次數等因素為主導的[16];

Bogdan等為研究性別和職位多樣性如何與團隊生產力和人員流動率的關系，通過對GitHub的數據進行回歸分析和調查發(fā)現性別和職位的多樣性都是積極和重要的生產力預測指標，因此將這些結果告訴各個公司的決策層，從而在招聘和績效方面得到良好的結果[17];

Bogdan等還通過對GitHub數據進行分析，探討開發(fā)人員如何使用持續(xù)集成，以及貢獻類型（直接與間接）和不同的項目特性（例如：編程語言和項目時間）是否與自動構建的成功相關[18];

1.2 數據采集系統(tǒng)

要對數據進行數據挖掘，那么第一步就是收集數據，只有擁有了大量的數據之后才能夠對數據進行分析。

李海燕等為幫助用戶盡早在網絡中發(fā)現負面信息，設計了一套網絡輿情爬蟲系統(tǒng)，該系統(tǒng)利用ontology的抽取方式和基于HTML頁面結構抽取方式相結合的方法獲取網頁關鍵信息，同時利用Nosql的數據庫構建集群數據庫，并實時對爬蟲狀態(tài)進行狀態(tài)監(jiān)控，從而滿足了企業(yè)、個人、單位快速發(fā)現負面信息的需求[19];

為了企業(yè)、公司、個人能夠及時發(fā)現自己關注的話題，避免不必要的損失，葉婷等設計了一種基于關鍵詞的微博爬蟲系統(tǒng)，該系統(tǒng)對需求關鍵詞展開搜索，然后利用廣度優(yōu)先的爬去策略，解決了傳統(tǒng)爬蟲無法解決的動態(tài)頁面、垂直爬取和自動登錄問題[20];

網絡爬蟲在爬取數據時往往會因為數據提供商為控制訪問頻率對API進行一定限制，因此爬蟲系統(tǒng)經常會遇到API訪問受限的問題，為解決這個問題，盧楊、李華康等設計了一種基于P2P等爬蟲系統(tǒng)，該系統(tǒng)避免新浪API等功能連接限制，使用基于模擬登陸的方式，根據用戶地址位置劃分任務，實現連續(xù)高效的數據采集爬蟲系統(tǒng)[21]

李晨等為解決單機爬蟲效率低、擴展性差的問題，設計并實現了一個基于MapReduce的爬蟲系統(tǒng)，該系統(tǒng)利用HDFS和HBASE對信息進行存儲管理，利用相似度分析的去重策略提高心性能，最終比單機爬蟲的速度提高了4.8倍[22];

魏少鵬等為了應對目前網絡爬蟲實現過程復雜、使用不友好的問題，提出了一種基于Chrome擴展的爬蟲系統(tǒng)，基于Netty框架實現中央服務器模塊和主從庫復制模塊，同時引用Spring框架管理中央服務器類間依賴和提升爬蟲系統(tǒng)的可擴展性;從而達到提高爬蟲系統(tǒng)的友好度、可擴展性和可用性[23];

為了提高爬蟲的性能，開發(fā)者在開發(fā)爬蟲的時候希望爬蟲只爬取那些尚未爬過的數據，也就是常說的增量更新，張雷等因此設計一種分布式爬蟲系統(tǒng)，該系統(tǒng)由基于ZooKeeper的分布式服務、系統(tǒng)組件和數據庫三部分組成，同時利用協(xié)調組件Co-ordinator定時向任務隊列導入向任務，從而實現周期性增量更新[24];

2 系統(tǒng)設計與實現

2.1 系統(tǒng)架構

系統(tǒng)整體架構為如圖1所示，系統(tǒng)主要分為任務推送器和任務執(zhí)行器兩個大板塊，它們之間通過任務隊列和數據存儲進行連接和交互。任務推送器基于給定的采集需求生成采集任務并推送到任務隊列中;任務執(zhí)行器從任務隊列中取出采集任務，然后從GitHub社區(qū)下載目標數據并存儲到數據庫中;其次，任務推送器還會對由于網絡問題等未被成功執(zhí)行的任務重新生成新的任務以保證任務的完整性。

2.2 任務推送器

任務推送器共分為三個模塊：任務監(jiān)控器、任務生成器和狀態(tài)記錄器

2.2.1 任務監(jiān)控器

該模塊根據執(zhí)行器啟動的節(jié)點數和任務隊列中所剩余的任務數，來動態(tài)調整隊列中的任務數。具體的，我們采用智能輪詢方法，間歇性地觀測任務隊列狀態(tài)，當任務數量小于預定義的閾值時，任務生成器繼續(xù)生成任務并推送;當存量滿足預設條件時，任務生成器則進行動態(tài)休眠，休眠時間為：

在上面的式子中，返回的是剩余任務數，是預定義的任務數量閾值，即剩余任務數越多，任務生成器休眠時間越長。

2.2.2 任務生成器

對于用戶給定的項目列表或者已采集數據的列表，任務生成器會根據任務模板生成采集任務。以采集項目的Pull-request列表為例，用戶首先指定要采集的項目集合PRJS，對于PRJS中的任一元素，任務生成器會應用以下所示的鏈接模板：

“https： //api.github.com/repos/[% s]/pulls？page=[%d]&per_page=lOO&state=all&direction=asc”

該鏈接模板對應著GitHub官方提供的API，符號“？”前面的部分用于指定目標項目，后面的部分是參數列表，例如per_page指定每一次訪問返回Pull-request的數量，all表示所有狀態(tài)的Pull-request都需要被采集。其中“口”中的參數需要根據項目名字和采集進度指定。對于用戶來說，如果想要采集Pull-request的commit和diff信息，則需要根據系統(tǒng)的采集歷史把項目的名稱和Pull-request的編號分別應用到以下鏈接模板：

“https： //api.github.com/repos/% s/pulls/%s/com-mits”

“https： //patch -diff.githubusercontent.com/raw/%s/pull/%s.diff”

2.2.3 狀態(tài)記錄器

狀態(tài)記錄器負責記錄任務生成器和任務執(zhí)行器的歷史處理狀態(tài)。為保證系統(tǒng)的高可靠性，我們要求系統(tǒng)可以隨時關閉以及隨時啟動，并且再次啟動后可以正確地繼續(xù)之前的工作。一條任務生成后，有兩處可以停留的地方：一個是在任務隊列中等待任務執(zhí)行器執(zhí)行;另一個是在任務執(zhí)行器中被執(zhí)行。這兩部分的數據由于是在內存中，因此當采集系統(tǒng)停掉或重啟后會丟失掉。為恢復這些丟失的數據，任務記錄器采用”記錄一確認”（ Record-Then-Confirm，RTC）的策略。

如圖2所示，RTC隨時記錄任務生成器和任務執(zhí)行器以批處理形式進行的操作，當系統(tǒng)重啟后，RTC首先取出最近的狀態(tài)記錄，然后把任務生成記錄與任務執(zhí)行記錄進行比對確認，然后把那些被生成后但是沒有被成功執(zhí)行的任務重新放到任務隊列中再次執(zhí)行。

2.3 任務執(zhí)行器

2.3.1 采集節(jié)點

為提高系統(tǒng)的采集性能，我們設計了分布式的任務執(zhí)行器，具體的任務采集工作由分布式采集節(jié)點執(zhí)行。如前所述，任務生成器把任務推送到任務隊列中，而每一個采集節(jié)點從任務隊列中取出任務去執(zhí)行，并把執(zhí)行結果進行持久化。由于每一個節(jié)點都是從任務隊列中取任務，他們之間并沒有發(fā)生交互和依賴，因此分布式節(jié)點集群具備非常靈活和強大的擴展伸縮能力。根據用戶的需求，采集節(jié)點的數目可以隨時添加以加快采集速率。

2.3.2 數據抽取器

任務執(zhí)行器把采集任務完成后，獲得的往往是原始數據，例如json數據、html文本或者純文本數據等。為了便于后續(xù)的數據處理和分析，數據抽取器負責對原始數據進行解析和抽取。抽取方法采用的是基于規(guī)則的形式，用戶根據具體要求指定待抽取字段和相應的抽取規(guī)則。抽取規(guī)則可以根據原始數據的格式進行調整，如可以使用XPath對html文本進行抽取，而利用鍵值嵌套路徑對json數據進行抽取。

2.3.3 token池

GitHub為限制惡意訪問，會對訪問者單位時間內的API訪問次數做限制，使其不能發(fā)起過多的訪問請求，否則平臺會拒絕響應并返回錯誤信息。若想獲得更高的訪問頻率，GitHub要求訪問者必須注冊GitHub賬戶并申請認證token.并在每次請求訪問時都附帶上該token信息。認證token能夠大幅度提高單位時間內的訪問頻率，因此我們?yōu)橄到y(tǒng)建立了智能認證模塊。

如圖3所示，首先，系統(tǒng)維護一批可用的token并建立token池，每次采集節(jié)點要進行網絡訪問時都要從token池隨機取出一個token，使用完后立即放回到token池中。此外，為了保證token的有效性，智能認證模塊隨時驗證token是否處于可用狀態(tài)，如若檢測到不可用的token則立即刪除，使得token池中的任何一個token時刻保持在有效狀態(tài)。

2.4 數據中間層

任務生成器和任務執(zhí)行器通過數據中間層解耦合，中間層主要包括任務隊列和數據庫。

2.4.1 任務隊列

任務隊列通過消息隊列技術實現，消息隊列本身的一些原子操作特性保證了并行操作的有效性。就業(yè)務邏輯來講，本文中的數據采集系統(tǒng)相當于生產者一消費者模式。任務生成器相當于生產者，而任務執(zhí)行器相當于消費者。任務生成器的工作效率比較高，單節(jié)點模式基本可以滿足需求，而消費者的工作效率比較低，需要用分布式多節(jié)點技術來加速。基于消息隊列技術的任務隊列可以非常巧妙地支持這種一對多的工作模式，任務生產器專注于向隊列中推送任務，而執(zhí)行器集群以并行的形式有條不紊地從任務隊列中取出任務并執(zhí)行。

2.4.2 數據存儲

任務執(zhí)行完畢所獲得的原始數據以及抽取后的結構化數據都會存到數據庫中進行持久化。底層數據存儲方案采取的是關系型數據庫，圖4展示了以pull-request的提交信息和變更信息為例的數據模式圖。

2.5 輔助工具

2.5.1 配置管理器

配置管理器負責系統(tǒng)中的各種配置工作，例如數據庫鏈接、消息隊列啟動和連接、日志記錄路徑配置等。配置管理器作為單獨模塊，剝離了系統(tǒng)中與主要業(yè)務邏輯無關的工作，能夠提升系統(tǒng)的遷移能力，便于系統(tǒng)部署到不同的環(huán)境。

2.5.2 日志記錄器

日志記錄器負責記錄系統(tǒng)運行中的實時狀態(tài)，例如對系統(tǒng)中關鍵節(jié)點的異常情況的記錄。完備的日志記錄是評估系統(tǒng)性能并進行針對性改進的重要前提，也是監(jiān)控系統(tǒng)運行狀態(tài)的有效數據源。

2.5.3 系統(tǒng)監(jiān)控器

系統(tǒng)監(jiān)控器以可視化界面直觀地展示系統(tǒng)各模塊的運行狀態(tài)。如圖5所示，結合進程運行狀態(tài)和日記記錄，系統(tǒng)監(jiān)控器能夠顯示各模塊是否處于正常運行狀態(tài)以及模塊的進度情況。此外，界面還提供了一些常用的交互功能，以允許用戶方便地執(zhí)行相關命令，如啟動或者停止某個模塊、動態(tài)增加或者減少采集節(jié)點的個數等。

3 系統(tǒng)評估

3.1 實驗環(huán)境

硬件：雙核3.6 GHz，8GB內存;運行操作系統(tǒng)：Ubuntu 16.04;單機限制帶寬：IOOMB。

3.2 評估結果

3.2.1 資源占用率評估

實驗過程中，我們對任務執(zhí)行器分別運行了單個節(jié)點、5個節(jié)點和10個節(jié)點，并對比了它們的資源占用情況，其對比結果如下表所示：

通過表1我們看出，系統(tǒng)對資源的占用非常低，平均每個任務節(jié)點在服務器上占用的CPU資源和內存資源的比例分別為1%和1.2%左右。由此可見，系統(tǒng)僅需非常低的資源配置，在網絡條件良好的情況下就可以正常運行，降低了系統(tǒng)對硬件配置的需求;與此同時，隨著任務節(jié)點的增加，系統(tǒng)對服務器資源的需求是線性增長的，由此沒有為系統(tǒng)增加額外的負擔，說明系統(tǒng)的穩(wěn)定性是良好的。

3.3 采集速率評估

實驗測試中，我們分別在單節(jié)點、5個節(jié)點和10個節(jié)點的情況下讓系統(tǒng)運行5小時，采集效率如圖6所示，從圖中我們可以看出，每個節(jié)點每小時采集的平均任務數量為1600個左右，該速率能夠較好地滿足用戶的實際需求，同時又能夠以一種友好的方式對目標網站進行持續(xù)采集。而且，隨著任務節(jié)點數量的增加，爬蟲系統(tǒng)的采集數量以線性遞增，說明各個任務節(jié)點互不影響，系統(tǒng)能夠保證在多個任務節(jié)點的情況下穩(wěn)定爬取指定的資源，由此可見系統(tǒng)的穩(wěn)定性以及魯棒性是良好的。即采集系統(tǒng)可以在保證系統(tǒng)穩(wěn)定性的前提下通過啟用多個任務節(jié)點來快速獲取指定資源的目的，從而滿足用戶的任務需求。