美團餐飲SaaS基於StarRocks構建商家資料中臺的探索

語言: CN / TW / HK
時間 2022-12-27 12:02:06
主題:
作者：何啟航，美團餐飲SaaS資料專家（文章整理自作者在 StarRocks Summit Asia 2022 的分享）
 
隨著社會經濟的發展，餐飲連鎖商家越來越大，“萬店時代”來臨。對於美團餐飲 SaaS 來說，傳統的 OLTP 引擎已經無法滿足當前資料生產和查詢場景，亟需一款 OLAP 資料引擎解決資料查詢複雜度大幅提高、資料價值挖掘能力不足等痛點。經過多方測試比對，美團餐飲 SaaS 選擇了 StarRocks 來構建商家資料中臺。
經過一段時間的探索，StarRocks 極速查詢、 簡單部署、高效運維等特點，很好滿足了美團商家資料中臺的需求，查詢效能提升了 28 倍以上。本文將從業務介紹、技術選型、資料中臺、建設成果等四個方面，介紹美團餐飲 SaaS 如何基於 StarRocks 為商家構建資料中臺。
 

業務介紹

首先，概要介紹一下美團餐飲系統，其使用的資料產品、基本的系統架構以及業務所面臨的痛點。

美團餐飲系統

上圖左側展示了美圖餐飲系統的功能全景圖。可以看到其功能非常豐富， toC 的部分包括掃碼點餐、外賣、團購等；toB 的部分包括老闆看到的一些經營分析、財務管理、進銷存等。
根據場景，系統分為線下和線上兩個部分：線下，為餐飲商戶提供餐廳數字化解決方案，幫餐廳實現從前廳管理、後廚生產管理、會員管理、線上運營管理，到供應鏈管理的整套數字化經營；線上，實現餐廳和平臺的打通，幫助餐廳連結顧客，幫助餐飲商戶瞭解顧客、商圈，輔助商業決策，併為顧客帶來更好的消費體驗。

資料產品

上圖展示了美團餐飲 SaaS 兩大類資料產品的截圖，左側是核心報表產品，右側是智慧應用。可以看到報表種類很多，有彙總表、明細表、業務預警表、財務統計表等。智慧應用的截圖是一個商家選址的應用。商家可以通過地圖去選擇一塊區域，然後根據一些標籤，比如業態、流量等去選擇合適的經營地址。
我們資料產品的使用者包括廚師長、收銀員、老闆、店長、財務，業務場景包括：
  • 經營分析：如分析營業額、收入等。
  • 智慧決策：利用分析結果進行智慧決策，比如為老闆推薦什麼菜賣的好，該如何配置套餐等等。
  • 業務預警：老闆可以配置一些閾值，比如收營員一天返結多少錢、退賬多少錢，一旦達到閾值就要通知老闆及財務對賬。
  • 財務對賬：一些比較大的商家每個月或者每個季度都有專門的財務進行對賬。
以上場景決定了我們的業務具有以下特點：
  • 資料質量高
  • 迭代效率高
  • 查詢體驗好
  • 資料體量大
其中，資料質量高是非常重要的一個特點。美團餐飲資料產品不同於一般的大資料產品，一般的大資料產品主要是作分析決策使用，而我們的場景中除了分析決策還要財務對賬。 財務對賬是和錢掛鉤的，算錯一分一釐都有可能引起客訴，嚴重情況還會引起資損，所以我們這裡對資料質量要求非常高。這也影響我們後續的技術架構選型，以及整體的系統設計。

系統架構

