一、數(shù)據(jù)需求的產(chǎn)生

騰梭科技的產(chǎn)品發(fā)展歷程經(jīng)歷了多個(gè)階段。最初，我們專注于與互聯(lián)網(wǎng)金融科技公司合作，提供網(wǎng)貸助貸核心對(duì)接等服務(wù)。隨后，我們通過與其他友商聯(lián)合打造業(yè)務(wù)獲得了突破。在此基礎(chǔ)上，我們開始將重心轉(zhuǎn)向行業(yè)內(nèi)的聯(lián)合業(yè)務(wù)開展，并逐步實(shí)現(xiàn)了對(duì)全量客戶群體的挖掘和線上營銷。同時(shí)，我們也探索了純線上獲客新零售業(yè)務(wù)模式。這些演進(jìn)不僅涵蓋了業(yè)務(wù)架構(gòu)和業(yè)務(wù)模式的調(diào)整，也促使了技術(shù)架構(gòu)的演化。我們從單一的交易中心向多業(yè)務(wù)場景分布式應(yīng)用發(fā)展，在后階段業(yè)務(wù)系統(tǒng)全面的進(jìn)行了微服務(wù)技術(shù)改造，以滿足新零售金融場景的需求。

二、OLAP選型困擾

在演進(jìn)過程中，我們產(chǎn)生了許多OLTP系統(tǒng)，包括MySQL、Oracle以及PG等等。然而，在數(shù)據(jù)規(guī)模不斷擴(kuò)大的情況下，OLTP系統(tǒng)之間出現(xiàn)了數(shù)據(jù)孤島和數(shù)據(jù)割裂現(xiàn)象，無法進(jìn)行端到端的數(shù)據(jù)關(guān)聯(lián)和打通。因此，引入AP系統(tǒng)或工具已成為研發(fā)必然選擇。但我們也面臨著選型上的困境。

OLAP的發(fā)展歷史已經(jīng)相當(dāng)悠久。技術(shù)棧中，我們使用廣義的OLAP技術(shù)，如ElasticSearch和Redis等工具進(jìn)行快速查詢。雖然這些工具在OLAP中屬于其中一種，但在數(shù)據(jù)規(guī)模擴(kuò)大的后續(xù)使用中，它們不能很好的勝任我們的需求。因此，我們進(jìn)行了OLAP引擎的選型調(diào)研。

在調(diào)研過程中，我們發(fā)現(xiàn)小團(tuán)隊(duì)會(huì)面臨兩種主要困境。對(duì)于大型企業(yè)來說，并不關(guān)心這些問題，因?yàn)榭傮w投入產(chǎn)出要求雖高，但他們可能有更高的預(yù)算，并擁有更完善的技術(shù)與生態(tài)系統(tǒng)。然而，對(duì)于小型技術(shù)公司來說，這兩個(gè)方面成為了我們的門檻——我們需要選擇能夠相對(duì)可控地支持后續(xù)業(yè)務(wù)發(fā)展的數(shù)據(jù)規(guī)模和靈活性高、成本相對(duì)低的工具或系統(tǒng)。我們需要避免陷入技術(shù)沼澤中，同時(shí)將技術(shù)門檻降至最低，避免深陷于Hadoop或SQL on hadoop技術(shù)生態(tài)中，從而讓我們的業(yè)務(wù)研發(fā)順暢而高效地進(jìn)行。

我們的業(yè)務(wù)演進(jìn)大概分成了三個(gè)階段。

第一個(gè)階段主要是基于離線數(shù)據(jù)的抽取階段，因?yàn)閺臉I(yè)務(wù)演進(jìn)的角度來看， OLTP 系統(tǒng)的出現(xiàn)導(dǎo)致了端到端數(shù)據(jù)無法實(shí)現(xiàn)關(guān)聯(lián)查詢。因此，我們需要工具來打通數(shù)據(jù)源和數(shù)據(jù)源之間的聯(lián)系。在第一個(gè)階段，我們選擇了Kettle，利用其ETL能力和豐富的技術(shù)組件構(gòu)建報(bào)表系統(tǒng)。Kettle在第一階段勝任了我們基礎(chǔ)的報(bào)表取數(shù)工作。但是，在基于Kettle做ETL的階段，我們?nèi)匀幻媾R著無法實(shí)時(shí)關(guān)聯(lián)查詢，數(shù)據(jù)源和數(shù)據(jù)源之間查詢時(shí)延高等問題。

