阿里主搜(淘寶天貓搜索)是搜索離線平臺非常重要的一個業(yè)務，具有數(shù)據(jù)量大、一對多的表很多、源表的總數(shù)多和熱點數(shù)據(jù)等特性。對于將主搜這種邏輯復雜的大數(shù)據(jù)量應用遷移到搜索離線平臺總是不缺少性能的挑戰(zhàn)，搜索離線平臺經(jīng)過哪些優(yōu)化最終實現(xiàn)全量高吞吐、增量低延遲的呢?

作者簡介：王偉駿，花名鴻歷，阿里巴巴搜索推薦事業(yè)部高級開發(fā)工程師。2016年碩士畢業(yè)于南京郵電大學。Apache Hadoop && Flink && Eagle Contributor。目前負責阿里巴巴搜索離線平臺Runtime層相關工作。 

另外，陳華曦(昆侖)給了本文很多建議，文中部分圖由李國鼎(石及)貢獻。

前言

在阿里搜索工程體系中我們把搜索引擎、在線算分等ms級響應用戶請求的服務稱之為“在線”服務;與之相對應的，將各種來源數(shù)據(jù)轉(zhuǎn)換處理后送入搜索引擎等“在線”服務的系統(tǒng)統(tǒng)稱為“離線”系統(tǒng)。搜索離線平臺作為搜索引擎的數(shù)據(jù)提供方，是集團各業(yè)務接入搜索的必經(jīng)之路，也是整個搜索鏈路上極為重要的一環(huán)，離線產(chǎn)出數(shù)據(jù)的質(zhì)量和速度直接影響到下游業(yè)務的用戶體驗。

搜索離線平臺經(jīng)過多年沉淀，不僅承載了集團內(nèi)大量搜索業(yè)務，在云上也有不少彈外客戶，隨著平臺功能的豐富，Blink(阿里內(nèi)部版本的Flink) 版本的領先。我們在2019年年初開始計劃把主搜(淘寶天貓搜索)遷移到搜索離線平臺上。

主搜在遷移搜索離線平臺之前的架構具有架構老化、Blink版本低、運維困難、計算框架不統(tǒng)一等不少缺點，隨著老主搜人員流失以及運維難度與日俱增，重構工作早已迫上眉睫。

對于將主搜這種邏輯復雜的X億數(shù)據(jù)量級應用遷移到搜索離線平臺總是不缺少性能的挑戰(zhàn)，業(yè)務特點與性能要求決定了主搜上平臺的過程中每一步都會很艱辛。為了讓性能達到要求，我們幾乎對每個Blink Job都進行了單獨調(diào)優(yōu)，最初的理想與最后的結(jié)局都是美好的，但過程卻是極其曲折的，本文將主要介紹主搜在遷移搜索離線平臺過程中在性能調(diào)優(yōu)方面具體做了哪些嘗試。

主搜遷移搜索離線平臺的完成對于平臺來說有里程碑式的意義，代表搜索離線平臺有能力承接超大型業(yè)務。

搜索離線平臺基本概念

搜索離線平臺處理一次主搜全增量主要由同步層和數(shù)據(jù)處理層組成，它們又分別包括全量和增量流程。為了讀者更好理解下文，先簡單介紹幾個關于搜索離線平臺的基本概念。

集團內(nèi)支撐業(yè)務

目前搜索離線平臺在集團內(nèi)支持了包括主搜，AE在內(nèi)的幾百個業(yè)務。其中數(shù)據(jù)量最大的為淘寶天貓評價業(yè)務，數(shù)據(jù)量達到了X百億條，每條數(shù)據(jù)近上X個字段。

??

場景

處理用戶的數(shù)據(jù)源(mysql或odps)表，將數(shù)據(jù)經(jīng)過一系列的離線處理流程，最終導入到Ha3在線搜索引擎或ES中。

??

平臺相關技術棧

如下圖，搜索離線平臺目前數(shù)據(jù)存儲基于HDFS/盤古，資源調(diào)度依賴于YARN或Hippo，計算框架統(tǒng)一用Flink/Blink執(zhí)行。

??

全量

全量是指將搜索業(yè)務數(shù)據(jù)全部重新處理生成，并傳送給在線引擎，一般是每天一次。

這么做有兩個原因：有業(yè)務數(shù)據(jù)是Daily更新;引擎需要全量數(shù)據(jù)來高效的進行索引整理和預處理，提高在線服務效率。全量主要分為同步層與數(shù)據(jù)處理層。

??

增量

增量是指將上游數(shù)據(jù)源實時發(fā)生的數(shù)據(jù)變化更新到在線引擎中。