我們整體中臺的架構和市面中臺的架構基本一致，最下面是業務資料，從下往上，根據資料處理流程分為以下幾層：
  • 第一層是資料同步層，使用公司的同步元件將資料入倉，到資料生產層。
  • 第二層是資料生產層，分為離線數倉和實時數倉兩塊。從上圖可以看到，離線數倉和實時數倉都採用了相同的分層模型，這樣的目的就是為了提高迭代效率。其他資料團隊，實時和離線通常是兩組人員來開發，離線可能使用 Apache Hive 等批計算引擎，實時可能選擇 Apache Flink、Apache Spark 等流式系統進行煙囪式的實時指標開發。我們為了加快迭代效率，統一了離線和實時數倉，採用了基於 SQL 的開發模式，讓一些離線分層模型可以得到複用，從而提高了迭代效率。
  • 第三層是資料儲存層，選擇了穩定性比較高的 MySQL 作為儲存引擎，但是隨著資料的持續增長，MySQL 會有效能和儲存的瓶頸，因此也逐漸引入了一些 HTAP 的儲存引擎，如 TiDB。
  • 第四層是資料服務層，提供一些原子的基礎服務，支撐百花齊放的資料應用。
  • 第五層就是資料應用層，包括報表和資料應用等。
為了保證資料質量，在這套架構上還橫向增加了監控系統和穩定性保障系統。監控系統主要是為了發現數據質量問題，並將其報給穩定性系統；穩定性保障系統會識別這些問題，然後選擇合適的方式去自動修復異常資料，進一步提高資料質量。

業務痛點

隨著業務發展，連鎖商家越來越大，我們邁入了“萬店時代”，大一點的連鎖管理的連鎖店可能有上萬家，這樣就帶來兩個痛點：
一，這些商家查詢的資料量和複雜度大幅提高。具體有三個方向的挑戰：
  • 資料儲存量大（單表 10T 級別，數百億資料）
  • 單次查詢上千萬資料量
  • 查詢複雜度高，最多涉及 5 張表 Join，數十欄位 Group 聚合
二，這種級別的商家一般會有自己的研發和 IT 人員，所以他們也要求獨立的資料價值挖掘能力，自己去分析資料集。這也帶來了三個方向的挑戰：
  • 異構資料來源的融合，商家可能使用不同的系統，比如收銀使用美團，而供應鏈、財務、人力用的是其它系統，在做資料分析時需要將不同資料融合進行統一分析，所以需要我們的資料中臺具備異構資料來源融合的能力。
  • 這種規模的商家一般會自己採辦 IDC 獨立進行部署，因此需要我們整體的資料中臺的部署，並且要低成本、高效地進行部署。
  • 現在我們資料中臺提供的一些業務模型和功能都是普適性的，是給一般商家使用的，但這種規模的商家一般都有自己獨特的需求，希望我們能夠提供一些大的底表，然後他們根據這些底表去做分析。
面對這些痛點，傳統的 OLTP 引擎無法滿足當前資料生產和查詢的場景。
 

技術選型

接下來介紹技術選型的過程以及 StarRocks 的特性。

儲存選型

前文提到 TP 引擎已無法滿足我們的使用場景，所以需要一款 AP 的引擎來解決以上痛點。但是由於我們是從 TP 引入到 AP ，因此 查詢效能好只是最基礎的一個要求。我們要根據自身業務特點，還要適配現有架構來進行選型，所以除了效能，我們 還要考慮使用成本、易用性和運維成本。
  • 使用成本：我們要求 AP 引擎要具有很好的 Join 能力，因為現在數倉沿用分層模型，主題表會涉及到很多表的關聯操作，如果 Join 能力不夠就會需要模型的調整，改動就會比較大。
  • 易用性：查詢端介面都是使用標準的 SQL 協議進行查詢，因此我們希望新的 AP 引擎也具備標準的 SQL 協議，這樣查詢端就無需做太多更改。
  • 運維成本：由於商家可能希望進行獨立部署，需要運維成本比較低，這樣就不需要投入過多的研發和 IT 資源。
基於以上幾點我們對比了市面上常見的 AP 引擎，Apache Druid、ClickHouse、Apache Kylin、StarRocks，最終選擇了 StarRocks。

選擇 StarRocks