第二個(gè)階段，我們進(jìn)行了對(duì)工具Trino的調(diào)研，想利用其在異構(gòu)數(shù)據(jù)源和聯(lián)合查詢方面的優(yōu)勢，建立起信貸和風(fēng)控等相關(guān)領(lǐng)域內(nèi)多數(shù)據(jù)源間的數(shù)據(jù)連通。但是這個(gè)過程中仍存在一些技術(shù)痛點(diǎn)。因?yàn)門rino是基于大內(nèi)存的SQL引擎，存儲(chǔ)引擎并不是它的強(qiáng)項(xiàng)。我們還需要比較高的點(diǎn)查響應(yīng)能力，但是Trino在處理小表和點(diǎn)查的場景上，有時(shí)會(huì)存在一些開銷，需要結(jié)合外部數(shù)據(jù)源進(jìn)行優(yōu)化，才能滿足響應(yīng)要求。雖然之前我們已經(jīng)解決了聯(lián)合查詢的問題，但是在數(shù)據(jù)規(guī)模擴(kuò)張和實(shí)施場景演進(jìn)的過程中，還需要進(jìn)一步的優(yōu)化。

在第三個(gè)階段，我們探索、實(shí)踐并應(yīng)用了Doris。引入Doris進(jìn)入我們OLAP系統(tǒng)的契機(jī)來自于我們在ToB項(xiàng)目中的需求。通過調(diào)研和使用Doris，我們發(fā)現(xiàn)它的整體性能以及數(shù)據(jù)規(guī)模擴(kuò)張后的表現(xiàn)，在絕大多數(shù)情況下，都能滿足我們的客戶體量和數(shù)據(jù)規(guī)模要求。Doris解決了前兩個(gè)階段遇到的共同問題，能夠打通數(shù)據(jù)源之間的關(guān)聯(lián)查詢，也能夠加速數(shù)據(jù)查詢速度。此外，Doris支持ISO標(biāo)準(zhǔn)SQL，與我們之前使用的MySQL OLTP系統(tǒng)無縫切換。同時(shí)，我們所使用的Doris是存算一體的，適用于我們后續(xù)的分庫分表和定時(shí)冷數(shù)據(jù)歸檔業(yè)務(wù)場景。

在第三個(gè)階段，我們引入了Doris。這主要是因?yàn)榍皟蓚€(gè)階段存在未解決的業(yè)務(wù)難題，我們決定借助Doris解決這些問題。

三、Apache Doris實(shí)踐

引入Doris之后，我們主要在兩個(gè)方面進(jìn)行了實(shí)踐和探索，即并發(fā)查詢的加速和數(shù)據(jù)架構(gòu)的建設(shè)。

1、并發(fā)查詢加速

因?yàn)樵谖覀冃窃屏闶鄣男刨J業(yè)務(wù)場景中，除了信貸以外，還有實(shí)時(shí)風(fēng)控業(yè)務(wù)，需要應(yīng)對(duì)低并發(fā)、高吞吐或高并發(fā)、高QPS的使用場景。我們的第一個(gè)實(shí)踐方向是查詢加速。

在進(jìn)行查詢加速時(shí)，我們遇到的第一個(gè)問題是模型選擇。我們選擇了Unique和明細(xì)模型，沒有使用聚合模型，因?yàn)槭羌兘鹑诮灰紫到y(tǒng)，大部分場景都聚焦于交易事件、日志或明細(xì)日志場景，還沒有使用聚合模型。后期可能會(huì)在偏實(shí)時(shí)場景中使用此模型，包括通過物化視圖進(jìn)行實(shí)時(shí)報(bào)表制作。

在查詢加速階段，我們遇到了很多問題，包括Doris基礎(chǔ)模型的選擇及其分區(qū)和存儲(chǔ)分層的精細(xì)設(shè)計(jì)，這些問題耽誤了我們很多時(shí)間。但在與社區(qū)的溝通中，我們更好地了解了Doris在邏輯分區(qū)和物理分桶上的設(shè)計(jì)，優(yōu)化了key值、列和分桶key的設(shè)計(jì)，讓我們在點(diǎn)查或并發(fā)查詢場景下更好地使用Colocation Join方式，避免出現(xiàn)在較大表上進(jìn)行跨節(jié)點(diǎn)Shuffle join的場景，提高了點(diǎn)查和高吞吐場景下并發(fā)查詢的效率。

