主頁 > 知識庫 > 剖析Spark集群技術(shù)在美團(tuán)網(wǎng)站的實(shí)戰(zhàn)運(yùn)用

剖析Spark集群技術(shù)在美團(tuán)網(wǎng)站的實(shí)戰(zhàn)運(yùn)用

熱門標(biāo)簽:機(jī)器人電銷哪個(gè)牌子好 阿里機(jī)器人電銷 廣西防封卡外呼系統(tǒng)原理是什么 清遠(yuǎn)語音外呼系統(tǒng)平臺 地圖標(biāo)注銷售好做嗎 地圖標(biāo)注標(biāo)記位置導(dǎo)航 地圖標(biāo)注操作方法 電銷外呼系統(tǒng)罵人 浙江呼叫中心外呼系統(tǒng)多少錢

前言
美團(tuán)是數(shù)據(jù)驅(qū)動(dòng)的互聯(lián)網(wǎng)服務(wù),用戶每天在美團(tuán)上的點(diǎn)擊、瀏覽、下單支付行為都會(huì)產(chǎn)生海量的日志,這些日志數(shù)據(jù)將被匯總處理、分析、挖掘與學(xué)習(xí),為美團(tuán)的各種推薦、搜索系統(tǒng)甚至公司戰(zhàn)略目標(biāo)制定提供數(shù)據(jù)支持。大數(shù)據(jù)處理滲透到了美團(tuán)各業(yè)務(wù)線的各種應(yīng)用場景,選擇合適、高效的數(shù)據(jù)處理引擎能夠大大提高數(shù)據(jù)生產(chǎn)的效率,進(jìn)而間接或直接提升相關(guān)團(tuán)隊(duì)的工作效率。
美團(tuán)最初的數(shù)據(jù)處理以Hive SQL為主,底層計(jì)算引擎為MapReduce,部分相對復(fù)雜的業(yè)務(wù)會(huì)由工程師編寫MapReduce程序?qū)崿F(xiàn)。隨著業(yè)務(wù)的發(fā)展,單純的Hive SQL查詢或者M(jìn)apReduce程序已經(jīng)越來越難以滿足數(shù)據(jù)處理和分析的需求。
一方面,MapReduce計(jì)算模型對多輪迭代的DAG作業(yè)支持不給力,每輪迭代都需要將數(shù)據(jù)落盤,極大地影響了作業(yè)執(zhí)行效率,另外只提供Map和Reduce這兩種計(jì)算因子,使得用戶在實(shí)現(xiàn)迭代式計(jì)算(比如:機(jī)器學(xué)習(xí)算法)時(shí)成本高且效率低。
另一方面,在數(shù)據(jù)倉庫的按天生產(chǎn)中,由于某些原始日志是半結(jié)構(gòu)化或者非結(jié)構(gòu)化數(shù)據(jù),因此,對其進(jìn)行清洗和轉(zhuǎn)換操作時(shí),需要結(jié)合SQL查詢以及復(fù)雜的過程式邏輯處理,這部分工作之前是由Hive SQL結(jié)合Python腳本來完成。這種方式存在效率問題,當(dāng)數(shù)據(jù)量比較大的時(shí)候,流程的運(yùn)行時(shí)間較長,這些ETL流程通常處于比較上游的位置,會(huì)直接影響到一系列下游的完成時(shí)間以及各種重要數(shù)據(jù)報(bào)表的生成。
基于以上原因,美團(tuán)在2014年的時(shí)候引入了Spark。為了充分利用現(xiàn)有Hadoop集群的資源,我們采用了Spark on Yarn模式,所有的Spark app以及MapReduce作業(yè)會(huì)通過Yarn統(tǒng)一調(diào)度執(zhí)行。Spark在美團(tuán)數(shù)據(jù)平臺架構(gòu)中的位置如圖所示:

