問題導讀:

1、美團離線計算平臺架構都有那些框架？

2、為什么要使用spark架構？

3、spark推廣過程中需要注意那些方面？

前言

美團是數(shù)據(jù)驅動的互聯(lián)網服務，用戶每天在美團上的點擊、瀏覽、下單支付行為都會產生海量的日志，這些日志數(shù)據(jù)將被匯總處理、分析、挖掘與學習，為美團的各種推薦、搜索系統(tǒng)甚至公司戰(zhàn)略目標制定提供數(shù)據(jù)支持。大數(shù)據(jù)處理滲透到了美團各業(yè)務線的各種應用場景，選擇合適、高效的數(shù)據(jù)處理引擎能夠大大提高數(shù)據(jù)生產的效率，進而間接或直接提升相關團隊的工作效率。

美團最初的數(shù)據(jù)處理以Hive SQL為主，底層計算引擎為MapReduce，部分相對復雜的業(yè)務會由工程師編寫MapReduce程序實現(xiàn)。隨著業(yè)務的發(fā)展，單純的Hive SQL查詢或者MapReduce程序已經越來越難以滿足數(shù)據(jù)處理和分析的需求。

一方面，MapReduce計算模型對多輪迭代的DAG作業(yè)支持不給力，每輪迭代都需要將數(shù)據(jù)落盤，極大地影響了作業(yè)執(zhí)行效率，另外只提供Map和Reduce這兩種計算因子，使得用戶在實現(xiàn)迭代式計算（比如：機器學習算法）時成本高且效率低。

另一方面，在數(shù)據(jù)倉庫的按天生產中，由于某些原始日志是半結構化或者非結構化數(shù)據(jù)，因此，對其進行清洗和轉換操作時，需要結合SQL查詢以及復雜的過程式邏輯處理，這部分工作之前是由Hive SQL結合Python腳本來完成。這種方式存在效率問題，當數(shù)據(jù)量比較大的時候，流程的運行時間較長，這些ETL流程通常處于比較上游的位置，會直接影響到一系列下游的完成時間以及各種重要數(shù)據(jù)報表的生成。

基于以上原因，美團在2014年的時候引入了Spark。為了充分利用現(xiàn)有Hadoop集群的資源，我們采用了Spark on Yarn模式，所有的Spark app以及MapReduce作業(yè)會通過Yarn統(tǒng)一調度執(zhí)行。Spark在美團數(shù)據(jù)平臺架構中的位置如圖所示：

經過近兩年的推廣和發(fā)展，從最開始只有少數(shù)團隊嘗試用Spark解決數(shù)據(jù)處理、機器學習等問題，到現(xiàn)在已經覆蓋了美團各大業(yè)務線的各種應用場景。從上游的ETL生產，到下游的SQL查詢分析以及機器學習等，Spark正在逐步替代MapReduce作業(yè)，成為美團大數(shù)據(jù)處理的主流計算引擎。目前美團Hadoop集群用戶每天提交的Spark作業(yè)數(shù)和MapReduce作業(yè)數(shù)比例為4：1，對于一些上游的Hive ETL流程，遷移到Spark之后，在相同的資源使用情況下，作業(yè)執(zhí)行速度提升了十倍，極大地提升了業(yè)務方的生產效率。

下面我們將介紹Spark在美團的實踐，包括我們基于Spark所做的平臺化工作以及Spark在生產環(huán)境下的應用案例。其中包含Zeppelin結合的交互式開發(fā)平臺，也有使用Spark任務完成的ETL數(shù)據(jù)轉換工具，數(shù)據(jù)挖掘組基于Spark開發(fā)了特征平臺和數(shù)據(jù)挖掘平臺，另外還有基于Spark的交互式用戶行為分析系統(tǒng)以及在SEM投放服務中的應用，以下是詳細介紹。

Spark交互式開發(fā)平臺

在推廣如何使用Spark的過程中，我們總結了用戶開發(fā)應用的主要需求：

數(shù)據(jù)調研：在正式開發(fā)程序之前，首先需要認識待處理的業(yè)務數(shù)據(jù)，包括：數(shù)據(jù)格式，類型（若以表結構存儲則對應到字段類型）、存儲方式、有無臟數(shù)據(jù)，甚至分析根據(jù)業(yè)務邏輯實現(xiàn)是否可能存在數(shù)據(jù)傾斜等等。這個需求十分基礎且重要，只有對數(shù)據(jù)有充分的掌控，才能寫出高效的Spark代碼；

代碼調試：業(yè)務的編碼實現(xiàn)很難保證一蹴而就，可能需要不斷地調試；如果每次少量的修改，測試代碼都需要經過編譯、打包、提交線上，會對用戶的開發(fā)效率影響是非常大的；

聯(lián)合開發(fā)：對于一整個業(yè)務的實現(xiàn)，一般會有多方的協(xié)作，這時候需要能有一個方便的代碼和執(zhí)行結果共享的途徑，用于分享各自的想法和試驗結論。

