美團外賣數據倉庫通過MOLAP+ROLAP雙引擎模式來適配不同應用場景。MOLAP引擎使用了Apache Kylin。ROLAP我們經過綜合考慮，選擇了Apache Doris。本文將介紹Doris在美團外賣數倉的實踐。
序言
本文側重於以Doris引擎為“發動機”的數倉生產架構的改進與思考。在開源的大環境下，各種數據引擎百花齊放，但由於業務的複雜性與多樣性，目前並沒有哪個引擎能夠適配所有業務場景，因此希望通過我們的業務實踐與思考為大家提供一些經驗參考。美團外賣數倉技術團隊致力於將數據應用效率最大化，同時兼顧研發、生產與運維成本的最小化，建設持續進步的數倉能力，也歡迎大家多給我們提出建議。
數倉交互層引擎的應用現狀
目前，互聯網業務規模變得越來越大，不論是業務生產系統還是日誌系統，基本上都是基於Hadoop/Spark分佈式大數據技術生態來構建數據倉庫，然後對數據進行適當的分層、加工、管理。而在數據應用交互層面，由於時效性的要求，數據最終的展現查詢還是需要通過DBMS（MySQL）、MOLAP（Kylin）引擎來進行支撐。如下圖所示：
彙總數據的交互
業務團隊日常經營分析最典型的場景就是各種維度下的自定義查詢，面對如此靈活可變、所見即所得的應用場景，美團平臺使用Kylin作為公司的主要MOLAP引擎。MOLAP是預計算生產，在增量業務，預設維度分析場景下表現良好，但在變化維的場景下生產成本巨大。例如，如果使用最新商家類型回溯商家近三個月的表現，需要重新計算三個月的Cube，需花費幾個小時，來計算近TB的歷史數據。另外，應對非預設維度分析，MOLAP模型需要重新進行適配計算，也需要一定的迭代工作。
明細數據的交互
業務分析除了宏觀數據之外，對明細數據查詢也是一種剛需。通常大家會選擇MySQL等關係型DB作為明細數據的快速檢索查詢，但當業務成長較快時，很快就會遇到性能瓶頸，並且運維成本也很高。例如，大數據量的同步、新增字段、歷史數據更新等操作，它們的維護成本都非常高。
外賣運營業務特點
美團的使命是“幫大家吃得更好，生活更好”。外賣業務為大家提供送餐服務，連接商家與用戶，這是一個勞動密集型的業務，外賣業務有上萬人的運營團隊來服務全國幾百萬的商家，並以“商圈”為單元，服務於“商圈”內的商家。
“商圈”是一個組織機構維度中的最小層級，源於外賣組織的特點，“商圈”及其上層組織機構是一個變化維度，當“商圈”邊界發生變化時，就導致在往常日增量的業務生產方式中，歷史數據的回溯失去了參考意義。在所有展現組織機構數據的業務場景中，組織機構的變化是一個繞不開的技術問題。此外，商家品類、類型等其它維度也存在變化維的問題。如下圖所示：
數據生產面臨的挑戰
數據爆炸，每日使用最新維度對歷史數據進行回溯計算。在Kylin的MOLAP模式下存在如下問題：
- 歷史數據每日刷新，失去了增量的意義。
- 每日回溯歷史數據量大，10億+的歷史數據回溯。
- 數據計算耗時3小時+，存儲1TB+，消耗大量計算存儲資源，同時嚴重影響SLA的穩定性。
- 預計算的大量歷史數據實際使用率低下，實際工作中對歷史的回溯80%集中在近1個月左右，但為了應對所有需求場景，業務要求計算近半年以上的歷史。
- 不支持明細數據的查詢。
解決方案：引入MPP引擎，數據現用現算
既然變化維的歷史數據預計算成本巨大，最好的辦法就是現用現算，但現用現算需要強大的並行計算能力。OLAP的實現有MOLAP、ROLAP、HOLAP三種形式，MOLAP以Cube為表現形式，但計算與管理成本較高。ROLAP需要強大的關係型DB引擎支撐。長期以來，由於傳統關係型DBMS的數據處理能力有限，所以ROLAP模式受到很大的侷限性。
隨著分佈式、並行化技術成熟應用，MPP引擎逐漸表現出強大的高吞吐、低時延計算能力，號稱“億級秒開”的引擎不在少數，ROLAP模式可以得到更好的延伸。單從業務實際應用考慮，性能在千萬量級關聯查詢現場計算秒開的情況下，已經可以覆蓋到很多應用場景，具備應用的可能性。例如：日數據量的ROLAP現場計算，周、月趨勢的計算，以及明細數據的瀏覽都可以較好的應對。
下圖是MOLAP模式與ROLAP模式下應用方案的比較：
MOLAP模式的劣勢
- 應用層模型複雜，根據業務需要以及Kylin生產需要，還要做較多模型預處理。這樣在不同的業務場景中，模型的利用率也比較低。
- Kylin配置過程繁瑣，需要配置模型設計，並配合適當的“剪枝”策略，以實現計算成本與查詢效率的平衡。
- 由於MOLAP不支持明細數據的查詢，在“彙總+明細”的應用場景中，明細數據需要同步到DBMS引擎來響應交互，增加了生產的運維成本。
- 較多的預處理伴隨著較高的生產成本。
ROLAP模式的優勢
- 應用層模型設計簡化，將數據固定在一個穩定的數據粒度即可。比如商家粒度的星形模型，同時複用率也比較高。
- App層的業務表達可以通過視圖進行封裝，減少了數據冗餘，同時提高了應用的靈活性，降低了運維成本。
- 同時支持“彙總+明細”。
- 模型輕量標準化，極大的降低了生產成本。
綜上所述，在變化維、非預設維、細粒度統計的應用場景下，使用MPP引擎驅動的ROLAP模式，可以簡化模型設計，減少預計算的代價，並通過強大的實時計算能力，可以支撐良好的實時交互體驗。
雙引擎下的應用場景適配問題
架構上通過MOLAP+ROLAP雙引擎模式來適配不同應用場景，如下圖所示：
技術權衡
MOLAP：通過預計算，提供穩定的切片數據，實現多次查詢一次計算，減輕了查詢時的計算壓力，保證了查詢的穩定性，是“空間換時間”的最佳路徑。實現了基於Bitmap的去重算法，支持在不同維度下去重指標的實時統計，效率較高。
ROLAP：基於實時的大規模並行計算，對集群的要求較高。MPP引擎的核心是通過將數據分散，以實現CPU、IO、內存資源的分佈，來提升並行計算能力。在當前數據存儲以磁盤為主的情況下，數據Scan需要的較大的磁盤IO，以及並行導致的高CPU，仍然是資源的短板。因此，高頻的大規模彙總統計，併發能力將面臨較大挑戰，這取決於集群硬件方面的並行計算能力。傳統去重算法需要大量計算資源，實時的大規模去重指標對CPU、內存都是一個巨大挑戰。目前Doris最新版本已經支持Bitmap算法，配合預計算可以很好地解決去重應用場景。
業務模型適配
MOLAP：當業務分析維度相對固化，並在可以使用歷史狀態時，按照時間進行增量生產，加工成本呈線性增長狀態，數據加工到更粗的粒度（如組織單元），減少結果數據量，提高交互效率。如上圖所示，由A模型預計算到B模型，使用Kylin是一個不錯的選擇。
ROLAP：當業務分析維度靈活多變或者特定到最新的狀態時（如上圖A模型中，始終使用最新的商家組織歸屬查看歷史），預計算回溯歷史數據成本巨大。在這種場景下，將數據穩定在商家的粒度，通過現場計算進行歷史數據的回溯分析，實現現用現算，可以節省掉預計算的巨大成本，並帶來較大的應用靈活性。這種情況下適合MPP引擎支撐下的ROLAP生產模式。
MPP引擎的選型
目前開源的比較受關注的OLAP引擎很多，比如Greenplum、Apache Impala、Presto、Doris、ClickHouse、Druid、TiDB等等，但缺乏實踐案例的介紹，所以我們也沒有太多的經驗可以借鑑。於是，我們就結合自身業務的需求，從引擎建設成本出發，並立足於公司技術生態融合、集成、易用性等維度進行綜合考慮，作為選型依據，最終我們平臺部門選擇了2018年剛進入Apache社區的Doris。
Doris簡介及特點
Doris是基於MPP架構的OLAP引擎，主要整合了Google Mesa（數據模型）、Apache Impala（MPP Query Engine）和Apache ORCFile （存儲格式，編碼和壓縮）的技術。
Doris的系統架構如下，主要分為FE和BE兩個組件，FE主要負責查詢的解析、編譯、優化、調度和元數據管理；BE主要負責查詢的執行和數據存儲。關於Doris的更多技術細節，可參考其官方文檔。
整體架構
Doris的特點：
- 同時支持高併發點查詢和高吞吐的Ad-hoc查詢。
- 同時支持離線批量導入和實時數據導入。
- 同時支持明細和聚合查詢。
- 兼容MySQL協議和標準SQL。
- 支持Rollup Table和Rollup Table的智能查詢路由。
- 支持較好的多表Join策略和靈活的表達式查詢。
- 支持Schema在線變更。
- 支持Range和Hash二級分區。
Doris在外賣數倉中的應用效率
上圖是我們在一個分析項目改造中的評估項目收益，整體在查詢效率不變的情況下，生產耗能及存儲成本都有較大收益。
以20臺BE+3FE的Doris環境，效率、性能表現情況如下：
- 支撐數據分析產品數十個以上，整體響應達到ms級。
- 支持百萬、千萬級大表關聯查詢，同時進行維表關聯的雪花模型，經過Colocate Join特性優化，可以實現秒級響應。
- 日級別，基於商家明細現場計算，同時滿足彙總及下鑽明細查詢，查詢時效基本都可以控制在秒級。
- 7日趨勢分析，2~3秒。由於數據量較大，根據集群規模不同查詢性能有所區別，但數據量較大時，調動的集群資源較多，因此MPP的併發性能受限於集群的性能。一般原則是併發較高的業務，需要嚴格控制查詢時效（基本在毫秒級），對於併發不高的業務，允許進行較大的查詢，但也要考慮集群的承受能力。
- 通過一年來的應用以及Doris的不斷改進升級，Doris的高可靠、高可用、高可擴展性也得到進一步驗證，服務穩定可靠。
準實時場景下的應用
離線業務分析大多基於T+1的離線數據，但在營銷活動場景下，外賣團隊往往需要當日的實時數據進行業務變化的監控與分析，通常情況下會採用實時流計算來實現。
外賣實時業務監控有如下特點：
- 避免分鐘級的生產波動影響，業務上10、15分鐘準實時數據可以滿足分析需要。
- 實時數據需要與離線數據進行日環比與周同比的比對。
- 訂單業務需要事件時間，體驗業務需要生產時間，業務對齊邏輯複雜。
- 不同業務線需求差異大，指標需要良好擴展性。
由於業務上的複雜性，實時流計算中，需要考慮諸多業務口徑的對齊，業務ER模型在合流處理中開發成本較高，資源佔用較大，通過設計基於Doris的準實時生產數倉，可以靈活地實現業務微批處理，且開發生產成本都比較低。以下為基於Doris的準實時數倉架構設計，是典型的實時Lambda生產架構：
實現準實時計算方案，需要以下能力的支撐：
- 實時的寫入能力：目前支持Kafka To Doris秒級延遲。在可靠性、穩定性建設方面仍需進一步提升。
- 引擎建設：短平快的計算+高效的存儲性能。目前Doris引擎性能仍有進步空間，2020年將有較大改進提升，隨著後續Page Cache，內存表等能力的上線，IO將不再拖後腿，併發能力將有較大提升。
- 可靠的調度能力：提供5、10、15、30分鐘的調度保障能力。
- Lambda架構簡化：實時數據與離線數據更好的在Doris中進行融合，靈活支撐應用。
- 高效的OLAP交互：支撐業務的靈活查詢訪問，業務層通過視圖進行邏輯封裝直接複用彙總層多維模型，提高了開發效率，減少了運維成本。
相比Storm、Flink中的窗口計算，準實時DB微批的優勢：
Doris引擎在美團的重要改進
Join 謂詞下推的傳遞性優化
如上圖所示，對於下面的 SQL：
<code>select * from t1 join t2 on t1.id = t2.id where t1.id = 1/<code>
Doris開源版本默認會對t2表進行全表Scan，這樣會導致上面的查詢超時，進而導致外賣業務在Doris上的第一批應用無法上線。
於是我們在Doris中實現了第一個優化：Join謂詞下推的傳遞性優化（MySQL和TiDB中稱之為Constant Propagation）。Join謂詞下推的傳遞性優化是指：基於謂詞t1.id = t2.id和t1.id = 1, 我們可以推斷出新的謂詞t2.id = 1，並將謂詞t2.id = 1下推到t2的Scan節點。這樣假如t2表有數百個分區的話，查詢性能就會有數十倍甚至上百倍的提升，因為t2表參與Scan和Join的數據量會顯著減少。
查詢執行多實例併發優化
如上圖所示，Doris默認在每個節點上為每個算子只會生成1個執行實例。這樣的話，如果數據量很大，每個執行實例的算子就需要處理大量的數據，而且無法充分利用集群的CPU、IO、內存等資源。
一個比較容易想到的優化手段是，我們可以在每個節點上為每個算子生成多個執行實例。這樣每個算子只需要處理少量數據，而且多個執行實例可以並行執行。
下圖是併發度設置為5的優化效果，可以看到對於多種類型的查詢，會有3到5倍的查詢性能提升：
Colocate Join
Colocate Join（Local Join）是和Shuffle Join、Broadcast Join相對的概念，即將兩表的數據提前按照Join Key Shard，這樣在Join執行時就沒有數據網絡傳輸的開銷，兩表可以直接在本地進行Join。
整個Colocate Join在Doris中實現的關鍵點如下：
- 數據導入時保證數據本地性。
- 查詢調度時保證數據本地性。
- 數據Balance後保證數據本地性。
- 查詢Plan的修改。
- Colocate Table元數據的持久化和一致性。
- Hash Join的粒度從Server粒度變為Bucket粒度。
- Colocate Join的條件判定。
關於Doris Colocate Join的更多實現細節，可以參考《Apache Doris Colocate Join 原理與實踐》。
對於下面的SQL，Doris Colocate Join和Shuffle Join在不同數據量下的性能對比如下：
<code>select count(*) FROM A t1 INNER JOIN [shuffle] B t5 ON ((t1.dt = t5.dt) AND (t1.id = t5.id)) INNER JOIN [shuffle] C t6 ON ((t1.dt = t6.dt) AND (t1.id = t6.id)) where t1.dt in (xxx days);/<code>
Bitmap 精確去重
Doris之前實現精確去重的方式是現場計算的，實現方法和Spark、MapReduce類似：
對於上圖計算PV的SQL，Doris在計算時，會按照下圖的方式進行計算，先根據page列和user_id列group by，最後再Count：
圖中是6行數據在2個BE節點上計算的示意圖
顯然，上面的計算方式，當數據量越來越大，到幾十億幾百億時，使用的IO資源、CPU資源、內存資源、網絡資源會變得越來越多，查詢也會變得越來越慢。
於是我們在Doris中新增了一種Bitmap聚合指標，數據導入時，相同維度列的數據會使用Bitmap聚合。有了Bitmap後，Doris中計算精確去重的方式如下：
可以看到，當使用Bitmap之後，之前的PV計算過程會大幅簡化，現場查詢時的 IO、CPU、內存，網絡資源也會顯著減少，並且不再會隨著數據規模而線性增加。
總結與思考
在外賣運營分析的業務實踐中，由於業務的複雜及應用場景的不同，沒有哪一種數據生產方案能夠解決所有業務問題。數據庫引擎技術的發展，為我們提供更多手段提升數據建設方案。實踐證明，以Doris引擎為驅動的ROLAP模式可以較好地處理彙總與明細、變化維的歷史回溯、非預設維的靈活應用、準實時的批處理等場景。而以Kylin為基礎的MOLAP模式在處理增量業務分析，固化維度場景，通過預計算以空間換時間方面依然重要。
業務方面，通過外賣數倉Doris的成功實踐以及跨事業群的交流，美團已經有更多的團隊瞭解並嘗試使用了Doris方案。而且在平臺同學的共同努力下，引擎性能還有較大提升空間，相信以Doris引擎為驅動的ROLAP模式會為美團的業務團隊帶來更大的收益。從目前實踐效果看，其完全有替代Kylin、Druid、ES等引擎的趨勢。
目前，數據庫技術進步飛速，近期柏睿數據發佈全內存分佈式數據庫RapidsDB v4.0支持TB級毫秒響應（處理千億數據可實現毫秒級響應）。可以預見，數據庫技術的進步將大大改善數倉的分層管理與應用支撐效率，業務將變得“定義即可見”，也將極大地提升數據的價值。
- Doris文檔和源碼
- Apache Kylin VS Apache Doris
- 朱良，美團外賣數據倉庫工程師。
- 凱森，Apache Kylin Committer，美團大數據工程師。
---------- END ----------
招聘信息
美團外賣數據智能組長期招聘數據倉庫、數據挖掘、機器學習、計算機視覺、搜索推薦算法工程師，座標北京。歡迎感興趣的同學發送閱歷到：[email protected]（郵件標題註明：外賣數據智能組）
閱讀更多 美團技術團隊 的文章