經(jīng)過近兩年的推廣和發(fā)展,從最開始只有少數(shù)團(tuán)隊(duì)嘗試用Spark解決數(shù)據(jù)處理、機(jī)器學(xué)習(xí)等問題,到現(xiàn)在已經(jīng)覆蓋了美團(tuán)各大業(yè)務(wù)線的各種應(yīng)用場景。從上游的ETL生產(chǎn),到下游的SQL查詢分析以及機(jī)器學(xué)習(xí)等,Spark正在逐步替代MapReduce作業(yè),成為美團(tuán)大數(shù)據(jù)處理的主流計(jì)算引擎。目前美團(tuán)Hadoop集群用戶每天提交的Spark作業(yè)數(shù)和MapReduce作業(yè)數(shù)比例為4:1,對于一些上游的Hive ETL流程,遷移到Spark之后,在相同的資源使用情況下,作業(yè)執(zhí)行速度提升了十倍,極大地提升了業(yè)務(wù)方的生產(chǎn)效率。
下面我們將介紹Spark在美團(tuán)的實(shí)踐,包括我們基于Spark所做的平臺化工作以及Spark在生產(chǎn)環(huán)境下的應(yīng)用案例。其中包含Zeppelin結(jié)合的交互式開發(fā)平臺,也有使用Spark任務(wù)完成的ETL數(shù)據(jù)轉(zhuǎn)換工具,數(shù)據(jù)挖掘組基于Spark開發(fā)了特征平臺和數(shù)據(jù)挖掘平臺,另外還有基于Spark的交互式用戶行為分析系統(tǒng)以及在SEM投放服務(wù)中的應(yīng)用,以下是詳細(xì)介紹。

Spark交互式開發(fā)平臺
在推廣如何使用Spark的過程中,我們總結(jié)了用戶開發(fā)應(yīng)用的主要需求:

數(shù)據(jù)調(diào)研:在正式開發(fā)程序之前,首先需要認(rèn)識待處理的業(yè)務(wù)數(shù)據(jù),包括:數(shù)據(jù)格式,類型(若以表結(jié)構(gòu)存儲則對應(yīng)到字段類型)、存儲方式、有無臟數(shù)據(jù),甚至分析根據(jù)業(yè)務(wù)邏輯實(shí)現(xiàn)是否可能存在數(shù)據(jù)傾斜等等。這個(gè)需求十分基礎(chǔ)且重要,只有對數(shù)據(jù)有充分的掌控,才能寫出高效的Spark代碼;
代碼調(diào)試:業(yè)務(wù)的編碼實(shí)現(xiàn)很難保證一蹴而就,可能需要不斷地調(diào)試;如果每次少量的修改,測試代碼都需要經(jīng)過編譯、打包、提交線上,會(huì)對用戶的開發(fā)效率影響是非常大的;
聯(lián)合開發(fā):對于一整個(gè)業(yè)務(wù)的實(shí)現(xiàn),一般會(huì)有多方的協(xié)作,這時(shí)候需要能有一個(gè)方便的代碼和執(zhí)行結(jié)果共享的途徑,用于分享各自的想法和試驗(yàn)結(jié)論。
基于這些需求,我們調(diào)研了現(xiàn)有的開源系統(tǒng),最終選擇了Apache的孵化項(xiàng)目Zeppelin,將其作為基于Spark的交互式開發(fā)平臺。Zeppelin整合了Spark,Markdown,Shell,Angular等引擎,集成了數(shù)據(jù)分析和可視化等功能。

我們在原生的Zeppelin上增加了用戶登陸認(rèn)證、用戶行為日志審計(jì)、權(quán)限管理以及執(zhí)行Spark作業(yè)資源隔離,打造了一個(gè)美團(tuán)的Spark的交互式開發(fā)平臺,不同的用戶可以在該平臺上調(diào)研數(shù)據(jù)、調(diào)試程序、共享代碼和結(jié)論。

