本文導(dǎo)讀：

在長期服務(wù)廣大規(guī)模商戶的過程中，銀聯(lián)商務(wù)已沉淀了龐大、真實、優(yōu)質(zhì)的數(shù)據(jù)資產(chǎn)數(shù)據(jù)，這些數(shù)據(jù)不僅是銀聯(lián)商務(wù)開啟新增長曲線的基礎(chǔ)，更是進一步服務(wù)好商戶的關(guān)鍵支撐。為更好提供數(shù)據(jù)服務(wù)，銀聯(lián)商務(wù)實現(xiàn)了從 Hadoop 到 Apache Doris 的架構(gòu)升級，使數(shù)據(jù)導(dǎo)入性能提升 2-5 倍、ETL 場景性能提升 3-12 倍、查詢分析響應(yīng)速度提升 10-15 倍，滿足大規(guī)模數(shù)據(jù)導(dǎo)入和實時極速查詢的業(yè)務(wù)需求，解決了業(yè)務(wù)和數(shù)據(jù)快速增長問題，提升了數(shù)據(jù)應(yīng)用構(gòu)建的效率，充分助力業(yè)務(wù)提效與數(shù)字資產(chǎn)的服務(wù)化，推進數(shù)字化進程的落地，展示了 Apache Doris 在推動金融科技創(chuàng)新方面的巨大潛力。

作者：銀聯(lián)商務(wù) 楊勁雄、周陽

如今，數(shù)據(jù)已經(jīng)成為了推動經(jīng)濟增長的新動力，數(shù)字技術(shù)正在成為社會發(fā)展的重要引擎。隨著數(shù)字經(jīng)濟的迅猛發(fā)展，金融企業(yè)紛紛加大在金融科技領(lǐng)域的投入，以提升自身的數(shù)字化運營能力，加速數(shù)字化轉(zhuǎn)型的進程。在這一背景之下，銀聯(lián)商務(wù)以 “全量打通、準(zhǔn)確實時、隨需自助、智能交互” 為數(shù)字化轉(zhuǎn)型目標(biāo)，加快推進數(shù)字基礎(chǔ)設(shè)施建設(shè)。

在長期服務(wù)廣大規(guī)模商戶的過程中，銀聯(lián)商務(wù)已沉淀了龐大、真實、優(yōu)質(zhì)的數(shù)據(jù)資產(chǎn)數(shù)據(jù)，這些數(shù)據(jù)不僅是銀聯(lián)商務(wù)開啟新增長曲線的基礎(chǔ)，更是進一步服務(wù)好商戶的關(guān)鍵支撐。為了實現(xiàn)數(shù)據(jù)資產(chǎn)可管理、可視化、可賦能的建設(shè)目標(biāo)，銀聯(lián)商務(wù)早在 2015 年就基于 Hadoop 體系構(gòu)建了大數(shù)據(jù)平臺，為公司及商戶提供了數(shù)據(jù)支持。但隨著業(yè)務(wù)的不斷擴展，銀聯(lián)商務(wù)總公司各部門和分子公司對于數(shù)據(jù)應(yīng)用的建設(shè)需求不斷涌現(xiàn)，早期基于 Hadoop 的大數(shù)據(jù)平臺已無法高效支撐拓展性、時效性與便捷性的業(yè)務(wù)需求，因此數(shù)據(jù)平臺的迭代升級勢在必行。

2020 年起，銀聯(lián)商務(wù)開啟了數(shù)據(jù)平臺的升級之旅，基于 Apache Doris 構(gòu)建了新一代實時數(shù)據(jù)倉庫架構(gòu)，使數(shù)據(jù)導(dǎo)入性能提升 2-5 倍、ETL 場景性能提升 3-12 倍、查詢分析響應(yīng)速度提升 10-15 倍，滿足大規(guī)模數(shù)據(jù)導(dǎo)入和實時極速查詢的業(yè)務(wù)需求，解決了業(yè)務(wù)和數(shù)據(jù)快速增長問題，提升了數(shù)據(jù)應(yīng)用構(gòu)建的效率，充分助力業(yè)務(wù)提效與數(shù)字資產(chǎn)的服務(wù)化，推進數(shù)字化進程的落地。

應(yīng)用場景

在長期為各行各業(yè)的海量商戶提供服務(wù)的過程中，銀聯(lián)商務(wù)沉淀了大量的交易數(shù)據(jù)、用戶數(shù)據(jù)、終端數(shù)據(jù)以及經(jīng)營數(shù)據(jù)等。通過對這些數(shù)據(jù)的挖掘和利用，為銀聯(lián)商務(wù)總、分、子公司以及商戶提供多元化的數(shù)據(jù)服務(wù)，可以發(fā)掘隱藏在其中的價值和消費趨勢，成為掌握經(jīng)營掌控、進行經(jīng)營決策的有效工具。典型數(shù)據(jù)服務(wù)場景包括：