再來具體看一下 StarRocks 是如何滿足我們商家資料中臺需求的。
上圖左側列出了 StarRocks 的一些特點，包括極速查詢、簡單部署、高效開發這三大方面。
這些特點可以幫助我們應對右側所列的技術挑戰，自下而上來看：
  • 獨立部署：因為 StarRocks 是不依賴其他任何外部系統的，同時可以線上進行節點的擴縮容、自動故障恢復，所以它可以滿足我們獨立部署的要求。
  • 多資料來源接入：StarRocks 支援市面上大部分資料來源，所以這一點也是滿足的。
  • 高效迭代：StarRocks 支援多種建模方式，支援多種 Join 方式，在引入的過程中整個數倉不需要做很多更改，我們的迭代效率會很高。
  • 大規模儲存：StarRocks 是分散式的資料庫，所以天然滿足大規模儲存。
  • 極速查詢：StarRocks 作為全新的 MPP 執行框架，相對於其它 AP 系統還做了很多獨特的優化，比如向量化執行引擎，以及 CBO 的一些專項優化等等，因此其查詢速度非常快。
  • 低程式碼 BI：依託極速查詢，可以做一些底表，商家能夠通過拖拉拽的簡單方式實現一些即席分析。
 

資料中臺

這一章節將介紹我們引入 StarRocks 之後新的資料中臺架構，以及一些關鍵設計，會分為 5 個部分：
  • 基於 StarRocks 的資料中臺架構
  • 資料同步
  • 虛擬檢視
  • 智慧分級查詢
  • 多活熱備

基於 StarRocks 的資料中臺架構

新的資料中臺在架構上並沒有太多改變，只是在各環節增強了能力。原始資料層，新增了異構資料來源，這樣可以支援商家其它產品資料的接入；資料同步層，基於 StarRocks 的導數功能擴充套件了資料同步的能力，讓其更加高效；資料倉庫層，還是沿用了當前數倉分層的模型設計，新增了 StarRocks 的資料來源，整體業務採取了混合儲存的模式；再往上，實現了零程式碼的 BI，基於 StarRocks 極速查詢的能力，支援大的 KA 進行自助分析。
下面具體介紹一些技術要點。

資料同步

整個資料生產系統採用的是 Lambda 架構，離線資料通過 Hive 計算；實時資料通過我們自研的實時計算系統，將資料生產到 Kafka。基於此我們的資料同步也分離線和實時兩個部分來設計。
首先，上圖中藍色的部分是專為離線資料設計的同步功能，分為三塊：全量導數、增量導數和變更導數。全量導數和變更導數使用了 StarRocks 的 Broker-load 功能，增量導數則使用了 StarRocks 的 Stream-load 功能。
全量導數，顧名思義，就是將全量的資料匯入到 StarRocks。由於我們的資料量非常大，有數十 TB，全量導數是十分耗費資源的，並且時間也比較長，因此我們僅會在表的初始化，或者表出現問題需要重新匯入時才會使用全量導數。對於歷史資料的變更我們是結合增量導數和變更導數來實現的。
增量導數是指只導最近一段時間的資料，資料量會比較少，比如只導最近一個月的資料，通過分割槽替換的方式來更新 StarRocks 的資料。但是變更還可能是在一個月之外的資料，所以在上游還會有另外一個離線任務去計算一個月之外產生變更的資料，計算完之後就會自動觸發變更導數。
變更導數會拿到歷史變更資料並對 StarRocks 的資料進行覆蓋。通過增量導數加上變更導數的方式，我們實現了歷史資料的更新，同時這種方式也大大減少了日常的導數量。我們進行了一個估計，10T 的資料可以控制在 100G 左右，這樣可以很大程度提高我們資料同步的效率。
下面綠色部分是實時資料的同步，實時資料的同步沒有做過多的設計，直接採用的是 StarRocks 的 Flink-Load。通過這種方式可以將資料同步到 StarRocks 中，但是我們採用的是混合儲存的方式，也就是資料會在多個數據源中儲存，那麼就存在資料一致性的問題。為了解決這個問題，我們專門設計了同步保障系統。
上圖中最右側的同步保障系統有兩個模組，第一個模組是監控系統，提供了多種監控方式，比如流式監控，實時監控 StarRocks 的變更資料，與其它資料來源變更資料進行實時校驗，並將異常進行記錄。還提供批量監控的功能，對 StarRocks 中的資料計算一個彙總值，比如算一張表的總金額、總訂單數，然後和另外一個數據源的總金額和總訂單數進行比對，如果發現有問題就說明資料在處理過程中存在問題，也會將這些資料異常記錄下來。所有記錄下來的異常會交給非同步糾錯模組，這個模組會去識別 StarRocks 整體的負載能力，當它低峰期的時候就會非同步進行修復。通過這種方式可以保證資料的最終一致性。從而提高了整體的資料質量。