集成在Zeppelin的Spark提供了三種解釋器:Spark、Pyspark、SQL,分別適用于編寫Scala、Python、SQL代碼。對于上述的數(shù)據(jù)調(diào)研需求,無論是程序設(shè)計(jì)之初,還是編碼實(shí)現(xiàn)過程中,當(dāng)需要檢索數(shù)據(jù)信息時(shí),通過Zeppelin提供的SQL接口可以很便利的獲取到分析結(jié)果;另外,Zeppelin中Scala和Python解釋器自身的交互式特性滿足了用戶對Spark和Pyspark分步調(diào)試的需求,同時(shí)由于Zeppelin可以直接連接線上集群,因此可以滿足用戶對線上數(shù)據(jù)的讀寫處理請求;最后,Zeppelin使用Web Socket通信,用戶只需要簡單地發(fā)送要分享內(nèi)容所在的http鏈接,所有接受者就可以同步感知代碼修改,運(yùn)行結(jié)果等,實(shí)現(xiàn)多個(gè)開發(fā)者協(xié)同工作。

Spark作業(yè)ETL模板
除了提供平臺化的工具以外,我們也會(huì)從其他方面來提高用戶的開發(fā)效率,比如將類似的需求進(jìn)行封裝,提供一個(gè)統(tǒng)一的ETL模板,讓用戶可以很方便的使用Spark實(shí)現(xiàn)業(yè)務(wù)需求。

美團(tuán)目前的數(shù)據(jù)生產(chǎn)主體是通過ETL將原始的日志通過清洗、轉(zhuǎn)換等步驟后加載到Hive表中。而很多線上業(yè)務(wù)需要將Hive表里面的數(shù)據(jù)以一定的規(guī)則組成鍵值對,導(dǎo)入到Tair中,用于上層應(yīng)用快速訪問。其中大部分的需求邏輯相同,即把Hive表中幾個(gè)指定字段的值按一定的規(guī)則拼接成key值,另外幾個(gè)字段的值以json字符串的形式作為value值,最后將得到的對寫入Tair。

由于Hive表中的數(shù)據(jù)量一般較大,使用單機(jī)程序讀取數(shù)據(jù)和寫入Tair效率比較低,因此部分業(yè)務(wù)方?jīng)Q定使用Spark來實(shí)現(xiàn)這套邏輯。最初由業(yè)務(wù)方的工程師各自用Spark程序?qū)崿F(xiàn)從Hive讀數(shù)據(jù),寫入到Tair中(以下簡稱hive2Tair流程),這種情況下存在如下問題:
每個(gè)業(yè)務(wù)方都要自己實(shí)現(xiàn)一套邏輯類似的流程,產(chǎn)生大量重復(fù)的開發(fā)工作;
由于Spark是分布式的計(jì)算引擎,因此代碼實(shí)現(xiàn)和參數(shù)設(shè)置不當(dāng)很容易對Tair集群造成巨大壓力,影響Tair的正常服務(wù)。
基于以上原因,我們開發(fā)了Spark版的hive2Tair流程,并將其封裝成一個(gè)標(biāo)準(zhǔn)的ETL模板,其格式和內(nèi)容如下所示:

source用于指定Hive表源數(shù)據(jù),target指定目標(biāo)Tair的庫和表,這兩個(gè)參數(shù)可以用于調(diào)度系統(tǒng)解析該ETL的上下游依賴關(guān)系,從而很方便地加入到現(xiàn)有的ETL生產(chǎn)體系中。

