摘要：?大數(shù)據(jù)計(jì)算服務(wù)（MaxCompute）是一種快速、完全托管的 GB/TB/PB 級數(shù)據(jù)倉庫解決方案，目前已在阿里巴巴內(nèi)部得到大規(guī)模應(yīng)用。來自阿里媽媽基礎(chǔ)平臺大規(guī)模數(shù)據(jù)處理技術(shù)專家向大家分享了MaxCompute在阿里媽媽數(shù)據(jù)字化營銷解決方案上的典型應(yīng)用經(jīng)驗(yàn)。首先介紹了廣告數(shù)據(jù)流，分析了MaxCompute 是如何解決廣告的問題；然后通過阿里媽媽內(nèi)部的應(yīng)用經(jīng)典場景來介紹其如何使用MaxCompute；最后介紹了MaxCompute提供的高級配套能力以及在計(jì)算和存儲方面的優(yōu)化。?

PPT材料下載地址：https://yq.aliyun.com/download/2730

視頻地址：https://edu.aliyun.com/lesson_1010_8790?spm=5176.10731542.0.0.Zy64Up#_8790

產(chǎn)品地址：https://www.aliyun.com/product/odps

演講嘉賓簡介：

梁時(shí)木(載思)，阿里媽媽基礎(chǔ)平臺大規(guī)模數(shù)據(jù)處理技術(shù)專家。

以下內(nèi)容根據(jù)演講嘉賓視頻分享以及PPT整理而成。

?

本次的分享主要分為兩部分：

一、?題外話：該部分主要介紹在聽完之前的分享后，嘉賓的幾點(diǎn)個(gè)人感受 。

二、廣告數(shù)據(jù)流介紹： 該部分主要是對沒有中間商賺差價(jià)的廣告數(shù)據(jù)流的基本介紹以及為什么MaxCompute能解決廣告的問題。

三、典型應(yīng)用場景：該部分主要通過阿里媽媽內(nèi)部的應(yīng)用經(jīng)典場景來介紹其如何使用MaxCompute，包括數(shù)據(jù)分層體系、報(bào)表和BI、搜索引擎索引構(gòu)建和算法實(shí)驗(yàn)。

四、高級功能和優(yōu)化：該部分主要就阿里媽媽在五六年的MaxCompute內(nèi)部使用和管理過程中的相關(guān)高級功能和優(yōu)化進(jìn)行公開分享，包括MaxCompute提供的高級配套能力以及在計(jì)算和存儲方面的優(yōu)化。

?

一、題外話

?

開始之前先聊一點(diǎn)題外話，是我在聽完剛才的分享之后的幾點(diǎn)感受。其實(shí)我從2013年就開始在內(nèi)部項(xiàng)目中使用MaxCompute,阿里媽媽作為第一批登月用戶，踩了很多坑。聽了剛才的分享，我的第一感受是，MaxCompute有好多功能我們都沒有關(guān)注過，作為一個(gè)資深用戶，很多功能都不知道聽起來好像有點(diǎn)不太合格，但轉(zhuǎn)念一想這可能是MaxCompute作為一個(gè)平臺、一個(gè)生態(tài)解決方案應(yīng)該具備的一種能力。就是說它讓一個(gè)終端用戶只需要看到你所關(guān)注的東西，有一些你不太關(guān)注的，而對于整個(gè)生態(tài)鏈上又必須有的東西它可能潛移默化的幫你做了，在我看來這其實(shí)是一種很強(qiáng)的能力。在聽完分享后的另一個(gè)感受就是我還是蠻慶幸在阿里這邊做這些事情的，一些中小公司在基礎(chǔ)設(shè)施服務(wù)這塊很需要一些第三方平臺的支持，因?yàn)槟銜?huì)發(fā)現(xiàn)它們?nèi)绻麖念^搭建的話，成本會(huì)特別高，而MaxCompute、阿里包括釘釘這樣的產(chǎn)品，撇開商業(yè)化這個(gè)因素，它們更多的其實(shí)是幫助我們推動(dòng)互聯(lián)網(wǎng)技術(shù)的進(jìn)步，幫助我們做一些基礎(chǔ)上的事情，從而讓我們有更多的精力去關(guān)注與自己業(yè)務(wù)相關(guān)的事情。

?

二、廣告數(shù)據(jù)流

?

聊完題外話，下面正式開始我的分享。首先向大家介紹一下廣告數(shù)據(jù)流。下圖是廣告數(shù)據(jù)流的一個(gè)簡化版本，因?yàn)槲覀兘裉斓闹黝}是大數(shù)據(jù)相關(guān)的計(jì)算，所以我們站在整個(gè)數(shù)據(jù)流的角度簡化介紹傳統(tǒng)廣告，如搜索廣告和定向廣告。在圖中可以很清楚的看到，從角色上來說，比較受關(guān)注的是廣告主和網(wǎng)民兩個(gè)角色。

?

?

廣告主后臺

?