• 經(jīng)營分析場景：建設(shè)指標(biāo)體系和駕駛艙，幫助業(yè)務(wù)方及管理者實時了解整體業(yè)務(wù)經(jīng)營狀態(tài)。
• 業(yè)務(wù)運營場景：建設(shè)標(biāo)簽體系，更好理解用戶畫像及需求，從而提供精準(zhǔn)的產(chǎn)品和業(yè)務(wù)服務(wù)。
• 數(shù)據(jù)分析和挖掘場景：構(gòu)建自助分析和報表服務(wù)，更好地了解自己的業(yè)務(wù)情況并做出科學(xué)決策。
• 對外數(shù)據(jù)服務(wù)場景：構(gòu)建對賬單、報表和數(shù)據(jù)報告服務(wù)，以幫助商戶更好地了解市場需求。

為滿足上述場景需求，銀聯(lián)商務(wù)早在 2015 年就引入了 Hadoop 體系構(gòu)建了大數(shù)據(jù)平臺，并基于 Hive 構(gòu)建了離線數(shù)倉。該架構(gòu)整合了來自 MySQL、Oracle、MongoDB 等多業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，按照 T+ 1 的時效性歸集到 Hive 離線數(shù)倉中，經(jīng)由 Hive 數(shù)倉各層的加工處理后分別同步至不同組件中提供數(shù)據(jù)查詢服務(wù)，包括基于 Kylin 與 HBase 構(gòu)建 Cube 進行指標(biāo)查詢分析，并使用 HBase 進行增量數(shù)據(jù)的質(zhì)量監(jiān)測，同時還將處理完畢的數(shù)據(jù)同步到 Oracle 中提供業(yè)務(wù)數(shù)據(jù)查詢。

該架構(gòu)各組件各司其職、整體架構(gòu)清晰，在早期承載了業(yè)務(wù)對于數(shù)據(jù)查詢服務(wù)的需求。在移動支付快速席卷的浪潮下，支付場景更加多元化，銀聯(lián)商務(wù)業(yè)務(wù)規(guī)模穩(wěn)步增長、總部及分子公司對于數(shù)據(jù)應(yīng)用的建設(shè)需求不斷涌現(xiàn)，而傳統(tǒng)的大數(shù)據(jù)平臺已經(jīng)無法高效支撐業(yè)務(wù)和數(shù)據(jù)的不斷增長，痛點逐步展現(xiàn)出來：

• 數(shù)據(jù)時效性：整體數(shù)據(jù)處理鏈路較長，大規(guī)模數(shù)據(jù)導(dǎo)入和加工處理的效率低，最新業(yè)務(wù)數(shù)據(jù)從生產(chǎn)到應(yīng)用的時間間隔太長，無法充分發(fā)揮實時數(shù)據(jù)的價值；
• 查詢效率低：Kylin 早期承擔(dān)了大多指標(biāo)查詢分析的需求，隨著業(yè)務(wù)量增長、數(shù)據(jù)預(yù)處理的成本越來越高、無法支持靈活快速的分析訴求，而 Hive 在應(yīng)對復(fù)雜查詢時性能不足、只能依賴于堆加機器，這無疑大大增加了硬件資源成本；
• 運維成本和可擴展性：整體架構(gòu)涉及多個組件，運維工作量較大，在應(yīng)對業(yè)務(wù)需求增長的過程中可擴展性不足，無法敏捷響應(yīng)數(shù)據(jù)的快速增長和數(shù)據(jù)應(yīng)用快速上線的要求。

目標(biāo)及選型

面向各行各業(yè)的數(shù)千萬商戶、行業(yè)特點和實際需求各不相同，在對企業(yè)內(nèi)部眾多平臺系統(tǒng)以及對客戶提供的產(chǎn)品進行全面梳理后，銀聯(lián)商務(wù)確定了數(shù)字化轉(zhuǎn)型要實現(xiàn)的核心目標(biāo)——“全量打通、準(zhǔn)確實時、隨需自助、智能交互”。

具體而言，“全量打通”即各平臺間充分互通、數(shù)據(jù)融合共享，便于更全面掌握數(shù)據(jù)主題的全方位信息、充分發(fā)揮數(shù)據(jù)的協(xié)同效應(yīng)；“準(zhǔn)確實時”即充分發(fā)揮數(shù)據(jù)的實時價值，并根據(jù)技術(shù)手段保證數(shù)據(jù)又“快”又“準(zhǔn)”，為后續(xù)分析打好堅實基礎(chǔ)；“隨需自取”即提供自助式的服務(wù)，靈活組合、按需取用，甚至實現(xiàn)量身定制、因客而變；“智能交互”即充分利用技術(shù)手段，從被動式的接受服務(wù)，變成主動式的能力輸出，提供分析、預(yù)測、輔助決策等智能服務(wù)，響應(yīng)用戶需求、實現(xiàn)雙向交互。