有了這個(gè)模板,用戶只需要填寫一些基本的信息(包括Hive表來源,組成key的字段列表,組成value的字段列表,目標(biāo)Tair集群)即可生成一個(gè)hive2Tair的ETL流程。整個(gè)流程生成過程不需要任何Spark基礎(chǔ),也不需要做任何的代碼開發(fā),極大地降低了用戶的使用門檻,避免了重復(fù)開發(fā),提高了開發(fā)效率。該流程執(zhí)行時(shí)會(huì)自動(dòng)生成一個(gè)Spark作業(yè),以相對保守的參數(shù)運(yùn)行:默認(rèn)開啟動(dòng)態(tài)資源分配,每個(gè)Executor核數(shù)為2,內(nèi)存2GB,最大Executor數(shù)設(shè)置為100。如果對于性能有很高的要求,并且申請的Tair集群比較大,那么可以使用一些調(diào)優(yōu)參數(shù)來提升寫入的性能。目前我們僅對用戶暴露了設(shè)置Executor數(shù)量以及每個(gè)Executor內(nèi)存的接口,并且設(shè)置了一個(gè)相對安全的最大值規(guī)定,避免由于參數(shù)設(shè)置不合理給Hadoop集群以及Tair集群造成異常壓力。

基于Spark的用戶特征平臺
在沒有特征平臺之前,各個(gè)數(shù)據(jù)挖掘人員按照各自項(xiàng)目的需求提取用戶特征數(shù)據(jù),主要是通過美團(tuán)的ETL調(diào)度平臺按月/天來完成數(shù)據(jù)的提取。

但從用戶特征來看,其實(shí)會(huì)有很多的重復(fù)工作,不同的項(xiàng)目需要的用戶特征其實(shí)有很多是一樣的,為了減少冗余的提取工作,也為了節(jié)省計(jì)算資源,建立特征平臺的需求隨之誕生,特征平臺只需要聚合各個(gè)開發(fā)人員已經(jīng)提取的特征數(shù)據(jù),并提供給其他人使用。特征平臺主要使用Spark的批處理功能來完成數(shù)據(jù)的提取和聚合。
開發(fā)人員提取特征主要還是通過ETL來完成,有些數(shù)據(jù)使用Spark來處理,比如用戶搜索關(guān)鍵詞的統(tǒng)計(jì)。
開發(fā)人員提供的特征數(shù)據(jù),需要按照平臺提供的配置文件格式添加到特征庫,比如在圖團(tuán)購的配置文件中,團(tuán)購業(yè)務(wù)中有一個(gè)用戶24小時(shí)時(shí)段支付的次數(shù)特征,輸入就是一個(gè)生成好的特征表,開發(fā)人員通過測試驗(yàn)證無誤之后,即完成了數(shù)據(jù)上線;另外對于有些特征,只需要從現(xiàn)有的表中提取部分特征數(shù)據(jù),開發(fā)人員也只需要簡單的配置即可完成。

在圖中,我們可以看到特征聚合分兩層,第一層是各個(gè)業(yè)務(wù)數(shù)據(jù)內(nèi)部聚合,比如團(tuán)購的數(shù)據(jù)配置文件中會(huì)有很多的團(tuán)購特征、購買、瀏覽等分散在不同的表中,每個(gè)業(yè)務(wù)都會(huì)有獨(dú)立的Spark任務(wù)來完成聚合,構(gòu)成一個(gè)用戶團(tuán)購特征表;特征聚合是一個(gè)典型的join任務(wù),對比MapReduce性能提升了10倍左右。第二層是把各個(gè)業(yè)務(wù)表數(shù)據(jù)再進(jìn)行一次聚合,生成最終的用戶特征數(shù)據(jù)表。
特征庫中的特征是可視化的,我們在聚合特征時(shí)就會(huì)統(tǒng)計(jì)特征覆蓋的人數(shù),特征的最大最小數(shù)值等,然后同步到RDB,這樣管理人員和開發(fā)者都能通過可視化來直觀地了解特征。 另外,我們還提供特征監(jiān)測和告警,使用最近7天的特征統(tǒng)計(jì)數(shù)據(jù),對比各個(gè)特征昨天和今天的覆蓋人數(shù),是增多了還是減少了,比如性別為女這個(gè)特征的覆蓋人數(shù),如果發(fā)現(xiàn)今天的覆蓋人數(shù)比昨天低了1%(比如昨天6億用戶,女性2億,那么人數(shù)降低了1%*2億=2萬)突然減少2萬女性用戶說明數(shù)據(jù)出現(xiàn)了極大的異常,何況網(wǎng)站的用戶數(shù)每天都是增長的。這些異常都會(huì)通過郵件發(fā)送到平臺和特征提取的相關(guān)人。

