第三章 系統設計與架構
3.4 深入推特資料搜集
3.4.2 使用具資源感知性之 Access Token Pool 進行效率化推文搜集
除了以 Streaming API 來搜集當下的推文外，更多的時侯，我們需要回朔目前時 點前的推文。
Streaming API 的使用我們只需要確保 Access Token 是合法且能通過推特 OAuth 驗證，即可進行資料的搜集，但它只能提供現在這個時點(含)以後的推文 資料；在另外一方面，使用 Search API 時我們除了要考量到 Rate Limiting 的問題 外，同時也需認知到 Access Token 數量是有限的，不可能無限地增加，因此，要 Token Pool 的概念，即將系統上所有的 Access Token 集中控管在一個 Token Pool 裡，並依循一動態調整機制，將可用的 Token 分派給推文搜集工作，讓每個工作
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
52
遠的等待，俾利研究人員能快速地發現有效的查詢關鍵字。圖 3. 19 納入比較準 則中的工作執行。，可用的 Token 數量小於設定工作的數目時(以下所提及之工 作皆為使用 Search API)，搜集程式會定期按使用者設定之比較準則來選出效能最 差的工作再將它停止，然後從等待佇列中取出一個等待執行最久的工作來加以執 行。
圖 3. 19 納入比較準則中的工作執行。
另外，在推文搜集方面，亳宅服務群所需執行的工作共分兩種，一為執行 使用 Search API 的工作，一為執行使用 Streaming API 的工作，使用 Streaming API 我們僅需要確保同一個時間內，只會有同一組 Access Token 被用做 Streaming API 的認證即可，然而在 Search API 的使用，卻有相當多種不同的設定可調整，Search API 的特性是搜集【過去】的推文，倘若我們不使用任何的參數，推特最多只會 回應 100 筆最新的推文，假設每次請求間沒有任何新推文出現，則下一次請求所 回覆的推文，將還是完成一模一樣的 100 則推文，也就是該次的推特 API 請求其 實是完全沒有任何效果，徒然浪費珍貴的 Rate Limiting，這樣會導致推文搜集的 不具效率，同時也無法達到獲得最多歷史推文的目標(以目前使用推特 API 的經
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
53
驗而言，推特最多可回覆 7 天前61，的推文，若無法即時地將最舊的歷史推文搜 集下來，隨著時間的經過能獲得的歷史推文將會愈來愈少)。
然而，若在事件不斷的發生下，不使用任何參數的搜尋方式，理應可以有效 地獲得最新且最大量的推文(假設新進推文的速量大於推特不再回覆的推文數量)，
換句話說，搜尋的方式是因時地制宜的，因此在使用 Search API 上，除了基本的 關鍵字設定外，我們還開放了往前(以獲得最新推文為優先)及往後回朔(以獲得歷 史推文為優先)的選項供使用者設定，另外為了讓使用者能更為細緻地調整搜尋 選項，同時也開放【level】的調整，即往前或往後要鑽的多深的程度，設定愈深，
理論上可搜集到的推文會愈多，但對於 Access Token 的 Rate Limiting 之消耗也將 愈快速。
圖 3. 20 使用 Search API 進行推文的搜集。
錯誤! 找不到參照來源。，可善加利用推特開放的 max_id 或 since_id 搜尋選 項來更有效率的搜集推文。在往後回朔搜集時，我們會設定 max_id 為所搜集到 的推文中最小的推文 ID，當進行 Search API 請求時，推特會回給我們最小的推文 ID 以前之推文，另外在實證上發現，若在歷史的推文數量眾多時，需要限定發
61 推特 API 能回覆的歷史推文從最早期的 2 週前，到約 10 天前，到目前為已限縮至 7 天前的推 文。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
54
推文的日期範圍(在此我們設定 until 的日期欄位)，才能更抓到更多的歷史資料。
在往前搜集的設定，我們會設定 since_id 為所搜集到推文中最大的推文 ID，則推 特會回應大於該 ID 的推文，達到搜集到極大化的最新推文之目的。
其中值得注意的一點是，在使用 max_id 或 since_id 的同時，我們必需要記住 上一次 API 回覆推文之最大或最小的推文 ID，以供設定下一次 API 請求的搜尋選 項，俾利推文的搜集能鑽的愈深或爬的愈高，此外，在推特回覆的推文已達其現 階段回覆的上限時，如已回朔到所有 7 天前的推文或真的沒有任何歷史的推文可 回覆時(推特回覆的推文少於 100 則或回覆的推文全部為重覆的推文)，此時我們 應該要將 max_id 或 since_id 重設為初始值，再發送新的 API 請求(即不帶任何搜 尋選項)。
同前文所述的，這樣的動態調整機制是因時地制宜的，也就是說，可能在一 開始我們需要先用盡全力的將珍貴的歷史推文給搜集起來，然後搜集的方針需轉 變為以最新的推文優先，在此我們也提供 On the fly 變更的模式，讓使用者能更 為細顆粒的進行推文搜集的調整。錯誤! 找不到參照來源。
圖 3. 21 On the fly 推文搜集方式的調整。
另外，為了要降低 Rate Limiting 對推文搜集之影響，我們在 Search API 的使 用上(search/tweets)，採用 Application Only 的認證模式，可以將 Rate Limiting 從 原先 Per User 認證下每 15 分鐘 180 次的 API 請求，提升到 450 次。