第四範式的人工智慧平台 Prophet 有可能替代 Spark 么?
第四範式先知:建模比Spark快416倍,支持萬億級別變數數
CEO 戴文淵的導師楊強是人工智慧遷移學習領域大牛,戴文淵自己拿過 ACM 冠軍,也是學術牛人,就職百度時據說是 T10 員工,光環很多……
Prophet誕生的原因是因為我們為各種行業提供服務,每個行業的差異化乍一看都不少,按照傳統的方式,我們需要case by case的去應對,給出對應的方法,然後進行實施。但在這個case by case的過程中,大部分的精力是花在如何把對領域專有知識的理解(業務理解)轉換為機器學習過程的具體操作(數據科學家的工作),對於端到端的兩端,數據 和 服務,反而是比較通用的。那麼如果能夠利用技術和演算法,解決專有知識到對應機器學習過程的映射問題,我們就可以建設一個通用的平台來使得AI應用到不同場景的代價變小,實現人工智慧的傻瓜機。Prophet就是這個目標的第一步。
首先Prophet定位在一套完整的平台,包括核心機器學習演算法框架GDBT(沒錯不是GBDT,這是個演算法框架,其作者起名為General Distributed BrainTechnology),以及機器學習任務調度框架TM,以及人機介面Lamma,還有架設在整個框架上的一系列運算元。當然這些都是內部名字無所謂,總的來說Prophet提供的是端到端的機器學習能力,進來是數據,出去是Service。
然後關於GDBT和Spark,應該說對比的是 基於GDBT的演算法 以及 基於Spark的演算法(MLLib實現),由於計算架構的不同,所以簡單的來說多少多少倍是沒有太多的意義,因為如果特徵維度多到一定程度,MLLib在不做數據採樣的情況下是無法完成某些訓練演算法的。但是具體在幾千萬行,幾十個核的場景下,快幾百倍是實測結果。
另外,我們在做的事情,演算法框架是一個部分,性能也是很重要的,但是做這些的目的是為了降低機器學習應用於具體行業的門檻和先決要求。這個先決要求既包含硬體上的,也包含人在機器學習方面知識的要求。擁有更強大的計算能力和特徵處理能力,意味著我們可以更少的讓人輸入信息,而更多的依靠計算機自身的學習和計算來找到機器學習演算法在具體問題上應用的最佳結合點,這其中甚至還需要包括如何去利用計算資源的投入避免機器學習常見的一些缺陷。
因此Prophet不會替代Spark,Prophet裡面的很多組件也是基於Spark的,Prophet的目標是把AI的能力較為容易的帶到各個應用場景,為了這個目標,我們會利用好GDBT,也會極致的利用好Spark,也會利用硬體技術的最新進展。
有希望進一步了解和加入的,歡迎站內信。
spark賣點本來就不是快,而是簡單、魯棒。
用spark無法指定機器間相互通信,只能map-reduce。好處很明顯,連Scala帶spark一個月就能上手幹活。壞處也很明顯,map-reduce靈活性不好,難以對程序深入優化。跟MPI集群比起來慢一二十倍很正常,比share memory的機器不知要慢多少倍了。
spark省了人力,浪費機器。機器和電費跟人力比起來值幾個錢?在大集群上跑,公司真在乎十分鐘和三個小時的差別?而且據說第四範式服務並不便宜。
spark開源社區日益成熟,文檔越來越詳細,你想問的問題也早就有解答了。第四範式能做到?開源機器學習工具還有很多,為了個人發展著想,以後要團隊合作,所以應該去學最流行的、大家都在用的,而不是最「好」的。
曬戴文淵大神的資歷就更可笑了。公平滴說,戴大神很厲害,但是他的背景與創始spark的那批人比起來還有挺大差距。
還有,快幾百倍的claim不嚴謹。即使相同的演算法同一個人實現,用不同分散式計算也很難做公平的對比。
要說更簡單,Spark有個叫KeystoneML的機器學習工具,大家不妨了解一下。聽了當時的產品發布會電視直播,這裡應該指的是prophet中演算法經過優化後的速度比spark的速度快吧。題主鏈接中的那幅圖中明顯指的不是GBDT這個演算法啊,好像是他們公司自己起名的一個框架吧,具體直接去看看視頻直播就明白了,看照片的信息量丟失太大了。
馬鐵大神的phd thesis 總結裡面說了一句話 大概意思是說 單純的如果使用mpi 來實現一個演算法 比spark 快五六倍是很正常的 但是spark 是一個 general 的 data flow 處理框架 就是可以在數據的生命周期裡面 可以使用spark 之上的具體實現來處理數據 ml 只是一部分而已 這就是spark 最大的賣點之一
所以你用這個Prophet平台來和spark 比 ml這方面的效率當然你要快了的 因為還有很多ml 專業的平台都要比spark 快 這就不列舉了
因為spark 基於 mapreduce的 這種program model 就不是適合ml的 特別是ml 裡面大量參數的模型 比如lda 之類的btw: 如果作為一個嚴格的論文來看的話 把spark 作為baseline 而不是做廣泛的實驗比較的話比如 各種平台演算法 數據集 演算法
這論文....不能。硬廣請自重。
你確定你給的鏈接的第一張圖上的 GDBT不是 GBDT寫錯了?
第四範式以變革者的姿態,進入了企業級服務領域,一個受制於客戶意志,能做的事情相當有限的領域。同時,第四範式這種花錢賺吆喝、免費服務的模式,畢竟難以延續。服務廠商總想用一兩次的低價換得口碑與市場,卻無一例外的陷入了低價中標的惡性循環中,最終拖累了自己與同行。
很會營銷
不能
被刪評論了,貴司可以。
作為產品狗,一直在關注第四範式的商業模式,感覺他們應該對自己的定位很清楚的。不是和自己用spark的公司競爭。關注那些有大量數據需求但是在這個領域有急切需求的。比如銀行、保險這些。前期項目預演,後期盡量形成標準服務輸出。
推薦閱讀:
※Spark SQL 和 Shark 在架構上有哪些區別?將來會合併嗎?
※hadoop 和spark如何系統的學習?
※MapReduce過程中,如果Map之後每個Key對應Value的數量不平衡會不會影響效率?
※Spark 為什麼 不允許 RDD 嵌套(如 RDD[RDD[T]])?