一般來講，廣告主首先會(huì)在廣告主后臺進(jìn)行相關(guān)的廣告設(shè)置，舉個(gè)最簡單的例子，一個(gè)廣告主要做一次廣告投放，首先需要設(shè)置一些基本信息，如將廣告投給“來自北京”的“男性”，或者當(dāng)用戶搜索“連衣裙”的時(shí)候?qū)V告投給他（她）。

?

投放引擎

?

廣告主做完設(shè)置之后，會(huì)用到最重要的一個(gè)服務(wù)，即投放引擎。它的作用是當(dāng)廣大網(wǎng)民在百度或淘寶鍵入搜索信息后想其投放相關(guān)的廣告。比如淘寶搜索“連衣裙”，結(jié)果頁里面顯示的一部分是自然搜索結(jié)果，還有一部分是帶有“廣告”圖標(biāo)的結(jié)果，這些結(jié)果就是通過投放引擎投放給廣大網(wǎng)民的。

與網(wǎng)民最相關(guān)的兩個(gè)行為是廣告曝光和廣告點(diǎn)擊。當(dāng)網(wǎng)民在使用某個(gè)平臺進(jìn)行搜索的時(shí)候，比如淘寶，投放引擎里面會(huì)用到兩個(gè)很關(guān)鍵的模塊來決定將什么廣告投放給網(wǎng)民，即索引和算法：

·???????索引構(gòu)建。當(dāng)用戶鍵入某個(gè)搜索關(guān)鍵詞后，如淘寶搜索“連衣裙”，會(huì)有上萬條商品滿足該關(guān)鍵詞，不可能將所有的商品都投放給用戶。 這個(gè)時(shí)候的解決方案是首先從廣告庫中查詢有多少廣告買了該商品，這個(gè)數(shù)據(jù)需要廣告主在后臺設(shè)置，即哪些廣告可以投放給該關(guān)鍵詞。

·???????算法模型。假如有一萬個(gè)廣告候選集，相關(guān)的評分服務(wù)會(huì)根據(jù)一系列的特征和后臺訓(xùn)練出來的模型對所有的廣告進(jìn)行打分排序，最終按照一定的規(guī)則展現(xiàn)給用戶。

?

反作弊

?

上面介紹的是網(wǎng)民看到廣告的過程，相應(yīng)的在系統(tǒng)后臺會(huì)產(chǎn)生一些日志，最典型的是廣告的曝光和點(diǎn)擊日志，會(huì)用到反作弊的模塊。因?yàn)楹芏鄷r(shí)候網(wǎng)民的行為不一定人操作的，有些是通過API或工具等惡意的手段進(jìn)行競爭，反作弊模塊的作用就是對這些行為進(jìn)行判斷并給出相應(yīng)懲罰決策，如扣費(fèi)。

?

基礎(chǔ)數(shù)據(jù)

?

經(jīng)過反作弊模塊的數(shù)據(jù)我們認(rèn)為是可信賴的，會(huì)將其存儲在基礎(chǔ)數(shù)據(jù)平臺中，此處的基礎(chǔ)數(shù)據(jù)平臺是一個(gè)抽象的概念，最終其實(shí)就是MaxCompute。

?

報(bào)表/BI

?

有了數(shù)據(jù)之后，最常見的兩個(gè)應(yīng)用場景是做報(bào)表/BI分析和模型訓(xùn)練。

·???????報(bào)表/BI分析。主要有兩種情況，一種情況是廣告主在設(shè)置了廣告投放之后，想要了解廣告的投放效果，此時(shí)會(huì)有相應(yīng)的統(tǒng)計(jì)數(shù)據(jù)到廣告主后臺；另一種情況下BI運(yùn)營的人員也會(huì)對這些數(shù)據(jù)進(jìn)行分析，如某些廣告位的表現(xiàn)情況。

·???????模型訓(xùn)練。前面已經(jīng)提到，投放引擎第一步只能拿到一個(gè)很大的廣告候選集，如何篩選用戶預(yù)估分最高的廣告并投放給用戶是模型訓(xùn)練這個(gè)模塊要做的事情。該模塊需要用已經(jīng)存儲的原始基礎(chǔ)數(shù)據(jù)去跑各種各樣的模型，從最傳統(tǒng)的邏輯回歸到現(xiàn)在的深度學(xué)習(xí)，跑完的數(shù)據(jù)再推送到投放引擎，這個(gè)時(shí)候就可以實(shí)現(xiàn)廣告的在線評分功能。

?

以上是廣告的簡要數(shù)據(jù)流的介紹，接下來分享為什么我們這么久以來一直堅(jiān)持用MaxCompute。總結(jié)一下主要有三點(diǎn)，即數(shù)據(jù)友好、生態(tài)完善持續(xù)改進(jìn)和性能強(qiáng)悍。

?

