閱讀891 返回首頁    go 阿裏雲 go 技術社區[雲棲]


上海QCon2017參會分享

標簽(空格分隔): QCon


10.17-10.19在上海度過了Qcon的三天。今年的Qcon主題非常的散,這也是近兩年無論ArchSummit還是QCon的一個特點,基本涵蓋了以互聯網技術為主的所有領域。

我個人主要關注還是雲計算、機器學習和大數據相關的話題,因此主要參與的topic也集中於此。本文就印象深刻的一些展開一點分享。

會場第一個關注的話題,是複旦危輝教授講的人工智能的一個概述,怎麼說呢?這個topic在這個時候回看,是整個QCon我個人認為最棒的topic,偏哲學層麵,主要糾正了一些大家對AI的認知,同時也再次強調了要正確認識DeepLearning。可惜這塊沒有PPT,真心無法傳播分享其精髓了。

機器學習應用

理解為算法應用好了,其實方法論確實是大同小異,隻是場景的不同,可以看出不同的技術團隊在各自場景中的一些取舍。

可配置係統的性能學習

首先看一個例子——《可配置係統的性能學習》。華東理工大學的AP做了基於機器學習來調整可配置係統的參數,期望獲取複雜參數係統中“最優”運行的參數組合。因為複雜的參數組合有組合爆炸的問題,在期望有較好性能的情況下能調節有效參數,對於複雜配置係統有很大幫助。具體的一個solution是通用的機器學習方法論,如下圖:
可配置係統

唯品金融機器學習

唯品金融的同學分享了他們的機器學習實戰經驗,比較貼地氣。有個談法挺樸實——沒有高大上,麵向業務的機器學習。
唯品金融在4大產品方向上做嚐試。

唯品1

當然這些也不是都實現了,分享的講師提到了一個有意思的話題:算法平台vs算法應用,那他也展示了在唯品金融,算法應用和平台又是如何建設的。

唯品2

可以看到平台、應用(預測模型)和策略層(人工幹預)很清晰的分層。anyway無論高大上與否,我認為這是一種正確且cost based的架構。

攜程度假智能雲客服平台

畢竟在客服團隊,看到客服平台還是忍不住去聽了一下。攜程的客服場景對應於CCO體係內,業務模式其實主要對標飛豬。其現狀

攜程度假客服

也是在解決多渠道(熱線、在線)多環節(售前、行中、售後)的各種谘詢和維權問題。那麼麵對複雜業務場景,攜程度假做了一層業務抽象

攜程度假客服2

可以看到,對於智能問答、智能分配、預警,與我們集團CCO的技術產品有同質性,也就是說在客服場景中,如此複雜的業務邏輯,必須通過幾個核心步驟和域劃分開。其中對於用戶意願的持續追蹤,我覺得與我們當前團隊做的主動服務以及小蜜團隊的障礙預測很類似。就是要基於數據在用戶動作前預知到用戶的意圖。具體如何做的呢?很遺憾,演講者沒有細節深入,隻有一個架構圖粗略的描述了整體係統的模塊劃分。不得不說太遺憾了。

攜程度假係統

這裏演講者著重講了攜程自己做的Easy AI平台,看UI截圖其實功能很簡單,就是集成了標注和一些model的管理。算是工程層麵的一個特色吧。

TensorFlow與深度學習

這個topic是Google Brain團隊帶來的,主要是TF的特性介紹,幾個新特性比較吸引人,如微博上前段時間比較火的eager execution,還有auto learning的Learn2learn。我對後者比較感興趣,這裏截了一些圖片簡單介紹。
複雜網絡

複雜網絡2

如上圖這樣的複雜網絡,是很難煉丹完成的,那麼learn2learn可以解決這類問題,一個主要方法就是迭代優選。就像去年和壽哥團隊簡單了解autolearning一樣,基本就是需要迭代來嚐試。

迭代

TF的learn2learn能力據說還不錯,很快可以搞出一個性能不錯的net。

l2l結果

Pinterest如何利用機器學習實現兩億月活躍用戶