而具體到數(shù)據(jù)服務(wù)層面，在為內(nèi)外部客戶提供數(shù)據(jù)服務(wù)的過程中，銀聯(lián)商務(wù)注意到用戶對數(shù)據(jù)分析的性能、分析模式的靈活性、數(shù)據(jù)服務(wù)的穩(wěn)定性以及數(shù)據(jù)應(yīng)用的時效性有著更高的期望，因此我們決定對現(xiàn)有架構(gòu)升級，旨在滿足新的業(yè)務(wù)訴求、解決早期架構(gòu)存在的問題，于是在 2020 年正式啟動了銀聯(lián)商務(wù)數(shù)據(jù)架構(gòu)的升級之旅，升級目標(biāo)主要包含幾方面：

• 統(tǒng)一、簡潔：單一系統(tǒng)即可完成數(shù)據(jù)加工和服務(wù)的統(tǒng)一，以簡化數(shù)據(jù)處理流程，提高工作效率；
• 穩(wěn)定、高效：支持高效的數(shù)據(jù)加工和高性能的數(shù)據(jù)查詢，同時系統(tǒng)和平臺的穩(wěn)定性得以充分的保證；
• 準(zhǔn)確、實時：支持數(shù)據(jù)實時更新以及接入，保證數(shù)據(jù)準(zhǔn)確、不丟不重；
• 安全、可靠：確保數(shù)據(jù)訪問和數(shù)據(jù)存儲的安全性，支持集群災(zāi)備、數(shù)據(jù)高可靠；

基于以上目標(biāo)，我們進行了深入的調(diào)研，在對比了多種大數(shù)據(jù)組件后，選擇引入 Apache Doris 來構(gòu)建新一代實時數(shù)據(jù)倉庫架構(gòu)。

基于 Apache Doris 的新一代實時數(shù)倉架構(gòu)

在架構(gòu)的迭代過程中，一方面我們需要務(wù)必保證業(yè)務(wù)無縫運轉(zhuǎn)、避免系統(tǒng)切換造成業(yè)務(wù)體驗受影響，另一方面需要兼顧與舊有架構(gòu)的兼容、根據(jù)實際情況逐步迭代、漸進式調(diào)整，同時也希望充分發(fā)揮全新架構(gòu)的能力優(yōu)勢，因此建設(shè)路徑逐步明晰：

• 引入實時數(shù)據(jù)處理和分析鏈路，提升數(shù)據(jù)時效性；
• 推動數(shù)據(jù)應(yīng)用從離線遷至實時，并持續(xù)提升查詢分析效率，為業(yè)務(wù)提效；
• 打通離線與實時數(shù)據(jù)鏈路的屏障，統(tǒng)一數(shù)據(jù)口徑和數(shù)據(jù)服務(wù)出口，提供一致性的數(shù)據(jù)服務(wù)體驗；

因此在新的架構(gòu)中，在原有離線數(shù)據(jù)倉庫體系中增加了一條實時鏈路，通過 Kafka 將 MySQL 等各類業(yè)務(wù)數(shù)據(jù)庫中的實時數(shù)據(jù)歸集并傳輸?shù)?Apache Doris 中，并利用 Flink 和 Doris SQL 對數(shù)據(jù)進行加工處理，在 Doris 內(nèi)部構(gòu)建了從 ODS 到 ADS 的數(shù)倉分層體系。同時基于 Doris 提供的 Multi-Catalog 能力打通對 Hive 數(shù)據(jù)的查詢，避免了繁重的數(shù)據(jù)遷移成本。各上層數(shù)據(jù)應(yīng)用統(tǒng)一對接 Doris 即可，無需在離線數(shù)據(jù)和實時數(shù)據(jù)間進行切換，由 Doris 統(tǒng)一對外提供查詢服務(wù)。

這一升級，極大提升了數(shù)據(jù)處理的效率和查詢的便捷性，當(dāng)前我們正逐步推進離線數(shù)倉向以 Apache Doris 為核心的實時數(shù)倉遷移，為更高效和更大規(guī)模的數(shù)據(jù)管理和分析做好準(zhǔn)備。

接下來我們將介紹基于 Apache Doris 的實時數(shù)倉架構(gòu)的規(guī)劃與設(shè)計，我們將從數(shù)據(jù)模型、分桶策略、數(shù)據(jù)同步與加工方式出發(fā)，分享實時架構(gòu)搭建的實踐經(jīng)驗。