1)?????用戶友好。從剛才的數(shù)據(jù)流介紹中，或多或少能看到一點(diǎn)，我們的應(yīng)用場景有很多，比如反作弊的場景，再比如報(bào)表和BI分析的場景，針對此MaxCompute提供各種各樣的計(jì)算能力和豐富易用的編程接口。最傳統(tǒng)的是SQL的表達(dá)支持，如果SQL表達(dá)的語義不滿足要求，加UDF仍然解決不了問題，MaxCompute還支持用戶自己寫一個(gè)MapReduce，提供原始數(shù)據(jù)用戶可以自己去加工；還支持用戶做一些圖計(jì)算像Deep Learning；另外MaxCompute本身也是支持Batch和Streaming兩種功能，包括之前提到的Spark Streaming；還有一點(diǎn)也是我比較喜歡的，在Hadoop生態(tài)圈中，大家其實(shí)更多的看到的是HDFS文件路徑，那在MaxCompute中，我們更多的看到的是一堆一堆的表，表對用戶來講有Schema，比空洞的文件更容易理解一點(diǎn)，針對這些表MaxCompute提供API層面的操作支持，另外也提供相應(yīng)的Function，包括UDF、UDTF類型的支持；同時(shí)MaxCompute還提供半結(jié)構(gòu)化類型的支持，如Volume，支持用戶操作相關(guān)的Resource。上述介紹的功能為用戶的開發(fā)提供了便利。

2)?????生態(tài)完善持續(xù)改進(jìn)。MaxCompute是一個(gè)平臺，一個(gè)生態(tài)系統(tǒng)。在體驗(yàn)過MaxCompute整套系統(tǒng)之后，我們發(fā)現(xiàn)其可以應(yīng)用到我們開發(fā)、運(yùn)維管理的整個(gè)過程中。從最開始數(shù)據(jù)產(chǎn)出之后，如果要加載到MaxCompute平臺中，可以通過“同步工具”來完成；數(shù)據(jù)同步之后，如果想要做數(shù)據(jù)處理，可以通過“DataWorks” 跑一些的簡單的模型來做數(shù)據(jù)分析和處理；復(fù)雜的數(shù)據(jù)處理可以通過“算法實(shí)驗(yàn)平臺” 來完成，目前支持TensorFlow上的一些功能；數(shù)據(jù)處理完后，傳統(tǒng)的做法是只看數(shù)據(jù)是否正確，但這對于系統(tǒng)管理人員來講是遠(yuǎn)遠(yuǎn)不夠的，還需要看結(jié)果好不好，是否有優(yōu)化的空間，以保證投入產(chǎn)出比，比如傳統(tǒng)的離線任務(wù)，分配資源的方式是基于plan的模式，用戶需要預(yù)先預(yù)估一個(gè)instance需要多少CPU和Memory，但是會(huì)存在兩個(gè)明顯問題，一個(gè)是依靠經(jīng)驗(yàn)的估計(jì)是不準(zhǔn)確的，另一個(gè)是現(xiàn)在的數(shù)據(jù)量是在不停變化的，無法很好地估計(jì)。針對這個(gè)需求，“數(shù)據(jù)治理”會(huì)給用戶相應(yīng)的反饋。

3)?????性能強(qiáng)悍。阿里媽媽作為業(yè)界數(shù)字化營銷的廠商來說，數(shù)據(jù)量非常大。目前使用MaxCompute已經(jīng)可以完成EB級別的數(shù)據(jù)存儲；在具體的場景中，可以完成千億級樣本百億級特征的訓(xùn)練實(shí)驗(yàn)；跑一個(gè)MapReduce或SQL的Job，MaxCompute可以實(shí)現(xiàn)十萬級實(shí)例的并發(fā)調(diào)度，后臺遠(yuǎn)遠(yuǎn)超過十萬實(shí)例的并發(fā)度；阿里媽媽一個(gè)BU，目前一天之內(nèi)跑在MaxCompute的Job數(shù)已經(jīng)達(dá)到十萬級別；最后是我們的報(bào)表數(shù)據(jù)，這其實(shí)也是最常見的一個(gè)場景，目前我們在MaxCompute的報(bào)表數(shù)據(jù)已經(jīng)到千億級別。

?

三、幾個(gè)典型的應(yīng)用場景

?

介紹完為什么使用MaxCompute之后，再給大家分享一下阿里媽媽的幾個(gè)典型的應(yīng)用場景中是如何使用MaxCompute的。

?

數(shù)據(jù)分層

?

?

前面介紹了廣告數(shù)據(jù)流，我們針對MaxCompute也對數(shù)據(jù)進(jìn)行了劃分（如上圖所示），主要?jiǎng)澐譃榱鶎?。

1)?????第一層是原始數(shù)據(jù)層，原始數(shù)據(jù)的來源一般有兩個(gè)，一個(gè)是我們的業(yè)務(wù)數(shù)據(jù)庫，比圖MySQL或Hbase,另一個(gè)是我們的業(yè)務(wù)訪問日志，如剛才提到的廣告的曝光和點(diǎn)擊日志，這些數(shù)據(jù)是放在我們的服務(wù)器上面的。