Spark數(shù)據(jù)挖掘平臺
數(shù)據(jù)挖掘平臺是完全依賴于用戶特征庫的,通過特征庫提供用戶特征,數(shù)據(jù)挖掘平臺對特征進(jìn)行轉(zhuǎn)換并統(tǒng)一格式輸出,就此開發(fā)人員可以快速完成模型的開發(fā)和迭代,之前需要兩周開發(fā)一個(gè)模型,現(xiàn)在短則需要幾個(gè)小時(shí),多則幾天就能完成。特征的轉(zhuǎn)換包括特征名稱的編碼,也包括特征值的平滑和歸一化,平臺也提供特征離散化和特征選擇的功能,這些都是使用Spark離線完成。

開發(fā)人員拿到訓(xùn)練樣本之后,可以使用Spark mllib或者Python sklearn等完成模型訓(xùn)練,得到最優(yōu)化模型之后,將模型保存為平臺定義好的模型存儲格式,并提供相關(guān)配置參數(shù),通過平臺即可完成模型上線,模型可以按天或者按周進(jìn)行調(diào)度。當(dāng)然如果模型需要重新訓(xùn)練或者其它調(diào)整,那么開發(fā)者還可以把模型下線。不只如此,平臺還提供了一個(gè)模型準(zhǔn)確率告警的功能,每次模型在預(yù)測完成之后,會(huì)計(jì)算用戶提供的樣本中預(yù)測的準(zhǔn)確率,并比較開發(fā)者提供的準(zhǔn)確率告警閾值,如果低于閾值則發(fā)郵件通知開發(fā)者,是否需要對模型重新訓(xùn)練。

在開發(fā)挖掘平臺的模型預(yù)測功時(shí)能我們走了點(diǎn)彎路,平臺的模型預(yù)測功能開始是兼容Spark接口的,也就是使用Spark保存和加載模型文件并預(yù)測,使用過的人知道Spark mllib的很多API都是私有的開發(fā)人員無法直接使用,所以我們這些接口進(jìn)行封裝然后再提供給開發(fā)者使用,但也只解決了Spark開發(fā)人員的問題,平臺還需要兼容其他平臺的模型輸出和加載以及預(yù)測的功能,這讓我們面臨必需維護(hù)一個(gè)模型多個(gè)接口的問題,開發(fā)和維護(hù)成本都較高,最后還是放棄了兼容Spark接口的實(shí)現(xiàn)方式,我們自己定義了模型的保存格式,以及模型加載和模型預(yù)測的功能。

以上內(nèi)容介紹了美團(tuán)基于Spark所做的平臺化工作,這些平臺和工具是面向全公司所有業(yè)務(wù)線服務(wù)的,旨在避免各團(tuán)隊(duì)做無意義的重復(fù)性工作,以及提高公司整體的數(shù)據(jù)生產(chǎn)效率。目前看來效果是比較好的,這些平臺和工具在公司內(nèi)部得到了廣泛的認(rèn)可和應(yīng)用,當(dāng)然也有不少的建議,推動(dòng)我們持續(xù)地優(yōu)化。
隨著Spark的發(fā)展和推廣,從上游的ETL到下游的日常數(shù)據(jù)統(tǒng)計(jì)分析、推薦和搜索系統(tǒng),越來越多的業(yè)務(wù)線開始嘗試使用Spark進(jìn)行各種復(fù)雜的數(shù)據(jù)處理和分析工作。下面將以Spark在交互式用戶行為分析系統(tǒng)以及SEM投放服務(wù)為例,介紹Spark在美團(tuán)實(shí)際業(yè)務(wù)生產(chǎn)環(huán)境下的應(yīng)用。

