閒魚技術——雨成

1.現狀

閒魚作為一款閒置交易APP，在二手交易市場中是當之無愧的佼佼者。閒魚從2014年誕生到現在七整年間持續增長，在這高速增長的背後帶來的是每天近百億的曝光點擊瀏覽等數據，在這些數據規模如此龐大的背後也會帶來諸多關於實時性的問題：

• 用戶反饋商品曝光異常，如何快速定位？
• 產品同學圈了一批商品，如何查看該樣本的實時報表？
• 發現問題總是晚一步，如何在第一時間獲取自定義的預警信息？    
• ......

為了解決上述的這些問題，我們開始了打造閒魚實時數倉的探索之路。

2.實時數倉調研

數倉調研

在開始設計閒魚的實時數據倉庫之前，我們也調研了集團內外的各種數據倉庫的設計與架構，一些是比較老的架構設計，另外一些是由於技術突破後進而帶來的創新性的解決方案。本文不妨將這些實時數據倉庫的新老設計做一下分類：

• 第一類：從無到有

  • 當Apache Storm(開源的分佈式實時計算系統)問世後，大數據不在依靠MapReduce這種單一的計算方式，擁有了當日數據當日處理的能力。

• 第二類：從有到全

  • 以Lambda和Kappa為代表的架構，能夠將實時與離線架構結合在一起，一套產品可以實現多種數據更新策略。

• 第三類：從全到簡

  • 以Flink為代表的支持窗口計算的流式框架出現，使離線和實時的邏輯能夠統一起來，一套代碼實現兩種更新策略，避免了因為開發方式不統一導致的數據不一致問題。

• 第四類：架構走向工具

  • 以Hologres為代表的HSAP(Hybrid Serving/Analytical Processing)引擎，用服務分析一體化的設計理念，統一分析型數據庫和業務數據庫，再配合Flink，真正實現數倉的徹底實時化。

首先我們摒棄了比較古老的方案，由於現在的技術創新非常快，湧現出很多優秀的產品可供我們去使用，另外基於閒魚自身的業務需求，最終選擇了Hologres[1]+Blink[2]來構建實時數據倉庫。

數據模型

不管是從計算成本，易用性，複用性，還是一致性等方面，我們都必須避免煙囪式的開發模式，而是以中間層的方式去建設實時數倉，煙囪式架構有很大弊端，它無法與其他系統進行有效協調工作，不利於業務沉澱，而且後期維護成本非常大。下圖展示了閒魚實時數倉的數據模型設計架構圖。

從上圖可以看出我們將實時數倉的數據模型分為4層，自底向上依次為ODS、DWD、DWS和ADS。通過多層設計可以將處理數據的流程沉澱在各層完成。比如在數據明細層統一完成數據的過濾、清洗、規範、脫敏流程；在數據彙總層加工共性的多維指標彙總數據，提高了代碼的複用率和整體生產效率。同時各層級處理的任務類型相似，可以採用統一的技術方案優化性能，使數倉技術架構更簡潔。下面對這四層進行簡單的介紹：

• ODS(Operational Data Store): 貼源層

  • 這一層又叫做貼源層,最為接近數據源的一層,需要存儲的數據量是最大的,存儲的數據也是最原始。對眾多數據源而言，他們的數據格式基本不一致，經過統一規格化後可以得到規整的數據，將數據源中的數據經過抽取、清洗、傳輸後裝入ODS層。

• DWD(Data Warehouse Detail)：數據明細層

  • 業務層與數據倉庫的隔離層，主要對ODS層做一些數據清洗和規範化的操作，並且可以按照不同的行為維度對數據進行劃分，例如本文對數據源就進行了劃分，主要分為瀏覽、曝光、點擊、交易等不同的維度，這些不同的維度能夠對上層調用方提供更細粒度的數據服務。

• DWS(Data WareHouse Servce)：數據服務層

  • 對各個域進行了適度彙總，主要以數據域+業務域的理念建設公共彙總層，與離線數倉不同的是，實時數倉的彙總層分為輕度彙總層和高度彙總層，例如將輕度彙總層數據寫入 ADS，用於前端產品複雜的OLAP查詢場景，滿足自助分析和產出報表的需求。