2)?????第二層是ODS層，即通過同步工具同步到MaxCompute平臺的數(shù)據(jù)，與原始數(shù)據(jù)同Schema。原始數(shù)據(jù)要做離線處理的時(shí)候（包括Streaming處理），我們內(nèi)部使用同步中心平臺進(jìn)行全量和增量同步，同時(shí)也會(huì)使用TimeTunnel進(jìn)行整個(gè)服務(wù)器日志的采集。最終同步到MaxCompute平臺的數(shù)據(jù)與原始數(shù)據(jù)是同Schema的，但是它能以天級、小時(shí)級、分鐘級實(shí)時(shí)或準(zhǔn)實(shí)時(shí)的將數(shù)據(jù)同步到離線平臺里面。

3)?????第三層是PDW/DWD。有了同步的數(shù)據(jù)后，大家知道，數(shù)據(jù)的格式是千奇百怪的，以日志為例，我們線上回流的日志是遵循一定的協(xié)議的，想要把數(shù)據(jù)真正用起來還需要經(jīng)過一系列的操作。第一步會(huì)進(jìn)行數(shù)據(jù)清洗，包括上面提到的反作弊也是一種清洗的方式；然后會(huì)對數(shù)據(jù)進(jìn)行簡單的拆解，將其拆解成可以理解的字段。

4)?????第四層是中間層MID/DWB。數(shù)據(jù)量過大的情況之下，比如阿里媽媽一天產(chǎn)出的業(yè)務(wù)數(shù)據(jù)高達(dá)幾十億，這個(gè)數(shù)據(jù)量根本無法實(shí)現(xiàn)直接處理分析，所以我們的做法是使用中間層，對DWD數(shù)據(jù)進(jìn)行上卷、字段篩選和Join，后續(xù)業(yè)務(wù)的應(yīng)用基本上是基于中間層來做的。

5)?????第五層是各種應(yīng)用場景生成的數(shù)據(jù)層APP/ADS/DWS。具體的場景包括離線報(bào)表和BI、全量索引構(gòu)建、模型訓(xùn)練，后面會(huì)從這三個(gè)方面的的場景來具體介紹以下如何使用MaxCompute。

6)?????最后是在線服務(wù)和在線數(shù)據(jù)存儲層。

?

報(bào)表和BI

?

?

首先介紹一下報(bào)表和BI是怎么使用MaxCompute的。對于一般的用戶來說，我們只需要了解兩部分內(nèi)容，包含什么Table，用SQL怎么處理它們。報(bào)表和BI具備以下兩個(gè)特點(diǎn)：

1)?????二維表和圖表為主。對于廣告主來講，信息的呈現(xiàn)主要通過二維表來完成，通過過濾排序就能看到想要了解的結(jié)果；而對于運(yùn)營人員來講，除了二維表之外，可能還需要一些圖表的具體分析。我們會(huì)提供這樣一種能力，這種能力就是，比如想要給廣告主來看的話，提供數(shù)據(jù)導(dǎo)出功能，將數(shù)據(jù)直接導(dǎo)到線上，供廣告主在后臺直接查看效果；其次在部門內(nèi)部發(fā)送支持郵件；再次我們提供類似小站的功能，即個(gè)性化門戶站點(diǎn)，后面會(huì)通過簡單的demo進(jìn)行展示。

2)?????高度SQL。上述介紹的所有功能都是高度依賴SQL的，大部分情況下是不需要做一些Java開發(fā)的，也不需要去寫太多的UDF，用戶在報(bào)表和BI中只需要去寫SQL，有些甚至只需要拖拽幾下就可以得到想要的結(jié)果。

?

下圖是報(bào)表和BI使用MaxCompute的demo截圖。用戶輸入簡單SQL表達(dá)之后，通過簡單的預(yù)處理就能看到想要的數(shù)據(jù)，這個(gè)數(shù)據(jù)不僅可以在系統(tǒng)中查看，還可以通過郵件的方式發(fā)送，或者推送的線上進(jìn)行展示。

?

?

索引構(gòu)建

?

?

廣告主在后臺更改投放設(shè)置之后，一旦數(shù)據(jù)量達(dá)到百萬、千萬甚至上億級別的時(shí)候，需要針對在線查詢做專有的引擎服務(wù)。阿里媽媽廣告搜索引擎索引構(gòu)建使用MaxCompute如上圖所示，使用的是Lambda架構(gòu)，支持離線和在線，可以使用Batch和Streaming處理和消費(fèi)。使用該架構(gòu)的背景是當(dāng)時(shí)阿里媽媽在做索引更新的時(shí)候，每天伴隨著各種各樣的實(shí)驗(yàn)來查看效果，常常會(huì)加很多字段，而且這種情況下并行的需求很高，所以我們對系統(tǒng)的要求是必須支持高頻的快速迭代，當(dāng)時(shí)我們定的目標(biāo)是加一個(gè)字段要在半天或者一天之內(nèi)搞定，并將結(jié)果推上線，同時(shí)要支持多人同時(shí)做這個(gè)事情，為了實(shí)現(xiàn)該需求，我們當(dāng)時(shí)也做了一些類似于組件化的工作。