虛擬檢視

另一個關鍵設計是虛擬檢視。上圖左側是我們現有的數倉開發模式，可以看到我們的數倉 RD 採用實時和離線計算平臺，使用分層的數倉模型進行開發，同時離線和實時採用相同的分層模型，分層模型是基於血緣關係進行預計算的，每一層的資料都物化儲存到了 MySQL 當中用於加速查詢，最終資料應用的一個查詢過來，只需要查詢 ADS 層就可以將結果返回給客戶，這樣就可以加快整個查詢。
然而這種方式在新的資料中臺中無法滿足低成本、高效的獨立部署，原因主要有兩點：
  • 沿用現有方式，需要額外部署一套離線計算系統和實時計算系統，增加了部署成本。
  • 拋棄分層模型，採用煙囪式開發，那麼和內部系統是兩套邏輯，會導致迭代慢。
針對以上問題， 我們的解法是，基於 StarRocks 高效的查詢能力和 Google 提出的 Shasta 理論，進行虛擬化檢視。整體的分層模型不變，開發方式也是一致的，但是 DWT 層和 ADS 層是虛擬化檢視，也就是資料不做物化儲存。當一次查詢過來時，還是會查詢 ADS 層，這時系統會判斷如果 ADS 的資料是虛擬檢視，就會將 SQL 進行下推，下推到 DWT 層，這時系統會發現 DWT 層同樣是虛擬檢視，然後 SQL 還會持續下推，一直推到 DWD 層，這一層是做了物化儲存的，就會生成一個真實 SQL 去查詢 StarRocks，最終將結果返回給使用者。
以前無法實現虛擬化檢視的原因是，下推的 SQL 會非常複雜，傳統的 TP 引擎根本無法查詢出來。
虛擬檢視的優勢可以總結為以下三點：
  • 首先，沿用分層模型，對於數倉 RD 是沒有感知的，仍然按照分層模型來開發，無論虛擬檢視還是物化檢視都是系統自動判斷，因此對於他們來說還是可以做到邏輯複用，提高迭代效率。
  • 第二點是去預計算，DWT 和 ADS 這種重計算的層級被我們虛擬化了，所以不需要額外去部署離線計算系統和實時計算系統，由此可以達到低成本的部署。
  • 第三點是資料無狀態，可以加快迭代。按照以前的開發模式，如果數倉 RD 的邏輯出現了 Bug，DWT 和 ADS 層的資料會出現問題，就要進行資料重刷，在非常大的資料規模下，在保證穩定性的同時去重刷 DWT 和 ADS 層的資料，這個動作是非常重的，有可能需要幾周的時間，迭代就會非常慢。而採用虛擬化檢視的形式，所見即所得，當邏輯出現問題時，只需要修改 DWT 和 ADS 層的 SQL 邏輯，查詢時直接查詢 DWD 層，就可以即時生效。DWD 層一般就是簡單的資料清洗入倉，通常不會有很多邏輯，所以問題也比較少。通過這種方式去掉了資料狀態，從而加快了迭代效率。
通過這三個優勢，保證了我們資料中臺低成本、高效的獨立部署。