舉兩個(gè)查詢加速方面的例子。第一個(gè)是在金融行業(yè)的日常業(yè)務(wù)中，我們會(huì)遇到眾多的報(bào)表和數(shù)據(jù)供應(yīng)場景。這些場景通常是低并發(fā)的，但需要高吞吐率。以往，我們采用了預(yù)聚合或MySQL分庫的方式，但是這會(huì)帶來很大的IO和CPU消耗，甚至?xí)?dǎo)致MySQL從庫崩潰?，F(xiàn)在，我們依靠Doris的多表聚合和高吞吐能力，成功解決了數(shù)據(jù)供應(yīng)和離線T+1報(bào)表供應(yīng)的痛點(diǎn)。此外，我們的后臺(tái)管理系統(tǒng)也得到了改善，比如我們可以利用Doris提供的索引機(jī)制，進(jìn)行多維度查詢，以及使用高基數(shù)索引布隆過濾器機(jī)制來提高客戶體驗(yàn)。

風(fēng)控系統(tǒng)存在特征指標(biāo)計(jì)算、特征模型以及逾期風(fēng)險(xiǎn)預(yù)測模型等場景，如B卡（逾期風(fēng)險(xiǎn)預(yù)測模型）貸中行為分析的場景，這些場景需要支持高QPS的點(diǎn)查。因此，我們利用Doris的key列設(shè)計(jì)和前綴索引機(jī)制來解決這些問題，基本上在key列設(shè)計(jì)合理的情況下，點(diǎn)查場景都能夠達(dá)到毫秒級(jí)的響應(yīng)。

2、數(shù)倉基座建設(shè)

第二個(gè)場景是在數(shù)據(jù)底座之上的探索。數(shù)據(jù)基礎(chǔ)源自于我們的業(yè)務(wù)需求。我們有一些針對(duì)企業(yè)的項(xiàng)目，需要建立數(shù)據(jù)倉庫，因?yàn)檫@些項(xiàng)目可能需要許多離線數(shù)據(jù)報(bào)表。所以我們建立了基于Doris的存儲(chǔ)與分析的數(shù)倉底座。主要采用Dolphin Scheduler離線調(diào)度工具，DataX數(shù)據(jù)采集，或者基于JDBC catalog從源業(yè)務(wù)端或異構(gòu)的數(shù)據(jù)源中做離線數(shù)據(jù)提取，亦或者采用 flink cdc做實(shí)時(shí)的binlog數(shù)據(jù)采集，并將其存入Doris數(shù)據(jù)存儲(chǔ)。進(jìn)行分析與建模后我們提供數(shù)據(jù)網(wǎng)關(guān)或報(bào)表系統(tǒng)等服務(wù)給業(yè)務(wù)人員，財(cái)務(wù)人員或?qū)崟r(shí)交易大屏，Boss系統(tǒng)等數(shù)據(jù)應(yīng)用，使得他們能夠使用包括數(shù)據(jù)分析人員在內(nèi)的Ad-hoc能力，實(shí)時(shí)分析風(fēng)險(xiǎn)數(shù)據(jù)。在監(jiān)控方面，我們使用一套Grafana、Prometheus和Loki監(jiān)控集群狀態(tài)，監(jiān)控Doris內(nèi)存和CPU使用率，包括在實(shí)時(shí)或離線ETL執(zhí)行時(shí)的compaction的穩(wěn)定性及查詢耗時(shí)等。

這是我們的業(yè)務(wù)模型。我們通過增量或全量方式獲取業(yè)務(wù)數(shù)據(jù)，包括日志數(shù)據(jù)，然后將其實(shí)時(shí)或準(zhǔn)實(shí)時(shí)地導(dǎo)入到我們構(gòu)建的數(shù)據(jù)集市中。這個(gè)數(shù)據(jù)集市仍然遵循數(shù)倉的分層模型，類似于離線數(shù)倉的模型。導(dǎo)入后，我們將使用調(diào)度工具將其調(diào)度到T+1時(shí)間，然后將數(shù)據(jù)匯總到DW層，最終將其應(yīng)用于我們的應(yīng)用端。

3、業(yè)務(wù)場景落地