對于整個(gè)索引構(gòu)建服務(wù)，由于時(shí)間關(guān)系在此只展示業(yè)務(wù)層，業(yè)務(wù)處理過程中需要面對各種異構(gòu)數(shù)據(jù)源，圖左側(cè)數(shù)據(jù)源層（Data Source Layer），如業(yè)務(wù)數(shù)據(jù)（來自MySQL）、算法數(shù)據(jù)和其他外部數(shù)據(jù)，最終將其沉淀到業(yè)務(wù)層（Business Layer）引擎的索引中，使其支持各種各樣的查詢。數(shù)據(jù)從數(shù)據(jù)源層到業(yè)務(wù)層需要經(jīng)過離線數(shù)據(jù)中心層（Offline DataCenter Layer）,分為上下兩部分，上半部分是批量層（Batch Layer），下半部分是Streaming層（Streaming Layer）。數(shù)據(jù)源的接入方式有兩種，一種是全量的方式，意思是將MaxCompute上面的一張表直接拖拽過來，然后跑一個(gè)離線的索引；但是還有一種情況，比如說廣告主做了一次改價(jià)，這種更改需要快速地反映到索引中，否則索引中一直存放的是舊信息，將會(huì)造成廣告主的投訴，因此除了全量流之外，還提供增量流，以將用戶的更改實(shí)施反饋到索引中。

·???????離線部分。我們提供一個(gè)類似同步工具的服務(wù)，叫做Importer，它是基于MaxCompute來實(shí)現(xiàn)的，大部分功能是跑在MaxCompute上的，因?yàn)檫@里面我們進(jìn)行了組件化，需要進(jìn)行一系列的類似于數(shù)據(jù)Combine、Merge的操作，還涉及到源數(shù)據(jù)的Schema和數(shù)據(jù)的多版本管理。離線數(shù)據(jù)存入ODPS中，通過Maxcompute的Batch views來查看。

·??????在線部分。簡單來講，比如拿到一條MySQL增量，通過解析將其直接流入消息隊(duì)列中，然后通過相應(yīng)的平臺包括Storm、Spark以及MaxCompute的Streaming等，利用和離線部分類似的組件跑索引。接下來通過Realtime views可以查到最新的數(shù)據(jù)，目前通過tair來實(shí)現(xiàn)。實(shí)時(shí)部分的數(shù)據(jù)每隔一定時(shí)間進(jìn)行Merge，就會(huì)形成多版本的數(shù)據(jù)。它的作用有兩個(gè)，一個(gè)是將這些數(shù)據(jù)直接批量往在線部分去灌，尤其是在線上數(shù)據(jù)出問題、走增量流程很慢的時(shí)候；另一個(gè)是在做離線索引構(gòu)建的時(shí)候，為了避免索引膨脹的問題，需要定期做一次離線全量，為了保證數(shù)據(jù)實(shí)時(shí)更新，需要有一條增量流在此期間往全量部分注入數(shù)據(jù)，為了避免因?yàn)榉?wù)宕機(jī)導(dǎo)致的效率低下，我們提供了多個(gè)版本增量數(shù)據(jù)的保存。

?

算法實(shí)驗(yàn)

?

?

接下來介紹一下算法實(shí)驗(yàn)使用MaxCompute的場景。不僅僅是算法實(shí)驗(yàn)，包括我們每天往線上推我們的性能模型的時(shí)候，都是下圖這套流程。整個(gè)流程的輸入是線上日志，比如哪些用戶瀏覽和點(diǎn)擊了哪些廣告，輸出是對用戶的瀏覽和點(diǎn)擊分析后抽取的特征進(jìn)行在線評分。中間大致可以抽象為六個(gè)步驟：

1)?????數(shù)據(jù)處理。數(shù)據(jù)處理除了前面提到的清洗和過濾反作弊之外，做的最簡單的是將多份數(shù)據(jù)合并成一份數(shù)據(jù)，這里面除了用到MapReduce和SQL之外，還用到了ShardJoin，是阿里媽媽和MaxCompute合作，為了應(yīng)對在離線數(shù)據(jù)進(jìn)行Join的過程中，兩邊數(shù)據(jù)都特別大時(shí)效率低的問題而開發(fā)的。原理很簡單，就是將右表拆成很多小塊，使用獨(dú)立RPC服務(wù)去查。數(shù)據(jù)處理在整個(gè)過程中的時(shí)間占比約為20%。

2)?????特征提取。經(jīng)過第一步之后輸出的結(jié)果是一整個(gè)不加處理的PV表，包含一系列的屬性字段，然后在此基礎(chǔ)上進(jìn)行特征提取，常用的是跑一個(gè)MapReduce，最重要的是有JNI的操作，實(shí)現(xiàn)特征提取和特征組合，生成唯一的key。比如我想要把UserId和Price聯(lián)合算出一個(gè)新的特征。原始的特征可能只有幾百個(gè)，但經(jīng)過交叉、笛卡爾積等操作之后，特征可能會(huì)達(dá)到幾百億，這個(gè)時(shí)候前面所提到的MaxCompute支持千億級別樣本、百億級別的計(jì)算能力便得到很好地發(fā)揮，這對于調(diào)度包括整個(gè)計(jì)算框架具有極其重要的意義。特征提取在整個(gè)過程中的時(shí)間占比約為15%。