實時數(shù)據(jù)倉庫體系的建設(shè)與實踐

在建設(shè)數(shù)據(jù)倉庫體系時，銀聯(lián)商務(wù)遵循邊治理、邊建設(shè)、邊賦能的原則，數(shù)據(jù)治理為關(guān)鍵一環(huán)，而統(tǒng)一規(guī)劃又是其核心內(nèi)容。因此數(shù)據(jù)倉庫的統(tǒng)一規(guī)劃能夠確保數(shù)據(jù)倉庫結(jié)構(gòu)設(shè)計的合理性，不僅有利于后續(xù)對架構(gòu)的管理維護，也有利于對數(shù)據(jù)可靠性和一致性的保障。因此我們在數(shù)據(jù)倉庫統(tǒng)一規(guī)劃方面采取了以下措施：

數(shù)倉分層的合理規(guī)劃

合理的數(shù)倉分層對數(shù)據(jù)的管理以及查詢性能的充分發(fā)揮起著關(guān)鍵作用，基于 Apache Doris 豐富的數(shù)據(jù)模型，我們對數(shù)倉的分層進行了提前規(guī)劃。先來了解 Doris 數(shù)據(jù)模型都具備哪些特性：

• Duplicate Key 模型：適用于明細數(shù)據(jù)查詢場景，可支持任何維度的即席查詢；
• Unique Key 模型：適用于對數(shù)據(jù)有唯一性約束的場景、需要支持數(shù)據(jù)精確去重，或者有數(shù)據(jù)更新需求、可支持大寬表的多流 Upsert 和部分列更新；
• Aggregate Key 模型：適用于報表查詢場景，通過數(shù)據(jù)的預(yù)聚合來加速報表分析。

結(jié)合實際應(yīng)用場景和數(shù)據(jù)模型，我們來介紹銀聯(lián)商務(wù)數(shù)倉分層策略：

• ODS 層主要采用 Duplicate Key 模型，例如在交易清算場景中，銀聯(lián)商務(wù)每天有幾千萬的清算數(shù)據(jù)需處理，清算日期跨度長達一年，這就要求所有數(shù)據(jù)能被完整地存儲。為了滿足這一需求，我們在 ODS 層選擇 Duplicate Key 模型，完全按照導(dǎo)入文件中的明細數(shù)據(jù)進行存儲，沒有任何聚合操作。而部分商戶訂單數(shù)據(jù)涉及到訂單狀態(tài)的更新，因此采取 Unique Key 模型，在數(shù)據(jù)導(dǎo)入過程中如果商戶 id 以及訂單 id 相同時自動更新成最新狀態(tài)。
• DWD 與 DWS 層所采取的數(shù)據(jù)模型基本相同，其本質(zhì)差異在于對于業(yè)務(wù)數(shù)據(jù)的抽象程度，主要采用的是 Unique Key 模型，而部分有明細數(shù)據(jù)存儲的場景還保留了 Duplicate Key 模型。以結(jié)算劃付場景為例，將結(jié)算日期作為分區(qū)字段，設(shè)置表模型為 Unique Key 模型，通過這種方式能夠?qū)崿F(xiàn)跨度長達一年結(jié)算數(shù)據(jù)狀態(tài)的自動更新。
• ADS 層作為高度業(yè)務(wù)數(shù)據(jù)的抽象，采用了 Aggregate Key 模型，通過對所有結(jié)算數(shù)據(jù)進行預(yù)聚合，可大幅提高數(shù)據(jù)查詢和分析的效率，減少實時計算的壓力。

分桶分區(qū)策略的合理設(shè)置

分區(qū)分桶是優(yōu)化數(shù)據(jù)存儲和提升查詢效率的重要手段，合理設(shè)置分桶數(shù)和分桶字段可以有效提升查詢速度和數(shù)據(jù)加工腳本的執(zhí)行效率。在數(shù)倉應(yīng)用中，我們參考實際數(shù)據(jù)規(guī)模和官網(wǎng)的設(shè)置建議，會對每一張表均規(guī)劃了分桶字段和分桶數(shù)。例如，在分店寬表中經(jīng)常需要查詢分店維度數(shù)據(jù)，因此我們將分店作為分桶字段，并根據(jù)表的大小設(shè)置分桶數(shù)。以下是我們在不同 Tablet 下 Bucket 設(shè)置的數(shù)量，可供參考：

多源數(shù)據(jù)遷移方案

