眾所周知，在當下，數據科學是一個蓬勃發展的領域，為什么會蓬勃發展呢?首先是因為大數據的發展。我們現在擁有了越來越多的數據，這為數據科學的應用創造了肥沃的土壤，進而使得一個又一個奇跡的創造成為可能。拿大家都耳熟能詳的AlphaGo作為例子。
十年以前，人們說計算機要在圍棋上打敗人類需要50年到100年的時間，但是10年內計算機就做到了這一點。為什么?就是因為可以獲取的棋譜的數據逐步線上化，基于這些數據和一些更新的方法，而不是靠計算量解決這個問題。基于大數據，很多影響人們生活的技術已經被孕育出來，比如計算廣告、推薦系統，現在還正在蓬勃發展的無人駕駛車等等。
在TalkingData，我們每天都處理大量的數據。目前在我們的平臺上，日活是2.5億、月活是6.5億。每天我們能夠收到14TB的數據，處理370億條消息，收到35億個位置定位點。這么龐大的數據基礎，加上和TalkingData的合作伙伴進行數據交換整合，我們形成了以人為中心的從里到外的三層數據，包括人的數據、基本屬性、興趣愛好，以及人經常出現的場景，在這些場景上的動作、行為。
基于這樣的數據海洋，我們的數據科學工作在各個層次、各個領域也是全面開花。為了支持在龐大的數據上去挖掘深度價值，我們在大規模機器學習方面做了很多工作。基于算法技術，我們支撐了很多數據挖掘的實際應用，努力把數據科學、算法的能力融入到DataCloud、MarketingCloud這些公司重量級戰略性產品里面。
同時，我們也會基于數據挖掘的能力以及相應的應用和產品，幫助我們的客戶去創造更大的價值。現在我們在銀行、地產、互聯網金融、零售里面都有很多成功的案例。在這里就不一一介紹了。
講完了目前數據科學的現狀，我們來講講數據科學面臨的挑戰。我們看到最大的挑戰是數據量的迅速膨脹。看到這樣一個報告：在2015年全球存儲的數據是不到8ZB(1ZB相當于100萬個PB的數據)。到了五年之后的2020年，這個數字將達到35ZB，數據的膨脹速度是非常快的。這就帶來了兩個大問題，其中一個是計算的瓶頸。雖然現在一般的大數據技術已經能夠處理很大的數據量了，但是在數據科學領域，很多機器學習算法有這樣的特性，當數據增長一倍的時候，相應計算量要增加4倍或8倍，也就是呈幾次方的速率來增長。可以想像，數據量的膨脹對于計算資源的需求是會呈幾何級數的擴大的。
據美國的報道，到2018年整個美國可能會有19萬數據科學家的缺口。因為我們數據膨脹很快，帶來了很多新的數據的問題，也帶來相應的新的探索機會。但是數據科學家的隊伍的發展和培養是沒有那么快的。在美國2018年的缺口是19萬，以中國的體量來看，肯定會有更多、更大的缺口。
計算的瓶頸，人的瓶頸都是我們面臨的挑戰。我們今天就來說說TalkingData是怎么去解決這兩個難題的。
突破計算的瓶頸
首先是怎么去突破計算上的瓶頸。剛才也談到了計算上的瓶頸，在這里說的更細一點，為什么計算量是隨著數據超線性增長的?這邊引用了非常有名的Machine Learning一篇文章，里面總結了機器學習的十大算法的復雜度。M是數據量，N是數據的維度，可以看到所有的算法要么是跟維度乘平方或三次方的關系，或者是跟M是平方或三次方的關系。
在小數據上不太突出的問題，比如在算法上需要多次迭代，在大數據的情況下，由于必須把數據放在HDFS上面， I/O的代價是非常龐大的。我們自己測算過一些，實際上真正計算的開銷僅僅占到全部開銷的5%到10%，90%到95%的時間都花在I/O上面。
為了解決大規模機器學習問題，工業界和學習界都做了很多努力。最開始是運用MPI，這個相對來說比較古老的并行接口來做大規模機器學習。MPI肯定本身還是比較靈活的，但是因為本身不是為大數據、以數據為中心的計算來設計的，所以在處理做大規模機器學習的時候還是有不少問題，首先開發不夠友好，學習曲線比較高。容錯性也比較差，如果跑一個大規模機器學習任務，跑了很久突然出問題了就不好處理。
Hadoop興起后，很多人也嘗試用Hadoop來實現機器學習算法。但是很快大家認識到在Hadoop上的MapReduce有很大的問題，一是BSP模式，所以同步代價很大。同時要做Shuffle，網絡瓶頸也比較大。因為單個節點上的內存限制，也不能把規模放得特別大。為了解決MapReduce，后面又提出了AllReduce，通過樹形通信來減少通信開銷，這個機制在Spark里面就實現了。當然還有一波人認為MapReduce太粗了，所以就提出了Graph-Base的模型，這套模型的表達能力比較強、比較靈活，也可以處理比較大的模型。我個人認為，這個模型稍微復雜了一點，對于開發者來說學習曲線相對高了一點，而且也不是對所有算法有比較好的效率。
最近幾年談到大規模機器學習的框架，經常被提起的是Parameter Sever，它是為了解決超大規模、超大維度吸收數據的機器學習的問題。因為它很簡單，就分成了Parameter Sever和worker兩組的節點。Parameter Sever可以把模型分布式在各個節點上，每個Work去進行算法的局部訓練，然后同步地去跟Parameter Sever來更新模型或者獲取最新的模型。這種模式，如果是稠密數據，比如有億維度數據是密的，肯定是不可行的。為什么呢?因為中間的通信會變得非常龐大。幸運的是超大規模機器學習的問題一般是稀疏的，所以目前Parameter Sever解決大規模機器學習最關注的一個方向。
市面上開源的大規模機器學習的框架并不是特別多或特別成熟。比如基于Hadoop Map Reduce Mahout，有很大的問題，效率很低。我曾經跑過一個算法，在幾百臺機器上花了50分鐘，數據是100+G，找了大內存機器去跑，自己寫了一個算法5分鐘就跑完了。實際上，基于Hadoop來做機器學習的效率非常低。后來Spark出現了，各種機制、調度比Hadoop更加優化一點。所以MLLib里面算法的效率是大大高于基于Hadoop的算法的效率。Graph-Basc有一個項目是Graphlab，后來基于Graphlab成立了一個公司叫Dato, 前幾個月剛改名Turi，剛剛被蘋果收購了。Parameter Sever開源的有ps-Lite，這個項目我們也做過一些調研，發現它總體來說是比較輕量級的框架，但是對于實際應用上來說，可能還不夠完善。另外一個是Petuum，在機器學習界很多人應該也知道它，我們現在也在跟他們在談一些合作，看看怎么把Petuum真正帶到實際應用中來。
我們現在要反思一下，我們看到前面的大規模機器學習解決的路徑是什么?基本上是在考慮如何能夠更好地并行，提高并行的效率。然后通過增加機器，計算能力和內存資源來解決計算的瓶頸。 但是大規模機器學習的計算瓶頸是算法本身造成的問題，一個是計算量跟數據量的超線性增長帶來的，一個是多次迭代帶來的。如果我們的算法能夠解決這兩個問題，在進行大規模機器學習的時候，對系統的壓力會減輕很多。我們的理想算法是什么樣子的?是線性算法，而且最好是迭代一次就能夠收斂并且取得很好的效果。
在這一塊，我們也做了很多的研究工作。之前我在IBM做機器學習研究的時候，看到了一個很有意思的算法，就是范偉博士在2003年提出來的隨機決策樹的算法。這個算法跟一般的決策樹或隨機決策樹有很大的不同，每一顆樹的構建過程是完全隨機的，隨機構建空樹以后，把數據灌進去，然后統計每個節點的分布。預測的時候，每個樹給出一個正常的預測過程，給出一個預測的概率，然后把多顆樹的結果做平均就可以了。我在2010年對算法的復雜度做過一些分析，應該說這是一個線性的算法，計算了跟數據量增長呈線性關系。
而且通常在單機上測的話比決策樹速度要快兩個數量級以上，通常跑的更精準，而且更不容易over fitting，算是比較好的base line算法。但是也有一個問題，因為樹結構的算法，并行化是比較困難，單機上比較好實現。怎么在構建的過程中同步樹的狀態，其實是非常麻煩的事情。
我們后來基于對隨機決策樹理論的研究，發現其實隨機決策樹起作用的不是因為用了決策樹這個結構。其實隨機決策樹起到的作用，僅僅是把數據隨機打散，每一個數據是不同的打散方式。我們想著用局部敏感哈希來代替樹的功能，就提出了隨機決策哈希的算法。這個文章發表在了2015年KDD的Bigmine Workshop上面。我們看看這兩個算法的精度跟傳統的算法的精度，后面三個分別是決策樹， SVM和Logistc Regression我們可以看到精度上面，這兩個都有比較大的優勢。而且和傳統的算法相比，運算時間也是有很大的優勢。
我們嘗試過把隨機決策樹做并行化，但是發現只有在一種情況下可以做到比較好的并行。所有的數據的功能全部是二值的，這種情況下建空樹，所有的空樹要建成滿二叉樹的狀態，可以用寬度優先的編碼方式，可以把每個節點編碼起來。中間的左右值節點有一個關系，可以通過運算方式去回溯，這樣就使樹在實際應用中不需要建立實體樹。在實際運用過程中，運用了一些哈希，在不建實體樹的情況下來保證隨機決策樹的算法，有一個小動畫來解釋基本原理。
RDH的算法是非常好并行的，也不用去考慮太多其他因素。但是我們為了進一步提高速度，因為我們做了局部敏感哈希，很多中間的過程就變成了binary的向量，可以用Bitmap表達，用Bitmap引擎來加速算法的運算過程。我們測過在4到5億的數據集上，可以做到100秒以內，在Spark上并行100秒以內的訓練過程，而且還包括了Spark本身的調度時間。
前面的方法都是非參數的方法，非參數的方法有很多的問題，一是模型建出來會比較大，應用起來沒有那么方便。二是可解釋性相對差一點，在很多實際應用中，我們還是希望使用更簡潔的參數模型，比如說像Logistic Regression等算法。要求解這種方法，基本的方法是梯度下降，大規模的問題用隨機梯度下降更多。我在這里簡單列了一下Batch的梯度下降和隨機梯度下降的區別。隨機梯度下降最大的好處是把計算量降下來了：原來做批量隨機梯度下降的話，計算量跟數據量是呈幾次方的關系，但是在隨機梯度下面基本上呈線性關系。但是隨機梯度下降還是要進行數據的多輪迭代，因為每次只過一個數據，過數據的次數就要更多一些。
另外，在實際應用中，梯度下降方法的參數都比較難調，比如對于學習率的設置，對于不同問題、不同數據是非常敏感的。如果再考慮到正則化系數，調參就變得更加復雜。
我們對SGD方法也做了很多的優化，一是我們現在做到了可以無參數一次迭代收斂。主要原理是利用每一步的梯度信息，進行動態學習率改變，讓模型快速收斂。這個工作還有一些理論上的小問題沒有完全解決，所以還沒有公布出來。隨著我們機器學習項目的開源，我們也會把這個研究結果，包括算法和理論上的成果公布出來。
在大規模學習上要做稀疏正則化也是比較大的難題，我們這邊采用了一些比較實用的方法，根據內存的容量動態計算可以保存高維度的模型。這樣就使得在做稀疏正則化的時候不需要調參數，盡可能保證豐滿的模型，同時保證要高效地把模型訓練出來。
在機器學習算法并行化方面，有三種可以考慮的方法：梯度平均，模型平均，還有結果平均。結果平均就是Ensemble，這里不討論。對于梯度平均而言是Spark Mllib，包括很多基于Parameter Server，用每一個數據或者每一個小批量的數據去產生一個對模型系數的更新量，然后把更新量匯集起來統一對模型進行更新，然后再把模型發送到所有節點，這是一個梯度平均的過程。另外一種方法更簡單一點，就是在每個數據分片上跑自己的模型，把所有數據分片的模型做平均。我們看過一些文獻，從理論上來說梯度平均的收斂性、理論保證會比模型平均更好一點。但是我們在實際中做了大量的測試，至少現在我們的方法跟MLlib對比有壓倒性的優勢。
我們把在前面參數和非參數模型上做的工作集合了起來，把它放到了即將開源的項目中，我們把這個項目叫做Fregata。Fregata是軍艦鳥的名字，TalkingData內部的項目不管是開源還是非開源的都是用鳥來命名。為什么將機器學習的這個項目命名成軍艦鳥呢?因為它是世界上飛行速度最快的鳥，可以超過400公里每小時。另外，它非常輕，只有3斤重，卻又兩米長的翼展，在全球分布很廣。這也是我們對項目的期許：輕量級，可以承載大規模的機器學習任務，效率高，同時又能適應非常廣的機器學習算法庫。
這就是Fregata與MLLib的LR算法比較，藍色的線都是Fregata的算法，綠色的是MLlib的算法，每個圖的橫坐標是數據掃描的次數，縱坐標是精度判斷指標AUC。我們可以看到，不管是精度、收斂速度和穩定性，Fregata都是遠遠強過Mllib的。基本上每一次都可以一次就達到最高的精度水平，或者非常接近最高的精度水平。
這是Fregata的配置和接口。配置只有一行，非常簡單。最簡單的訓練代碼也就5行，因為我們不需要去設置參數，所以代碼就變得非常簡潔。
總結一下Fregata的特點。首先是對大規模問題的支持。我們實際測試過，處理超大規模10億級樣本，是完全沒有問題的。對于超大規模維度的問題，Fregata能根據內存容量動態確定稀疏度的方式解決，而且速度非常快，如果內存加速的話，可以在億級別的數據上做到10秒級別的速度;無內存加速的話，也能達到分鐘級訓練。據我了解，國內互聯網公司里面非常昂貴的機器學習平臺上面的速度，可能至少要比我們這個慢一個數量級。
我們跟MLlib做過對比，在某些情況下能夠快1000倍，一般情況快個10倍以上也是很正常的。由于我們的開發是基于Spark原生版本，所以能非常容易的融入數據處理流程。因為不需要解決調參的問題，所以可以做一個標準組件，比較容易嵌入數據處理流程。
超越個人的智慧
簡單再講講TalkingData怎么在解決人的瓶頸。因為我們的數據科學家團隊并不是特別大，這樣一個比較小的團隊，面臨著這么大量的數據，靠自己是很難完成的。
我們TalkingData作為一個中立的數據平臺，愿意把數據開放出去。但是在開放數據創造更大價值，跟保護數據的安全隱私的全方位怎么平衡呢?今年上半年我們做了一個TalkingData的數據開放沙箱，在沙箱里可以向指定的人開放指定的數據。數據科學家可以在沙箱里探索數據、創造價值，同時保護原始數據不能夠被拿出沙箱來保證數據的安全，來確保利用數據創造價值和保護數據安全的平衡。
沙箱的應用上，有比較成功案例。一是我們向Thasos開放了8TB的數據，二是我們跟清華大學合作的課程開放了100GB的數據，他們在上面做了很有意思的工作。
即使把數據開放出去引入全球的數據科學人才，也不能完全解決人的問題。剛才也看到了全球的人才是比較有限的。現在再看大數據四個V的支撐技術做的什么樣，在速度跟體量上面，有很多大數據技術解決得不錯了。在價值方面，我們有很多的人工智能的方面的發展也是非常迅速的。但是解決數據來源的復雜性是很難的，我們內部有數據管理員的團隊，他們就是每天純手工來做數據標準化清洗的工作，目前來說是整個大數據里面最短的一版，所以現在我們也在努力嘗試把智能的方法引入到數據準備、數據清洗的工作中來。
我們未來希望能夠用智能做數據的自動關聯，希望把幾十個來源不同的數據源、不同格式的扔進去，就可以很快地把數據關系梳理清楚，相似、相同的數據下表達方式不同的也能夠迅速聚集在一起。
在這個方面我們已經做了很多工作，比如在android的和包方面用了深度學習技術、文本技術，把各種技術集合在一起來判斷多個不同的包是不是屬于一個應用。
讓我們來暢想一下未來，前面提到了在大數據上孕育了非常多的智能奇跡。如果在把這些智能運用在駕馭數據，可以形成非常好的正循環，使得數據科學發展變得越來越快的加速螺旋上升的過程，為我們創造更好的未來。
Q&A
Q1：如何訪問talking data的沙箱?
張夏天：目前訪問TalkingData的數據沙箱需要向TalkingData提出申請，明確使用數據范圍，用途, 并簽訂NDA以后(如果涉及商業用途還需要簽訂商業合同)后，TalkingData會為申請者提供訪問帳號。
Q2：也就是一個新版的mllib?
張夏天：可以這么認為。我們在實際使用中，發現MLLib的問題還是比較多的，無論是訓練速度還是精度都不能滿足我們的需要。因此我們自己實現了一些Spark上的機器學習算法。
Q3：大數據應用的最新挑戰是什么?
張夏天：目前來說我們認為最新的挑戰是把數據處理流程如何智能化。現在大數據應用最大的一個短板就在于應用的成本很高，而很大一塊以成本就在于基礎的數據處理過程，需要投入大量的人力來完成，限制了大數據應用的規模化快速復制。因此我們認為未來應該應用數據科學，人工智能的先進技術和方法來解決數據處理過程過于繁瑣和笨重的問題，降低大數據應用的成本。
Q4：fetegata基于spark實現的，他是如何做到性能比spark高很多倍。另外我們用它不需要調整參數就可以得到很好的效果，具體是怎么做到的?
張夏天：最根本的原因就是提高了算法的收斂速度和穩定性，使得在一般情況下，只需要掃描一次數據，極大降低IO開銷。關于Fregata是如何做到這點的，大家可以耐心等待幾周，我們很快將把Fregata開源出來，同時會在arxiv網站上publish相關論文，屆時歡迎到家試用和批評指正。
Q5：lib庫的一個特點是根據內存大小，自動調整維度么?
張夏天：是的。因為Spark平臺本身的限制，參數并行很困難，因此單個節點的內存大小就限制了模型的大小。在面對超大維度問題時，通過稀疏正則化可以降低模型的規模，使得能夠在單個節點的內存中存儲。但是一般的稀疏正則化方法的稀疏度是依賴于L1正則化項的系數的，并不能精確控制模型的稀疏度。我們在很多實踐中發現，做模型稀疏度越高其精度也會越低，所以我們希望算法能夠把模型的規模降到內存剛好裝下的規模，取得精度和效率之間最好的平衡。
Q6：您好，fregata的功能確實很強悍，目前是開源的嗎，普通用戶怎么能夠體驗到?
張夏天：10月份之內會開源，到時候會發布到Github上，所有人都能使用。我們將采用Apache 2.0的License。
Q7：在優化過程中，模型平均是否受數據分布傾斜的影響，比梯度平均較大?你們工作中，比spark的梯度平均好的原因，是不是因為你們的數據分布較均衡?這是不是算是極端情形，而不能看做一般情形?
張夏天：應該不是。我們的測試不僅是基于我們自己的數據，我們還測試了很多公開數據集。有大數據集，也有小數據集，有低維度密集數據，也有高維度系數數據。測試的結果都是類似的。
講師介紹
張夏天：TalkingData首席數據科學家，12年大規模機器學習和數據挖掘經驗，對推薦系統、計算廣告、大規模機器學習算法并行化、流式機器學習算法有很深的造詣;在國際頂級會議和期刊上發表論文12篇，申請專利9項;前IBM CRL、騰訊、華為諾亞方舟實驗室數據科學家;KDD2015、DSS2016國際會議主題演講;機器學習開源項目Dice創始人。
京公網安備 11010502049343號