這也就意味著在我們的場景中對于增量數(shù)據(jù)不需要保證Exactly Once語義，只需要保證At Least Once語義。基于該背景，我們才能用全鏈路異步化的思維來解一對多問題(下文會詳細講解)。

與全量一樣，增量也分為同步層與數(shù)據(jù)處理層。

??

一對多

在搜索這個領域某些業(yè)務數(shù)據(jù)需要用一對多的形式來描述，比如商品寶貝和SKU的關系即是個典型的一對多數(shù)據(jù)的例子。在搜索離線基于Hologres(阿里巴巴自研分布式數(shù)據(jù)庫)存儲的架構中，一對多的數(shù)據(jù)存儲在單獨的一張雙pk的HoloTable中，第一、二主鍵分別的寶貝ID與SKU_ID。

有了上面這些概念之后，在后續(xù)的段落中我們會看到搜索離線平臺針對主搜各Blink Job的性能調(diào)優(yōu)，先簡要概括下主搜業(yè)務特點與性能要求。

數(shù)據(jù)存儲方式

搜索離線平臺以前用HBase做鏡像表時，是用一張多列族大寬表來存儲業(yè)務單維度所有數(shù)據(jù)。經(jīng)過詳細調(diào)研之后，我們決定用Hologres替換HBase，所以需要對存儲架構做全面的重構。用多表來模擬HBase中的多列族，單HoloTable中包括很多業(yè)務數(shù)據(jù)源表的數(shù)據(jù)。重構后的數(shù)據(jù)存儲方式大致如下：

??

??

同步層

所謂同步層，一般是將上游數(shù)據(jù)源的數(shù)據(jù)同步到鏡像表，供數(shù)據(jù)處理層高效處理。由于業(yè)務方單維度的數(shù)據(jù)有很多Mysql表或odps表組成，少則X張，多則像主搜這樣X張。所以將同緯度數(shù)據(jù)聚合到一張Holo表中時，如果多張表兩兩join的話會產(chǎn)生大量shuffle，所以我們采取異步upsert方式，不同數(shù)據(jù)源表的數(shù)據(jù)寫Holo表中不同的列來解決海量數(shù)據(jù)導入問題。

??

??

數(shù)據(jù)處理層

所謂數(shù)據(jù)處理層，是指將同步層得到的各鏡像表(HBase/Holo)的數(shù)據(jù)進行計算，一般包括多表Join、UDTF等，以方便搜索業(yè)務的開發(fā)和接入。

主搜業(yè)務特點與性能要求

下面首先介紹下主搜業(yè)務特點與性能要求，再詳細介紹我們進行了怎樣的調(diào)優(yōu)才達到了性能的要求。

主搜業(yè)務特點

• 數(shù)據(jù)量大

主搜有X億(有效的X億)個商品，也就是主維度有X億條數(shù)據(jù)，相比于平臺其他業(yè)務(除淘寶評價業(yè)務)多出X個數(shù)量級。這么多數(shù)據(jù)我們能否在X個多小時完成全量?如何實現(xiàn)高吞吐?挑戰(zhàn)非常大。

• 一對多的表很多

主搜業(yè)務有很多一對多的表需要Join，例如一個商品對應多個SKU，部分商品對應了接近X個SKU信息。這些信息如何能夠高性能的轉(zhuǎn)換為商品維度，并與商品信息關聯(lián)?

• 源表的總數(shù)多

主搜有X多張表(包括一對多的表)，平臺其他業(yè)務的源表個數(shù)一般都在個位數(shù)。源表數(shù)量多會導致一系列的問題，比如讀取ODPS數(shù)據(jù)時如何避免觸發(fā)ODPS的限制?拉取大表數(shù)據(jù)時如何做到高吞吐?這些問題都需要我們一一解決。

• 熱點數(shù)據(jù)

主搜有一些大賣家(餓了么，盒馬等)對應了很多商品，導致在數(shù)據(jù)處理層出現(xiàn)非常嚴重的數(shù)據(jù)傾斜等問題。如何解決大數(shù)據(jù)處理方向經(jīng)常出現(xiàn)的SKEW?

主搜性能要求

• 全量(同步層 + 數(shù)據(jù)處理層)高吞吐!

全量要求每天一次，在有限的資源情況下每次處理X億的商品，這么大的數(shù)據(jù)量，如何實現(xiàn)高吞吐，挑戰(zhàn)非常大!

• 增量(同步層 + 數(shù)據(jù)處理層)低延遲!

增量要在Tps為X W的情況下達到秒級低延遲，并且雙11期間有部分表(例如XX表)的Tps能達到X W，增量如何保證穩(wěn)定的低延遲?值得思考!

下面一一描述我們是如何解決這些問題來達到性能要求的。

Blink Job性能調(diào)優(yōu)詳解