在銀聯(lián)商務(wù)各分支機構(gòu)數(shù)據(jù)遷移至 Doris 的過程中，我們發(fā)現(xiàn)分支機構(gòu)本地系統(tǒng)采用的數(shù)據(jù)庫種類繁多，文件存儲格式也比較復(fù)雜，這給數(shù)據(jù)遷移工作帶來不小的挑戰(zhàn)。為確保數(shù)據(jù)遷移的順利進行，我們針對不同數(shù)據(jù)和文件格式制定了相應(yīng)的遷移方案。

Doris 支持多種豐富的數(shù)據(jù)遷移方式，無論是離線數(shù)據(jù)同步還是實時數(shù)據(jù)同步，都能找到高效快捷的數(shù)據(jù)遷移方式：

• 在實時場景中，使用 Flink CDC 方式實時獲取 MySQL Binlog，其中一部分數(shù)據(jù)直接通過 Flink CDC 寫入 Doris，另一部分高流量數(shù)據(jù)則先同步至 Kafka 中進行削峰、再經(jīng)由 Flink-Doris-Connector 寫入到 Doris 中。
• 在離線場景中，數(shù)據(jù)來源更加多樣、并且文件格式也更加復(fù)雜，因此采用了多種方式進行數(shù)據(jù)遷移。對于 S3 和 HDFS 上的歷史數(shù)據(jù)及增量數(shù)據(jù)，使用 Broker Load 進行批量導(dǎo)入；對于 Hive 及 JDBC 外表存儲的數(shù)據(jù)，使用 Insert into 方式進行同步；對于文件格式的數(shù)據(jù)，使用 Flink Ftp Connector 和 Flink Doris Connector 同步（因 Ftp 方式在銀聯(lián)商務(wù)內(nèi)部是跨系統(tǒng)的數(shù)據(jù)文件交互方式，文件的格式復(fù)雜，因此開發(fā)了 Flink Ftp Connector，可支持復(fù)雜的數(shù)據(jù)格式、支持多換行符等復(fù)雜應(yīng)用場景）。

豐富的數(shù)據(jù)遷移方式使得我們可以輕松地將數(shù)據(jù)從各類數(shù)據(jù)庫遷移至 Doris 中來，同時，多文件格式的同步解決了分支機構(gòu)數(shù)據(jù)不統(tǒng)一、不規(guī)范的問題，大大降低了各分支機構(gòu)數(shù)據(jù)遷移的難度及成本，為銀聯(lián)商務(wù)的數(shù)據(jù)整合和統(tǒng)一管理提供了有力支持。

全量與增量數(shù)據(jù)的同步

在大量離線數(shù)據(jù)同步的過程中，業(yè)務(wù)的連續(xù)性和數(shù)據(jù)的準(zhǔn)確性保證十分重要，因此我們采取了兩種方式來應(yīng)對全量數(shù)據(jù)同步和增量數(shù)據(jù)同步。

在全量同步場景中，我們首先創(chuàng)建相同表結(jié)構(gòu)的臨時表，將全量數(shù)據(jù)導(dǎo)入臨時表后、再利用 ALTER TABLE t1 REPLACE WITH TABLE t2 語句對臨時表和正式表進行原子替換操作，該臨時表即成為正式表，且前端業(yè)務(wù)查詢不會有任何的阻滯。在增量同步場景則創(chuàng)建了新的增量分區(qū)，將增量數(shù)據(jù)直接同步至增量分區(qū)。

alter table ${DB_NAME}.${TBL_NAME} drop partition IF EXISTS p${P_DOWN_DATE};
ALTER TABLE ${DB_NAME}.${TBL_NAME} ADD PARTITION IF NOT EXISTS  p${P_DOWN_DATE} VALUES [('${P_DOWN_DATE}'), ('${P_UP_DATE}'));

LOAD LABEL ${TBL_NAME}_${load_timestamp} ...

離線數(shù)據(jù)加工任務(wù)遷移

當(dāng)前我們已經(jīng)把離線數(shù)倉的數(shù)據(jù)加工任務(wù)直接遷移到 Doris 進行，采用 Doris SQL 進行數(shù)據(jù)加工處理，通過調(diào)度平臺進行任務(wù)調(diào)度。

以清分流水交易寬表場景為例，過去每天需加工三千萬條數(shù)據(jù)、在 Hive 離線數(shù)倉采用的 TEZ 計算引擎進行數(shù)據(jù)加工，在分配 2T 的計算資源下，整條鏈路加工耗時長達 2.5 小時。當(dāng)將數(shù)據(jù)加工任務(wù)遷移至 Apache Doris 后，僅使用過去一半的計算資源，即可將整條鏈路加工耗時縮短為 0.5 小時，整條鏈路執(zhí)行效率提升 5 倍以上，且單個腳本執(zhí)行時效也從 8 分鐘提升到 10 秒。

金融級數(shù)倉穩(wěn)定性最佳實踐

