關于大規模實時數倉搭建，我有幾條心得...

閑魚技術——雨成

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是一個高效的、可靠的、可擴充的消息通信平台。