第三章 系統設計與架構
3.5 實作推特資料搜集之服務群
3.5.4 守衛(Guardian)
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
62
塞線程的機制。圖 3. 27 一個生產者(管家)與一個消費者(房務員)的模式。
圖 3. 27 一個生產者(管家)與一個消費者(房務員)的模式。
目前本系統提供三個 Token 最佳化的選項供終端使用者設定，分別為以下的 三種：
1、推文量：即以每個工作所搜集的推文數量為比較基準，搜集到愈少推文的工 作視為愈無效率的工作。
2、成長率：以(第 2 次搜集到的推文量−第 1 次搜集到的推文量)
第一次搜集到的推文量 之比率為比較的基準，比率愈
低視為較無效率的工作。
3、斜率：以第第22次搜集到的推文量次搜集的結束時間−−第第11次搜集到的推文量次搜集的結束時間之比率為比較基準，比率愈低視 為較無效率的工作。
除了動態 Token 的調整外，房務員也肩負了定期監控是否有新的 Token 可用 時的任務，如終端使用者新增了一個新的 Token，則當房務員發現它是可用的時 候，即會從櫃台等候區的佇列中取出等最久的工作，發送開始執行工作的訊息到 暫存區裡。
3.5.4 守衛(Guardian)
守衛，顧名思義它主要是負責監控推文搜集服務群的狀態，在這裡我們將它設計 為一個守護(Daemon)線程，即當系統上沒有其它的執行序在運行時，守衛即會停 止工作，如此可以確保這個執行序永遠都是最後一個結束。另一方面，在每一輪 的監控任務時，除房務員這個定時啓動的線程外(由其自身於每次啓動時更新執 行的狀態)，它會將所有服務群成員的線程狀態，定期地更新到資料庫中，俾利
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
63
使用者的監控與管理。圖 3. 28 守衛線程之前端監控介面。
圖 3. 28 守衛線程之前端監控介面。
綜合本章各小節所述，推文資料搜集服務群的導入，可以有效地將前端使用 者介面的展現與後端系統的核心邏輯加以區隔，如此不但可以增加程式的穩定性，
也對於未來的維護與更進一步的發展有相當大的助益，另外，動態調整機制的採 用，不但可以在同一段時間內同時進行不同推文關鍵字的搜集，也可以讓推文的 搜集與最適關鍵字的發掘更有效率。
‧
個案 1 背景：烏克蘭危機(Ukraine crisis)起因於 2013 年底烏國總統亞努科維 奇拒絕簽署與歐盟的經濟合作協定造成的反政府示威，到了 2014 年 2 月底情勢
“Eastern Ukraine” “Eastern Ukraine”
Russia sanction Obama Putin
表 4. 1 個案 1 多個與單一關鍵字實驗。
‧
地有新的推文被發送出來。其中針對 Eastern Ukraine 關鍵字採用推文內容需完全 符合的搜尋方式，Russia sanction 及 Obama Putin 則是設定搜集推文內需有上述 關鍵字出現即可。‧
我們對採用單一關鍵字，Eastern Ukraine，進行了 50 分鐘的推特資料搜集，而三 個分別針對可能與該事件有關的關鍵字，Token 的動態調整模式設定為依搜集推
“Eastern Ukraine” 103/200 “Eastern Ukraine” 283/21992 Russia sanction 100/200
Obama Putin 175/13900
表 4. 3 個案 1 實驗結果。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
67
媒體的，如 NBC63、WashingtonPost64等，圖 4. 1 Eastern Ukrain 推文引用網域統計。
圖 4. 1 Eastern Ukrain 推文引用網域統計。
而在地理資訊分析下，我們也可以很明顯的發現推文大多數是發自歐美國家，
尤其是美、英兩國占有接近 5 成的比例，圖 4. 2 Eastern Ukraine 國別分析。符合 一般認知西方國家對於歐洲事務相當關切的預期。另外，在多關鍵字搜尋並使用 Russia sanction 這個關鍵字，在地理資訊分析下，我們很驚訝的發現有超過 6 成 的推文是從印度所發送出來的，相當值得研究人員更進一步的探索。
63 http://www.nbcnews.com/
64 http://www.washingtonpost.com/
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
68
圖 4. 2 Eastern Ukraine 國別分析。
圖 4. 3 Russia sanction 推文國別分析。
回到個案 2，發生在台灣的太陽花學運，該事件已於 2014 年 4 月中旬暫告一 段落，在單一關鍵字的推文搜集上，我們採用【太陽花學運】為搜尋關鍵字，實 驗時間 40 分鐘。在多關鍵字且採用 Token 動態調整機制中，除了【太陽花學運】
這個關鍵字外，我們還針對此波學運的主要領導人及學運期間的重大事件之發生 地點進行推文的搜集，實驗時間 40 分鐘，並皆設定欲搜集推文資料的區間為在 2014 年 5 月 7 日之前，最後其實驗結果如表 4. 4 個案 2 實驗結果。
多關鍵字，推文數/
推特回應筆數
單一關鍵字，推文 數/推特回應筆數 太陽花學運 100/300 太陽花學運 100/11100
林飛帆 OR 陳為廷 OR 魏楊
100/200
占領立法院 OR 占 5/1200
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
69
領行政院
表 4. 4 個案 2 實驗結果。
由於太陽花學運已經告一個段落，故一開始我們就估計能搜集到的推文數量 將不會太多。其次，從實驗結果可以發現，在關鍵字均為【太陽花學運】的情況 下，單一關鍵字搜尋所搜集到的推文與相對被分配到較少時間的多關字搜尋所得 到的推文數量其實是完全相同(100 則)，從這裡我們可以推論為若對已落幕的事 件進行歷史推文搜集(我們將搜尋的區間設定為 2014 年 5 月 7 日前)，在該日的 推文量有限的情況下，搜尋的時間並不會與能搜集到的推文數量呈現完全地正相 關。另外，從表 4. 4 個案 2 實驗結果。所示，採用多關鍵字搜尋確能挖掘出更多 的推文，換句話說，即便是事件發生後一段時間再進行研究，我們仍然有相當的 機會，找到最佳的搜尋關鍵字。
在另外一方面，我們可以從所搜集到的推文之每日推文量/推文人比例圖，
發現目前推特只回應 4 天的推文歷史資料，若將實驗日 5 月 8 日也計算進去，推 特 API 可回應約 5 天左右的歷史資料，這樣的結果比我們從網路上搜集到推持 API 使用者宣稱的一周還要來的少。
圖 4. 4 個案 2 每日推文量/推文人比例圖。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
70
在推文內容引用網址之網域統計下，似乎是因為事件的起源是屬學生及公民 團體，故推文所引用的網址前三名分為別 Plurk、想想台灣65以及自由時報，社群 媒體占第一位，而主要的帄面媒體反而位居於第三位；即便在多關鍵字搜尋下，
以學運主要領導人為關鍵字的推文引用網域統計，亦可以看到社群媒體占了相當 重要的角色。圖 4. 5 個案 2 太陽花學運推文引用網域統計。圖 4. 6 個案 2 太陽花 學運主要領導人推文引用網域統計。
圖 4. 5 個案 2 太陽花學運推文引用網域統計。
圖 4. 6 個案 2 太陽花學運主要領導人推文引用網域統計。
在地理資訊分析方面，由於本事件是屬台灣的國內事務，有超過 7 成比重的
65 http://www.thinkingtaiwan.com/
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
71
推文是在台灣本島所發布出來，更有 9 成以上的推文分布在台灣、日本、中國及 美國，符合我們一般的認知。圖 4. 7 個案 2 太陽花學運推文國別分析。
圖 4. 7 個案 2 太陽花學運推文國別分析。
4.3 比較本帄台與 YourTwapperKeeper 之推文搜集
YourTwapperKeeper66是一套免費的開放原始碼的推文搜集帄台，使用 PHP、
Apache 及 MySQL，是研究人員在使用付費推文搜集帄台外的另一個選項。唯其 帄台的設計一次僅能設定一個 Access Token(即當有多個工作時，勢必需要共同分 享唯一一個珍貴的 Access Token)，同時使用者介面的設計亦較為陽春，本節將針 對 YourTwapperKeeper 與本帄台在推文的搜集上，進行實證的比較與分析。
4.3.1 個案設計
本小節將會從國內發生的事件與國外發生之事件中，分別設計不同的個案，來比 較本系統與 YourTwapperKeeper 的異同。
個案 1 背景：台北捷運隨機殺人事件發生於 2014.5.21 下午 16:22 至 16:26，
兇手為當時就讀於東海大學環境工程學系二年級的鄭捷，案發當日的下午，趁著
66 https://github.com/540co/yourTwapperKeeper
‧
實驗方式：本系統與 YourTwapperKeeper 分別設定不同的 Access Token，搜尋關 鍵字均為【鄭捷】，同時進行 30 分鐘的推文搜集，同時，本系統設定推特 API 請求周期為 30 秒，使用推特 Search API 設定進行往後且搜尋深度最深(即歷史資 料優先)的推文搜集。
個案 2 背景：烏克蘭危機，背景同 4.1 節個案 1。
目的：搜集與烏克蘭危機相關的推文(本事件於實驗時仍持續發生)。
實驗方式：本系統與 YourTwapperKeeper 分別設定不同的 Access Token，多個搜 尋關鍵字分別為【Ukraine】、【Crimea】及【Putin】，同時進行 30 分鐘的推文搜 集，同時，本系統設定推特 API 請求周期為 30 秒，使用推特 Search API 設定進 行往後且搜尋深度最深(即歷史資料優先)的推文搜集。
4.3.2 比較與分析
本小節將先從單一關鍵字推文搜尋的結果，比較本系統與 YourTwapperKeeper 的 差異，再從多關鍵字的推文搜尋進行更深入的比較與分析。
FloodFire YourTwapperKeeper F Delta Y Delta 0~5 分 1912 1490 1912 1490
‧
由表 4. 5 本系統與 YourTwapperKeeper 搜尋關鍵字鄭捷推文搜集結果。中可 非常的明顯地發現，本系統所能搜集的推文數量，以 1.13 倍之頗相當大幅度地 頻率遠高於台灣，故理應可對本系統與 YourTwapperKeeper 效能的差異做出更為 具體的比較。
‧
FloodFire YourTwapperKeeper F Delta Y Delta
5 5738 2667 5738 2667 點是，本系統在前 10 分鐘內搜集多數的推文，YourTwapperKeeper 則是集中在第 一個五分鐘，爾後的推文搜集量均相差不多，在此可以推論，本系統在歷史資料 的搜集能力較為強大下，需花費較長的時間(約 10 分鐘)才能將可搜集到的推文 給完整地搜集下來，然而 YourTwapperKeeper 則開始分神於較新推文的搜集。圖 4. 9 本系統與 YourTwapperKeeper 綜合三個搜尋關鍵字的總搜集推文量趨勢比較。，可發現 YourTwapperKeeper 的資料搜集較為的線性，本系統則會先呈現高仰角的 趨勢再回到帄緩的曲線中。圖 4.10 到 4.12 分別展現出本系統與
YourTwapperKeeper 在【Ukraine】、【Crimea】及【Putin】關鍵字下所搜集到推 文數量之比較，我們可以證明本系統在歷史資料搜集方面具有絶對的優勢，
而在新推文的取得方面，由於推特一次回應的數量最多不超過 100 則推文，
理論上兩系統不會有太過明顯的差異。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
75
圖 4. 9 本系統與 YourTwapperKeeper 綜合三個搜尋關鍵字的總搜集推文量趨勢比較。
圖 4. 10 本系統與 YourTwapperKeeper 在以 Ukraine 為關鍵字的推文搜集趨勢比較。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
76
圖 4. 11 本系統與 YourTwapperKeeper 在以 Crimea 為關鍵字的推文搜集趨勢比較。
圖 4. 12 本系統與 YourTwapperKeeper 在以 Putin 為關鍵字的推文搜集趨勢比較。
‧
在系統核心邏輯的推文搜集上，我們提出了【豪宅服務群(Mansion Household Service)】的概念，在推特目前仍對其 API 的呼叫有 Rate Limiting 之限制，以及在 假設 Access Token 是相對珍貴稀少的情況下，透過服務群四個隨從(minion)，門 房、管家、房務員及守衛的分工合作，可以在前端使用者設定的工作大於目前擁
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
78
1、事件與工作的核心設計理念。
2、訊息趨動的觀念。
3、模型、視圖與控制器(MVC)之設計模式。
3、模型、視圖與控制器(MVC)之設計模式。