當(dāng)前 Apache Doris 在銀聯(lián)商務(wù)已廣泛應(yīng)用于多個業(yè)務(wù)場景，服務(wù)了內(nèi)部各類經(jīng)營分析報表、用戶標(biāo)簽、自助取數(shù)平臺等應(yīng)用，并對外部商戶提供了對賬單、報表、數(shù)據(jù)報告等多種數(shù)據(jù)服務(wù)，因此集群的穩(wěn)定性和可用性對于平臺用戶體驗和業(yè)務(wù)連續(xù)性而言至關(guān)重要，任何集群故障或不穩(wěn)定因素都可能導(dǎo)致業(yè)務(wù)決策受阻、用戶信任度受影響。

因此銀聯(lián)商務(wù)采取大量措施來保證集群穩(wěn)定性和可用性，包括多租戶資源隔離、精細權(quán)限管理、集群災(zāi)備以及多種穩(wěn)定性調(diào)優(yōu)策略。

多租戶資源隔離

在實際業(yè)務(wù)運行過程中，往往存在多個業(yè)務(wù)或者不同部門同時查詢同一份數(shù)據(jù)的情況發(fā)生，在有限的資源條件下往往可能因查詢?nèi)蝿?wù)件的資源搶占導(dǎo)致查詢性能下降甚至集群不穩(wěn)定，同時針對組織架構(gòu)的不同層級對于數(shù)據(jù)的可見性要求也不一致，因此我們結(jié)合自身業(yè)務(wù)類型以及 Apache Doris 多租戶資源隔離能力進行了深度應(yīng)用。

單查詢資源限制，保證查詢間資源可控

在對內(nèi)部多個應(yīng)用進行梳理后，我們根據(jù)業(yè)務(wù)分析負載對場景和租戶進行了細分，主要劃分為數(shù)據(jù)加工（ETL）、數(shù)據(jù)探索（Ad-hoc）、數(shù)據(jù)看板（Reporting）和數(shù)據(jù)服務(wù)（Data Serving）四個場景。為確保各個場景及租戶之間的獨立性，我們對每個場景的單查詢進行了資源限制。具體來說，我們?yōu)槊總€租戶設(shè)置了四類 Doris 賬號，并對賬號的 CPU 和內(nèi)存使用資源進行了限制，初始值統(tǒng)一設(shè)置為 5 CPU，后續(xù)則根據(jù)各租戶使用情況進行微調(diào)，以達到適配的資源分配。目前銀聯(lián)商務(wù)各場景分配情況如下：

該策略的優(yōu)點在于，即使單個租戶的資源使用量增加，也只會影響該租戶在特定場景下的使用，不會對其他租戶、其他場景產(chǎn)生任何影響，有效提升了平臺的穩(wěn)定性。

基于 Resource Tag 的多租戶數(shù)據(jù)與查詢隔離

而面對總-分公司的數(shù)據(jù)使用場景，我們采用了基于 Resource Tag 的資源組物理****隔離方式，以確保數(shù)據(jù)的安全性和獨立性。

目前在 Apache Doris 中存儲了豐富多樣的數(shù)據(jù)，基于數(shù)據(jù)安全的角度考慮，對數(shù)據(jù)可見范圍進行了精細劃分，總公司可以訪問到公司層的全部數(shù)據(jù)，而分公司只能訪問自身業(yè)務(wù)范疇內(nèi)的數(shù)據(jù)。除此以外，還有部分數(shù)據(jù)是由總公司授權(quán)分公司進行查詢，或者分公司個性化數(shù)據(jù)需要與總公司數(shù)據(jù)進行關(guān)聯(lián)。在這一場景之下，我們采取了 Resource Tag 的資源隔離模式，將數(shù)據(jù)和集群可用資源單獨劃分開來。

具體而言，我們?yōu)榉止九渲锚毩⒌馁Y源組，將分公司個性化數(shù)據(jù)以三副本的方式存儲到獨立資源組中，同時將總公司數(shù)據(jù)設(shè)置為四副本，將其中三副本存儲在總公司資源組中，剩余單副本存儲到分公司獨立資源組中。當(dāng)分公司查詢總公司數(shù)據(jù)時，僅會查詢分公司資源組中的單副本數(shù)據(jù)，通過這樣的方式即保證了數(shù)據(jù)的安全性，也提高了系統(tǒng)的穩(wěn)定性及可靠性。具體方案如下：

• 設(shè)置 BE 節(jié)點標(biāo)簽：分配總公司資源組和分公司資源組，并在服務(wù)器上設(shè)置對應(yīng)標(biāo)簽。
• 設(shè)置數(shù)據(jù)分布：建表時設(shè)置replication_allocation，同時將總分公司比例設(shè)置為 3:1，該比例可結(jié)合總分公司的實際使用情況靈活調(diào)整。
• 設(shè)置用戶資源組：為用戶設(shè)置對應(yīng)的默認資源組，總、分公司使用各自資源組，從而實現(xiàn)總分公司查詢隔離。

