早期架構(gòu)選用的是 Hadoop 生態(tài)圈組件，以 Spark 批計算引擎為核心構(gòu)建了最初的離線數(shù)倉架構(gòu)，基于 Flink 計算引擎進(jìn)行實時處理。從源端采集到的業(yè)務(wù)數(shù)據(jù)和日志數(shù)據(jù)將分為實時和離線兩條鏈路：在實時部分，業(yè)務(wù)庫數(shù)據(jù)通過 Binlog 的方式接入，日志數(shù)據(jù)使用 Flume-Kafka-Sink 進(jìn)行實時采集，利用 Flink 將數(shù)據(jù)計算寫入到 Kafka 和 MySQL中。在實時數(shù)倉的內(nèi)部，遵守數(shù)據(jù)分層的理論以實現(xiàn)最大程度的數(shù)據(jù)復(fù)用。

在離線部分，利用 Sqoop 和 DataX 對全量和增量業(yè)務(wù)庫中的數(shù)據(jù)進(jìn)行定時同步，日志數(shù)據(jù)通過 Flume 和日志服務(wù)進(jìn)行采集。當(dāng)不同數(shù)據(jù)源進(jìn)入到離線數(shù)倉后，首先使用 Hive on Spark/Tez 進(jìn)行定時調(diào)度處理，接著根據(jù)維度建模經(jīng)過 ODS、DWD、DWS、ADS 層數(shù)據(jù)，這些數(shù)據(jù)存儲在 HDFS 和對象存儲 COS  上，最終利用 Presto 進(jìn)行數(shù)據(jù)查詢展示，并通過 Metabase 提供交互式分析服務(wù)。同時為了保障數(shù)據(jù)的一致性，我們會通過離線數(shù)據(jù)對實時數(shù)據(jù)進(jìn)行定期覆蓋。

問題與挑戰(zhàn)：基于 Hadoop 的早期架構(gòu)可以滿足我們的初步需求，而面對較為復(fù)雜的分析訴求則顯得心有余而力不足，再加上近年來，荔枝微課用戶體量不斷上升，數(shù)據(jù)量呈指數(shù)級上升，為了更好地為業(yè)務(wù)賦能，提高用戶使用體驗，業(yè)務(wù)側(cè)對數(shù)據(jù)的實時性、可用性、響應(yīng)速度也提出了更高的要求。在這樣的背景下，早期架構(gòu)暴露的問題也越發(fā)明顯：

·組件繁多，維護(hù)復(fù)雜，運維難度非常高

·數(shù)據(jù)處理鏈路過長，導(dǎo)致查詢延遲變高

·當(dāng)有新的數(shù)據(jù)需求時，牽一發(fā)而動全身，所需開發(fā)周期比較長

·數(shù)據(jù)時效性低，只可滿足 T+1 的數(shù)據(jù)需求，從而也導(dǎo)致數(shù)據(jù)分析效率低下

三、技術(shù)選型

通過對數(shù)據(jù)規(guī)模及早期架構(gòu)存在的問題進(jìn)行評估，我們決定引入一款實時數(shù)倉來搭建新的數(shù)據(jù)平臺，同時希望新的 OLAP 引擎可以具備以下能力：

·支持 Join 操作，可滿足不同業(yè)務(wù)用戶靈活多變的分析需求

·支持高并發(fā)查詢，可滿足日常業(yè)務(wù)的報表分析需求

·性能強悍，可以在海量數(shù)據(jù)場景下實現(xiàn)快速響應(yīng)

·運維簡單，縮減運維人力的投入和成本的支出，實現(xiàn)降本提效

·統(tǒng)一數(shù)倉構(gòu)建，簡化繁瑣的大數(shù)據(jù)軟件棧

·社區(qū)活躍，在使用過程中遇到問題，可迅速與社區(qū)取得聯(lián)系

基于以上要求，我們快速定位了 Apache Doris 和 ClickHouse 這兩款開源 OLAP 引擎 ，這兩款引擎都是當(dāng)下使用較為廣泛、口碑不錯的產(chǎn)品。在調(diào)研中發(fā)現(xiàn)，ClickHouse在寬表查詢時有著非常出色的性能表現(xiàn)，寫入速度快，對于大量的數(shù)據(jù)更新非常實用；但對于join場景，通常需要額外的調(diào)優(yōu)才能有較好的表現(xiàn)。而我們在大多數(shù)業(yè)務(wù)場景中都需要基于明細(xì)數(shù)據(jù)進(jìn)行大數(shù)據(jù)量的 Join，相比而言，Apache Doris 多表 Join 能力強悍，高并發(fā)能力優(yōu)異，完全可以滿足我們?nèi)粘５臉I(yè)務(wù)報表分析需求。除此之外，Apache Doris 可以同時支持實時數(shù)據(jù)服務(wù)、交互數(shù)據(jù)分析和離線數(shù)據(jù)處理多種場景，并且支持 Multi Catalog ，可以實現(xiàn)統(tǒng)一的數(shù)據(jù)門戶，這幾個特點都是我們核心考慮的幾個能力。