基于這些需求，我們調研了現(xiàn)有的開源系統(tǒng)，最終選擇了Apache的孵化項目Zeppelin，將其作為基于Spark的交互式開發(fā)平臺。Zeppelin整合了Spark，Markdown，Shell，Angular等引擎，集成了數(shù)據(jù)分析和可視化等功能。

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

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

Spark作業(yè)ETL模板

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

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

由于Hive表中的數(shù)據(jù)量一般較大，使用單機程序讀取數(shù)據(jù)和寫入Tair效率比較低，因此部分業(yè)務方決定使用Spark來實現(xiàn)這套邏輯。最初由業(yè)務方的工程師各自用Spark程序實現(xiàn)從Hive讀數(shù)據(jù)，寫入到Tair中（以下簡稱hive2Tair流程），這種情況下存在如下問題：

每個業(yè)務方都要自己實現(xiàn)一套邏輯類似的流程，產生大量重復的開發(fā)工作；

由于Spark是分布式的計算引擎，因此代碼實現(xiàn)和參數(shù)設置不當很容易對Tair集群造成巨大壓力，影響Tair的正常服務。

基于以上原因，我們開發(fā)了Spark版的hive2Tair流程，并將其封裝成一個標準的ETL模板，其格式和內容如下所示：

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

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

基于Spark的用戶特征平臺

在沒有特征平臺之前，各個數(shù)據(jù)挖掘人員按照各自項目的需求提取用戶特征數(shù)據(jù)，主要是通過美團的ETL調度平臺按月/天來完成數(shù)據(jù)的提取。

但從用戶特征來看，其實會有很多的重復工作，不同的項目需要的用戶特征其實有很多是一樣的，為了減少冗余的提取工作，也為了節(jié)省計算資源，建立特征平臺的需求隨之誕生，特征平臺只需要聚合各個開發(fā)人員已經提取的特征數(shù)據(jù)，并提供給其他人使用。特征平臺主要使用Spark的批處理功能來完成數(shù)據(jù)的提取和聚合。

開發(fā)人員提取特征主要還是通過ETL來完成，有些數(shù)據(jù)使用Spark來處理，比如用戶搜索關鍵詞的統(tǒng)計。

開發(fā)人員提供的特征數(shù)據(jù)，需要按照平臺提供的配置文件格式添加到特征庫，比如在圖團購的配置文件中，團購業(yè)務中有一個用戶24小時時段支付的次數(shù)特征，輸入就是一個生成好的特征表，開發(fā)人員通過測試驗證無誤之后，即完成了數(shù)據(jù)上線；另外對于有些特征，只需要從現(xiàn)有的表中提取部分特征數(shù)據(jù)，開發(fā)人員也只需要簡單的配置即可完成。

在圖中，我們可以看到特征聚合分兩層，第一層是各個業(yè)務數(shù)據(jù)內部聚合，比如團購的數(shù)據(jù)配置文件中會有很多的團購特征、購買、瀏覽等分散在不同的表中，每個業(yè)務都會有獨立的Spark任務來完成聚合，構成一個用戶團購特征表；特征聚合是一個典型的join任務，對比MapReduce性能提升了10倍左右。第二層是把各個業(yè)務表數(shù)據(jù)再進行一次聚合，生成最終的用戶特征數(shù)據(jù)表。

特征庫中的特征是可視化的，我們在聚合特征時就會統(tǒng)計特征覆蓋的人數(shù)，特征的最大最小數(shù)值等，然后同步到RDB，這樣管理人員和開發(fā)者都能通過可視化來直觀地了解特征。 另外，我們還提供特征監(jiān)測和告警，使用最近7天的特征統(tǒng)計數(shù)據(jù)，對比各個特征昨天和今天的覆蓋人數(shù)，是增多了還是減少了，比如性別為女這個特征的覆蓋人數(shù)，如果發(fā)現(xiàn)今天的覆蓋人數(shù)比昨天低了1%（比如昨天6億用戶，女性2億，那么人數(shù)降低了1％＊2億＝2萬）突然減少2萬女性用戶說明數(shù)據(jù)出現(xiàn)了極大的異常，何況網站的用戶數(shù)每天都是增長的。這些異常都會通過郵件發(fā)送到平臺和特征提取的相關人。

Spark數(shù)據(jù)挖掘平臺

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

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

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

以上內容介紹了美團基于Spark所做的平臺化工作，這些平臺和工具是面向全公司所有業(yè)務線服務的，旨在避免各團隊做無意義的重復性工作，以及提高公司整體的數(shù)據(jù)生產效率。目前看來效果是比較好的，這些平臺和工具在公司內部得到了廣泛的認可和應用，當然也有不少的建議，推動我們持續(xù)地優(yōu)化。

隨著Spark的發(fā)展和推廣，從上游的ETL到下游的日常數(shù)據(jù)統(tǒng)計分析、推薦和搜索系統(tǒng)，越來越多的業(yè)務線開始嘗試使用Spark進行各種復雜的數(shù)據(jù)處理和分析工作。下面將以Spark在交互式用戶行為分析系統(tǒng)以及SEM投放服務為例，介紹Spark在美團實際業(yè)務生產環(huán)境下的應用。