接下來演示一下我們在整體業(yè)務(wù)場景和落地方案中的幾個(gè)小案例。第一個(gè)案例是風(fēng)控大數(shù)據(jù)報(bào)表平臺(tái)，正如之前所述，我們引入Doris來支持這個(gè)項(xiàng)目。我們的客戶是一家銀行，有較高的報(bào)表需求，包括風(fēng)控和信貸兩方面，共計(jì)近百張報(bào)表。通過前幾個(gè)階段的探索和技術(shù)手段，我們難以滿足合作伙伴在業(yè)務(wù)規(guī)模和業(yè)務(wù)場景上的需求，因此我們進(jìn)行了Doris方案的調(diào)研，并成功運(yùn)用于風(fēng)控大數(shù)據(jù)報(bào)表平臺(tái)技術(shù)方案中。

我們基于海豚調(diào)度，做數(shù)據(jù)源的抽取，然后在中間構(gòu)建工作流，完成ODS、 DW，以及ODS數(shù)據(jù)的 detail 加工，整體數(shù)據(jù)規(guī)模大概為 20T 左右，在這樣的規(guī)模下整體任務(wù)編排和調(diào)度的性能，可以保持在5小時(shí)之內(nèi)。

當(dāng)前生產(chǎn)環(huán)境采用Doris1.2.4 的版本，在升級(jí)之前用的是 20 年Doris0.14的版本。升級(jí)后整體性能得到了提升，在沒有做SQL優(yōu)化的情況下，能夠達(dá)到4倍的性能提升。編排調(diào)度從之前的 4 小時(shí)縮減到了現(xiàn)在的1小時(shí)。

我們采用了兩種方式來進(jìn)行數(shù)據(jù)的ETL。第一種是基于接入腳本進(jìn)行T+1的數(shù)據(jù)ETL。另一種方式是基于Doris的JDBC Catalog進(jìn)行準(zhǔn)實(shí)時(shí)數(shù)據(jù)抽取。由于我們的業(yè)務(wù)合作伙伴對(duì)數(shù)據(jù)實(shí)時(shí)性要求比較高，例如交易報(bào)表和風(fēng)控審核等，需要分鐘級(jí)或?qū)崟r(shí)效果。我們通過海豚調(diào)度做分鐘級(jí)的調(diào)度，并結(jié)合Doris的JDBC Catalog進(jìn)行抽取。我們的現(xiàn)有技術(shù)解決方案大多數(shù)報(bào)表都是T+1模式的工作流調(diào)度進(jìn)行抽取。對(duì)于實(shí)時(shí)性要求比較高的場景，例如大屏或儀表盤的數(shù)據(jù)診斷，我們會(huì)使用分鐘級(jí)的調(diào)度抽取。我們正在探索使用Flink CDC的方式進(jìn)行更準(zhǔn)確、更實(shí)時(shí)的場景，例如風(fēng)控監(jiān)控預(yù)警等。目前我們正在調(diào)研基于Streampark的Flink任務(wù)開發(fā)和管理，同時(shí)結(jié)合Doris的Flink CDC進(jìn)行實(shí)時(shí)ETL，尚未投入到生產(chǎn)環(huán)境中。

接下來的這個(gè)案例是我們考慮日志存儲(chǔ)分析時(shí)進(jìn)行的研究。我們發(fā)現(xiàn)在業(yè)務(wù)開發(fā)和業(yè)務(wù)運(yùn)營的過程中，有許多日志場景需要處理，包括生產(chǎn)異常日志和 API 訪問日志等。因此，我們針對(duì) Doris 1.2.4 版本進(jìn)行了研究，以探索它在統(tǒng)一日志存儲(chǔ)和分析方面的能力。雖然該版本沒有使用倒排索引，但總體來看，性能基本上能夠滿足大部分客戶在相應(yīng)數(shù)據(jù)規(guī)模下的需求。

然后我們自主開發(fā)了用于實(shí)時(shí)數(shù)據(jù)采集的Flume的Java的sink的代理應(yīng)用服務(wù)，并配合Doris Streamload方式，實(shí)現(xiàn)了將批量數(shù)據(jù)實(shí)時(shí)注入到Doris系統(tǒng)中。我們基于數(shù)據(jù)做了日志場景監(jiān)控，通過分析API訪問模式，我們發(fā)現(xiàn)了大量的HTTP訪問場景。在業(yè)務(wù)端，我們實(shí)現(xiàn)了相對(duì)實(shí)時(shí)的監(jiān)控預(yù)警。最后，與前文所述的日志分析場景相似，我們的客戶在進(jìn)行營收信貸業(yè)務(wù)（包括廣告投放和自主獲客）時(shí)需要用戶行為數(shù)據(jù)。因此，我們研究了使用 JSONB 存儲(chǔ)方式來收集小程序或廣告投放的用戶訪問日志，并利用JSONB的存儲(chǔ)和分析能力，分析用戶行為以解鎖用戶意向。