根據(jù)上述主搜業(yè)務特點與性能要求羅列出下圖，左邊與中間兩列表示主搜哪些特點導致某階段任務性能差。所以我們要對相應階段Blink Job進行調(diào)優(yōu)，調(diào)優(yōu)完成也就代表著平臺能滿足圖中最右邊一列主搜所需要的全量高吞吐與增量低延遲的性能要求。

??

下面按照全量，增量，解一對多問題的脈絡來給大家介紹我們是如何解決上述五個問題之后達到全量高吞吐以及增量低延遲的性能要求的。

全量高吞吐性能調(diào)優(yōu)

全量主要包括同步層與數(shù)據(jù)處理層，必須實現(xiàn)高吞吐才能讓全量在X個多小時之內(nèi)完成。同步層在短時間內(nèi)要同步約X張表中的上X億全量數(shù)據(jù)，且不影響同時在運行的增量時效性是一個巨大的挑戰(zhàn)。數(shù)據(jù)處理層要在短時間內(nèi)處理X多億條數(shù)據(jù)，Join很多張鏡像表，以及UDTF處理，MultiGet等，最后產(chǎn)生全量HDFS文件，優(yōu)化過程一度讓人頻臨放棄。這里重點介紹數(shù)據(jù)處理層的性能調(diào)優(yōu)歷程。

該Job的調(diào)優(yōu)歷時較長，嘗試方案較多，下面按照時間順序講解。

• 初始形態(tài)

首先提一下IC維度為商品維度，UIC維度為賣家維度，并且最開始我們的方案是沒有FullDynamicNestedAggregation和IncDynamicNestedAggregation的(后文會詳細提到這兩個Job)。Scan IC維度單Pk表之后做一系列的DImJoin、UDTF、MultiJoin。在測試過程中發(fā)現(xiàn)DimJoin多pk表(一對多表)的數(shù)據(jù)時，性能非常低下，全鏈路Async的流程退化成了Sync，原因是我們一對多的數(shù)據(jù)存在單獨的一個SaroTable(對多個HoloTable的邏輯抽象)中，對指定第一pk來取對應所有數(shù)據(jù)用的是Partial Scan，這是完全Sync的，每Get一次都要創(chuàng)建一個Scanner，雖然我們不但對于DimJoin加了Cache，并且對于主搜特有的MultiGet也加了對于SubKey的精準Cache。但是測試下來發(fā)現(xiàn)，性能還是完全得不到滿足，所以嘗試繼續(xù)優(yōu)化。

??

• 引入LocalJoin與SortMergeJoin

由于性能瓶頸是在DimJoin多pk的SaroTable這里，所以我們想辦法把這部分去掉。由于一對多的SaroTable只有兩個維度具有，所以我們嘗試先分別將IC維度與UIC維度的所有表(包括單pk與多pk)進行LocalJoin，結(jié)果再進行SortMergeJoin，然后繼續(xù)別的流程。

首先介紹下Local Join。由于HoloStore保證相同DB中所有表都是按照相同的Partition策略，并且都是按照主鍵字典序排好序的，所以我們可以將同緯度同Partition的數(shù)據(jù)拉取到一個進程中進行Join，避免了Shuffle，如下圖所示。

??

所以拓撲大概變?yōu)椋?/p>

??

經(jīng)過測試，由于業(yè)務上面存在大賣家(一個賣家有很多商品)，導致SortMergeJoin之后會有很嚴重的長尾，如下圖所示，Uid為101與103的數(shù)據(jù)都是落到同一個并發(fā)中，我曾經(jīng)嘗試再這個基礎之上再加一層PartitionBy nid打散，發(fā)現(xiàn)無濟于事，因為SortMergeJoin的Sort階段以及External Shuflle對于大數(shù)據(jù)量的Task需要多次進行Disk File Merge，所以該長尾Task還是需要很長時間才能Finish。

??

• 加鹽打散大賣家

所以我們需要繼續(xù)調(diào)優(yōu)。經(jīng)過組內(nèi)討論我們決定對大賣家進行加鹽打散，從ODPS源表中找出Top X的大賣家ID，然后分別在主輔維度Scan + Local Join之后分別加上UDF與UDTF，具體流程圖與原理示例見下面兩幅圖：

??

如上圖所示，Uid為101與103的數(shù)據(jù)被打散到多個并發(fā)中了，并且因為我們在SortMergeJoin之后加了UDTF把加的Salt去掉，所以最終數(shù)據(jù)不會有任何影響。

• 最終形態(tài)