更靈活的資源隔離方案

基于 Resource Tag 的資源隔離方案實現(xiàn)的是物理層級的資源隔離，盡管在獨立性方面更佳、但在資源的利用率方面還存在一定的優(yōu)化空間，并且無法保證進程內(nèi)更細粒度的資源隔離，因此 Apache Doris 在 2.0 版本中推出了 Workload Group 資源軟限制。

從實現(xiàn)原理來看， Workload Group 通過對工作負載分組管理，將用戶執(zhí)行的 Query 與 Workload Group 相關(guān)聯(lián)，可限制單個 Query 在 BE 節(jié)點上的 CPU 和內(nèi)存資源的百分比，并可以配置開啟資源組的內(nèi)存軟限制。當(dāng)集群資源緊張時，可自動終止內(nèi)存占用較大的查詢?nèi)蝿?wù)以緩解集群壓力。當(dāng)集群資源空閑時，當(dāng) Workload Group 使用資源超過預(yù)設(shè)值時，其他 Workload Group 可以共享空閑集群資源，并自動突破闕值、確保查詢?nèi)蝿?wù)的穩(wěn)定執(zhí)行，通過這一方式實現(xiàn)內(nèi)存和 CPU 資源的精細化管控。

我們也在持續(xù)探索新版本特性與業(yè)務(wù)的結(jié)合，后續(xù)對于數(shù)據(jù)加工、數(shù)據(jù)探索、數(shù)據(jù)看板和數(shù)據(jù)服務(wù)等場景的單查詢資源限制可以通過 Workload Group 來實現(xiàn)，并且還可以進一步利用任務(wù)優(yōu)先級和任務(wù)排隊機制來保證關(guān)鍵業(yè)務(wù)的優(yōu)先運轉(zhuǎn)。

精細用戶權(quán)限管理

為了滿足業(yè)務(wù)需求和法規(guī)合規(guī)的要求，銀聯(lián)商務(wù)建立了嚴(yán)格的用戶權(quán)限管理制度。該制度明確了不同用戶群體的角色和權(quán)限，確保了用戶只能訪問其需要的功能和數(shù)據(jù)。以下為銀聯(lián)商務(wù)用戶權(quán)限管理的方案：

• 用戶權(quán)限設(shè)置：針對每個分支機構(gòu)不同場景的不同用戶，為用戶設(shè)置不同的數(shù)據(jù)使用權(quán)限。
• 庫、表、行級權(quán)限管理：為滿足各分公司權(quán)限管理需求，一般會為每個分公司建立視圖，該方式操作繁瑣，且與 Hive 數(shù)倉的使用有較大差異，可能需要對表、語句進行修改。通過 ROW POLICY機制可以便捷實現(xiàn)庫、表、行級的權(quán)限控制，并可以將原來 Hive 數(shù)倉的任務(wù)較為無縫地遷移到 Doris 中。
• 列級權(quán)限管理：當(dāng)前采用構(gòu)建視圖的方式進行列級權(quán)限管理。

集群穩(wěn)定性保障

• SQL 熔斷：平臺對內(nèi)部用戶開放后，經(jīng)常會面臨用戶查詢 SQL 不規(guī)范消耗過多資源的情況，針對于這種情況，采用 SQL 熔斷機制對高危的 SQL 及時熔斷，以保證集群的穩(wěn)定運行。
• 導(dǎo)入并發(fā)控制：考慮我們經(jīng)常需將歷史數(shù)據(jù)同步到平臺中，這就會涉及大量數(shù)據(jù)修改任務(wù)，可能對集群會造成比較大的壓力。因此，我們使用了 Unique Key 模型的 Merge-on-Write 更新模式、啟用了 Vertical Compaction 和 Segment Compaction 并通過調(diào)整 Compaction 參數(shù)調(diào)整，以控制數(shù)據(jù)導(dǎo)入頻率、減輕集群的壓力。
• 網(wǎng)絡(luò)流量控制：針對離線、實時不同場景設(shè)置了 QoS ，通過 QoS 策略進一步實現(xiàn)網(wǎng)絡(luò)隔離?？紤]到銀聯(lián)商務(wù)內(nèi)部有上海和武漢兩套集群，異地網(wǎng)絡(luò)交互過程中的流量至關(guān)重要，因此，我們通過 QoS 策略來實現(xiàn)了精確的網(wǎng)絡(luò)隔離操作，確保不同場景下的網(wǎng)絡(luò)服務(wù)質(zhì)量與穩(wěn)定性。
• 監(jiān)控報警：為滿足公司內(nèi)部夜班值班監(jiān)控的要求，我們使用 Doris 與內(nèi)部監(jiān)控報警平臺進行對接。將 Doris 相關(guān)的監(jiān)控報警與聲光監(jiān)控、CU 即時通訊軟件以及郵件進行了對接，實現(xiàn)了對問題的實時監(jiān)控和處理。