在生產(chǎn)實(shí)踐中，我們發(fā)現(xiàn)在使用 JSONB 存儲(chǔ)格式的情況下，數(shù)據(jù)體積至少降低了70%。而之前我們在存儲(chǔ)和壓縮時(shí)使用ElasticSearch或Redis進(jìn)行查詢加速?？蛻舻姆答佉沧C明了效率的提升，獲得了高度評(píng)價(jià)。

接下來分享一下星云在在線分析處理（OLAP）的發(fā)展過程中，包括在引用Doris之后，整個(gè)架構(gòu)的收益。

首先，涉及到的用戶群體，除了開發(fā)人員之外，還有業(yè)務(wù)人員。他們能夠自主地獲取和導(dǎo)出數(shù)據(jù)，系統(tǒng)可以滿足多個(gè)維度下分鐘或秒級(jí)別的數(shù)據(jù)查詢需求。

運(yùn)維成本是我們引入Doris最核心的收益點(diǎn)之一。由于我們是專注于業(yè)務(wù)研發(fā)的部門，相比于數(shù)據(jù)研發(fā)和運(yùn)維人員，我們的實(shí)力稍顯薄弱。因此，在選型階段，我們花費(fèi)了相當(dāng)?shù)木紤]整體生產(chǎn)運(yùn)維的問題。選擇使用Doris也是希望借助其靈活的架構(gòu)使運(yùn)維更加簡便。在生產(chǎn)環(huán)境中，我們基本上不需要對(duì)Doris進(jìn)行獨(dú)立的運(yùn)維配合，因?yàn)樗陨砭途邆浔；顧C(jī)制和自運(yùn)維的能力。

另外，在查詢延遲方面取得了不少進(jìn)展。從業(yè)務(wù)角度來看，包括風(fēng)險(xiǎn)控制和信貸審查，以及偏離線計(jì)算的場景。根據(jù)以往的收益，在像MySQL這樣的情況下，引入Trino僅需幾分鐘，甚至十分鐘內(nèi)的查詢響應(yīng)時(shí)間就能顯著提高。在大表的關(guān)聯(lián)查詢中，基本上可以實(shí)現(xiàn)分鐘或秒級(jí)的響應(yīng)速度。在點(diǎn)查產(chǎn)品中，甚至可以達(dá)到毫秒級(jí)的響應(yīng)速度。

關(guān)于資源的節(jié)省，直接的效益主要體現(xiàn)在存儲(chǔ)層面有了大幅度的提升。對(duì)于用戶而言，他們的磁盤空間釋放與需求得到了更加緊湊的管理。

四、后期規(guī)劃

最后，介紹一下我們基于Doris在業(yè)務(wù)層面上的規(guī)劃，我們可能還會(huì)偏向于解決業(yè)務(wù)痛點(diǎn)的規(guī)劃。首先，我們會(huì)開發(fā)智能數(shù)據(jù)網(wǎng)關(guān)，該網(wǎng)關(guān)主要面向外部數(shù)據(jù)源的對(duì)接，對(duì)接之后會(huì)將數(shù)據(jù)寫入到OLTP系統(tǒng)中，包括MySQL或者業(yè)務(wù)關(guān)鍵庫，我們也可能會(huì)在之后的應(yīng)用中使用甚至將其放入Redis中。

首先，我們需要做一個(gè)數(shù)據(jù)網(wǎng)關(guān)，主要是為了收斂多種異構(gòu)數(shù)據(jù)源的場景，希望能使它更加靈活。在開始設(shè)計(jì)數(shù)據(jù)網(wǎng)關(guān)路由時(shí)，我們考慮是否可以從統(tǒng)一的數(shù)據(jù)存儲(chǔ)位置中采集數(shù)據(jù)。我們可以基于Doris采集數(shù)據(jù)，當(dāng)Doris的數(shù)據(jù)無法滿足需求，或者Doris集群出現(xiàn)問題導(dǎo)致延遲較高時(shí)，我們再下發(fā)到下一級(jí)，以兜底查詢。這是我們后續(xù)規(guī)劃的使用場景。