這是矽穀專場的一個topic,Pinterest的同學分享了一個推薦rank的係統演化。算是比較經典吧,而且進度和集團手淘的千人千麵也差不多。基本上第一階段都是規則策略,然後演化為線性模型,接下來GBDT用boost組合的方式來優化,到如今演化到DeepLearning。

其首頁的推薦核心是個性化主頁
問題場景

核心問題是
核心問題

係統演化剛開始的規則(基於時間)
p1

線性預測(LR、500+稀疏特征)
p2

GBDT(XGboost、深度7、700+特征)
p3

DL(TensorFlow、1層embeding+4層全連接的神經網絡、ReLu+SigmoidGate混合神經元)
p4

係統演化
p5

最後的總結還是不錯的。線性模型不能很好的利用高維複雜特征,另外cross feature都要手工做,同時用戶特征(年齡、性別等)對於模型無意義,因為不同的user-item pair,user維度是一致的。那GBDT其實是演講者最推崇的一個模型,因為這個模型對於性能的提升是巨大的,且有效的探索和豐富了特征空間,能做特征分析的算法,我個人也傾向於應該是一種合理的算法(符合人類直覺),我相信如果不是DEEPLearning太火,Pinterest的首頁推薦應該就是GBDT了。因為講者自己也說了,GBDT的離散特征處理不足的問題,也可以通過加embedding解決。

大數據

最後還是要談回大數據,之前archsummit思考裏就講過離線計算的大數據架構已經是一個穩態架構,果然在2017大家已經不談了,實時計算出現了穩定的專場占據著大數據專場的一個固定席位。今年的實時主要是阿裏的介紹為主,包含Blink Sql和毅行的Porshe,因為內部有更多機會了解,因此沒去。主要聽了一個talkingData的內存計算和Linkedin的係統分享。

基於內存的分布式計算

這個話題扯的太大了,其實TalkingData就是在做我4年前在無線和一群小夥伴做的事,實時計算uv。他們提到的架構主要是用bitmap來去重,而bitmap又是以blob的結構存mysql的,導致binlog巨大。因此提出一個改進的方案在內存中分布式的存儲來計算。大體流程是這樣:

td流程

這個blade就是核心的內存計算框架,大體集群包含

td集群

這裏主從是雙寫的,也無法解決完全的高可用,隻能是相比老係統提高。這裏當時會場有很多人有疑問,不過沒有深入細究。

Building Invisible Data Infrastructure at LinkedIn

linkedin的這個topic話題很大,不過主要介紹了兩個開源的係統:Helix和Nuage。

topic開始先普及了一下分布式係統,介紹了一些難點:
分布式係統難點

Helix主要是負責做分布式的集群管理,而Nuage則關注雲平台。Helix的抽象主要麵向Node和機器,管理的資源就是Database和Job。主要的資源狀態包括master、slave、online和offline。核心通過zk來協調,有個spectator負責做資源mapping。細節比如如何高可用的利用zk,沒有仔細講。主要架構簡圖如下:

helix

Helix照演講者介紹來看,基本管理了linkedin的全部db資源,不僅是關係數據庫,包括文檔數據庫、kv數據庫、OLAP數據庫都是通過helix管理的。而Nuage更像一個管理平台,Nuage本意就是法語的cloud的意思。其提出兩個核心概念——Automation、Self-service,這個聽起來很好。而Nuage的目標也是做這樣的事情。讓開發和運維過程更自動化和自服務,降低犯錯的可能性,統一審批和安全流程、一致的監控和告警、做容量預估,anyway,這樣的管理平台可想象的空間真的很大。這兩年看到集團內部這麼多的基礎運維平台出現,如果打包合並,就是Ali的Nuage。智能自動化運維不是夢。

Nuage

最後附一個LinkedIn的data infrastructure圖結束。外加一句總結:大數據離線&實時架構穩定了、高可用高並發互聯網架構穩定了、機器學習的套路也算固定了,後麵會是什麼呢?我非常看好Robotics,including chatbot。

linkedin

Reference

最後更新:2017-11-08 20:34:35

  上一篇:go  CUDA存儲器【中科院課件】
  下一篇:go  阿裏雲前端周刊 - 第 31 期