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

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

二、OLAP選型困擾

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

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

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

我們的業(yè)務演進大概分成了三個階段。

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

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

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

在第三個階段，我們引入了Doris。這主要是因為前兩個階段存在未解決的業(yè)務難題，我們決定借助Doris解決這些問題。

三、Apache Doris實踐

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

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

因為在我們星云零售的信貸業(yè)務場景中，除了信貸以外，還有實時風控業(yè)務，需要應對低并發(fā)、高吞吐或高并發(fā)、高QPS的使用場景。我們的第一個實踐方向是查詢加速。

在進行查詢加速時，我們遇到的第一個問題是模型選擇。我們選擇了Unique和明細模型，沒有使用聚合模型，因為是純金融交易系統(tǒng)，大部分場景都聚焦于交易事件、日志或明細日志場景，還沒有使用聚合模型。后期可能會在偏實時場景中使用此模型，包括通過物化視圖進行實時報表制作。

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

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

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

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

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

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

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

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

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

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

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

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

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

在生產(chǎn)實踐中，我們發(fā)現(xiàn)在使用 JSONB 存儲格式的情況下，數(shù)據(jù)體積至少降低了70%。而之前我們在存儲和壓縮時使用ElasticSearch或Redis進行查詢加速。客戶的反饋也證明了效率的提升，獲得了高度評價。

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

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

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

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

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

四、后期規(guī)劃

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

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

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

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

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

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

因為我們之前的日志分析方案是基于ELK（Elasticsearch, Logstash, Kibana），而ClickHouse并不在我們的技術(shù)棧中使用。雖然你剛才提到了與ClickHouse的比較，但我們并沒有實際經(jīng)驗。不過相對于ELK，我們之前的方案已經(jīng)帶來了很大的收益。

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

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

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

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

在存儲方面，我們會定期備份源數(shù)據(jù)，而對于B1節(jié)點的數(shù)據(jù)存儲，因為我們使用三副本（大概10個節(jié)點，包括3個FB節(jié)點和7個BE節(jié)點），所以計劃依賴Doris自身的副本和副本修復機制。因此，在運維方面，我們只進行了源數(shù)據(jù)的定期對等備份。