智慧分級查詢

我們的查詢有如下特點：
  • OLAP 併發能力低於 OLTP 引擎，當前場景高峰期併發查詢 QPS 很高（萬級別），壓力很大；
  • 99%+的查詢資料量小（數十萬以內），這部分查詢 OLAP 和 OLTP 效能差距不大，但如果全部放在 OLAP，收益較低，同時也會增加 OLAP 引擎的穩定性風險。
所以 我們的整體思路是減少 OLAP 的 併發 壓力 ，提高每次查詢的 ROI。我們設計了分級查詢，智慧預測查詢資料量，合理路由（MySQL->TiDB->StarRocks），資料量大的去 StarRocks 查詢，資料量小的就去 OLTP 查詢。
上圖下半部分展示了整體的系統設計。系統提供了一個智慧查詢 SDK，是嵌入到介面服務當中的，因此對上游業務是沒有感知的，上游並不知道查詢的是哪個資料來源，但可以快速拿到資料。智慧查詢 SDK 分為兩個模組，一個是資料來源自動切換模組，會根據我們的分級策略自動選擇不同的資料來源，去查詢返回資料。
核心模組是智慧分級策略模組，其分級策略有兩個部分，一個是實時的動態路由配置策略，這是 RD 根據經驗進行配置的，比如通過經驗發現商戶在查詢大於一個月的資料量時會很慢，這部分需要 OLAP 引擎去加速，就會配置一個到 OLAP 去查詢的策略，這部分是人工配置的策略。第二部分是機器自動識別的策略，我們會有離線任務，每天批量地去分析現有商戶查詢的資料量，比如分析出某些商戶在某些場景下的查詢效能比較差，這一部分需要加速，就會記錄下來，在後面查詢時，如果命中這些記錄就會放置到 OLAP 中去查詢，提升查詢體驗。通過這種智慧分級的策略，提高了每次查詢的 ROI，同時也增強了 OLAP 的穩定性。

多活熱備

最後一個設計要點是多活熱備，也是為了增強穩定性。
多活熱備分為兩層，第一層是 StarRocks 的主備叢集的切換，第二層是 OLAP 叢集和 OLTP 叢集的切換。在此之上我們還增加了資料質量監控和自動降級恢復兩層。
其運作方式為：
  • 首先，資料質量監控系統會實時監控資料質量，一旦發現數據質量降到了一個水位線之後，會自動觸發 StarRocks 的主備切換。
  • 如果資料質量還沒有恢復，則會再次觸發降級，從 OLAP 降到 OLTP 系統，前面提到這種查詢有可能在 OLTP 上是查不出來的，所以這種降級是有損降級，會犧牲查詢體驗，但是整體風險是可控的。
  • 當告警恢復後，會自動切回到 StarRocks 主叢集上進行查詢。
 

建設成果

我們的探索過程分為 4 個階段：
  • 第一個階段是可行性驗證，主要驗證了虛擬檢視可以秒級出數，滿足實時分析的場景。
  • 第二個階段是效能壓測，相比之前的 OLTP 引擎，查詢效能提升了 28 倍以上（複雜場景從數十秒到亞秒級別），併發能力也有了很大提升、吞吐在餐飲 SaaS 場景下約為 0.16qps/core。
  • 第三個階段是試點執行，完成了一套試點叢集的搭建和對應的系統建設，整個試執行期間未出現事故，整體查詢體驗得到了較大改善（tp90 提升 30%，tp99 提升 500%）。
  • 最後一個階段是正式部署，現在還沒有實施，後續會根據商家的需求進行獨立部署。
經過一段時間的探索，StarRocks 已經有一套試點叢集，其極速查詢、 簡單部署、高效運維等特點能夠很好地滿足美團商家資料中臺的需求。目前對 StarRocks 的使用還處於初級階段，後續會繼續探索更多高階功能，覆蓋更多業務場景，持續提升美團 SaaS 資料中臺的能力。
「」