我在臉書上說:
在之間提了很多次, 也規劃很多次計劃, 想要解決這樣的問題, 做出一個媒體觀察與使用者建議的系統, 但最後都不了了之, 因為這邊有幾個困難點:這個系統源自於 2007/2008 年樂生事件給我很大的感觸, 當時透過 Plurk/Facebook 等 SNS 收到資訊, 覺得整個世界被樂生洗版, 但事實上對大部份的民眾是完全不知道這回事, 一直等倒 2008/2009 因為選舉關係主流媒體批露才被大家知道, 此時發現 SNS 會造成資訊獲取很大的謬誤.
1. 要搜集各個新聞平台的內容資訊做分析
2. 要能夠計算了解到讀者怎看這新聞
3. 要有以新聞字詞為主的語意網路
單單這三點都不是一個小系統, 甚至又是一個可以獨立為 Big Data 專案的事, 而事實上像這樣的系統, 一開始的系統分析就往往跟你習慣的方式不太一樣.
Big Data 的很多 V 其中有兩個是 Variety (多樣性) 與 Veracity (真實性), 通常在系統規劃中, 最常遇到的就是開 Spec (規格), 但由於 Big Data 的資料源本來就是來自於各個地方, 與其說有 Spec 還不如在面臨成千上萬個 Spec 中, 你不可能定義出一個準確的規格書? 不要說拿不到, 事實上也不存在 (每天都有人在變動), 即使你以為很單純的東西, 事實上沒那麼單純.
這跟一般人在做軟體不一樣, 甚至在做網站也不一樣, 在這個如此多元的資料格式, 不穩定的資料源來實作, 若沒有去接觸真實的資料端, 很難去了解與面對這資料的困難度與複雜性, 且加上這系統本身應該是由資料開始去規劃, 然後往想要解決的目標去進行, 在某方面是這種 Down-Top 的設計思維, 須要的是 "實作的能力" 以及 "目標的認知".
在這實作的經驗中, 我把過程分成幾階段:
搜集資料: 如何透過公開內容去搜集與建立字詞資料庫, 如何透過 API 去抓使用者資料, 這些不只要面對 "格式", 更要解決 "方法", 其中還有一個可怕的環節: "臉書最難捉摸的API" 可以說是被這事折騰了很久.
儲存資料: 在某方面, 這是須要很多 Know-How 的, 但相對的也是較為單純的, 因為通常儲存資料都是在自己這邊, 選擇那些資料庫, 那些儲存與讀取方法雖然是跟系統有關, 跟資料使用方式有關, 只要有經驗問題都不大.
除錯資料: 如同前面所說的, 格式來源都不穩定的情型下, 如何判斷那些資料是正確的, 尤其在 Big Data 中, 最須要的是 "Aggregation", 也就是聚合, 把相同點找出來判讀成一件事, 例如要找出那些網址事實上在說同一件事, 這在實作過程中是遇到最多的調整工夫.
計算資料: 通常說計算資料有時候是最簡單的, 因為這些 Know-How 只要多看幾本書就可以了, 尤其是在模型的判讀, 選擇與檢核要有能力, 但這也是最吃能力的, 因為沒有選對好的演算法與模型, 很多事情都很難真的準確, 我也還須要在這方面有更多的學習.
呈現資料: 這呈現資料不是單純的 UI, 或是 Visualization, 還包含資料在不同的使用情境, 須求有不同的觀點, 在這系統我實作了不少方式, 但最後也有發行後發現更好改善後放棄的, 也就是說 Presentation 呈現是面對 Scenario 情境多元時要如何選擇這議題, 這也是系統最後功能決勝點.
解讀資料: 有時系統做出來時, 會出現超乎你預期的結果, 有些可能是單純有 Bug 錯誤, 有時是演算法不夠解讀, 但更有可能的是必須在透過人的解讀中, 找到新的發法或開發新系統, 這也是所謂 Data Scientist 的能力差異之一.
在經過這幾個 Data 環節中, 一步步往目標前進, 單單這個系統, 離最初的命題大概是 100 分中已完成 3~4 分, 也就是連 5% 都還不到, 雖然現在已經做到一件很重要的事:
"已經知道台灣臉書熱門的話題是那些"
雖然這成就已經解開, 但也至少要有 20 個以上的成就解開才勉強可以道白金殿堂吧, 加油吧, 林克....
後記: 本來覺得這是老生常談, 類似的觀點已經寫不只三次了, 但看到 CK 一直在寫相關文章, 尤其是這篇 "資料分析的三個層次", 看了我有很大的感觸, 因為要完成這樣的事情, 真的須要 Read the Data, Read Between the Data, Read Beyond the Data 的能力阿.
沒有留言:
張貼留言