早期架構選用的是 Hadoop 生態(tài)圈組件，以 Spark 批計算引擎為核心構建了最初的離線數(shù)倉架構，基于 Flink 計算引擎進行實時處理。從源端采集到的業(yè)務數(shù)據(jù)和日志數(shù)據(jù)將分為實時和離線兩條鏈路：在實時部分，業(yè)務庫數(shù)據(jù)通過 Binlog 的方式接入，日志數(shù)據(jù)使用 Flume-Kafka-Sink 進行實時采集，利用 Flink 將數(shù)據(jù)計算寫入到 Kafka 和 MySQL中。在實時數(shù)倉的內部，遵守數(shù)據(jù)分層的理論以實現(xiàn)最大程度的數(shù)據(jù)復用。
在離線部分，利用 Sqoop 和 DataX 對全量和增量業(yè)務庫中的數(shù)據(jù)進行定時同步，日志數(shù)據(jù)通過 Flume 和日志服務進行采集。當不同數(shù)據(jù)源進入到離線數(shù)倉后，首先使用 Hive on Spark/Tez 進行定時調度處理，接著根據(jù)維度建模經過 ODS、DWD、DWS、ADS 層數(shù)據(jù)，這些數(shù)據(jù)存儲在 HDFS 和對象存儲 COS 上，最終利用 Presto 進行數(shù)據(jù)查詢展示，并通過 Metabase 提供交互式分析服務。同時為了保障數(shù)據(jù)的一致性，我們會通過離線數(shù)據(jù)對實時數(shù)據(jù)進行定期覆蓋。
問題與挑戰(zhàn)：基于 Hadoop 的早期架構可以滿足我們的初步需求，而面對較為復雜的分析訴求則顯得心有余而力不足，再加上近年來，荔枝微課用戶體量不斷上升，數(shù)據(jù)量呈指數(shù)級上升，為了更好地為業(yè)務賦能，提高用戶使用體驗，業(yè)務側對數(shù)據(jù)的實時性、可用性、響應速度也提出了更高的要求。在這樣的背景下，早期架構暴露的問題也越發(fā)明顯：
·組件繁多，維護復雜，運維難度非常高
·數(shù)據(jù)處理鏈路過長，導致查詢延遲變高
·當有新的數(shù)據(jù)需求時，牽一發(fā)而動全身，所需開發(fā)周期比較長
·數(shù)據(jù)時效性低，只可滿足 T+1 的數(shù)據(jù)需求，從而也導致數(shù)據(jù)分析效率低下
三、技術選型
通過對數(shù)據(jù)規(guī)模及早期架構存在的問題進行評估，我們決定引入一款實時數(shù)倉來搭建新的數(shù)據(jù)平臺，同時希望新的 OLAP 引擎可以具備以下能力：
·支持 Join 操作，可滿足不同業(yè)務用戶靈活多變的分析需求
·支持高并發(fā)查詢，可滿足日常業(yè)務的報表分析需求
·性能強悍，可以在海量數(shù)據(jù)場景下實現(xiàn)快速響應
·運維簡單，縮減運維人力的投入和成本的支出，實現(xiàn)降本提效
·統(tǒng)一數(shù)倉構建，簡化繁瑣的大數(shù)據(jù)軟件棧
·社區(qū)活躍，在使用過程中遇到問題，可迅速與社區(qū)取得聯(lián)系
基于以上要求，我們快速定位了 Apache Doris 和 ClickHouse 這兩款開源 OLAP 引擎 ，這兩款引擎都是當下使用較為廣泛、口碑不錯的產品。在調研中發(fā)現(xiàn)，ClickHouse在寬表查詢時有著非常出色的性能表現(xiàn)，寫入速度快，對于大量的數(shù)據(jù)更新非常實用；但對于join場景，通常需要額外的調優(yōu)才能有較好的表現(xiàn)。而我們在大多數(shù)業(yè)務場景中都需要基于明細數(shù)據(jù)進行大數(shù)據(jù)量的 Join，相比而言，Apache Doris 多表 Join 能力強悍，高并發(fā)能力優(yōu)異，完全可以滿足我們日常的業(yè)務報表分析需求。除此之外，Apache Doris 可以同時支持實時數(shù)據(jù)服務、交互數(shù)據(jù)分析和離線數(shù)據(jù)處理多種場景，并且支持 Multi Catalog ，可以實現(xiàn)統(tǒng)一的數(shù)據(jù)門戶，這幾個特點都是我們核心考慮的幾個能力。
同時，我們也了解到騰訊云數(shù)據(jù)倉庫 Doris這款產品。作為一款支持在線業(yè)務和多維分析的實時數(shù)倉產品，騰訊云數(shù)據(jù)倉庫 Doris 100% 兼容開源 Apache Doris，整體架構簡潔易用，極簡運維，彈性伸縮，功能完備，一站式的分析解決方案，滿足各種業(yè)務數(shù)據(jù)分析場景，能夠助力企業(yè)快速構建云上數(shù)據(jù)分析平臺。
在多源數(shù)據(jù)加工方面， Flink 有著優(yōu)秀的表現(xiàn)滿足我們的實時數(shù)據(jù)加工訴求，我們選擇了騰訊云大數(shù)據(jù) EMR-Flink。騰訊云EMR是一款基于云原生技術和泛 Hadoop 生態(tài)開源技術的安全、低成本、高可靠的開源大數(shù)據(jù)平臺，提供了非常豐富的組件選項。而作為云原生大數(shù)據(jù)產品，騰訊云數(shù)據(jù)倉庫 Doris與EMR這兩款產品之間能夠無縫集成與聯(lián)動。
基于以上優(yōu)勢，我們最終選擇與騰訊云大數(shù)據(jù)合作，采用騰訊云數(shù)據(jù)倉庫 Doris + EMR 來搭建新的實時數(shù)倉架構體系。
四、新的架構及方案
在新的架構中我們采取 騰訊云數(shù)據(jù)倉庫 Doris 和 騰訊云EMR-Flink 來構建實時數(shù)倉，多種數(shù)據(jù)源的數(shù)據(jù)經過 Flink CDC 或 Flink 加工處理后，入庫到 Kafka 和 Doris 中，最終由 Doris 提供統(tǒng)一的查詢服務。在數(shù)據(jù)同步上，一般通過 Flink CDC 將 RDS 數(shù)據(jù)實時同步到 Doris，通過 Flink 將 Kafka 的日志數(shù)據(jù)加工處理到 Doris，重要的指標數(shù)據(jù)一般由 Flink 計算，再經過 Kafka 分層處理寫入到 Doris 中。
·在存儲媒介上，主要使用 騰訊云數(shù)據(jù)倉庫 Doris 進行流批數(shù)據(jù)的統(tǒng)一存儲。
·架構收益：成功構建了規(guī)范的、計算統(tǒng)一的實時數(shù)倉平臺，騰訊云數(shù)據(jù)倉庫 Doris 的 Multi Catalog 功能助力我們統(tǒng)一了不同數(shù)據(jù)源出口，實現(xiàn)聯(lián)邦查詢。同時利用外部表插入的方式進行快速數(shù)據(jù)同步和修復，真正實現(xiàn)了統(tǒng)一數(shù)據(jù)門戶。
·數(shù)據(jù)實時性有效提升，通過 Flink + Doris 架構，實時性從早期 T+1 縮短為的分鐘級延遲。并發(fā)能力強，可以覆蓋更多的業(yè)務場景。
·極大地減少了運維成本，Doris 架構簡單，只有 FE 和 BE 兩個進程，不依賴其他系統(tǒng)；另外，集群擴縮容非常簡單，可實現(xiàn)用戶無感知擴容。
·開發(fā)周期從周級別降至天級別，開發(fā)周期大幅縮短，開發(fā)效率較之前提升了50%。
五、搭建經驗 數(shù)據(jù)建模
結合騰訊云數(shù)據(jù)倉庫 Doris 的特性，我們對數(shù)據(jù)倉庫進行了建模，建模方式與傳統(tǒng)數(shù)倉類似：
1、ODS 層：ODS 層日志數(shù)據(jù)選擇 Duplicate 模型的分區(qū)表，分區(qū)表方便進行數(shù)據(jù)修復，Duplicate 模型還可以減少非必要的 Compaction。ODS 層業(yè)務庫數(shù)據(jù)采用 Unique 數(shù)據(jù)模型（業(yè)務庫 MySQL 單表數(shù)據(jù)通過 Flink CDC 實時同步到 Doris，Kafka 日志數(shù)據(jù)經 Flink 清洗，通過 Doris 的 Routine Load 寫入 Doris 作為 ODS 層），DISTRIBUTED BY HASH KEY 根據(jù)具體的業(yè)務場景進行選擇：
如果考慮機器資源，可選擇均勻分布的 KEY，讓 Tablet 數(shù)據(jù)能夠均勻分布，使得查詢時各 BE 資源能夠充分利用，避免出現(xiàn)木桶效應；
如果考慮大表 Join 性能，可以依據(jù) Colocate Join 特性進行創(chuàng)建，讓 Join 查詢更高效；
Doris 1.2 版本中 Unqiue 模型開始支持寫時合并 Merge On Write，進一步提升了 Unique 模型的查詢性能；
2、DWD 層：對于通過 Flink 將數(shù)據(jù)進行 Join 打寬處理分別寫入 Doris 和 Kafka 中的場景，選擇使用 Unique 數(shù)據(jù)模型；
對于高頻查詢的寬表選擇 Doris 的 Aggregate 模型，使用 REPLACE_IF_NOT_NULL 字段類型，將多個事實單表進行插入，通過 Doris 的 Compaction 機制可以有效減少 Flink 狀態(tài) TTL 導致歷史數(shù)據(jù)沒有及時更新的問題。
3、DWS 層和 ADS 層：主要采用 Unique 數(shù)據(jù)模型，DWS 層根據(jù)數(shù)據(jù)量大小按天、月進行分區(qū)。除此之外，我們還會利用INSERT INTO語句進行 5 分鐘的任務調度和 T+1 的任務修復來進行數(shù)倉分層，便于需求的快速開發(fā)和實時數(shù)據(jù)修復。對于 Duplicate 模型的數(shù)據(jù)表，我們會創(chuàng)建 Rollup 的物化視圖，通過擊中物化視圖查詢能夠加快上層表查詢效率。
數(shù)據(jù)開發(fā)
在荔枝微課業(yè)務中，運營人員經常會有調整直播課程信息、修改專欄名稱等操作，針對維度快速變化但寬表中維度列沒有及時更新的場景，為了能更好地滿足業(yè)務需求，我們利用 Doris Aggregate 模型 的 REPLACE_IF_NOT_NULL字段特性，通過 Flink CDC 多表分別寫入 Doris 維度表的部分列。當課程維度表數(shù)據(jù)發(fā)生變化時，需要查詢上層維度（專欄和直播間），對維度表補全，再將數(shù)據(jù)插入到 Doris 中；當上層維度（專欄和直播間）發(fā)生變化時，需要下鉆查詢課程表，補全對應的課程 ID ，再將數(shù)據(jù)插入到 Doris 中。通過該方式可以保證維度表中所有字段的實時性，數(shù)據(jù)查詢時再通過寬表來關聯(lián)維表補全維度字段展示數(shù)據(jù)。
庫表設計
在初期設計階段，為了更好地利用騰訊云數(shù)據(jù)倉庫 Doris 提供的 Colocation Join 功能，我們特別設計了事實表的主鍵，如下圖示例：
在業(yè)務庫中課程表 A 和課程表 B 的關系是A.id=B.lecture_id，為了實現(xiàn) Colocation Join，我們將 B 的distributed by hash key設置為lecture_id。當面對多事實表時，先進行 Colocation Join ，再進行維度 Bucket Shuffle Join ，以實現(xiàn)快速查詢響應。而使用這個方式可能導致以下問題：當選取的 lecture_id 進行DISTRIBUTED BY時，數(shù)據(jù)庫主鍵 ID 并不是均勻分布的，在數(shù)據(jù)量很大的情況下可能會導致數(shù)據(jù)傾斜，而各個機器的 Tablet 大小不一致，在高并發(fā)查詢時可能出現(xiàn) BE 機器資源使用不均衡，從而影響查詢穩(wěn)定性，造成資源浪費。
基于以上問題，我們嘗試進行調整，并對查詢效率和機器資源的占用這兩方面進行了評估權衡，最終決定在盡量不影響查詢效率的前提下，盡可能提高資源利用率。在資源利用上，我們在建表時利用colocate_with屬性，在不同數(shù)量和類型的 Distributed Key 創(chuàng)建不同的 Group，實現(xiàn)機器資源能得以充分利用。
在查詢效率上，根據(jù)業(yè)務場景和需求對前綴索引的字段順序進行針對性調整，對于必選或高頻的查詢條件，將字段放在 UNIQUE KEY 前面，根據(jù)維度按照從高到低的順序進行設計。其次我們利用物化視圖對字段順序進行調整，盡可能使用前綴索引進行查詢，以加快數(shù)據(jù)查詢 。除此之外，我們對數(shù)據(jù)量進行月、天分區(qū)，對明細數(shù)據(jù)進行分桶，通過合理庫表的設計減少 FE 元數(shù)據(jù)的壓力。
數(shù)據(jù)管理
在數(shù)據(jù)管理方面，我們進行了以下操作：
·監(jiān)控告警：對于重要的單表，我們一般通過 騰訊云數(shù)據(jù)倉庫 Doris 來創(chuàng)建外部表，通過數(shù)據(jù)質量監(jiān)控來對比業(yè)務庫數(shù)據(jù)和 Doris 數(shù)據(jù)，進行數(shù)據(jù)質量稽查告警。
·數(shù)據(jù)備份與恢復：我們會將 Doris 數(shù)據(jù)定期導入到 HDFS 進行備份，避免數(shù)據(jù)誤刪除或丟失的情況發(fā)生。比如當因某些原因導致 Flink 同步任務失敗、無法從 Checkpoint 進行啟動時，我們可讀取最新的數(shù)據(jù)進行同步，歷史缺失數(shù)據(jù)通過外部表進行修復，使得同步任務能夠快速恢復。
六、收益總結
在新架構中我們從 Hadoop 生態(tài)完全地遷移到 Flink + Doris 上，在上層構建不同的數(shù)據(jù)應用，比如自助報表、自助數(shù)據(jù)提取、數(shù)據(jù)大屏、業(yè)務預警等，Doris 通過應用層接口服務項目統(tǒng)一對外提供 API 查詢，新架構的應用也為我們帶來了許多收益：支撐了荔枝微課內部 90% 以上的業(yè)務場景，整體可達到毫秒級的查詢響應。
·支持千萬級甚至億級大表關聯(lián)查詢，可實現(xiàn)秒級甚至毫秒級響應。
·Doris 統(tǒng)一了數(shù)據(jù)源出口，查詢效率顯著提升，支持多種數(shù)據(jù)的聯(lián)邦查詢，降低了多數(shù)據(jù)查詢的復雜度以及數(shù)據(jù)鏈路處理成本。
·Doris 架構簡單，極大簡化了大數(shù)據(jù)的架構體系；并高度兼容 MySQL 的語法，極大降低開發(fā)人員接入成本。
七、未來規(guī)劃
荔枝微課在引入騰訊云數(shù)據(jù)倉庫 Doris 之后，在內部得到了非常廣泛的應用，滿足了各業(yè)務場景需求、實現(xiàn)降本提效，深得十方融海各數(shù)據(jù)部門高度認可。未來我們期待 騰訊云數(shù)據(jù)倉庫 Doris在實時數(shù)據(jù)處理場景的能力上有更進一步的提升，包括 Unique 模型上的部分列更新、單表物化視圖上的計算增強、自動增量刷新的多表物化視圖等，通過不斷的迭代更新，使實時數(shù)倉的構建更加簡單易用。最后，感謝騰訊云大數(shù)據(jù)和selectDB團隊，感謝其對問題的快速響應和積極的技術支持。同時，騰訊云也將不斷打磨產品，探索惠及更多行業(yè)場景的云端實踐之路。
