大家好，我是來自第四范式的胡時(shí)偉，今天很高興能夠和我們的算法科學(xué)家涂威威一起跟大家分享我們在AI開發(fā)平臺(tái)“先知”產(chǎn)品的一些經(jīng)驗(yàn)，共同探討機(jī)器學(xué)習(xí)從系統(tǒng)和工程方面的優(yōu)化方向。
接下來主要從如下幾個(gè)方面來講述：
為什么人工智能系統(tǒng)需要高維大規(guī)模機(jī)器學(xué)習(xí)模型
訓(xùn)練高維大規(guī)模機(jī)器學(xué)習(xí)模型算法的工程優(yōu)化
機(jī)器學(xué)習(xí)產(chǎn)品的架構(gòu)實(shí)踐
首先先從人工智能發(fā)展說起，人工智能并不是一個(gè)最近出現(xiàn)的概念，早在60年代就有著名學(xué)者曾經(jīng)預(yù)言二十年內(nèi)機(jī)器將能夠完成人能做到的一切工作。到今天我們又聽到說20年之內(nèi)，一大半的工作崗位將被機(jī)器人替代。那么60年代到今天發(fā)生的最大的區(qū)別是什么？這其中發(fā)生了兩個(gè)重大的變化，第一個(gè)是計(jì)算能力的突飛猛進(jìn)，今天的手機(jī)一個(gè)核的計(jì)算能力就足以秒殺當(dāng)年的超級計(jì)算機(jī)。第二個(gè)是我們擁有了大數(shù)據(jù)，TB級的數(shù)據(jù)存儲(chǔ)、處理在今天已經(jīng)不再困難，而20年前，GB級的硬盤才剛剛興起。
因此我們說今天人工智能=機(jī)器學(xué)習(xí)+大數(shù)據(jù)，那么什么樣是好的人工智能呢？這里引入一個(gè)“VC維”的概念。“VC”維是1960年代到1990年代由Vapnik及Chervonenkis建立的一套統(tǒng)計(jì)學(xué)習(xí)理論。VC維反映了函數(shù)集的學(xué)習(xí)能力，VC維越大則模型或函數(shù)越復(fù)雜，學(xué)習(xí)能力就越強(qiáng)。之前，統(tǒng)計(jì)建模曾經(jīng)進(jìn)入過一個(gè)誤區(qū)，就是去追求經(jīng)驗(yàn)風(fēng)險(xiǎn)最小化，什么意思呢？就是說我希望建立一個(gè)模型，在給定的樣本上不要有誤差，這樣感覺非常好，但是往往這么一來，在實(shí)際的預(yù)測中非常糟糕，這是為什么呢？是因?yàn)椴捎昧艘恍￢C維很高的模型，雖然函數(shù)集學(xué)習(xí)能力是強(qiáng)了，但是由于數(shù)據(jù)不夠，所以導(dǎo)致置信風(fēng)險(xiǎn)變大產(chǎn)生了一些類似過擬合的情況，最后這個(gè)模型還是不好用。
但是今天我們進(jìn)入了大數(shù)據(jù)時(shí)代，樣本的數(shù)量，包括樣本的特征豐富程度有了極大提升，這就又帶來了提升VC維的新機(jī)會(huì)。我們經(jīng)常說經(jīng)驗(yàn)主義害死人，過去的建模就是害怕經(jīng)驗(yàn)主義，所以呢就把這個(gè)大腦變笨，降低VC維，使得模型更有效。但是今天的大數(shù)據(jù)情況下，可以通過補(bǔ)充更多的閱歷（數(shù)據(jù)），來避免經(jīng)驗(yàn)主義，那么一個(gè)閱歷豐富的聰明的人，自然是要比一個(gè)笨的記不住東西的人要好的。因此我們說大數(shù)據(jù)人工智能時(shí)代，提升VC維變成了一個(gè)好的人工智能系統(tǒng)的關(guān)鍵因素。
那么機(jī)器學(xué)習(xí)中的高維度從何而來？傳統(tǒng)方法只能利用可以放在特征矩陣這個(gè)平面中的數(shù)據(jù)，對于立體的數(shù)據(jù)，多維度的數(shù)據(jù)，因?yàn)樗鼈兌嗖皇菙?shù)字，所以傳統(tǒng)機(jī)器學(xué)習(xí)模型無法處理，只能選擇舍棄。但在實(shí)際工業(yè)應(yīng)用中，這類非數(shù)字化的數(shù)據(jù)所包含的信息，往往信息價(jià)值很高，比如它可能對個(gè)性化推薦很有影響，可能對泛化處理有幫助。為了能成分利用這些數(shù)據(jù)，我們對特征矩陣外的立體的數(shù)據(jù)通過切片等算法進(jìn)行變換，使得變換后的數(shù)據(jù)成為特征矩陣的一部分，同時(shí)還對不同特征之間進(jìn)行交叉組合等操作，這樣特征矩陣的每一行的列數(shù)就從原始數(shù)據(jù)的列數(shù)，變成了每一行都是一個(gè)巨大（比如2的64次方）的向量，形成超高維度的模型。
高維度模型真正的意義何在？通過對原來立體數(shù)據(jù)切片處理，可以使得某些過去只能有簡單線性表達(dá)的數(shù)據(jù)，比如年齡等，獲得更接近真實(shí)情況的細(xì)膩體現(xiàn)；此外，原來機(jī)器學(xué)習(xí)不能利用的非數(shù)字、沒有排序關(guān)系的數(shù)據(jù)，比如姓名等，也可以發(fā)揮其價(jià)值所在。舉個(gè)例子，在個(gè)性化推薦的場景中，體現(xiàn)個(gè)性化信息的數(shù)據(jù)之間通常是不可比的，比如，我們先只考慮熱度、推薦序號(hào)和用戶ID三個(gè)變量，其中用戶ID這個(gè)變量就是傳統(tǒng)機(jī)器學(xué)習(xí)模型所不能利用的，只有通過將這個(gè)數(shù)據(jù)切片處理，獲得一個(gè)高維度模型，才可以真正將用戶信息這個(gè)數(shù)據(jù)發(fā)揮出價(jià)值。
要獲得一個(gè)成功的高維度模型，就需要好的機(jī)器學(xué)習(xí)系統(tǒng)，這個(gè)系統(tǒng)應(yīng)當(dāng)具備兩個(gè)特征：橫向可擴(kuò)展的高計(jì)算性能和算法本身在收斂過程中的正確性。為此，我們的算法工程團(tuán)隊(duì)開發(fā)了一系列的基礎(chǔ)設(shè)施組件，組成了大規(guī)模分布式機(jī)器學(xué)習(xí)框架GDBT（General Distributed Brain Technology）。GDBT是一個(gè)由C++編寫的，完全分布式的適合于機(jī)器學(xué)習(xí)計(jì)算場景的計(jì)算框架，可以運(yùn)行在單機(jī)、MPI、Yarn、Mesos等多個(gè)分布式環(huán)境。
大規(guī)模分布式機(jī)器學(xué)習(xí)框架GDBT
機(jī)器學(xué)習(xí)是一種數(shù)據(jù)驅(qū)動(dòng)的實(shí)現(xiàn)人工智能的方式，機(jī)器學(xué)習(xí)在實(shí)際應(yīng)用中的大數(shù)據(jù)、高維度背景導(dǎo)致需要一個(gè)高效計(jì)算的平臺(tái)，同時(shí)，監(jiān)督學(xué)習(xí)領(lǐng)域著名的No Free Lunch定理指出，沒有一個(gè)機(jī)器學(xué)習(xí)模型能夠?qū)λ械膯栴}都是最有效的。所以在不同的實(shí)際問題里，需要使用不同的機(jī)器學(xué)習(xí)算法或者對機(jī)器學(xué)習(xí)算法做適應(yīng)性地調(diào)整，去達(dá)到更好的實(shí)際效果。因此在實(shí)際的應(yīng)用中，需要能夠非常容易地開發(fā)出適應(yīng)實(shí)際問題的機(jī)器學(xué)習(xí)算法。相比于傳統(tǒng)的ETL計(jì)算，機(jī)器學(xué)習(xí)算法的計(jì)算過程有很多自身的要求和特點(diǎn)。
在框架設(shè)計(jì)上，沒有普適的最好的框架，只有最適合自身應(yīng)用場景的框架。GDBT框架的設(shè)計(jì)初衷主要就是打造一個(gè)專門為分布式大規(guī)模機(jī)器學(xué)習(xí)設(shè)計(jì)的計(jì)算框架，兼顧開發(fā)效率和運(yùn)行效率。GDBT框架不是某一種算法，而是一種通用的機(jī)器學(xué)習(xí)算法計(jì)算框架，使算法工程師可以基于GDBT開發(fā)各種傳統(tǒng)或者創(chuàng)新算法的分布式版本，而不用過多地關(guān)心分布式底層細(xì)節(jié)。
目前比較流行的計(jì)算框架比如Hadoop、Spark其重點(diǎn)任務(wù)大多是ETL類的任務(wù)。前面提到機(jī)器學(xué)習(xí)計(jì)算任務(wù)相比于傳統(tǒng)的ETL計(jì)算任務(wù)有很多自身的特點(diǎn)，時(shí)間有限這里可以簡單地展開一下。
在計(jì)算方面：相比于ETL會(huì)做的一些相對“簡單”的運(yùn)算，機(jī)器學(xué)習(xí)算法會(huì)對數(shù)據(jù)做相對復(fù)雜的運(yùn)算，一些非線性的模型，比如深度學(xué)習(xí)模型會(huì)需要比較密集的計(jì)算；在實(shí)際的應(yīng)用中，需要考慮不同計(jì)算資源的特性；分布式計(jì)算中，由于分布式帶來的通訊、同步、災(zāi)備等等的overhead需要調(diào)整計(jì)算模式來盡可能地降低。
在通訊方面：很多機(jī)器學(xué)習(xí)算法在計(jì)算過程中會(huì)頻繁使用到全局或者其他節(jié)點(diǎn)的信息，對網(wǎng)絡(luò)吞吐和通訊延遲的要求要遠(yuǎn)高于ETL任務(wù)。同時(shí)，很多機(jī)器學(xué)習(xí)任務(wù)對于一致性的要求要低于ETL任務(wù)，在系統(tǒng)的設(shè)計(jì)上可以使用放松的一致性要求。
在存儲(chǔ)方面：ETL需要處理來源不同的各種數(shù)據(jù)，比較少的反復(fù)迭代運(yùn)算，很多機(jī)器學(xué)習(xí)算法會(huì)對數(shù)據(jù)做反復(fù)的迭代運(yùn)算，可能會(huì)有大量的不斷擦寫的中間數(shù)據(jù)產(chǎn)生，對存儲(chǔ)的使用效率、訪問效率有著更高的需求。
在災(zāi)備和效率的權(quán)衡方面：容災(zāi)策略有兩方面的額外開銷，一方面來自于執(zhí)行過程中為了容災(zāi)所需要做的額外的諸如狀態(tài)保存之類的操作，另一方面來自于災(zāi)難恢復(fù)時(shí)所需要進(jìn)行的額外重復(fù)計(jì)算開銷。這兩方面的開銷是此消彼長的。與ETL計(jì)算任務(wù)不同，機(jī)器學(xué)習(xí)計(jì)算任務(wù)流程相對復(fù)雜，中間狀態(tài)較多，在較細(xì)的粒度上進(jìn)行容災(zāi)會(huì)增加執(zhí)行過程中的額外開銷。因此在容災(zāi)策略和容災(zāi)粒度上，機(jī)器學(xué)習(xí)計(jì)算任務(wù)和ETL計(jì)算任務(wù)之間的權(quán)衡點(diǎn)不一樣。
GDBT計(jì)算框架針對機(jī)器學(xué)習(xí)任務(wù)在計(jì)算、通訊、存儲(chǔ)、災(zāi)備等方面做了深入的優(yōu)化。時(shí)間有限，這里可以簡單的講一點(diǎn)GDBT的工作，有興趣了解更多的同學(xué)可以會(huì)后再和我們聯(lián)系，或者加入第四范式一起解決這些有趣的問題：）
在計(jì)算方面，計(jì)算硬件發(fā)展到今天，提升計(jì)算能力的主要方式是堆積計(jì)算能力的分布式并行計(jì)算，比如現(xiàn)在做深度學(xué)習(xí)非常流行的GPU本身也是一種并行計(jì)算硬件，針對不同需求的計(jì)算硬件的種類也在變多，比如FPGA等等。對于大數(shù)據(jù)、高維度、復(fù)雜的機(jī)器學(xué)習(xí)計(jì)算任務(wù)，GDBT框架充分考慮了分布式并行計(jì)算的特點(diǎn)，針對不同的硬件資源、不同的算法場景做了調(diào)度、計(jì)算模式、機(jī)器學(xué)習(xí)算法部件的抽象等的優(yōu)化。GDBT框架本身在設(shè)計(jì)上也刻意避免了現(xiàn)在一些框架設(shè)計(jì)容易走入的誤區(qū)。比如：為了分布式而分布式，但是忘記了分布式帶來的overhead。GDBT框架針對單機(jī)、分布式模式分別進(jìn)行了優(yōu)化，框架本身會(huì)對不同規(guī)模的計(jì)算任務(wù)、不同的計(jì)算環(huán)境做自適應(yīng)的調(diào)整選擇更高效的實(shí)現(xiàn)。
然后在通訊方面，通信效率是分布式機(jī)器學(xué)習(xí)系統(tǒng)中至關(guān)重要的部分。首先,相比于ETL任務(wù),很多機(jī)器學(xué)習(xí)算法在計(jì)算過程中會(huì)頻繁使用到全局或者其他節(jié)點(diǎn)的信息,對網(wǎng)絡(luò)吞吐和通訊延遲的要求都很高。其次,一些機(jī)器學(xué)習(xí)算法在通信時(shí)可能有很多可以合并處理的通訊需求。再次,很多機(jī)器學(xué)習(xí)算法并不要 求在所有環(huán)節(jié)保證強(qiáng)一致性。最后,對于不同的網(wǎng)絡(luò)拓?fù)?最優(yōu)的通訊方式也會(huì)不一樣。因?yàn)榇嬖诳赡艿暮喜⑻幚怼⒎菑?qiáng)一致性需求、網(wǎng)絡(luò)拓?fù)涿舾械?就會(huì)存在有別于傳統(tǒng)通訊框架的優(yōu)化。先知的GDBT計(jì)算框架內(nèi)部,針對機(jī)器學(xué)習(xí)計(jì)算任務(wù)單獨(dú)開發(fā)了一套通信框架,為機(jī)器學(xué)習(xí)任務(wù)提供了更高效、更易用的支持點(diǎn)對點(diǎn)異步、點(diǎn)對點(diǎn)同步、深入優(yōu)化的組通訊(比如類MPI的Broadcast、 AllReduce、Gather、Scatter等等)的通信框架,同時(shí)為應(yīng)用層提供了簡便易用的合并、本地緩存 等等功能。
然后介紹下我們在參數(shù)服務(wù)器（Parameter Server）方面的工作，很多機(jī)器學(xué)習(xí)算法的學(xué)習(xí)過程都是在“學(xué)習(xí)”一組參數(shù),對于分布式機(jī)器學(xué)習(xí)任務(wù),不同的節(jié)點(diǎn)需要對“全局”的這組參數(shù)進(jìn)行讀取和更新,由于是分布式并行的計(jì)算任務(wù),因此存在著一致性的問題,不同的機(jī)器學(xué)習(xí)算法或者同一個(gè)機(jī)器學(xué)習(xí)算法的不同實(shí)現(xiàn)對一致性的要求會(huì)不盡相同,不同的 一致性策略對整體算法的效率會(huì)產(chǎn)生很大的影響。參數(shù)服務(wù)器就是為了解決分布式并行機(jī)器學(xué)習(xí)任務(wù)中多機(jī)協(xié)同讀取、更新同一組參數(shù)設(shè)計(jì)的,設(shè)計(jì)上需要提供簡單易操作的訪問接口方便機(jī)器學(xué)習(xí)專家開發(fā)算法,同時(shí)也需要提供可選擇的一致性策略、災(zāi)備等等。
另外，由于是為機(jī)器學(xué)習(xí)任務(wù)設(shè)計(jì)，參數(shù)服務(wù)器的設(shè)計(jì)目標(biāo)是高吞吐、低延遲。GDBT中的參數(shù)服務(wù)器針對不同的應(yīng)用場景做了更 加深入的優(yōu)化,結(jié)合高效緩存、智能合并等優(yōu)化策略以及基于GDBT自帶的高效異步通訊框架,同 時(shí),還針對稀疏、稠密等不同的參數(shù)場景進(jìn)行了針對性優(yōu)化;內(nèi)置提供了豐富的一致性策略可供用戶選擇或自定義一致性策略；GDBT將參數(shù)服務(wù)器看成一種特殊的Key-Value存儲(chǔ)系統(tǒng),對其進(jìn)行了獨(dú)立的災(zāi)備設(shè)計(jì),同時(shí)提供不同粒度的災(zāi)備選項(xiàng),便于在實(shí)際的部署中選擇合適的災(zāi)備策略提升效率。
這次我主要講計(jì)算框架方面的工作，以后有機(jī)會(huì)可以再詳細(xì)分享我們在機(jī)器學(xué)習(xí)算法框架以及機(jī)器學(xué)習(xí)算法方面的設(shè)計(jì)工作。針對機(jī)器學(xué)習(xí)算法計(jì)算，GDBT框架做了進(jìn)一步的抽象，比如數(shù)據(jù)流、優(yōu)化算子、多模型框架等等，這里簡單介紹下數(shù)據(jù)流的設(shè)計(jì)。對于研究并實(shí)現(xiàn)機(jī)器學(xué)習(xí)算法的專家而言，算法的核心就是數(shù)據(jù)的各種變換和計(jì)算。GDBT框架為了讓機(jī)器學(xué)習(xí)專家更容易、更快速地開發(fā)出不同的機(jī)器學(xué)習(xí)算法提供了數(shù)據(jù)流的抽象，使得機(jī)器學(xué)習(xí)專家通過描述數(shù)據(jù)流DAG圖的方式編寫機(jī)器學(xué)習(xí)算法。機(jī)器學(xué)習(xí)專家只需要關(guān)注數(shù)據(jù)的核心變換和計(jì)算邏輯，GDBT計(jì)算框架將機(jī)器學(xué)習(xí)專家描述的數(shù)據(jù)流圖進(jìn)行高效的分布式計(jì)算。
數(shù)據(jù)流計(jì)算框架的抽象一方面有助于降低機(jī)器學(xué)習(xí)專家的開發(fā)門檻、提升開發(fā)速度（他們不需要關(guān)注底層分布式、并行細(xì)節(jié)），另一方面也為GDBT框架提供了更大的空間去進(jìn)行數(shù)據(jù)流執(zhí)行優(yōu)化，能夠進(jìn)一步提升執(zhí)行效率（如果GDBT框架只在底層模塊進(jìn)行優(yōu)化，將會(huì)非常乏力；但是數(shù)據(jù)流的抽象使得GDBT框架能夠更全面地了解計(jì)算任務(wù)的pattern，可以做更多的優(yōu)化工作）。
在存儲(chǔ)、災(zāi)備設(shè)計(jì)等方面，GDBT也做了深入的優(yōu)化，比如多級緩存的設(shè)計(jì)、框架層面對存儲(chǔ)讀取寫入、網(wǎng)絡(luò)訪問、計(jì)算過程等等的災(zāi)備設(shè)計(jì)，對不同計(jì)算規(guī)模采取不同的災(zāi)備粒度等等，這里時(shí)間有限，就不做過多介紹了。機(jī)器學(xué)習(xí)算法部分的工作以后有機(jī)會(huì)可以再一起交流。
GDBT定制的通信框架、算法框架以及參數(shù)服務(wù)器，為進(jìn)行大規(guī)模機(jī)器學(xué)習(xí)訓(xùn)練提供了基石。當(dāng)然GDBT還有一個(gè)很大的特性是算法開發(fā)者友好，對于算法開發(fā)來說，學(xué)術(shù)研究和工業(yè)應(yīng)用之間存在一定的取舍。一些其他的算法框架比如Tensorflow，比較注重研究上的易用性，從而在效率上有所舍棄，而一些注重于生產(chǎn)應(yīng)用的算法框架特別是分布式框架，在算法二次開發(fā)和擴(kuò)展上則捉襟見絀。GDBT提供的是工業(yè)級的開發(fā)者易用性，從語言級別，GDBT整體基于C++ 14標(biāo)準(zhǔn)，為算法的開發(fā)提供了更大的自由。從功能抽象上，GDBT提供了對參數(shù)服務(wù)器和算子的良好包裝，在GDBT上，只需要數(shù)百行代碼就可以實(shí)現(xiàn)像邏輯回歸、矩陣分解等算法的分布式版本。
機(jī)器學(xué)習(xí)算法框架的語言選擇問題
關(guān)于機(jī)器學(xué)習(xí)算法框架的語言選擇問題，因?yàn)榻裉旌芏嗟拇髷?shù)據(jù)框架都是基于Hadoop/Spark這一套的，都是JVM上的東西，因此基于JVM從整體來說接入生態(tài)是比較容易的，但其實(shí)有三點(diǎn)理由讓我們選擇C++而不是基于JVM去做這件事情。
首先我們前面講過，目前雖然計(jì)算能力對傳統(tǒng)應(yīng)用來說井噴，我們經(jīng)常說CPU過剩、GPU過剩。但是對于高維機(jī)器學(xué)習(xí)過程來說，依然是資源非常緊張的，這里面包括計(jì)算、網(wǎng)絡(luò)、內(nèi)存等多個(gè)方面，我們看Spark的Project Tungsten也做了大量堆外內(nèi)存管理的工作以提升數(shù)據(jù)的處理效率，但是對機(jī)器學(xué)習(xí)來說，基本上整個(gè)過程都需要對內(nèi)存和計(jì)算過程進(jìn)行精細(xì)控制，以及避免不可控的GC過程。
其次，C++的一些語言特性，比如運(yùn)算符重載機(jī)制也可以使得框架上層的算法應(yīng)用的語法比較簡單優(yōu)雅，不會(huì)變成巨大的一坨，而大規(guī)模機(jī)器學(xué)習(xí)很多時(shí)候和字符串組成的離散特征打交道，C++對字符串處理的效率也要高出JVM-Based語言非常多。
再次，Spark目前的機(jī)制和Parameter Server的結(jié)合很難做到優(yōu)雅和完美，強(qiáng)行對接PS會(huì)破壞Spark自身的災(zāi)備、任務(wù)調(diào)度等特性。如果不對接，那么就基本上只能靠降低模型大小來確保效率，和高維度的目標(biāo)南轅北轍。所以綜合考慮，我們還是選擇C++來實(shí)現(xiàn)整個(gè)一套的系統(tǒng)，而將和大數(shù)據(jù)框架的對接以及開發(fā)門檻降低這個(gè)任務(wù)交給整個(gè)機(jī)器學(xué)習(xí)系統(tǒng)的架構(gòu)。
整體架構(gòu)
上面講了很多機(jī)器學(xué)習(xí)算法框架，但有過實(shí)踐經(jīng)驗(yàn)的朋友都知道，光有一個(gè)算法框架只相當(dāng)于汽車有了發(fā)動(dòng)機(jī)，離開起來還很遠(yuǎn)。我們總結(jié)一個(gè)完整的機(jī)器學(xué)習(xí)系統(tǒng)需要有如下部分：
- 數(shù)據(jù)引入和預(yù)處理
- 特征工程
- 模型訓(xùn)練算法（支持參數(shù)靈活調(diào)整和二次開發(fā)）
- 模型評估
- 模型上線（批量預(yù)估、實(shí)時(shí)API調(diào)用、線上特征實(shí)時(shí)計(jì)算）
那么對于這所有的部分，我們開發(fā)了一個(gè)叫『先知』的整體平臺(tái)產(chǎn)品，我們先看一下先知的整體架構(gòu)圖：
這套架構(gòu)能夠給我們帶來如下幾個(gè)優(yōu)勢：
1. 把整個(gè)機(jī)器學(xué)習(xí)過程作為一個(gè)整體來看待，做到各模塊的深度整合。下面是我們產(chǎn)品的一個(gè)截圖
同時(shí)呢，這個(gè)DAG圖的背后我們還做了很多工作，一個(gè)比較有意思的就是對存儲(chǔ)的抽象和適配。我們有的客戶是用AWS作為基礎(chǔ)設(shè)施，而有的客戶用阿里云做基礎(chǔ)設(shè)施，有的客戶則選擇在IDC內(nèi)構(gòu)建自己的機(jī)房。這里面就有塊存儲(chǔ)、云盤、SSD、內(nèi)存盤等多種存儲(chǔ)服務(wù)。
另外，一個(gè)完整的機(jī)器學(xué)習(xí)過程，往往還要從數(shù)據(jù)庫里面導(dǎo)入數(shù)據(jù)，最終要把數(shù)據(jù)導(dǎo)出到某個(gè)指定的位置。導(dǎo)數(shù)據(jù)在邏輯上的復(fù)雜性和由于某些開源模塊不支持內(nèi)存緩存和SSD導(dǎo)致的性能的低下都是困擾數(shù)據(jù)科學(xué)家的問題。
對此設(shè)計(jì)了一個(gè)兩層的存儲(chǔ)抽象層API，第一層是一個(gè)開源項(xiàng)目alluxio，就是以前的tachyon，alluxio這個(gè)東西是非常好的，好在哪里呢？他用一套解決方案一下子解決了幾個(gè)問題，第一是可以支持很多分布式的文件系統(tǒng)，包括S3、Ceph等。第二還能夠比較透明的解決內(nèi)存和SSD加速的問題。針對Alluxio這個(gè)項(xiàng)目，我們將整個(gè)的數(shù)據(jù)處理、模型訓(xùn)練、預(yù)估體系，包括我們自己開發(fā)的GDBT框架都和alluxio做了深度的融合集成，也針對開源的產(chǎn)品在訪問調(diào)度、吞吐、SSD優(yōu)化上做了一些增強(qiáng)和修補(bǔ)的工作。
第二層是DataManager，我們知道企業(yè)的應(yīng)用，特別在意安全性，那么如果我們直接把底層的文件系統(tǒng)暴露給使用者，會(huì)導(dǎo)致權(quán)限隔離等個(gè)方面的隱患。Datamanager提供了一個(gè)數(shù)據(jù)的邏輯沙箱，使得每個(gè)使用者在自己的DAG里面只能用一個(gè)唯一的名字來訪問到自己安全容器內(nèi)部的數(shù)據(jù)，這樣不僅保證了安全，也避免了使用者直接去處理各種各樣的長的數(shù)據(jù)文件的URI。
2. 給開發(fā)者提供比較好的體驗(yàn)，相信使用大數(shù)據(jù)系統(tǒng)的朋友都有一個(gè)感受，就是在分布式時(shí)代，調(diào)試變得難了。一方面很多時(shí)候日志太過于復(fù)雜，不知道錯(cuò)誤在哪里，另外一方面經(jīng)常出現(xiàn)跑了幾個(gè)小時(shí)報(bào)一個(gè)錯(cuò)前功盡棄的情況。先知平臺(tái)從產(chǎn)品上做了很多工作，比如說Schema推斷
3. 支持模型的上線，模型上線有幾個(gè)技術(shù)上的難點(diǎn)，一是線上線下的一致性，而是性能。線上線下一致性為什么難，因?yàn)槟憧吹接?xùn)練過程是那么復(fù)雜一個(gè)DAG圖，那么對應(yīng)的線上多個(gè)數(shù)據(jù)源，也要經(jīng)過一個(gè)組合、變換的過程，那如果每次都去手動(dòng)開發(fā)，這個(gè)代價(jià)就不得了。
先知的架構(gòu)支持從線下的DAG導(dǎo)出線上服務(wù)的核心部分，那么特征工程、模型計(jì)算就可以直接獲得一個(gè)可用的API，可以極大的節(jié)省開發(fā)者的代價(jià)。另外一個(gè)難題就是性能，因?yàn)榫€下批量的訓(xùn)練，可以花很長時(shí)間，而線上如果是實(shí)時(shí)預(yù)估，那么就要毫秒級的響應(yīng)，也要求很高的QPS。
我們在線上有一個(gè)叫Cannon的分布式KV框架，可以支持到數(shù)十T分布式內(nèi)存的模型高性能存儲(chǔ)和查詢。而模型計(jì)算的部分也可以復(fù)用GDBT的代碼，既減少了開發(fā)量，又為一致性提供了保證。這里面也有很多有意思的工程優(yōu)化，比如說如何解決機(jī)器數(shù)變大、網(wǎng)絡(luò)條件變差情況下的可用性塌方式下降。今天時(shí)間有限就不展開說了，有機(jī)會(huì)可以再跟大家分享。
小結(jié)
非常感謝大家耐心聽我們分享了上面我們做的這些微小的工作。第四范式是一個(gè)工程師為主的公司，我們有數(shù)十個(gè)來自于各大國內(nèi)外公司頂尖機(jī)器學(xué)習(xí)團(tuán)隊(duì)的優(yōu)秀工程師，各路ACM冠軍選手每天在各個(gè)方向上做很多深入的產(chǎn)品和工程優(yōu)化工作，希望能夠促進(jìn)機(jī)器學(xué)習(xí)和AI在各行各業(yè)的發(fā)展，也希望能夠給從業(yè)者們帶來更好用的平臺(tái)和工具。
當(dāng)然做出好的機(jī)器學(xué)習(xí)解決方案，最關(guān)鍵的還是要和行業(yè)結(jié)合，工具和平臺(tái)系統(tǒng)只是其中的一小部分，所以還希望能夠向各位同仁多多學(xué)習(xí)。這里打個(gè)小廣告，現(xiàn)在先知平臺(tái)公有云版本已經(jīng)向業(yè)務(wù)場景成熟的企業(yè)客戶有限名額的開放合作，如果有風(fēng)控、內(nèi)容推薦、客戶經(jīng)營等場景，數(shù)據(jù)量較大的朋友，我們也可以一起互相切磋，互相學(xué)習(xí)。謝謝大家。
Q&A
Q1：請問先知平臺(tái)用到深度學(xué)習(xí)框架了么？
答：現(xiàn)有的開源的深度學(xué)習(xí)框架不能完全解決先知平臺(tái)客戶的問題，因?yàn)楹芏鄬?shí)際的問題，除了包含稠密的連續(xù)特征之外，還有大規(guī)模的稀疏離散特征，目前大部分的開源框架大多focus在稠密連續(xù)特征的深度學(xué)習(xí)問題上，對學(xué)術(shù)界比較關(guān)心的同學(xué)，可能可以發(fā)現(xiàn)google最近有一篇wide&deep learning的論文是做類似的事情的，這個(gè)解決方案和我們?nèi)昵霸诎俣茸龅慕鉀Q方案很類似，但是很可惜的是開源的tensorflow在這個(gè)問題上效率非常糟糕。實(shí)際問題的難點(diǎn)在于它是IO密集（大規(guī)模稀疏）且計(jì)算密集的（稠密），而且這樣的模型是極其難調(diào)的，我們有很多新的算法在解決這方面的問題，不僅僅是深度學(xué)習(xí)。
Q2：是通過何種機(jī)制做到數(shù)百倍的加速的？
答：從算法設(shè)計(jì)到GDBT平臺(tái)設(shè)計(jì)和底層優(yōu)化，都有很多工作，今天的講座里面有涉及到一些，可以翻看記錄；
Q3：有沒有提出一些最優(yōu)化框架，比如SVRG等來加速收斂？
答：對于不同的問題，不同的場景，會(huì)對優(yōu)化算法有不同的需求，比如收斂速度、稀疏性、穩(wěn)定性、是否便于實(shí)現(xiàn)、是否便于分布式并行、是否訪存友好等等，先知支持多種優(yōu)化算法（batch/stochastic的都有），比如lbfgs、FOBOS、RDA、FTRL、SVRG、Frank-wolfe等等都會(huì)有涉及，同時(shí)針對不同的應(yīng)用場景也需要做一定的改進(jìn)和調(diào)整。
Q4：超參數(shù)學(xué)習(xí)這塊是通過bayes還是強(qiáng)化學(xué)習(xí)呢？
答：目前產(chǎn)品中的是bayesian的，其他方式也正在嘗試。
Q5：在何種情況下如何判定自動(dòng)特征不能起作用而改為人工特征呢？
答：有很多特征選擇的算法和策略，同時(shí)，對于實(shí)際的問題，可以先用自動(dòng)特征處理取得一個(gè)初步的效果，再從實(shí)際模型效果去看是否需要人工介入做進(jìn)一步的優(yōu)化，自動(dòng)特征工程是一個(gè)很難的問題，目前其實(shí)是很難做到100%全自動(dòng)的，我們平臺(tái)期望能夠盡最大可能的降低人力。
Q6：先知在實(shí)現(xiàn)過程中用到參數(shù)服務(wù)器了沒有？ 模型的訓(xùn)練，是采用異步asp，還是同步bsp，還是半異步的ssp這種？ 如果是異步，如何解決收斂困難的問題？
答：前面有提到，我們用到了parameter server。模型訓(xùn)練支持多種模式，對于不同的算法，不同的計(jì)算環(huán)境，會(huì)采用不同的同步方式。其實(shí)目前大部分情況下，如果數(shù)據(jù)切分 計(jì)算調(diào)度得當(dāng)，異步和同步差別沒有特別大，計(jì)算資源有較大差別的時(shí)候，還是建議帶版本控制；更好的方式是采用類似的計(jì)算資源做好數(shù)據(jù)切分和計(jì)算調(diào)度。
Q7: 第四范式的先知和谷歌的Tensor flow有什么區(qū)別？
答： 從覆蓋范圍上，先知是一個(gè)機(jī)器學(xué)習(xí)應(yīng)用全生命周期管理的平臺(tái)，而Tensorflow對應(yīng)的是先知的GDBT部分。而對于GDBT和Tensorflow的區(qū)別來說，前面也講到，首先Tensorflow更多是為算法研究目的而存在的，已經(jīng)有一些benchmark說明tensorflow比目前很多開源的深度機(jī)器學(xué)習(xí)框架都要慢，所以也有個(gè)外號(hào)叫Tensorslow。當(dāng)然我個(gè)人覺得這并不公平，因?yàn)門ensorflow本身也不是為大規(guī)模工業(yè)應(yīng)用設(shè)計(jì)的，只是現(xiàn)在好的框架的確太貧乏了。Tensorflow的一些設(shè)計(jì)理念比如高兼容性，跨平臺(tái)也是很好的。這方面GDBT也都有考慮和規(guī)劃。
Q8：GDBT有沒有解決模型并行訓(xùn)練問題？還是只依靠數(shù)據(jù)并行？
答：也分不同的算法，GDBT同時(shí)支持模型分布式和數(shù)據(jù)分布式。
Q9：GDBT怎么能夠同時(shí)支持連續(xù)、離散的這兩種數(shù)據(jù)的融合訓(xùn)練？
答：解決這個(gè)問題，一個(gè)是效率，首先框架底層上要能夠支持很靈活的調(diào)度，能夠根據(jù)連續(xù)和離散的數(shù)據(jù)的計(jì)算特性做針對性的設(shè)計(jì)，比如連續(xù)復(fù)雜模型是計(jì)算密集，可能需要調(diào)度到GPU運(yùn)算，離散數(shù)據(jù)可能是IO密集，需要做好計(jì)算調(diào)度，資源異步調(diào)度；更重要的是在算法上做更多的新的改進(jìn)，因?yàn)閷W(xué)術(shù)界大多情況下是分別考慮，我們有一系列自己重新設(shè)計(jì)的算法。對算法細(xì)節(jié)有興趣的同學(xué)，可以考慮加入到第四范式，或者等我們的專利公開:)
Q10：請問GDBT對于異構(gòu)計(jì)算的支持情況如何？
答：GDBT目前支持CPU和GPU的異構(gòu)計(jì)算。在百度的時(shí)候，我們有過在模型預(yù)測時(shí)使用FPGA，不過，最近GPU進(jìn)展不錯(cuò)，比如nvidia有一些新的芯片比如Tesla P4的出現(xiàn)，可能會(huì)對FPGA有一定的沖擊，對于FPGA的使用，目前我們研究上還是跟隨狀態(tài)，并沒有集成到先知產(chǎn)品中。
Q11：第四范式的人工智能平臺(tái)先知可以直接替代 Spark 么？
答： Prophet誕生的原因是因?yàn)槲覀優(yōu)楦鞣N行業(yè)提供服務(wù)，每個(gè)行業(yè)的差異化乍一看都不少，按照傳統(tǒng)的方式，我們需要case by case的去應(yīng)對，給出對應(yīng)的方法，然后進(jìn)行實(shí)施。但在這個(gè)case by case的過程中，大部分的精力是花在如何把對領(lǐng)域?qū)Ｓ兄R(shí)的理解（業(yè)務(wù)理解）轉(zhuǎn)換為機(jī)器學(xué)習(xí)過程的具體操作（數(shù)據(jù)科學(xué)家的工作），對于端到端的兩端，數(shù)據(jù) 和 服務(wù)，反而是比較通用的。那么如果能夠利用技術(shù)和算法，解決專有知識(shí)到對應(yīng)機(jī)器學(xué)習(xí)過程的映射問題，我們就可以建設(shè)一個(gè)通用的平臺(tái)來使得AI應(yīng)用到不同場景的代價(jià)變小，實(shí)現(xiàn)人工智能的傻瓜機(jī)。Prophet就是這個(gè)目標(biāo)的第一步。
首先Prophet定位在一套完整的平臺(tái)，包括核心機(jī)器學(xué)習(xí)算法框架GDBT（沒錯(cuò)不是GBDT，這是個(gè)算法框架，其作者起名為General Distributed Brilliant Technology），以及機(jī)器學(xué)習(xí)任務(wù)調(diào)度框架TM，以及人機(jī)接口Lamma，還有架設(shè)在整個(gè)框架上的一系列算子。當(dāng)然這些都是內(nèi)部名字無所謂，總的來說Prophet提供的是端到端的機(jī)器學(xué)習(xí)能力，進(jìn)來是數(shù)據(jù)，出去是Service。
然后關(guān)于GDBT和Spark，應(yīng)該說對比的是 基于GDBT的算法 以及 基于Spark的算法（MLLib實(shí)現(xiàn)），由于計(jì)算架構(gòu)的不同，所以簡單的來說多少多少倍是沒有太多的意義，因?yàn)槿绻卣骶暥榷嗟揭欢ǔ潭龋琈LLib在不做數(shù)據(jù)采樣的情況下是無法完成某些訓(xùn)練的。但是具體在幾千萬行，幾十個(gè)核的場景下，快幾百倍是實(shí)測結(jié)果。
另外，我們在做的事情，算法框架是一個(gè)部分，性能也是很重要的，但是做這些的目的是為了降低機(jī)器學(xué)習(xí)應(yīng)用于具體行業(yè)的門檻和先決要求。這個(gè)先決要求既包含硬件上的，也包含人在機(jī)器學(xué)習(xí)方面知識(shí)的要求。擁有更強(qiáng)大的計(jì)算能力和特征處理能力，意味著我們可以更少的讓人輸入信息，而更多的依靠計(jì)算機(jī)自身的學(xué)習(xí)和計(jì)算來找到機(jī)器學(xué)習(xí)算法在具體問題上應(yīng)用的最佳結(jié)合點(diǎn)，這其中甚至還需要包括如何去利用計(jì)算資源的投入避免機(jī)器學(xué)習(xí)常見的一些缺陷。
因此Prophet不會(huì)替代Spark，Prophet里面的很多組件也是基于Spark的，Prophet的目標(biāo)是把AI的能力較為容易的帶到各個(gè)應(yīng)用場景，為了這個(gè)目標(biāo)，我們會(huì)利用好GDBT，也會(huì)極致的利用好Spark，也會(huì)利用硬件技術(shù)的最新進(jìn)展。一切為了AI for everyone。
（以上部分來源于知乎：https://www.zhihu.com/question/48743915#）
簡單的來說，先知的設(shè)計(jì)范圍超出了Spark，包含了Spark，所以不能說是替代。
Q12：什么樣的企業(yè)用得起機(jī)器學(xué)習(xí)來輔助運(yùn)營？使用你們機(jī)器學(xué)習(xí)系統(tǒng)的門檻是什么?
答：從目前來看，需要有一個(gè)好的業(yè)務(wù)場景和足夠的數(shù)據(jù)。互聯(lián)網(wǎng)的APP或者非常大的傳統(tǒng)行業(yè)里面的推薦、營銷、定價(jià)等場景都比較適合。數(shù)據(jù)量小的就要看，通常來說10萬多樣本分布均勻就有這個(gè)可能。用這個(gè)機(jī)器學(xué)習(xí)系統(tǒng)目前的門檻是首先要能理解數(shù)據(jù)和業(yè)務(wù)，有一定的統(tǒng)計(jì)的背景和思路，然后就是能夠?qū)雽?dǎo)出數(shù)據(jù)，最后就是閱讀一下先知的使用手冊和培訓(xùn)視頻。
Q13：電商推薦平臺(tái)，怎么樣能最快地應(yīng)用機(jī)器學(xué)習(xí)的精準(zhǔn)推薦？
答：對于推薦場景，我們有相對比較成熟的接入方案，可以快速通過數(shù)據(jù)和API接入，通過公有云的SaaS服務(wù)享受到GDBT的能力以及先知的整體效果。有需求的朋友可以關(guān)注我們的官方網(wǎng)站和公眾號(hào)（NextParadigm），我們會(huì)近期放出先知推薦的試用邀請。
Q14：機(jī)器學(xué)習(xí)目前哪些企業(yè)和行業(yè)應(yīng)用比較廣泛？國內(nèi)有哪些成功案例。
答：大規(guī)模機(jī)器學(xué)習(xí)，BAT今日頭條等，廣告推薦為主，成不成功請看他們收錢增長的速度特別是百度09年之后的增長。我們在銀行最近的探索也有很多成功的例子，比如在營銷和定價(jià)、反欺詐方面。另外風(fēng)控一向是機(jī)器學(xué)習(xí)的主戰(zhàn)場。
Q15：自動(dòng)特征這套做法，跟百度鳳巢的那套是一樣的對吧？ 百度有公開論文，是gradient boosting factorization machine，這個(gè)方法比深度學(xué)習(xí)那個(gè)自動(dòng)特征相比如何
答：做法和夏粉老師的那套不一樣；夏老師和張潼老師這篇文章和nn-based的各有優(yōu)劣。其實(shí)NN沒有大家想的那么萬能，“人工”的很多feature combination是NN學(xué)不出來的，其中有很多有趣的問題，這里就不贅述了，可以再交流。
另外：對于FPGA和GPU的未來我們有一段簡單的思考，之前有準(zhǔn)備過一段，之前沒用上，現(xiàn)在貼這里：
FPGA是作為專用集成電路領(lǐng)域中的一種半定制電路而出現(xiàn)的，既解決了全定制電路的不足，又克服了原有可編程邏輯器件門電路數(shù)有限的缺點(diǎn)。機(jī)器學(xué)習(xí)尤其是深度學(xué)習(xí)是計(jì)算密集型的，比如深度學(xué)習(xí)里面有大量的浮點(diǎn)矩陣運(yùn)算這種并行浮點(diǎn)運(yùn)算需求，傳統(tǒng)的CPU從設(shè)計(jì)上而言已經(jīng)很難滿足這種大規(guī)模浮點(diǎn)計(jì)算密集型任務(wù)。目前針對這種機(jī)器學(xué)習(xí)任務(wù)，CPU主流的替代選擇是FPGA和GPU。
GPU是固定的計(jì)算架構(gòu)的計(jì)算設(shè)備，有著良好的軟件編程接口，但是對于特定的計(jì)算模式和模型結(jié)構(gòu)不一定是最優(yōu)的選擇。FPGA本身是一種可編程的硬件，對于有研發(fā)能力的廠商而言，深度優(yōu)化過的FPGA，相比GPU，能夠提供更專有的硬件加速，更重要的是FPGA在單位能耗上能提供的計(jì)算能力要高于GPU。
另外，企業(yè)級FPGA也比企業(yè)級GPU便宜很多。但是FPGA的缺點(diǎn)也非常明顯，對相關(guān)專業(yè)人才的要求非常高，需要能夠?qū)?fù)雜的機(jī)器學(xué)習(xí)算法映射到硬件邏輯上，同時(shí)提供高吞吐和低延遲，開發(fā)難度很大。對于中小公司而言，如果沒有相應(yīng)的FPGA研發(fā)能力，或者無法支撐高昂的研發(fā)成本，在機(jī)器學(xué)習(xí)尤其是深度學(xué)習(xí)的訓(xùn)練/預(yù)估硬件解決方案上可以選擇架構(gòu)固定的GPU；
而對于有相應(yīng)能力的大中型企業(yè)而言，F(xiàn)PGA帶來的硬件成本的大幅降低和能耗的大幅降低，能夠輕易覆蓋研發(fā)團(tuán)隊(duì)的費(fèi)用，在機(jī)器學(xué)習(xí)尤其是深度學(xué)習(xí)預(yù)估的硬件解決方案上FPGA會(huì)是更合適的選擇。
同時(shí)，在制造工藝上，相比于FPGA，GPU是固定的專用計(jì)算架構(gòu)且不提供可編程能力，可以通過不斷的芯片優(yōu)化，提供更強(qiáng)的計(jì)算能力，對于計(jì)算更加密集的深度學(xué)習(xí)訓(xùn)練任務(wù)，GPU現(xiàn)在還是更合適的選擇。隨著GPU在芯片上不斷優(yōu)化提升和能耗的降低，以及FPGA不斷提升芯片可提供的計(jì)算能力，兩者的差距在不斷縮小，未來兩者的地位是否會(huì)有大的變革，值得期待。
講師介紹
胡時(shí)偉 第四范式聯(lián)合創(chuàng)始人，研發(fā)副總裁
在大規(guī)模機(jī)器學(xué)習(xí)、廣告、搜索、行業(yè)垂直應(yīng)用、系統(tǒng)運(yùn)維、研發(fā)團(tuán)隊(duì)管理等領(lǐng)域擁有豐富經(jīng)驗(yàn)。
曾主持架構(gòu)了百度“知心”系統(tǒng)和鏈家網(wǎng)系統(tǒng)，在百度任職期間作為系統(tǒng)架構(gòu)負(fù)責(zé)人，主持了百度商業(yè)客戶運(yùn)營、鳳巢新興變現(xiàn)、“商業(yè)知心”搜索、阿拉丁生態(tài)等多個(gè)核心系統(tǒng)的架構(gòu)設(shè)計(jì)工作。在擔(dān)任鏈家網(wǎng)研發(fā)負(fù)責(zé)人期間，從0開始完成了鏈家網(wǎng)新主站、經(jīng)紀(jì)人新作業(yè)系統(tǒng)、績效變革系統(tǒng)的整體架構(gòu)設(shè)計(jì)以及研發(fā)團(tuán)隊(duì)的建設(shè)管理，參與規(guī)劃及推動(dòng)了鏈家系統(tǒng)和研發(fā)體系的互聯(lián)網(wǎng)化轉(zhuǎn)型。
現(xiàn)任第四范式研發(fā)總工程師，負(fù)責(zé)產(chǎn)品技術(shù)團(tuán)隊(duì)以及第四范式核心產(chǎn)品『先知』機(jī)器學(xué)習(xí)平臺(tái)的研發(fā)工作。
涂威威 第四范式數(shù)據(jù)建模專家
在大規(guī)模分布式機(jī)器學(xué)習(xí)系統(tǒng)架構(gòu)、大規(guī)模機(jī)器學(xué)習(xí)算法設(shè)計(jì)和應(yīng)用、在線營銷系統(tǒng)方面有深厚積累。
百度最高獎(jiǎng)triity發(fā)起人之一。
首次將FPGA應(yīng)用于在線營銷深度學(xué)習(xí)預(yù)估系統(tǒng)。
設(shè)計(jì)開發(fā)百度機(jī)器學(xué)習(xí)計(jì)算框架ELF。
聯(lián)系客服
