經驗分享：如何提高機器學習數(shù)據(jù)采集的效率

在新的一年里，很多人都在思考如何利用機器學習（ML）算法來提高產品或服務的質量。
PredictionIO公司與許多公司合作，部署他們的第一個ML系統(tǒng)和大數(shù)據(jù)基礎設施。PredictionIO總結了數(shù)據(jù)收集任務中的一些好的實踐，并愿意與你分享這些經驗。
如果你正在考慮采用ML，以正確的格式收集正確的數(shù)據(jù)，將會降低你的數(shù)據(jù)清理工作以及數(shù)據(jù)浪費。

要收集所有數(shù)據(jù)
收集所有數(shù)據(jù)是非常重要的。除非你真正訓練一個預測模型，否則你將很難知道哪個屬性哪些信息具有預測價值，并提供最好的結果。 如果一條信息沒有收集到，我們就沒有辦法獲取它，并永遠地失去它了。存儲成本的低廉，也使得你可以收集一切與你的應用程序、產品或服務相關的數(shù)據(jù)。
這里有兩個例子：
    在產品推薦中，收集用戶標識符、物品（即產品）標識和行為數(shù)據(jù)包括評分是非常重要的。 其他相關屬性，如類別、描述、價格等數(shù)據(jù)，對于推薦模型的提升也是有用的。隱含的行為，如意見，可能比顯性評分更加有用。
    在預測泰坦尼克號乘客的生存上，我們憑直覺知道，乘客的年齡、性別等屬性和結果是有關聯(lián)的。 其他屬性如船上兒童的數(shù)目、車費和客艙可能是也可能不是有用的信息。在你開始建立預測模型之前，你很難知道哪些方面將會對預測最有價值。
存儲日志是一種常見的解決方案;他們以后可以提取、轉換和加載來訓練你的機器學習模型。
每個事件的時間戳
每個事件的時間戳都是很重要的，尤其是對于用戶的動作或行為數(shù)據(jù)來說。時間戳能夠阻止我們在構建機器學習模型時出現(xiàn)先窺偏差(Look-ahead Bias)。
PredictionIO提供支持最佳實踐的Event Server或“基于事件的風格”收集數(shù)據(jù)。這意味著一切被視為有時間戳的事件而收集，不管他是一個用戶（例如“Sarah Connor”），一件物品（例如“終結者”），或者一個用戶對物品的操作（“Sarah Connor查看終結者“）。
舉個例子，創(chuàng)建用戶Sarah Connor：

注意，entityId我們使用了通用唯一標識符（UUID），而eventTime我們使用ISO 8601的格式。
保持屬性一致性
使用一致的屬性值。如果性別使用了“Female”，最好往后保持使用相同的符號，而不是以“F”或“female”或“girl”來替代。 當你刪除了一項特征，你應該將之從訓練集之中排除。你可以清理與該特征相關聯(lián)的數(shù)據(jù)并重新導入。 當您添加一個新的特征，回填字段的默認值是重要的。
避免序列化和二進制
在Event Server 中，“屬性”區(qū)域允許任何形式自由的JSON對象。為了方便，我們可以存儲一個轉義JSON字符串作為該區(qū)域之一。 然而，序列化可能會混淆數(shù)據(jù)，使之變成一個不可用的點。舉例如下：
錯誤的代碼:

正確的代碼 :

可能的例外是當序列化大幅降低存儲空間時。例如，你可能希望使用Protocol Buffer來存儲數(shù)據(jù)，并把它們作為二進制字符串序列化。 這樣做可以節(jié)省5倍的存儲空間，但它會使你的數(shù)據(jù)不可解析。更糟糕的是，如果你失去了你的消息定義文件，數(shù)據(jù)將會永久丟失。 除非你的數(shù)據(jù)大小有谷歌或亞馬遜那樣的規(guī)模，不然這可能不值得。
查詢時間
大型數(shù)據(jù)集的查詢是耗時的工作。PredictionIO Event Server 通過（entityId，entityType）索引數(shù)據(jù)。 如果你想有效地查詢，根據(jù)你的需要選擇“entityId”和“entityType”。
使用隊列服務
建議使用消息隊列機制將事件數(shù)據(jù)傳遞到Event Store。如果Event Store暫時不可用，消息將駐留在隊列中，直到它被處理。 數(shù)據(jù)不會丟失。
我們希望這篇文章對你有用。如果你有其他的技巧或者其他的問題，請在評論中與我們分享！