3)?????樣本生成。一條樣本出來后一般需要設(shè)置target和正負(fù)例，針對每一個(gè)特征會(huì)生成一個(gè)全局id，最后進(jìn)行序列化。之所以進(jìn)行序列化是因?yàn)槊總€(gè)計(jì)算框架對于輸入樣本會(huì)有格式要求，序列化實(shí)際上是對輸入樣本進(jìn)行相應(yīng)的格式轉(zhuǎn)換。樣本生成在整個(gè)過程中的時(shí)間占比約為15%。

4)?????模型訓(xùn)練。模型訓(xùn)練的輸入是上一步產(chǎn)生的千億級別的樣本，輸出是每一個(gè)特征的權(quán)重。比如“男性”這個(gè)特征的權(quán)重，購買力是一顆星對應(yīng)的特征的權(quán)重。模型訓(xùn)練在整個(gè)過程中的時(shí)間占比是40%左右，這個(gè)時(shí)間和模型復(fù)雜度有關(guān)，比如說是運(yùn)行了簡單的邏輯回歸或者復(fù)雜的深度學(xué)習(xí)，時(shí)間是不同的。

5)?????模型評估。有了訓(xùn)練后的模型，接下來要進(jìn)行評估，使用Auc評估訓(xùn)練模型的效果。一般在樣本生成的時(shí)候會(huì)對樣本進(jìn)行分類，分為訓(xùn)練樣本和測試樣本，使用測試樣本對訓(xùn)練好的模型進(jìn)行評估。模型評估在整個(gè)過程中的時(shí)間占比是5%。

6)?????模型應(yīng)用。模型評估達(dá)到一定標(biāo)準(zhǔn)之后就可以將訓(xùn)練好的模型推到線上，這個(gè)過程比較復(fù)雜，包括數(shù)據(jù)導(dǎo)出、數(shù)據(jù)分發(fā)、加載、切換生成在線打分服務(wù)。模型應(yīng)用在整個(gè)過程中的時(shí)間占比是5%。

?

以上介紹的六個(gè)步驟和MaxCompute最相關(guān)的是數(shù)據(jù)處理（20%）、特征提取（15%）、樣本生成（15%）和模型訓(xùn)練（40%），時(shí)間占比百分之九十以上的操作都是在MaxCompute進(jìn)行的。

?

?

?

為了支撐算法實(shí)驗(yàn)，我們基于MaxCompute搭建了算法實(shí)驗(yàn)框架（如上圖所示）。整個(gè)模型訓(xùn)練不需要開發(fā)太多的代碼，一般來講只需要做兩個(gè)方面的改動(dòng)，傳統(tǒng)的邏輯回歸需要增刪改特征，深度學(xué)習(xí)中需要更改各種網(wǎng)絡(luò)，整個(gè)流程是高度一致的。因此我們將這個(gè)過程抽象成為Matrix的解決方案。這套解決方案對外來講是運(yùn)行了一個(gè)pipeline，串聯(lián)一系列任務(wù)，這些任務(wù)最終運(yùn)行在MaxCompute上面。對外提供Matrix Client，用戶大部分情況下只需要進(jìn)行配置文件的修改，比如設(shè)置特征抽取的方式，知道原表的Schema抽第幾行第幾個(gè)字段；抽取的特征怎么做組合，如第一個(gè)特征和第二個(gè)特征進(jìn)行叉乘生成新的特征；包括特征選擇方式，如低頻特征進(jìn)行過濾。框架將上述功能組件化，用戶只需要像拼積木一樣將需要的功能拼接起來，每一個(gè)積木進(jìn)行相應(yīng)的配置，比如輸入表是什么。樣本輸入模型之前，樣本的格式是固定的，在此基礎(chǔ)上我們實(shí)現(xiàn)了調(diào)度框架Husky，主要實(shí)現(xiàn)pipeline的管理，實(shí)現(xiàn)任務(wù)的最大化并行執(zhí)行。其他功能由于時(shí)間關(guān)系在此不多做介紹。

?

四、高級功能和優(yōu)化

?

高級配套能力

?

因?yàn)榘⒗飲寢屧贛axCompute上曾經(jīng)的資源使用量占比達(dá)到三分之一，從計(jì)算到存儲。因此我們根據(jù)自己的經(jīng)驗(yàn)，接下來分享一下大家有可能用到的MaxCompute的一些高級功能和優(yōu)化。

?

?

MaxCompute提供了我們認(rèn)為比較重要的四個(gè)功能有：