• ADS(Application Data Store)：應用數據服務層

  • 主要是為了具體需求而構建的應用層，通過 RPC 框架對外提供服務，例如本文中提到的數據報表分析與展示、監控告警、流量調控、開放平臺等應用。

• DIM(Dimension)：維表

  • 在實時計算中非常重要，也是重點維護的部分，維表需要實時更新，且下游基於最新的維表進行計算，例如閒魚的實時數倉維表會用到閒魚商品表、閒魚用戶表、人群表、場景表、分桶表等。

3.技術方案

整體架構

上面對閒魚實時數倉的數據模型進行了解剖並詳細地介紹了模型的各層次設計思想和實際運用。下面是根據數據模型構建的技術架構圖，共分為五個層次，自底向上分別為數據源、數據接入層、數據計算層、數據服務層和應用層。

數據源是整個實時數倉的底座，閒魚擁有眾多場景，例如首頁推薦、猜你喜歡、搜索等，在這些場景中會有不同的用戶行為，用戶產生的曝光、點擊、瀏覽等行為日誌會被上層存儲工具收集。如上圖中的數據接入層，可以將數據源接入到UT[3]日誌、黃金令箭、數據備庫或服務端日誌中存儲。
數據清洗與規整是構建實時數倉的核心過程，數據計算層利用Blink的實時處理能力將不同格式的數據統一清洗、補充和規整後存入TT[4]中。數據服務層是實時數倉的網關層，將實時數據進行邏輯處理後對外提供數據服務和API網關能力。
應用層是最貼近用戶的層次，這一層是為了具體需求而構建的，可以對各個維度數據進行實時報表展示，對線上異常流量監控告警，對商品域進行流量調控，還可供其他應用開放相關接口等。

技術難點

整體的技術架構如上圖所示，構建實時數倉的關鍵是實時數據處理以及實時交互的能力，閒魚每日產生近百億的埋點數據以及服務器日誌，在構建實時數倉有以下關鍵難點：

• 數據量大，需要處理的埋點數據以及服務器日誌達百億。
• 實時性能要求高，監控告警需要較高的實時性。
• 分析交互需求強，數據分析場景複雜且交互頻繁。
• 異構數據源多，閒魚各個系統模塊產生各類格式的數據。

首先如何能夠即穩定又高效地處理數據是我們亟待解決的問題，在面臨海量數據計算處理時，我們選用了集團內部的流式計算框架Blink，它是基於開源框架Flink的再封裝的新一代流式計算引擎，經過多年雙11的考驗，其實時計算能力對我們系統來說是毋庸置疑的。
我們在做實時報表展示時結合性能和實際情況，會對實時數據進行分鐘級別的數據聚合，通過Blink提供的滾動窗口聚合就能夠高效地解決該問題。滾動窗口將每個元素分配到一個指定窗口大小的窗口中，滾動窗口有一個固定的大小，並且不會出現重疊。例如：如果指定了一個1分鐘大小的滾動窗口，那麼無限流的數據會根據時間劃分成[0:00 - 0:01), [0:01, 0:02), [0:02, 0:03)... 等窗口，滾動窗口劃分形式如下圖所示。

我們在編寫分鐘級別的Blink任務時，只需要在 GROUP BY 子句中定義滾動窗口即可，偽代碼如下：

GROUP BY TUMBLE(<time-attr>, <size-interval>)

上述SQL中的參數必須是流中的一個合法的時間屬性字段，有兩種類型： processing time 或是 event time。

• Event Time：用戶提供的事件時間(通常是數據的最原始的創建時間)，event time一定是用戶提供在表的schema裡的數據。
• Processing Time：表示系統對事件進行處理的本地系統時間，單位為毫秒。

根據項目實際情況，因為我們聚合的是埋點事件當時的數據，所以選擇使用Event Time，選擇該類型時間的另一好處是在重跑某個時間段的任務時也能夠保持結果的一致性。

