Apache Spark在大規模分布式自然語言處理的應用

d2dn 9年前發布 | 17K 次閱讀 分布式/云計算/大數據 Apache Spark

 Apache Spark在大規模分布式自然語言處理的應用

 

我們TripAdvisor公司擁有大量的用戶評價數據,據最近的一次公告,大約有幾億條。我是從事機器學習相關的工作,在機器學習中我們常喜歡做的一件事就是堆砌大量數據來分析。

最近我一直在研究一個有趣的問題,我想給大家介紹一下。在這篇博文里,我先會引入問題,以及解決它的技術支持手段。在后續的博文里,我將深入剖析算法 本身。如果你最近瀏覽過Tripadvisor網站,也許會注意到我們給站點內的賓館、餐廳和景點都貼上了不同的元數據標記(我們稱之為標簽)。其中一些 是我們從各種數據源搜集的簡單是非問答結果。如“這家賓館是否提供游泳池?”,“這是一家意大利餐館嗎?”等等。

如果有可靠的數據源,這些信息對我們很有幫助,可是如果沒有呢?也許在世界的某個角落你始終無法獲得可靠的數據源(畢竟我們的業務遍布全球)。有時候 又會遇到主觀性問題,像“這是個浪漫的賓館嗎?”所有的賓館經理可能都給出一個肯定的答案。顧客卻不一定這么認為。那么該如何對付這些問題呢?其實,當你 擁有像我們這么優質的客戶基礎時,你直接問他們就夠了。這段時期,我們一直讓用戶在“發表評價”的表格最后或者其它地方再回答一些簡單的是非題。平均每個 評價里,用戶能回答三個問題。這些答案對我們來說是非常有用的,同時也能惠及站內的其它用戶。

最近,我正在努力挖掘這些答案的最大潛在價值,這個項目被稱之為“自動貼標簽”。任何時候如果對用戶的答案沒有把握,你可以直接去詢問用戶那些問題, 但這會浪費他們時間,結果的覆蓋率也有局限性。為了避免上述情況,我們基于自然語言構建了回歸模型,來預測用戶對每個問題回答“是”或者“不是”的概率。 這樣我們只有在給出所有數據仍不能確定用戶答案的時候才去詢問他們。

具體說來,就是當用戶在填寫評價表時,我們嘗試在見到用戶填寫的內容前,去預測該用戶對給定的貼標簽問題回答“是”的概率值。注意,這與看到評價表的 內容再做預測是有區別的。因為我們不是想預測當前這位用戶是否度過了一個浪漫之夜,亦或賓館是否給他們帶來了家的溫馨感覺。我們是想知道下一位客戶是否在 這家賓館能有上述那些體驗。我發現當人們經歷一段非常浪漫的時光后,他們就會基于自己的體驗給賓館一個浪漫的標簽,而不在意賓館的其它方面品質。通過預測 某個特定地區的贊成投票比例,我們能平滑這種噪音的影響,從而得到對某個賓館、飯店、景點的浪漫程度、溫馨程度等方面的客觀預測。

我們采用半監督形式的邏輯回歸來處理這個問題。模型主要包含“詞袋”類型的特征,來自用戶提交的對于賓館各方面的文字評價。由于它屬于一種半監督方 法,所以我們不僅用帶有標簽的地點評價數據訓練模型,還使用了大量未標記的數據。另外,在實際應用模型預測最終結果時,我們還需要讀取和處理所有評價記 錄。在這之上,我們得到了上百個不同的標簽。

大家思考一會兒。上百萬條的評價記錄乘以上百個標簽。算法本身就很炫酷,我也將在另一篇博文里詳細介紹。今天,我想先介紹算法依賴的技術方法。我們使 用Spark技術來實現這個算法。Spark是一款卓越的數據分布式計算引擎,它能把數據分散到集群的所有節點進行計算。它和Map/Reduce有兩個 重要的區別:

Spark程序代碼更容易閱讀和理解,因為一切都是逐步展開,沒有太多的模板規則。比如,對比Spark和Map/Reduce對Word Count(大數據領域的“Hello World”)的實現過程。

Spark的操作都在內存中完成,只在需要的時候把數據寫出到磁盤。

基于Spark技術,處理所有這些數據的過程就顯得簡潔易懂。我們僅需把所有文字評價讀入分散在集群各個節點的內存中,然后迭代地每次處理一個標簽。原來最耗時的反復讀文件和轉換數據格式步驟,現在只需要在開頭處理一次就夠了。

整個數據處理過程被分為三個階段。

數據集生成:讀入對所有地點(飯店、賓館、景點)有投票的所有評價,然后給每個標簽生成一個數據集。這一步包括特征選擇、生成特征向量和準備交叉驗證數據集。(后兩步對解決本問題至關重要。)

訓練模型:對每個標簽,調整規則化參數并訓練模型。這個原本“尷尬的并行”階段被Spark的并行計算操作完美地解決了。我只需要把數據集廣播到各個節點,并且并行我想調整的參數。每個任務僅返回我用來選擇模型的誤差估計值。

應用:把所有評價讀入內存。沒錯,是所有的。迭代地給每個地點的每個標簽打分,把結果存儲到Hadoop文件系統。再用“加載數據”把他們導入Hive,這一步本質上就是一個HDFS的簡單重命名操作。

所有步驟都極度高效地完成。Spark讓我方便地控制哪些內容需要保留在內存中,哪些不再有用的需要涮出。我還能選擇數據在節點的分區方式。我確保數 據基于地點的ID分區,使得reduction和grouping步驟的節點間數據交換最少。除此之外,我可以使用真正的、易讀的Java語言。不必再拘 泥于使用某些類SQL語言,或者Map/Reduce要求的大量模板規則和易混淆的代碼。

我對Spark提供集群操控功能真的十分滿意,強烈推薦大家也用一下。

來源:TripAdvisor   作者:Jeff Palmucci  譯者/趙屹華

譯者簡介:趙屹華,計算廣告工程師@搜狗,前生物醫學工程師,關注推薦算法、機器學習領域。

 本文由用戶 d2dn 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!