Spark在交互式用戶行為分析系統(tǒng)中的實(shí)踐
美團(tuán)的交互式用戶行為分析系統(tǒng),用于提供對海量的流量數(shù)據(jù)進(jìn)行交互式分析的功能,系統(tǒng)的主要用戶為公司內(nèi)部的PM和運(yùn)營人員。普通的BI類報(bào)表系統(tǒng),只能夠提供對聚合后的指標(biāo)進(jìn)行查詢,比如PV、UV等相關(guān)指標(biāo)。但是PM以及運(yùn)營人員除了查看一些聚合指標(biāo)以外,還需要根據(jù)自己的需求去分析某一類用戶的流量數(shù)據(jù),進(jìn)而了解各種用戶群體在App上的行為軌跡。根據(jù)這些數(shù)據(jù),PM可以優(yōu)化產(chǎn)品設(shè)計(jì),運(yùn)營人員可以為自己的運(yùn)營工作提供數(shù)據(jù)支持,用戶核心的幾個(gè)訴求包括:

自助查詢,不同的PM或運(yùn)營人員可能隨時(shí)需要執(zhí)行各種各樣的分析功能,因此系統(tǒng)需要支持用戶自助使用。
響應(yīng)速度,大部分分析功能都必須在幾分鐘內(nèi)完成。
可視化,可以通過可視化的方式查看分析結(jié)果。
要解決上面的幾個(gè)問題,技術(shù)人員需要解決以下兩個(gè)核心問題:

海量數(shù)據(jù)的處理,用戶的流量數(shù)據(jù)全部存儲在Hive中,數(shù)據(jù)量非常龐大,每天的數(shù)據(jù)量都在數(shù)十億的規(guī)模。
快速計(jì)算結(jié)果,系統(tǒng)需要能夠隨時(shí)接收用戶提交的分析任務(wù),并在幾分鐘之內(nèi)計(jì)算出他們想要的結(jié)果。
要解決上面兩個(gè)問題,目前可供選擇的技術(shù)主要有兩種:MapReduce和Spark。在初期架構(gòu)中選擇了使用MapReduce這種較為成熟的技術(shù),但是通過測試發(fā)現(xiàn),基于MapReduce開發(fā)的復(fù)雜分析任務(wù)需要數(shù)小時(shí)才能完成,這會(huì)造成極差的用戶體驗(yàn),用戶無法接受。

因此我們嘗試使用Spark這種內(nèi)存式的快速大數(shù)據(jù)計(jì)算引擎作為系統(tǒng)架構(gòu)中的核心部分,主要使用了Spark Core以及Spark SQL兩個(gè)組件,來實(shí)現(xiàn)各種復(fù)雜的業(yè)務(wù)邏輯。實(shí)踐中發(fā)現(xiàn),雖然Spark的性能非常優(yōu)秀,但是在目前的發(fā)展階段中,還是或多或少會(huì)有一些性能以及OOM方面的問題。因此在項(xiàng)目的開發(fā)過程中,對大量Spark作業(yè)進(jìn)行了各種各樣的性能調(diào)優(yōu),包括算子調(diào)優(yōu)、參數(shù)調(diào)優(yōu)、shuffle調(diào)優(yōu)以及數(shù)據(jù)傾斜調(diào)優(yōu)等,最終實(shí)現(xiàn)了所有Spark作業(yè)的執(zhí)行時(shí)間都在數(shù)分鐘左右。并且在實(shí)踐中解決了一些shuffle以及數(shù)據(jù)傾斜導(dǎo)致的OOM問題,保證了系統(tǒng)的穩(wěn)定性。

結(jié)合上述分析,最終的系統(tǒng)架構(gòu)與工作流程如下所示:

