線上系統與分析系統對數據效能的不同需求

前面兩篇以系統的觀點分享數據系統儲存與傳輸資料的格式。今天我想分享我對數據分析所使用的格式的看法。 以系統的觀點,資料很自然的是一筆一筆做處理的。這是因為系統在收到一筆資料(Bid Request)之後,是要很快的做反應的(我要出標嘛?要的話出多少錢?)。因此,系統的觀點通常在追求我們對單一筆資料的處理時間。舉例來說,RTB系統都會即時監控平均每一個bid request的處理時間(主管希望系統平均的處理時間在0.05秒以下)。 然而在分析數據時,處理完一筆並沒有太多意義,而是要處理完全部的數據。因此,分析的觀點通常在追求我們處理整體資料的時間。舉例來說,一天有86400秒。如果用和線上系統相同的方式做處理, »

能應付變化的資料格式(續)

在專案的開始,我們選擇json作為資料的格式後,慢慢的也體驗到這個選擇的問題了。 在其他工具上的效能問題 json雖然在nodejs上非常方便,讀取與寫入的效能也很棒,但是當我切換到其他工具時(例如R或java),json就不這麼方便了。 舉例來說,如果我們把上一篇的範例資料重複10000次之後(產生一個共40000行json的檔案),在我的電腦上使用nodejs讀取只需要1.7秒,但是使用R的jsonlite::stream_in卻需要27.2秒,效能差很大。 就我所知,nodejs在處理json資料上做了很多優化,所以效能很高(差不多和protocol buffer一樣快)。但是其他工具處理json就慢多了。 彈性太大導致執行期的錯誤 »

能應付變化的資料格式

在專案進行中,我們需要決定資料格式。 一開始,我們採用json作為資料的傳輸格式。主因是我們串接的SSP也都是使用json作為資料交換的格式,另一個主因則是我們的服務是使用nodejs架設的,後端串接mongodb。這樣的架構下,選擇json作為儲存資料的格式是非常自然的。 另一方面,json使用起來非常的自由,當我們需要任何新的資訊時,可以直接變更資料。但是隨著專案的成長,這樣的自由也帶來了維護的挑戰。等到之後,我想再向讀者分享我的看法。這裡我先分享使用json做資料格式的心得。 由於公司指派支援的工程師很忙,所以我不期待能夠建構一個Hadoop/Spark Cluster來進行資料分析,而是以節省工程能量的方式做分析。 在以下的內文中,我拿Smaato的範例資料為例做解釋。 讀者想練習的話, »

資料系統的挑戰 --- 專屬的工程能量

我在剛開始工作時,公司讓一名很忙的工程師與我搭配。主管說:「你就開需求,看要收集什麼資料,讓工程師來收集吧!」 這是很標準的工程面的想法:確定需求、開發、驗收。 但是在分析數據時,我們其實是一直在嘗試各種錯誤: 也因此,在該名工程師完成第一版之後,我很快地提出第二版的需求。但是因為他也有許多其他重要的工作,而我卻無法肯定我的工作的重要性(大部分的想法其實是失敗的),所以很快地,我們的合作就無法滿足我的工作需求了:我只能一直等該名工程師有空的時間。短期的修正還好,但是一些大的更動,往往一等就是數個月。畢竟其他的需求都是確定性的需求,但是我這裡的需求往往是不確定效用的, »

從Data Engineer、Data Architecture到Data Science -- 序言

今年我因緣際會,得到一個在start up 中建構RTB(Real Time Bidding)的廣告即時競標系統的職位。憑藉著過去的經驗,我一直很期待能依照自己想法打造資料科學團隊的機會。原先我以為這個職位能帶給我這樣的機會,只是人算不如天算,最後變成了單打獨鬥的狀況。 但無論如何,這裡的主管還是給予我足夠的信任,放手讓我從建構出標系統,做到後端的機器學習。於是我能實現自己對數據系統的想法,並獲得了驗證。我也把單兵作戰視為一個巨大的挑戰,但是在利用Google Cloud Platform來放大自己的工作能量之後,我終於能運用少少的人力處理小小的數據(目前一秒大概千筆資料上下,實在不敢說大) »