同時，我們也了解到騰訊云數(shù)據(jù)倉庫 Doris這款產(chǎn)品。作為一款支持在線業(yè)務(wù)和多維分析的實時數(shù)倉產(chǎn)品，騰訊云數(shù)據(jù)倉庫 Doris 100% 兼容開源 Apache Doris，整體架構(gòu)簡潔易用，極簡運維，彈性伸縮，功能完備，一站式的分析解決方案，滿足各種業(yè)務(wù)數(shù)據(jù)分析場景，能夠助力企業(yè)快速構(gòu)建云上數(shù)據(jù)分析平臺。

在多源數(shù)據(jù)加工方面， Flink 有著優(yōu)秀的表現(xiàn)滿足我們的實時數(shù)據(jù)加工訴求，我們選擇了騰訊云大數(shù)據(jù) EMR-Flink。騰訊云EMR是一款基于云原生技術(shù)和泛 Hadoop 生態(tài)開源技術(shù)的安全、低成本、高可靠的開源大數(shù)據(jù)平臺，提供了非常豐富的組件選項。而作為云原生大數(shù)據(jù)產(chǎn)品，騰訊云數(shù)據(jù)倉庫 Doris與EMR這兩款產(chǎn)品之間能夠無縫集成與聯(lián)動。

基于以上優(yōu)勢，我們最終選擇與騰訊云大數(shù)據(jù)合作，采用騰訊云數(shù)據(jù)倉庫 Doris + EMR 來搭建新的實時數(shù)倉架構(gòu)體系。

四、新的架構(gòu)及方案

在新的架構(gòu)中我們采取  騰訊云數(shù)據(jù)倉庫 Doris 和 騰訊云EMR-Flink 來構(gòu)建實時數(shù)倉，多種數(shù)據(jù)源的數(shù)據(jù)經(jīng)過 Flink CDC 或 Flink 加工處理后，入庫到  Kafka 和 Doris 中，最終由 Doris 提供統(tǒng)一的查詢服務(wù)。在數(shù)據(jù)同步上，一般通過 Flink CDC 將 RDS 數(shù)據(jù)實時同步到 Doris，通過 Flink 將 Kafka 的日志數(shù)據(jù)加工處理到 Doris，重要的指標(biāo)數(shù)據(jù)一般由 Flink 計算，再經(jīng)過 Kafka 分層處理寫入到 Doris 中。

·在存儲媒介上，主要使用 騰訊云數(shù)據(jù)倉庫 Doris 進(jìn)行流批數(shù)據(jù)的統(tǒng)一存儲。

·架構(gòu)收益：成功構(gòu)建了規(guī)范的、計算統(tǒng)一的實時數(shù)倉平臺，騰訊云數(shù)據(jù)倉庫 Doris 的 Multi Catalog 功能助力我們統(tǒng)一了不同數(shù)據(jù)源出口，實現(xiàn)聯(lián)邦查詢。同時利用外部表插入的方式進(jìn)行快速數(shù)據(jù)同步和修復(fù)，真正實現(xiàn)了統(tǒng)一數(shù)據(jù)門戶。

·數(shù)據(jù)實時性有效提升，通過 Flink + Doris 架構(gòu)，實時性從早期 T+1 縮短為的分鐘級延遲。并發(fā)能力強，可以覆蓋更多的業(yè)務(wù)場景。

·極大地減少了運維成本，Doris 架構(gòu)簡單，只有 FE 和 BE 兩個進(jìn)程，不依賴其他系統(tǒng)；另外，集群擴(kuò)縮容非常簡單，可實現(xiàn)用戶無感知擴(kuò)容。

·開發(fā)周期從周級別降至天級別，開發(fā)周期大幅縮短，開發(fā)效率較之前提升了50%。

五、搭建經(jīng)驗 數(shù)據(jù)建模

結(jié)合騰訊云數(shù)據(jù)倉庫 Doris 的特性，我們對數(shù)據(jù)倉庫進(jìn)行了建模，建模方式與傳統(tǒng)數(shù)倉類似：