用戶在系統(tǒng)界面中選擇某個(gè)分析功能對應(yīng)的菜單,并進(jìn)入對應(yīng)的任務(wù)創(chuàng)建界面,然后選擇篩選條件和任務(wù)參數(shù),并提交任務(wù)。
由于系統(tǒng)需要滿足不同類別的用戶行為分析功能(目前系統(tǒng)中已經(jīng)提供了十個(gè)以上分析功能),因此需要為每一種分析功能都開發(fā)一個(gè)Spark作業(yè)。
采用J2EE技術(shù)開發(fā)了Web服務(wù)作為后臺系統(tǒng),在接收到用戶提交的任務(wù)之后,根據(jù)任務(wù)類型選擇其對應(yīng)的Spark作業(yè),啟動(dòng)一條子線程來執(zhí)行Spark-submit命令以提交Spark作業(yè)。
Spark作業(yè)運(yùn)行在Yarn集群上,并針對Hive中的海量數(shù)據(jù)進(jìn)行計(jì)算,最終將計(jì)算結(jié)果寫入數(shù)據(jù)庫中。
用戶通過系統(tǒng)界面查看任務(wù)分析結(jié)果,J2EE系統(tǒng)負(fù)責(zé)將數(shù)據(jù)庫中的計(jì)算結(jié)果返回給界面進(jìn)行展現(xiàn)。

該系統(tǒng)上線后效果良好:90%的Spark作業(yè)運(yùn)行時(shí)間都在5分鐘以內(nèi),剩下10%的Spark作業(yè)運(yùn)行時(shí)間在30分鐘左右,該速度足以快速響應(yīng)用戶的分析需求。通過反饋來看,用戶體驗(yàn)非常良好。目前每個(gè)月該系統(tǒng)都要執(zhí)行數(shù)百個(gè)用戶行為分析任務(wù),有效并且快速地支持了PM和運(yùn)營人員的各種分析需求。

Spark在SEM投放服務(wù)中的應(yīng)用
流量技術(shù)組負(fù)責(zé)著美團(tuán)站外廣告的投放技術(shù),目前在SEM、SEO、DSP等多種業(yè)務(wù)中大量使用了Spark平臺,包括離線挖掘、模型訓(xùn)練、流數(shù)據(jù)處理等。美團(tuán)SEM(搜索引擎營銷)投放著上億的關(guān)鍵詞,一個(gè)關(guān)鍵詞從被挖掘策略發(fā)現(xiàn)開始,就踏上了精彩的SEM之旅。它經(jīng)過預(yù)估模型的篩選,投放到各大搜索引擎,可能因?yàn)槭袌龈偁庮l繁調(diào)價(jià),也可能因?yàn)樾Ч患驯黄认戮€。而這樣的旅行,在美團(tuán)每分鐘都在發(fā)生。如此大規(guī)模的隨機(jī)“遷徙”能夠順利進(jìn)行,Spark功不可沒。

Spark不止用于美團(tuán)SEM的關(guān)鍵詞挖掘、預(yù)估模型訓(xùn)練、投放效果統(tǒng)計(jì)等大家能想到的場景,還罕見地用于關(guān)鍵詞的投放服務(wù),這也是本段介紹的重點(diǎn)。一個(gè)快速穩(wěn)定的投放系統(tǒng)是精準(zhǔn)營銷的基礎(chǔ)。

美團(tuán)早期的SEM投放服務(wù)采用的是單機(jī)版架構(gòu),隨著關(guān)鍵詞數(shù)量的極速增長,舊有服務(wù)存在的問題逐漸暴露。受限于各大搜索引擎API的配額(請求頻次)、賬戶結(jié)構(gòu)等規(guī)則,投放服務(wù)只負(fù)責(zé)處理API請求是遠(yuǎn)遠(yuǎn)不夠的,還需要處理大量業(yè)務(wù)邏輯。單機(jī)程序在小數(shù)據(jù)量的情況下還能通過多進(jìn)程勉強(qiáng)應(yīng)對,但對于如此大規(guī)模的投放需求,就很難做到“兼顧全局”了。