1)?????實(shí)時(shí)Dashboard和Logview。Logview前面已經(jīng)介紹過了，通過它用戶可以不用再去扒日志，可以很快速地查看任務(wù)情況，查找問題原因，另外還提供各種實(shí)時(shí)診斷的功能。當(dāng)集群出現(xiàn)問題的時(shí)候?qū)崟r(shí)Dashboard可以從從各個(gè)維度幫用戶分析當(dāng)前運(yùn)行集群的Project或Quta或任務(wù)相關(guān)信息，其后臺依賴于一系列的源數(shù)據(jù)管理。當(dāng)然，MaxCompute能提供的功能遠(yuǎn)不止實(shí)時(shí)Dashboard和Logview，但是這兩個(gè)功能在個(gè)人、集群管理過程是被高度依賴的。

2)?????強(qiáng)大的調(diào)度策略。主要有三種：

·???????第一種是交互式搶占。傳統(tǒng)的搶占方式比較粗暴，當(dāng)用戶提交一個(gè)任務(wù)的時(shí)候，比如分Quta，無論是Hadoop還是MaxCompute，都會(huì)分析是minQuta還是maxQuta，這種情況下一定會(huì)涉及到共享與資源搶占的問題。如果不搶占，一個(gè)任務(wù)會(huì)跑很長時(shí)間；如果直接將任務(wù)停掉，已經(jīng)運(yùn)行起來的任務(wù)可能需要重新再運(yùn)行，導(dǎo)致效率低下。交互式搶占比較好地解決了這個(gè)問題，其提供了一種協(xié)議，這個(gè)協(xié)議需要和各個(gè)框架之間達(dá)成，比如說要kill掉某個(gè)任務(wù)之前，會(huì)在一定時(shí)間之前發(fā)送kill的命令，并給予任務(wù)指定的運(yùn)行時(shí)間，如果這個(gè)時(shí)間結(jié)束之后仍然運(yùn)行不完，則kill掉。

·???????第二種是全局調(diào)度。阿里云的機(jī)器已經(jīng)達(dá)到了萬級，當(dāng)某個(gè)集群的任務(wù)跑的很卡的時(shí)候，如果發(fā)現(xiàn)其他集群比較空閑，全局調(diào)度策略便可以發(fā)揮作用，將任務(wù)分配到較為空閑的集群上運(yùn)行，這種調(diào)度過程對于用戶來講是透明的，用戶只能直觀地感受任務(wù)的運(yùn)行速度發(fā)生變化。

·???????第三種是兼顧All-or-nothing和Increment的資源分配方式。簡單來講，比如前者跑了圖計(jì)算的訓(xùn)練模型，后者跑了SQL，這兩種計(jì)算的資源分配方式有很大不同。對于SQL來講，如果需要一千個(gè)實(shí)例來運(yùn)行mapper，不用等到一千個(gè)實(shí)例攢夠了再去運(yùn)行，可以拿到一個(gè)實(shí)例運(yùn)行一個(gè)mapper,因?yàn)檫@種計(jì)算實(shí)例之間沒有信息交互；但是模型訓(xùn)練是一輪一輪進(jìn)行迭代的，第一輪迭代運(yùn)行完之后才能開始運(yùn)行第二輪迭代，因此注定需要所有的資源準(zhǔn)備好了之后才能運(yùn)行，因此阿里云的調(diào)度人員在后臺做了很多兼顧這兩方面資源分配的工作。

3)?????數(shù)據(jù)地圖。幫助的用戶描述數(shù)據(jù)、任務(wù)之間的關(guān)系，方便用戶后續(xù)業(yè)務(wù)的處理。

4)?????數(shù)據(jù)治理。任務(wù)運(yùn)行結(jié)束對于集群或者任務(wù)管理人員來講并沒有結(jié)束，還需要去看任務(wù)跑得好不好，這個(gè)時(shí)候服務(wù)治理就可以提供很多優(yōu)化建議，比如某個(gè)數(shù)據(jù)跑到最后沒有人用，那與其相關(guān)的鏈路是否可以取消，這種治理不管對于內(nèi)部系統(tǒng)還是外部系統(tǒng)來講可以節(jié)省很多的資源開銷。

?

計(jì)算優(yōu)化

?

?

?

接下來就上面介紹的數(shù)據(jù)治理向大家分享一下我們的經(jīng)驗(yàn)。在數(shù)據(jù)治理計(jì)算優(yōu)化方面，我們主要的用到了MaxCompute的以下四個(gè)功能：

1)?????無用/相似任務(wù)分析。這個(gè)很容易理解，它可以幫助用戶分析出哪些任務(wù)是沒有用的，哪些任務(wù)是相似的，這需要依托于數(shù)據(jù)地圖的強(qiáng)大關(guān)系梳理能力分析出任務(wù)的有效性。

