一、數據需求的產生

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

二、OLAP選型困擾

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

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

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

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

第一個階段主要是基于離線數據的抽取階段，因為從業務演進的角度來看， OLTP 系統的出現導致了端到端數據無法實現關聯查詢。因此，我們需要工具來打通數據源和數據源之間的聯系。在第一個階段，我們選擇了Kettle，利用其ETL能力和豐富的技術組件構建報表系統。Kettle在第一階段勝任了我們基礎的報表取數工作。但是，在基于Kettle做ETL的階段，我們仍然面臨著無法實時關聯查詢，數據源和數據源之間查詢時延高等問題。

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

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

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

三、Apache Doris實踐

引入Doris之后，我們主要在兩個方面進行了實踐和探索，即并發查詢的加速和數據架構的建設。

1、并發查詢加速

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

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

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

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

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

2、數倉基座建設

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

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

3、業務場景落地

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

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

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

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

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

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

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

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

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

運維成本是我們引入Doris最核心的收益點之一。由于我們是專注于業務研發的部門，相比于數據研發和運維人員，我們的實力稍顯薄弱。因此，在選型階段，我們花費了相當的精力考慮整體生產運維的問題。選擇使用Doris也是希望借助其靈活的架構使運維更加簡便。在生產環境中，我們基本上不需要對Doris進行獨立的運維配合，因為它自身就具備保活機制和自運維的能力。

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

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

四、后期規劃

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

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

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

五、問答環節

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

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

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

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

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

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

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

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