新版SEM投放服務(wù)在15年Q2上線,內(nèi)部開發(fā)代號為Medusa。在Spark平臺上搭建的Medusa,全面發(fā)揮了Spark大數(shù)據(jù)處理的優(yōu)勢,提供了高性能高可用的分布式SEM投放服務(wù),具有以下幾個(gè)特性:

低門檻,Medusa整體架構(gòu)的設(shè)計(jì)思路是提供數(shù)據(jù)庫一樣的服務(wù)。在接口層,讓RD可以像操作本地?cái)?shù)據(jù)庫一樣,通過SQL來“增刪改查”線上關(guān)鍵詞表,并且只需要關(guān)心自己的策略標(biāo)簽,不需要關(guān)注關(guān)鍵詞的物理存儲位置。Medusa利用Spark SQL作為服務(wù)的接口,提高了服務(wù)的易用性,也規(guī)范了數(shù)據(jù)存儲,可同時(shí)對其他服務(wù)提供數(shù)據(jù)支持?;赟park開發(fā)分布式投放系統(tǒng),還可以讓RD從系統(tǒng)層細(xì)節(jié)中解放出來,全部代碼只有400行。
高性能、可伸縮,為了達(dá)到投放的“時(shí)間”、“空間”最優(yōu)化,Medusa利用Spark預(yù)計(jì)算出每一個(gè)關(guān)鍵詞在遠(yuǎn)程賬戶中的最佳存儲位置,每一次API請求的最佳時(shí)間內(nèi)容。在配額和賬號容量有限的情況下,輕松掌控著億級的在線關(guān)鍵詞投放。通過控制Executor數(shù)量實(shí)現(xiàn)了投放性能的可擴(kuò)展,并在實(shí)戰(zhàn)中做到了全渠道4小時(shí)全量回滾。
高可用,有的同學(xué)或許會(huì)有疑問:API請求適合放到Spark中做嗎?因?yàn)楹瘮?shù)式編程要求函數(shù)是沒有副作用的純函數(shù)(輸入是確定的,輸出就是確定的)。這確實(shí)是一個(gè)問題,Medusa的思路是把請求API封裝成獨(dú)立的模塊,讓模塊盡量做到“純函數(shù)”的無副作用特性,并參考面向軌道編程的思路,將全部請求log重新返回給Spark繼續(xù)處理,最終落到Hive,以此保證投放的成功率。為了更精準(zhǔn)的控制配額消耗,Medusa沒有引入單次請求重試機(jī)制,并制定了服務(wù)降級方案,以極低的數(shù)據(jù)丟失率,完整地記錄了每一個(gè)關(guān)鍵詞的旅行。

結(jié)論和展望
本文我們介紹了美團(tuán)引入Spark的起源,基于Spark所做的一些平臺化工作,以及Spark在美團(tuán)具體應(yīng)用場景下的實(shí)踐??傮w而言,Spark由于其靈活的編程接口、高效的內(nèi)存計(jì)算,能夠適用于大部分?jǐn)?shù)據(jù)處理場景。在推廣和使用Spark的過程中,我們踩過不少坑,也遇到過很多問題,但填坑和解決問題的過程,讓我們對Spark有了更深入的理解,我們也期待著Spark在更多的應(yīng)用場景中發(fā)揮重要的作用。

標(biāo)簽:伊春 江蘇 雅安 沈陽 廊坊 包頭 德宏 臺灣

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《剖析Spark集群技術(shù)在美團(tuán)網(wǎng)站的實(shí)戰(zhàn)運(yùn)用》,本文關(guān)鍵詞  剖析,Spark,集群,技術(shù),在,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《剖析Spark集群技術(shù)在美團(tuán)網(wǎng)站的實(shí)戰(zhàn)運(yùn)用》相關(guān)的同類信息!
  • 本頁收集關(guān)于剖析Spark集群技術(shù)在美團(tuán)網(wǎng)站的實(shí)戰(zhàn)運(yùn)用的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章