2)?????HBO?(History-based optimization) +?CBO?(Cost-based optimization)。它其實(shí)解決的是優(yōu)化的問題，在跑計(jì)算任務(wù)的時(shí)候，不管使用的是SQL還是MapReduce，一定會(huì)預(yù)先設(shè)定CPU和Memory的值，但是預(yù)先設(shè)定往往是不準(zhǔn)確的。解決的方式有兩種，一種是先將任務(wù)運(yùn)行一段時(shí)間，根據(jù)運(yùn)行情況計(jì)算每個(gè)實(shí)例大概需要的CPU和Memory，這種方式就是History-based optimization；而第二種方式是Cost-based optimization，解決的是基于成本的優(yōu)化，時(shí)間關(guān)系在此不多做介紹，后期如果大家感興趣的話，會(huì)組織相關(guān)的高階分享。

3)?????列裁剪。它解決的問題是不用講整個(gè)表中的所有字段都列出來，比如Select *，根據(jù)SQL語義，它可以實(shí)現(xiàn)十個(gè)字段只需要加載前五個(gè)字段。這對于整個(gè)任務(wù)的執(zhí)行效率包括整個(gè)磁盤的IO有很大益處。

4)?????Service? Mode。傳統(tǒng)運(yùn)行MapReduce的時(shí)候，會(huì)有shuffle的過程，這個(gè)過程會(huì)涉及到數(shù)據(jù)在Mapper和Reducer端的落盤，這個(gè)落盤操作是很耗時(shí)間的，對于一些中小型任務(wù)來講（可能只需要兩三分鐘就運(yùn)行完），是不需要落盤操作的。MaxCompute會(huì)預(yù)判任務(wù)的執(zhí)行時(shí)間，短小任務(wù)通過Service Mode的方式來降低任務(wù)的運(yùn)行時(shí)間。

?

存儲優(yōu)化

?

MaxCompute除了計(jì)算優(yōu)化，還有存儲方面的優(yōu)化。存儲優(yōu)化主要體現(xiàn)在以下一個(gè)方面：

1)?????無用數(shù)據(jù)分析和下線。這個(gè)前面也已經(jīng)反復(fù)介紹過了，可以幫助用戶分析無用的數(shù)據(jù)并下線，和無用Job分析是類似的原理。這里的難點(diǎn)是“最后一公里”，即數(shù)據(jù)從離線平臺產(chǎn)出之后導(dǎo)到線上，最后這一公里的元素是很難去追蹤的，這依賴于工具和平臺高度的標(biāo)準(zhǔn)化，阿里內(nèi)部的好處是這一塊已經(jīng)做到了標(biāo)準(zhǔn)化。隨著后續(xù)阿里云暴露的服務(wù)越來越多，這個(gè)難點(diǎn)將有希望被攻克，能夠幫用戶分析出來哪些數(shù)據(jù)是真的沒有人用。

2)?????生命周期的優(yōu)化。一份表到底要保存多少時(shí)間一開始是依靠人去估計(jì)和設(shè)置的，比如一年，但根據(jù)實(shí)際的訪問情況你會(huì)發(fā)現(xiàn)，保存一天或者三天就可以。這個(gè)時(shí)候依托于MaxCompute的數(shù)據(jù)治理，會(huì)幫助用戶分析出某張表適合的保存時(shí)間，這對于存儲的優(yōu)化具有極其重要的意義。

3)?????Archive。數(shù)據(jù)是有冷熱之分的，尤其是分布式文件存儲的時(shí)候，都是通過雙備份的方式來存儲數(shù)據(jù)，當(dāng)然雙備份尤其意義在，比如可以讓你的數(shù)據(jù)更加可靠、不會(huì)丟失，但這樣帶來了一個(gè)問題是數(shù)據(jù)的存儲將會(huì)變得大。MaxCompute提供了冷數(shù)據(jù)策略，不做雙備份，通過一定的策略將數(shù)據(jù)變成1.5備份，用1.5倍的空間達(dá)到雙備份的效果。

4)?????Hash Clustering。這個(gè)屬于存儲和計(jì)算優(yōu)化中和的事情。每次在做MapReduce的時(shí)候，中間可能需要做Join操作， 每次Join操作的時(shí)候可能會(huì)對某個(gè)表做Sort操作，但是Sort操作沒必要每次都去做，這樣就可以針對Sort操作提前做一些存儲上的優(yōu)化。

?

下圖展示了的阿里媽媽預(yù)估的ODPS存儲消耗趨勢，可以很明顯的看到預(yù)期消耗隨著時(shí)間推移幾乎呈直線增長，但中間使用MaxCompute做了幾次優(yōu)化之后，明顯感覺存儲消耗增長趨勢減緩。

?

?

介紹這么多優(yōu)化的功能，最終目的是希望大家對MaxCompute有更多的了解和期待，大家如果有更多的需求可以向MaxCompute平臺提出。

?

如需了解更多關(guān)于MaxCompute產(chǎn)品和技術(shù)信息，可加入“MaxCompute開發(fā)者交流”釘釘群；

群號11782920，或掃描如下二維碼加入釘釘群。

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

云棲號 - 上云就看云棲號

總結(jié)

以上是生活随笔為你收集整理的阿里妈妈数据字化营销与MaxCompute的不解之缘的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。