第二個(gè)問題是做數(shù)據(jù)統(tǒng)一歸檔。我們的歷史數(shù)據(jù)很多，因此需要對(duì)歷史數(shù)據(jù)進(jìn)行定期歸檔。但是目前的痛點(diǎn)是，如果沒有使用OLAP引擎，或者沒有Hadoop這樣的生態(tài)系統(tǒng)，我們將其遷移到MySQL時(shí)，對(duì)歷史數(shù)據(jù)的分析會(huì)變得非常復(fù)雜。如果我們將其歸檔到Lioak中，則整體存儲(chǔ)占用的資源會(huì)相對(duì)更高。我們計(jì)劃使用Doris來處理統(tǒng)一存儲(chǔ)和歸檔數(shù)據(jù)的應(yīng)用和場景。

五、問答環(huán)節(jié)

Q:第一個(gè)問題是在日志查詢的案例里面日志查詢是模糊查詢嗎？性能怎么樣？有沒有和 ClickHouse 做過對(duì)比？

A: 是的，我們所引用的版本是 Doris1.2.4，它不像最新的版本2.0一樣支持日志檢索和倒排索引場。我們?nèi)匀皇褂玫氖荄oris1.2的穩(wěn)定版本，在后來的Doris2.0中提供了倒排索引，包括日志場景，可以更高效地分析日志場景。我們使用了它的模糊匹配，雖然沒有經(jīng)過優(yōu)化，但依然能夠取得很好的效果。我們采用暴力的更新方法，在單個(gè)分區(qū)的情況下，基本上可以實(shí)現(xiàn)毫秒級(jí)的響應(yīng)。在跨越多個(gè)分區(qū)的情況下，也能在秒級(jí)或者分鐘級(jí)別滿足我們在日志分析場景中的需求。

因?yàn)槲覀冎暗娜罩痉治龇桨甘腔贓LK（Elasticsearch, Logstash, Kibana），而ClickHouse并不在我們的技術(shù)棧中使用。雖然你剛才提到了與ClickHouse的比較，但我們并沒有實(shí)際經(jīng)驗(yàn)。不過相對(duì)于ELK，我們之前的方案已經(jīng)帶來了很大的收益。

Q: 第二個(gè)問題是關(guān)于風(fēng)險(xiǎn)控制大數(shù)據(jù)報(bào)表案例的。業(yè)務(wù)方問到這個(gè)大屏幕每隔多長時(shí)間會(huì)刷新一次，以及如何保證數(shù)據(jù)鏈路的及時(shí)性。

A：實(shí)時(shí)性要求有兩個(gè)不同的場景，一是交易大屏，一是風(fēng)控。針對(duì)拒絕原因或通過率等指標(biāo)，兩者的實(shí)時(shí)性要求不同。對(duì)于交易大屏場景，最好能在分鐘級(jí)內(nèi)刷新一次，間隔為10秒、5秒或10秒。而對(duì)于風(fēng)控場景，則要求分鐘級(jí)的實(shí)時(shí)效果。因此，在技術(shù)選擇和實(shí)現(xiàn)上，我們有所區(qū)別。對(duì)于風(fēng)控的場景，我們采用海豚調(diào)度的準(zhǔn)實(shí)時(shí)數(shù)據(jù)采集，并配置分鐘級(jí)的調(diào)度任務(wù)，將業(yè)務(wù)庫中的數(shù)據(jù)抽取到Doris中。通過基于Doris的查詢性能，我們可以輕松抗衡大屏的刷新。

Q：第三個(gè)問題涉及高可用性，例如在運(yùn)維方面的存儲(chǔ)是否采用了RAID技術(shù)，以及壞盤的應(yīng)對(duì)處理方式。

A：關(guān)于運(yùn)維，我們的高可用主要基于Doris內(nèi)部的高可用機(jī)制，我們只實(shí)現(xiàn)了應(yīng)用層面的?；顧C(jī)制。在大內(nèi)存和高吞吐量下，可能會(huì)崩潰B1進(jìn)程，但我們的保活機(jī)制可以在秒級(jí)內(nèi)重啟進(jìn)程，確保服務(wù)正常。

在存儲(chǔ)方面，我們會(huì)定期備份源數(shù)據(jù)，而對(duì)于B1節(jié)點(diǎn)的數(shù)據(jù)存儲(chǔ)，因?yàn)槲覀兪褂萌北荆ù蟾?0個(gè)節(jié)點(diǎn)，包括3個(gè)FB節(jié)點(diǎn)和7個(gè)BE節(jié)點(diǎn)），所以計(jì)劃依賴Doris自身的副本和副本修復(fù)機(jī)制。因此，在運(yùn)維方面，我們只進(jìn)行了源數(shù)據(jù)的定期對(duì)等備份。