通過Blink的這個法寶我們能夠高效實時地處理海量數據，那在面臨數據分析場景複雜並且交互非常頻繁的這種情況下，我們又如何去避免傳統OLAP的存儲計算弊端呢？在尋找實時的並且兼併服務/分析一體化的系統工具時我們發現了一款利器，它就是Hologres(Holographic+Postgres)，它支持對萬億級數據進行高併發低延時多維分析透視和業務探索，可以輕鬆而且經濟的使用現有BI工具分析所有數據，在面臨PB級數據時依然能夠保持秒級響應的能力，並且簡單易用，能夠快速上手。
Hologres是基於存儲計算分離的設計模式而構建的，數據全部存在一個分佈式文件系統中，存儲引擎的總體架構如下圖所示：

每個分片(shard)構成了一個存儲管理和恢復的單元(recovery unit)，上圖展示了一個分片的基本架構，一個分片由多個tablet組成，這些tablet會共享一個日誌（Write-Ahead Log，簡稱WAL，所有的新數據都是以append-only的形式插入的。當寫操作不斷進來，每個tablet裡會積累出很多文件。當一個tablet裡小文件積累到一定數量時，存儲引擎會在後臺把小文件合併起來，能減少使用系統資源且合併後的文件減少了，提高了讀的性能，為實時高效分析提供了可能性。

上面詳細描述了海量數據的實時處理、數據存儲以及分析的解決方案，那在面對異構數據源接入又是如何處理的呢？閒魚由於場景眾多，業務複雜，在處理異構數據源時我們採用領域維度統計的方式，將不同領域的各類數據源字段統一化，在Blink清洗數據時會結合場景、人群、分桶等維度信息來解決異構數據源的問題。

由上圖可知，領域模塊主要分為流量域、用戶域、交易域、互動域等，每個領域中都會抽象出相應的對象，例如流量域中有商品、廣告和運營投放；用戶域中有用戶、設備、賣家和買家；交易域中有詢單、成交、GMV；互動域中有收藏、超讚和評論。
在設計異構數據源的解決方案時也考慮到後面打造開放平臺的需求，所以將數據接入層抽象成不同領域的接口對外提供接入服務並且在應用層也開放了各個維度的統計接口。這樣對有接入實時數倉的業務需求時可以通過數據層和應用層開放的抽象接口快速接入，不用考慮整個鏈路中間的細節，能夠極大地減少開發週期。

4.階段性成果

本文中所構建的實時數倉在實時報表，曝光異常反饋等方面有所應用，通過平臺可以實時地瀏覽系統大盤、首頁、猜你喜歡、搜索等場景的各個維度數據，提升了閒魚各個場景的實時數據的豐富度。目前通過實時數倉的應用，也取得了一些成果：

• 能夠實時評估線上策略的最終效果；
• 能夠快速排查定位用戶反饋的曝光異常問題；
• 能夠給產品同學提供圈品後的實時報表信息等等。

5.展望

目前我們對實時數倉的開發還處於初期階段，後續我們會加大力度投入研發，使實時數倉在更多的場景應用起來，打造一個實時、全面、穩定的流量應用平臺。後期我們將會在以下幾個方面深挖和優化：

• 與集團內的其他監控告警平臺對接，使得在本平臺內不僅能夠更細粒度地監控各個場景的商品流量異常情況，而且能夠收穫一個擁有監控、預警、定位、自修復一站式的安保平臺。
• 打造實時數倉的開放平臺提供給其他團隊使用，能夠節約更多的人力資源和開發週期。

註釋：
[1] Hologres: Hologres是阿里巴巴自主研發的一款交互式分析產品，兼容PostgreSQL 11協議，與大數據生態無縫連接，支持高併發和低延時地分析處理PB級數據。
[2] Blink:Blink是阿里巴巴實時計算部通過改進開源Apache Flink項目而創建的阿里內部產品。
[3] UT:UserTrack主要指無線端 APP 的各種用戶行為操作日誌，是所有基於用戶行為分析的運營報表的基礎。
[4] TT:TimeTunnel是一個高效的、可靠的、可擴展的消息通信平臺。