基于 CCR 的集群災(zāi)備能力

對于金融企業(yè)而言，服務(wù)穩(wěn)定性和數(shù)據(jù)安全性是至關(guān)重要的一環(huán)，而災(zāi)備方案是確保業(yè)務(wù)連續(xù)性和數(shù)據(jù)安全性的重要措施，通過集群災(zāi)備，能夠在災(zāi)難或故障發(fā)生時迅速恢復(fù)業(yè)務(wù)和數(shù)據(jù)，最大程度地減少損失和風(fēng)險。

對于銀聯(lián)商務(wù)的核心業(yè)務(wù)數(shù)據(jù)，我們期望能夠?qū)崿F(xiàn)跨集群異地的災(zāi)備，因此我們基于跨集群數(shù)據(jù)復(fù)制能力構(gòu)建主備集群的雙活方案。正常業(yè)務(wù)查詢訪問的是主集群，關(guān)鍵業(yè)務(wù)數(shù)據(jù)會同步寫入至備用集群且保持實時更新，這樣即使某個集群發(fā)生宕機事件，也可以迅速切換到備用集群，以快速恢復(fù)核心業(yè)務(wù)和數(shù)據(jù)。

總結(jié)與規(guī)劃

面對日益增長的數(shù)據(jù)處理和分析需求，銀聯(lián)商務(wù)選擇基于 Apache Doris 構(gòu)建新一代實時數(shù)據(jù)倉庫，截至目前 Apache Doris 已經(jīng)服務(wù)了經(jīng)營分析報表、用戶標(biāo)簽、自助取數(shù)等多個內(nèi)部業(yè)務(wù)以及對外商戶數(shù)據(jù)服務(wù)場景。

僅以對賬單查詢場景為例，在半年對賬單場景下數(shù)據(jù)查詢時效從 8 分鐘降低到 3 秒，提速超 100 倍，在全年對賬單查詢中耗時也縮短至 2 分鐘內(nèi)，多數(shù)典型查詢場景性能提升了 10- 15 倍，整體查詢分析效率得到極大幅度提升。此外，數(shù)據(jù)導(dǎo)入性能平均提升了 2- 5 倍，數(shù)據(jù)處理加工速度效率提升了 3- 12 倍，數(shù)據(jù)應(yīng)用的時效性得到大幅增強。

通過更高效、更實時、更靈活的數(shù)據(jù)分析支持，銀聯(lián)商務(wù)能夠更好地理解市場、把握機會、優(yōu)化運營，從而實現(xiàn)業(yè)務(wù)的持續(xù)增長和創(chuàng)新發(fā)展。未來，銀聯(lián)商務(wù)還將繼續(xù)深入使用 Apache Doris ，并在以下三個方面進行探索和實踐：文章來源地址http://www.zghlxwxcb.cn/news/detail-782927.html

• 統(tǒng)一查詢引擎：將 Doris 作為聯(lián)邦查詢的統(tǒng)一入口，通過 Multi-Catalog 接入底層各數(shù)據(jù)源。同時將 Doris 完全作為對外數(shù)據(jù)服務(wù)的統(tǒng)一出口，實現(xiàn)數(shù)據(jù)查詢服務(wù)的統(tǒng)一路由，為用戶提供更便捷、更高效的數(shù)據(jù)查詢服務(wù)。
• 存算分離架構(gòu)：進一步探索存算分離架構(gòu)、實現(xiàn)資源的彈性擴縮容，并將離線數(shù)倉任務(wù)全部遷移到 Doris 中，實現(xiàn)實時化改造以及計算負載的進一步隔離。
• 自動化運維：對接公司內(nèi)部的業(yè)務(wù)流程，實現(xiàn)相關(guān)工作的自動化運維處理，并完成業(yè)務(wù)問題的快速排查；基于 Doris 實現(xiàn)更靈活的數(shù)據(jù)血緣分析，幫助銀聯(lián)商務(wù)更好地理解數(shù)據(jù)之間的關(guān)系和影響，為業(yè)務(wù)決策提供更準(zhǔn)確的數(shù)據(jù)管理支持。

到了這里，關(guān)于查詢速度提升15倍！銀聯(lián)商務(wù)基于 Apache Doris 的數(shù)據(jù)平臺升級實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！