Spark在交互式用戶行為分析系統(tǒng)中的實踐

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

自助查詢，不同的PM或運營人員可能隨時需要執(zhí)行各種各樣的分析功能，因此系統(tǒng)需要支持用戶自助使用。

響應速度，大部分分析功能都必須在幾分鐘內完成。

可視化，可以通過可視化的方式查看分析結果。

要解決上面的幾個問題，技術人員需要解決以下兩個核心問題：

海量數(shù)據(jù)的處理，用戶的流量數(shù)據(jù)全部存儲在Hive中，數(shù)據(jù)量非常龐大，每天的數(shù)據(jù)量都在數(shù)十億的規(guī)模。

快速計算結果，系統(tǒng)需要能夠隨時接收用戶提交的分析任務，并在幾分鐘之內計算出他們想要的結果。

要解決上面兩個問題，目前可供選擇的技術主要有兩種：MapReduce和Spark。在初期架構中選擇了使用MapReduce這種較為成熟的技術，但是通過測試發(fā)現(xiàn)，基于MapReduce開發(fā)的復雜分析任務需要數(shù)小時才能完成，這會造成極差的用戶體驗，用戶無法接受。

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

結合上述分析，最終的系統(tǒng)架構與工作流程如下所示：

用戶在系統(tǒng)界面中選擇某個分析功能對應的菜單，并進入對應的任務創(chuàng)建界面，然后選擇篩選條件和任務參數(shù)，并提交任務。

由于系統(tǒng)需要滿足不同類別的用戶行為分析功能（目前系統(tǒng)中已經提供了十個以上分析功能），因此需要為每一種分析功能都開發(fā)一個Spark作業(yè)。

采用J2EE技術開發(fā)了Web服務作為后臺系統(tǒng)，在接收到用戶提交的任務之后，根據(jù)任務類型選擇其對應的Spark作業(yè)，啟動一條子線程來執(zhí)行Spark-submit命令以提交Spark作業(yè)。

Spark作業(yè)運行在Yarn集群上，并針對Hive中的海量數(shù)據(jù)進行計算，最終將計算結果寫入數(shù)據(jù)庫中。

用戶通過系統(tǒng)界面查看任務分析結果，J2EE系統(tǒng)負責將數(shù)據(jù)庫中的計算結果返回給界面進行展現(xiàn)。

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

Spark在SEM投放服務中的應用

流量技術組負責著美團站外廣告的投放技術，目前在SEM、SEO、DSP等多種業(yè)務中大量使用了Spark平臺，包括離線挖掘、模型訓練、流數(shù)據(jù)處理等。美團SEM（搜索引擎營銷）投放著上億的關鍵詞，一個關鍵詞從被挖掘策略發(fā)現(xiàn)開始，就踏上了精彩的SEM之旅。它經過預估模型的篩選，投放到各大搜索引擎，可能因為市場競爭頻繁調價，也可能因為效果不佳被迫下線。而這樣的旅行，在美團每分鐘都在發(fā)生。如此大規(guī)模的隨機“遷徙”能夠順利進行，Spark功不可沒。

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

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

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

低門檻，Medusa整體架構的設計思路是提供數(shù)據(jù)庫一樣的服務。在接口層，讓RD可以像操作本地數(shù)據(jù)庫一樣，通過SQL來“增刪改查”線上關鍵詞表，并且只需要關心自己的策略標簽，不需要關注關鍵詞的物理存儲位置。Medusa利用Spark SQL作為服務的接口，提高了服務的易用性，也規(guī)范了數(shù)據(jù)存儲，可同時對其他服務提供數(shù)據(jù)支持?；赟park開發(fā)分布式投放系統(tǒng)，還可以讓RD從系統(tǒng)層細節(jié)中解放出來，全部代碼只有400行。

高性能、可伸縮，為了達到投放的“時間”、“空間”最優(yōu)化，Medusa利用Spark預計算出每一個關鍵詞在遠程賬戶中的最佳存儲位置，每一次API請求的最佳時間內容。在配額和賬號容量有限的情況下，輕松掌控著億級的在線關鍵詞投放。通過控制Executor數(shù)量實現(xiàn)了投放性能的可擴展，并在實戰(zhàn)中做到了全渠道4小時全量回滾。

高可用，有的同學或許會有疑問：API請求適合放到Spark中做嗎？因為函數(shù)式編程要求函數(shù)是沒有副作用的純函數(shù)（輸入是確定的，輸出就是確定的）。這確實是一個問題，Medusa的思路是把請求API封裝成獨立的模塊，讓模塊盡量做到“純函數(shù)”的無副作用特性，并參考面向軌道編程的思路，將全部請求log重新返回給Spark繼續(xù)處理，最終落到Hive，以此保證投放的成功率。為了更精準的控制配額消耗，Medusa沒有引入單次請求重試機制，并制定了服務降級方案，以極低的數(shù)據(jù)丟失率，完整地記錄了每一個關鍵詞的旅行。

結論和展望

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