1、ODS 層：ODS 層日志數(shù)據(jù)選擇 Duplicate 模型的分區(qū)表，分區(qū)表方便進(jìn)行數(shù)據(jù)修復(fù)，Duplicate 模型還可以減少非必要的 Compaction。ODS 層業(yè)務(wù)庫數(shù)據(jù)采用 Unique 數(shù)據(jù)模型（業(yè)務(wù)庫 MySQL 單表數(shù)據(jù)通過 Flink CDC 實時同步到 Doris，Kafka 日志數(shù)據(jù)經(jīng) Flink 清洗，通過 Doris 的 Routine Load 寫入 Doris 作為 ODS 層），DISTRIBUTED BY HASH KEY 根據(jù)具體的業(yè)務(wù)場景進(jìn)行選擇：

如果考慮機器資源，可選擇均勻分布的 KEY，讓 Tablet 數(shù)據(jù)能夠均勻分布，使得查詢時各 BE 資源能夠充分利用，避免出現(xiàn)木桶效應(yīng)；

如果考慮大表 Join 性能，可以依據(jù) Colocate Join 特性進(jìn)行創(chuàng)建，讓 Join 查詢更高效；

Doris 1.2 版本中 Unqiue 模型開始支持寫時合并 Merge On Write，進(jìn)一步提升了 Unique 模型的查詢性能；

2、DWD 層：對于通過 Flink 將數(shù)據(jù)進(jìn)行 Join 打?qū)捥幚矸謩e寫入 Doris 和 Kafka 中的場景，選擇使用 Unique 數(shù)據(jù)模型；

對于高頻查詢的寬表選擇 Doris 的 Aggregate 模型，使用 REPLACE_IF_NOT_NULL 字段類型，將多個事實單表進(jìn)行插入，通過 Doris 的 Compaction 機制可以有效減少 Flink 狀態(tài) TTL 導(dǎo)致歷史數(shù)據(jù)沒有及時更新的問題。

3、DWS 層和 ADS 層：主要采用 Unique 數(shù)據(jù)模型，DWS 層根據(jù)數(shù)據(jù)量大小按天、月進(jìn)行分區(qū)。除此之外，我們還會利用INSERT INTO語句進(jìn)行 5 分鐘的任務(wù)調(diào)度和 T+1 的任務(wù)修復(fù)來進(jìn)行數(shù)倉分層，便于需求的快速開發(fā)和實時數(shù)據(jù)修復(fù)。對于 Duplicate 模型的數(shù)據(jù)表，我們會創(chuàng)建 Rollup 的物化視圖，通過擊中物化視圖查詢能夠加快上層表查詢效率。

數(shù)據(jù)開發(fā)

在荔枝微課業(yè)務(wù)中，運營人員經(jīng)常會有調(diào)整直播課程信息、修改專欄名稱等操作，針對維度快速變化但寬表中維度列沒有及時更新的場景，為了能更好地滿足業(yè)務(wù)需求，我們利用 Doris Aggregate 模型 的 REPLACE_IF_NOT_NULL字段特性，通過 Flink CDC 多表分別寫入 Doris 維度表的部分列。當(dāng)課程維度表數(shù)據(jù)發(fā)生變化時，需要查詢上層維度（專欄和直播間），對維度表補全，再將數(shù)據(jù)插入到 Doris 中；當(dāng)上層維度（專欄和直播間）發(fā)生變化時，需要下鉆查詢課程表，補全對應(yīng)的課程 ID ，再將數(shù)據(jù)插入到 Doris 中。通過該方式可以保證維度表中所有字段的實時性，數(shù)據(jù)查詢時再通過寬表來關(guān)聯(lián)維表補全維度字段展示數(shù)據(jù)。   

庫表設(shè)計

在初期設(shè)計階段，為了更好地利用騰訊云數(shù)據(jù)倉庫 Doris 提供的 Colocation Join 功能，我們特別設(shè)計了事實表的主鍵，如下圖示例：

在業(yè)務(wù)庫中課程表 A 和課程表 B 的關(guān)系是A.id=B.lecture_id，為了實現(xiàn) Colocation Join，我們將 B 的distributed by hash key設(shè)置為lecture_id。當(dāng)面對多事實表時，先進(jìn)行 Colocation Join ，再進(jìn)行維度 Bucket Shuffle Join ，以實現(xiàn)快速查詢響應(yīng)。而使用這個方式可能導(dǎo)致以下問題：當(dāng)選取的 lecture_id 進(jìn)行DISTRIBUTED BY時，數(shù)據(jù)庫主鍵 ID 并不是均勻分布的，在數(shù)據(jù)量很大的情況下可能會導(dǎo)致數(shù)據(jù)傾斜，而各個機器的 Tablet 大小不一致，在高并發(fā)查詢時可能出現(xiàn) BE 機器資源使用不均衡，從而影響查詢穩(wěn)定性，造成資源浪費。