這樣全量FullJoin總算完成了，并且性能也勉強達標，所以我們開始調(diào)整增量流程(IncJoin)，這時發(fā)現(xiàn)IncJoin跟FullJoin的初始形態(tài)存在一樣的問題，追增量非常慢，永遠追不上，所以組內(nèi)討論之后決定在同步層針對全量新增一個FullDynamicNestedAggregation Job(下文會詳細提到)，這是一個Blink Batch Job它將各維度一對多的SaroTable數(shù)據(jù)寫到對應維度的主表中，然后在FullJoin最開始Scan時一起Scan出來，這樣就避免了DimJoin多pk的SaroTable。最終達到了全量高吞吐的要求，全量FullJoin最終形態(tài)如下：

??

增量低延遲性能調(diào)優(yōu)

增量性能主要受困于數(shù)據(jù)處理層IncJoin，該Job最開始是一個Blink Stream Job，主要是從SwiftQueue中讀出增量消息再關聯(lián)各個鏡像表中的數(shù)據(jù)來補全字段，以及對數(shù)據(jù)進行UDTF處理等，最后將增量消息發(fā)往在線引擎SwiftQueue中。

基于“流批一體”的思想，經(jīng)過一系列嘗試，我們增量數(shù)據(jù)處理層Job的最終形態(tài)如下。與全量不同的是由于增量是實時更新的，所以更新記錄不僅要寫到Swift Queue中，還要寫入SaroTable中。另外，我們根據(jù)業(yè)務特點給各個Job分別加了按pk對記錄去重的window。

??

解一對多問題

主搜有很多一對多的表，在數(shù)據(jù)處理層如何高效的將數(shù)據(jù)Get出來轉(zhuǎn)換為主維度之后進行字段補全，困擾我們很久。

為了提升效率我們必須想辦法提升Cpu利用率。所以Get記錄改為全鏈路異步來實現(xiàn)，由于我們一對多數(shù)據(jù)存在多pk的HoloTable中，指定第一pk去獲取相關數(shù)據(jù)在Holo服務端是以Scan來實現(xiàn)的。這樣由于異步編程的傳染性，全鏈路異步會退化為同步，性能完全不達標。

• 解決方法

為了將“偽異步”變成真正的全鏈路異步，經(jīng)過多次討論與實踐之后，我們決定將一對多表中相同第一pk的多條數(shù)據(jù)Scan出來GroupBy為一條數(shù)據(jù)，將每個字段轉(zhuǎn)化為Json之后再Put進主表中，主要步驟如下圖所示。

??

我們針對全量與增量在同步層加Job來解決，分別為FullDynamicNestedAggregation(Blink Batch Job)與IncDynamicNestedAggregation(Blink Stream Job)，這兩個Job大致流程為如下圖所示。

??

值得一提的是，正如前文介紹增量時提到的背景，我們的場景中對于增量數(shù)據(jù)不需要保證Exactly Once語義，只需要保證At Least Once語義。所以基于該背景，我們能夠?qū)?shù)據(jù)處理層增量Job拆分為兩個Job執(zhí)行，一對多的問題得以解決。

這樣我們在數(shù)據(jù)處理層就不需要去Scan HoloTable了，從而可以用全鏈路異步化的方式來提升增量整體性能。

•  截斷優(yōu)化

為了避免將多條數(shù)據(jù)轉(zhuǎn)為一條數(shù)據(jù)之后由于數(shù)據(jù)量過大導致FullGC的“大行”問題。基于業(yè)務的特性，我們對于每個一對多表在Scan時支持截斷功能，對于相同的第一pk記錄，只Scan一定條數(shù)的記錄出來組裝為Json，并且可以針對不同的表實現(xiàn)白名單配置。

• 加過濾Window優(yōu)化

針對業(yè)務的特點，一對多的很多表雖然可以接受一定時間的延遲，但是為了避免對離線系統(tǒng)以及在線BuildService造成太大的沖擊，所以更新不能太多，所以我們加了30min的去重窗口，這個窗口作用非常大，平均去重率高達X%以上。

結(jié)語

經(jīng)過一系列優(yōu)化，主搜不僅在資源上相對于老架構有不少的節(jié)省，而且同時實現(xiàn)全量高吞吐與增量低延遲，并且在2019年度雙11 0點應對突增流量時表現(xiàn)的游刃有余。

對系統(tǒng)進行性能調(diào)優(yōu)是極其復雜且較精細的工作，非常具有技術挑戰(zhàn)性。不僅需要對所選用技術工具(Flink/Blink)熟悉，而且對于業(yè)務也必須了解。加window，截斷優(yōu)化，加鹽打散大賣家等正是因為業(yè)務場景能容忍這些方法所帶來的相應缺點才能做的。

除了本文提到的調(diào)優(yōu)經(jīng)驗，我們對同步層全增量Job與MultiGet也進行了不少調(diào)優(yōu)，篇幅原因與二八原則這里就不詳細介紹了。