基于以上問題，我們嘗試進(jìn)行調(diào)整，并對查詢效率和機器資源的占用這兩方面進(jìn)行了評估權(quán)衡，最終決定在盡量不影響查詢效率的前提下，盡可能提高資源利用率。在資源利用上，我們在建表時利用colocate_with屬性，在不同數(shù)量和類型的 Distributed Key 創(chuàng)建不同的 Group，實現(xiàn)機器資源能得以充分利用。

在查詢效率上，根據(jù)業(yè)務(wù)場景和需求對前綴索引的字段順序進(jìn)行針對性調(diào)整，對于必選或高頻的查詢條件，將字段放在 UNIQUE KEY 前面，根據(jù)維度按照從高到低的順序進(jìn)行設(shè)計。其次我們利用物化視圖對字段順序進(jìn)行調(diào)整，盡可能使用前綴索引進(jìn)行查詢，以加快數(shù)據(jù)查詢 。除此之外，我們對數(shù)據(jù)量進(jìn)行月、天分區(qū)，對明細(xì)數(shù)據(jù)進(jìn)行分桶，通過合理庫表的設(shè)計減少 FE 元數(shù)據(jù)的壓力。

數(shù)據(jù)管理

在數(shù)據(jù)管理方面，我們進(jìn)行了以下操作：

·監(jiān)控告警：對于重要的單表，我們一般通過 騰訊云數(shù)據(jù)倉庫 Doris 來創(chuàng)建外部表，通過數(shù)據(jù)質(zhì)量監(jiān)控來對比業(yè)務(wù)庫數(shù)據(jù)和 Doris 數(shù)據(jù)，進(jìn)行數(shù)據(jù)質(zhì)量稽查告警。

·數(shù)據(jù)備份與恢復(fù)：我們會將 Doris 數(shù)據(jù)定期導(dǎo)入到 HDFS 進(jìn)行備份，避免數(shù)據(jù)誤刪除或丟失的情況發(fā)生。比如當(dāng)因某些原因?qū)е?Flink 同步任務(wù)失敗、無法從 Checkpoint 進(jìn)行啟動時，我們可讀取最新的數(shù)據(jù)進(jìn)行同步，歷史缺失數(shù)據(jù)通過外部表進(jìn)行修復(fù)，使得同步任務(wù)能夠快速恢復(fù)。

六、收益總結(jié)

在新架構(gòu)中我們從 Hadoop 生態(tài)完全地遷移到 Flink + Doris 上，在上層構(gòu)建不同的數(shù)據(jù)應(yīng)用，比如自助報表、自助數(shù)據(jù)提取、數(shù)據(jù)大屏、業(yè)務(wù)預(yù)警等，Doris 通過應(yīng)用層接口服務(wù)項目統(tǒng)一對外提供 API 查詢，新架構(gòu)的應(yīng)用也為我們帶來了許多收益：支撐了荔枝微課內(nèi)部 90% 以上的業(yè)務(wù)場景，整體可達(dá)到毫秒級的查詢響應(yīng)。

·支持千萬級甚至億級大表關(guān)聯(lián)查詢，可實現(xiàn)秒級甚至毫秒級響應(yīng)。

·Doris 統(tǒng)一了數(shù)據(jù)源出口，查詢效率顯著提升，支持多種數(shù)據(jù)的聯(lián)邦查詢，降低了多數(shù)據(jù)查詢的復(fù)雜度以及數(shù)據(jù)鏈路處理成本。

·Doris 架構(gòu)簡單，極大簡化了大數(shù)據(jù)的架構(gòu)體系；并高度兼容 MySQL 的語法，極大降低開發(fā)人員接入成本。

七、未來規(guī)劃

荔枝微課在引入騰訊云數(shù)據(jù)倉庫 Doris 之后，在內(nèi)部得到了非常廣泛的應(yīng)用，滿足了各業(yè)務(wù)場景需求、實現(xiàn)降本提效，深得十方融海各數(shù)據(jù)部門高度認(rèn)可。未來我們期待 騰訊云數(shù)據(jù)倉庫 Doris在實時數(shù)據(jù)處理場景的能力上有更進(jìn)一步的提升，包括 Unique 模型上的部分列更新、單表物化視圖上的計算增強、自動增量刷新的多表物化視圖等，通過不斷的迭代更新，使實時數(shù)倉的構(gòu)建更加簡單易用。最后，感謝騰訊云大數(shù)據(jù)和selectDB團(tuán)隊，感謝其對問題的快速響應(yīng)和積極的技術(shù)支持。同時，騰訊云也將不斷打磨產(chǎn)品，探索惠及更多行業(yè)場景的云端實踐之路。

崔歡歡