導(dǎo)讀：約苗平臺(tái)是國(guó)內(nèi)目前最大的成人預(yù)防接種管理服務(wù)平臺(tái)。近年來(lái)，隨著各功能的不斷完善，用戶數(shù)量不斷增多，越來(lái)越多注冊(cè)數(shù)據(jù)、疫苗類別點(diǎn)擊數(shù)據(jù)、頁(yè)面瀏覽時(shí)長(zhǎng)等數(shù)據(jù)被生成和積累，如何有效利用這些數(shù)據(jù)進(jìn)行處理分析，對(duì)于約苗提高工作效率、優(yōu)化運(yùn)營(yíng)決策有著不容小覷的作用?；诖思s苗平臺(tái)歷經(jīng)三代架構(gòu)演進(jìn)，最終通過(guò) Apache Doris 重構(gòu)了數(shù)據(jù)平臺(tái)架構(gòu)，統(tǒng)一了數(shù)據(jù)源出口，實(shí)現(xiàn)了近 300 倍的查詢提速，目前已在消息系統(tǒng)、運(yùn)營(yíng)平臺(tái)、數(shù)據(jù)平臺(tái)、日志系統(tǒng)中得到廣泛的應(yīng)用，接入近百億的數(shù)據(jù)量，并且在持續(xù)增加中。

四川馬太科技有限公司是一家扎根于疾病防控領(lǐng)域，具有專業(yè)的研發(fā)與運(yùn)營(yíng)團(tuán)隊(duì)的互聯(lián)網(wǎng)公司，長(zhǎng)期致力于改善和提升中國(guó)公眾疾病防控水平，助力“健康中國(guó)2030”。旗下?lián)碛袊?guó)內(nèi)用戶量最大的成人疾病預(yù)防信息與服務(wù)平臺(tái)“約苗”（以下簡(jiǎn)稱“約苗平臺(tái)”）。“約苗平臺(tái)”運(yùn)用互聯(lián)網(wǎng)＋模式傳播健康科普知識(shí)，為疾病防控提供先進(jìn)的服務(wù)和管理工具。圍繞公共衛(wèi)生服務(wù)機(jī)構(gòu)的疾病預(yù)防業(yè)務(wù)，開展政策、疾病教育及預(yù)約服務(wù)。發(fā)展至今已是國(guó)內(nèi)最大的成人預(yù)防接種管理服務(wù)平臺(tái)，作為連接公共衛(wèi)生服務(wù)機(jī)構(gòu)與公眾的橋梁，現(xiàn)已連接近 5000 家公共衛(wèi)生服務(wù)機(jī)構(gòu)和 4000 余萬(wàn)用戶，累計(jì)提供 2000 余萬(wàn)次疫苗預(yù)約服務(wù)，并產(chǎn)生科普內(nèi)容閱讀數(shù) 3.3 億次。

業(yè)務(wù)背景

隨著約苗平臺(tái)各功能的不斷完善，用戶數(shù)量不斷增多，越來(lái)越多注冊(cè)、疫苗類別點(diǎn)擊、頁(yè)面瀏覽時(shí)長(zhǎng)等數(shù)據(jù)被生成和積累，如何有效利用這些數(shù)據(jù)進(jìn)行處理分析，對(duì)于提高工作效率、優(yōu)化運(yùn)營(yíng)決策、增加下單率有著不容小覷的作用，因此我們決定搭建約苗數(shù)據(jù)架構(gòu)，通過(guò)數(shù)據(jù)分析處理結(jié)果賦能業(yè)務(wù)發(fā)展，從而提高企業(yè)競(jìng)爭(zhēng)力。

基于此，我們踏上了數(shù)據(jù)架構(gòu)搭建及優(yōu)化之路，為滿足不同場(chǎng)景下的數(shù)據(jù)處理和分析需求，相關(guān)場(chǎng)景對(duì)數(shù)據(jù)架構(gòu)提出了以下幾點(diǎn)要求：

• 用戶行為分析 ： 通過(guò)用戶瀏覽內(nèi)容或頁(yè)面的時(shí)長(zhǎng)進(jìn)行用戶分層、掌握用戶行為喜好，通過(guò)對(duì)新用戶的增量和用戶活躍度進(jìn)行統(tǒng)計(jì)，以便工作人員調(diào)整運(yùn)營(yíng)策略，提高用戶留存率和活躍度。在該場(chǎng)景下，要求所有查詢需要在 5s 內(nèi)返回結(jié)果。

• 平臺(tái)通知: 約苗平臺(tái)消息推送服務(wù)包含 App 推送、內(nèi)置通知、短信、信公眾號(hào)推送，在該場(chǎng)景下，期望可達(dá)到毫秒級(jí)查詢響應(yīng)，解決 C 端通知查詢延遲的問(wèn)題。

• 市場(chǎng)報(bào)表統(tǒng)計(jì): 市場(chǎng)部每天需對(duì)相關(guān)業(yè)務(wù)進(jìn)行報(bào)表統(tǒng)計(jì)，但由于數(shù)據(jù)量巨大，通常會(huì)出現(xiàn)查詢速度較慢的問(wèn)題，這將嚴(yán)重影響產(chǎn)出計(jì)算，期望可以實(shí)現(xiàn)秒級(jí)查詢響應(yīng)。

為了滿足要求，約苗的數(shù)據(jù)架構(gòu)已經(jīng)經(jīng)歷了三代演進(jìn)。第一代架構(gòu)基于 Elasticsearch，第二代架構(gòu)引入了 ClickHouse，目前正在使用的是基于 Apache Doris 的第三代架構(gòu)。本文將詳細(xì)介紹這三代架構(gòu)的演進(jìn)歷程和搭建經(jīng)驗(yàn)。

基于 Elasticsearch 的第一代架構(gòu)

第一代數(shù)據(jù)架構(gòu)是基于 Elasticsearch 來(lái)構(gòu)建的，主要用于處理來(lái)自業(yè)務(wù)各系統(tǒng)和日志系統(tǒng)的數(shù)據(jù)。其中，業(yè)務(wù)數(shù)據(jù)首先存儲(chǔ)在 MySQL 中，然后使用 Flink CDC 對(duì) MySQL Binlog 監(jiān)聽，將數(shù)據(jù)同步到 Elasticsearch 中。當(dāng)展示層發(fā)起聚合請(qǐng)求時(shí)，Elasticsearch 中的數(shù)據(jù)進(jìn)入聚合層對(duì)應(yīng)的服務(wù)中實(shí)時(shí)計(jì)算，最終將結(jié)果輸出到展示端。

架構(gòu)搭建完后我們立即投入生產(chǎn)來(lái)驗(yàn)證效果，但在使用中我們發(fā)現(xiàn) Elasticsearch 在高并發(fā)讀取和寫入的過(guò)程中延遲非常高，而為改善該問(wèn)題，我們又增設(shè)了多套集群配置，但仍然于事無(wú)補(bǔ)。除此之外，Elasticsearch 得數(shù)據(jù)查詢性能也會(huì)隨著數(shù)據(jù)增長(zhǎng)而下降。在這個(gè)情況下，如果想要提高 Elasticsearch 響應(yīng)速度，還需進(jìn)一步增加集群配置，以提高 Elasticsearch 集群負(fù)載能力，成本投入非常大。

引入 ClickHouse 的第二代架構(gòu)

基于上述問(wèn)題，我們對(duì)架構(gòu)進(jìn)行了升級(jí)。為避免架構(gòu)演進(jìn)對(duì)代碼帶來(lái)過(guò)大沖擊，我們保留了第一代架構(gòu)中基本的數(shù)據(jù)同步邏輯，在其基礎(chǔ)上增加了 Apisix、Kafka、ClickHouse 同步流程，在此基礎(chǔ)上對(duì) Flink 同步流程進(jìn)行了優(yōu)化。為了降低 Elasticsearch 的壓力，我們將日志數(shù)據(jù)、行為數(shù)據(jù)和文件系統(tǒng)數(shù)據(jù)進(jìn)行了整體的遷移都 ClickHouse 。在 ClickHouse 同步流程中，我們使用 APISIX 的 Kafka-Logger 對(duì)行為采集和日志系統(tǒng)的數(shù)據(jù)進(jìn)行直接上報(bào)，使用同步工具對(duì)上報(bào)數(shù)據(jù)進(jìn)行清洗過(guò)濾，最終存儲(chǔ)到 ClickHouse中。在使用 Flink 同步時(shí)，我們引入了 RabbitMQ 消息組件來(lái)保障數(shù)據(jù)同步的穩(wěn)定性（因歷史原因未使用 Kafka，建議盡量使用統(tǒng)一的消息隊(duì)列組件）。

在使用過(guò)程中我們發(fā)現(xiàn) ClickHouse 性能固然強(qiáng)悍，但需要不斷進(jìn)行調(diào)優(yōu)，工程師的學(xué)習(xí)成本非常高，同時(shí)隨著用戶的體量的不斷上升，用戶活躍度的持續(xù)提高，ClickHouse 的運(yùn)維管理和調(diào)優(yōu)成本也逐步攀高。而過(guò)高的集群壓力再次導(dǎo)致 C端部分業(yè)務(wù)出現(xiàn)數(shù)據(jù)同步和查詢出現(xiàn)長(zhǎng)達(dá) 5s 的延遲，這依舊沒有解決根本問(wèn)題。

基于 Doris 的新一代架構(gòu)

01 選擇 Doris 的原因

為徹底解決早期架構(gòu)出現(xiàn)的問(wèn)題，我們進(jìn)行了深度調(diào)研，旨在選擇更適合我們的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)。在初步了解后，我們首先放棄了 Hadoop。一方面，Hadoop 的開發(fā)和運(yùn)維難度較大，會(huì)增加我們的工作量；另一方面，Hadoop 更適合處理大數(shù)據(jù)量的批處理場(chǎng)景，而我們需要支持流批一體，以解決C端用戶的查詢延遲較高的問(wèn)題。進(jìn)一步了解之后，我們排除了 Kudu 選項(xiàng)。這是因?yàn)?Kudu 使用成本非常高，特別是在沒有主鍵的情況下，Kudu 會(huì)占用大量存儲(chǔ)資源。此外，一般情況下，為了滿足讀性能，Kudu 會(huì)犧牲寫性能，這與我們的業(yè)務(wù)需求不符。在多方面的了解和對(duì)比后，我們發(fā)現(xiàn) Apache Doris 最符合我們的要求，因?yàn)?Doris 具有以下優(yōu)勢(shì)：

• 支持更靈活的查詢：Doris 可以支持靈活且多變的數(shù)據(jù)分析需求，以滿足需求方針對(duì)不同群體高頻次的營(yíng)銷活動(dòng)。

• 支持聯(lián)邦查詢：Apache Doris 1.2 版本推出了多源數(shù)據(jù)目錄（Multi-Catalog）通過(guò)簡(jiǎn)單的命令便可以方便地連接到各自外部數(shù)據(jù)源并自動(dòng)同步元數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)出口統(tǒng)一，實(shí)現(xiàn)統(tǒng)一的分析體驗(yàn)。

• 查詢性能優(yōu)異：Doris Join 能力強(qiáng)大，依托列式存儲(chǔ)引擎、現(xiàn)代的 MPP 架構(gòu)、向量化查詢引擎、預(yù)聚合物化視圖、數(shù)據(jù)索引的實(shí)現(xiàn)，在低延遲和高吞吐查詢上，都達(dá)到了極速性能。

• 運(yùn)維難度低：Doris 對(duì)于集群和和數(shù)據(jù)副本管理上做了很多自動(dòng)化工作，使得集群運(yùn)維起來(lái)非常的簡(jiǎn)單，幾乎可以實(shí)現(xiàn)零門檻運(yùn)維。與此同時(shí)，Apache Doris 社區(qū)非?；钴S，響應(yīng)迅速，并且 SelectDB 為社區(qū)提供了一支專職的工程師團(tuán)隊(duì)，免費(fèi)為用戶提供技術(shù)支持服務(wù)。

02 數(shù)據(jù)架構(gòu)的重建

引入 Doris 后，我們對(duì)數(shù)據(jù)架構(gòu)進(jìn)行了重構(gòu)，Doris 的位置及作用可從上方架構(gòu)圖得知。

由圖可知，Doris 的數(shù)據(jù)來(lái)源非常多樣化，包括通過(guò) Flink-CDC、Binlog 的業(yè)務(wù)數(shù)據(jù)，經(jīng)由 Kafka 的行為數(shù)據(jù)和日志數(shù)據(jù)，以及從自研的全量/增量工具同步的其他數(shù)據(jù)。此外，還有部分通過(guò) Doris Stream Load 和 Routine Load 同步的數(shù)據(jù)。這些來(lái)自不同工具的數(shù)據(jù)統(tǒng)一由 ETL 處理，最終存儲(chǔ)到 Kafka 或 Doris 集群中。其中存儲(chǔ)到 Kafka 中的數(shù)據(jù)會(huì)通過(guò) Routine Load 高效寫入到 Doris 中，最終由 Doris 統(tǒng)一提供數(shù)據(jù)服務(wù)。Doris 的引入解決了各類同步工具的數(shù)據(jù)源統(tǒng)一的問(wèn)題，不再需要維護(hù)大量配置，而統(tǒng)一數(shù)據(jù)出口也讓數(shù)據(jù)處理變得更加簡(jiǎn)單和高效。

在新一代架構(gòu)中，Doris 已完全取代了 ClickHouse，相比于 ClickHouse，Doris 具有更好的性能和更廣泛的適用性，在約苗所服務(wù)的業(yè)務(wù)已逐步從統(tǒng)計(jì)分析擴(kuò)展到業(yè)務(wù)系統(tǒng)?；?Doris 的高性能、高并發(fā)的支持，約苗平臺(tái)的用戶端相關(guān)業(yè)務(wù)延遲問(wèn)題也得到了成功解決，使得數(shù)據(jù)查詢和分析更加及時(shí)和準(zhǔn)確。

新數(shù)據(jù)架構(gòu)搭建經(jīng)驗(yàn)

在新架構(gòu)的使用過(guò)程中，我們積累了許多實(shí)踐經(jīng)驗(yàn)，希望能夠與大家分享。以下是我們總結(jié)出來(lái)的一些經(jīng)驗(yàn)：

01 Routine Load 實(shí)現(xiàn)數(shù)據(jù)快速導(dǎo)入

在數(shù)據(jù)導(dǎo)入方面，我們強(qiáng)烈建議使用 Stream Load 和 Routine Load 這兩種工具，因?yàn)樗鼈兊男阅苓h(yuǎn)遠(yuǎn)高于其他導(dǎo)入方式。

Stream Load 和 Routine Load 是 Doris 常見的兩種數(shù)據(jù)導(dǎo)入方式，Stream load 是一個(gè)同步的導(dǎo)入方式，用戶通過(guò)發(fā)送 HTTP 協(xié)議發(fā)送請(qǐng)求將本地文件或數(shù)據(jù)流導(dǎo)入到 Doris 中。Routine Load 功能支持用戶提交一個(gè)常駐的導(dǎo)入任務(wù)，通過(guò)不斷的從指定的數(shù)據(jù)源讀取數(shù)據(jù)，將數(shù)據(jù)導(dǎo)入到 Doris 中。

我們?cè)?jīng)嘗試過(guò)其他的數(shù)據(jù)導(dǎo)入方式，經(jīng)過(guò)多次壓力測(cè)試和性能對(duì)比，并結(jié)合我們的實(shí)際數(shù)據(jù)類型，最終選擇了 Stream Load 和 Routine Load 進(jìn)行數(shù)據(jù)導(dǎo)入。Routine Load 是一種高效、穩(wěn)定的數(shù)據(jù)導(dǎo)入工具，它依賴于 Kafka 并具有極好的可靠性。與其他數(shù)據(jù)導(dǎo)入方式相比，Routine Load 支持的配置豐富，能夠根據(jù)配置來(lái)過(guò)濾和合并數(shù)據(jù)，同時(shí)需要開通的網(wǎng)絡(luò)策略也更少，能夠很好地滿足同步數(shù)據(jù)的需求。最重要的是，Routine Load 可以達(dá)到每分鐘數(shù)百萬(wàn)行的數(shù)據(jù)導(dǎo)入，完全符合我們對(duì)數(shù)據(jù)導(dǎo)入速度的要求。

在使用 Routine Load 進(jìn)行數(shù)據(jù)導(dǎo)入時(shí)，難免會(huì)出現(xiàn)全量和增量數(shù)據(jù)同時(shí)同步的情況，或者在多線程消費(fèi)下出現(xiàn)數(shù)據(jù)積壓的情況，這就需要保證數(shù)據(jù)的一致性。因此我們可以通過(guò) Doris 支持的 Sequence 列來(lái)保證數(shù)據(jù)的一致性，用戶可以在導(dǎo)入時(shí)指定 Sequence 列，相同 Key 列下，REPLACE 聚合類型的列將按照 Sequence 列的值進(jìn)行替換，較大值可以替換較小值，反之則無(wú)法替換。該方法將順序的確定交給了用戶，由用戶控制替換順序。具體的實(shí)現(xiàn)方式如下：

1. 在定義表時(shí)，先定義一個(gè)列，比如定義為 order_id。

2. 接著在創(chuàng)建 Routine Load 時(shí)指定根據(jù) order_id 列進(jìn)行寫入，以保證數(shù)據(jù)寫入順序。

3. 在寫入數(shù)據(jù)時(shí)，需要保證每條數(shù)據(jù)都擁有 order_id 列有值。

4. 在進(jìn)行全量同步時(shí)，可以使用 Java-sync 來(lái)實(shí)現(xiàn)，全量同步時(shí)需要保證 order_id 始終為 0。

5. 在進(jìn)行增量同步時(shí)，可以使用讀取 Binlog 的方式進(jìn)行同步，增量同步的 order_id 需要從 1 開始。另外可以記錄增量同步的 order_id 值，以保證數(shù)據(jù)準(zhǔn)確寫入 Unique 表。

02 分區(qū)分桶和查詢實(shí)踐

在使用 Doris 進(jìn)行數(shù)據(jù)存儲(chǔ)時(shí)，建表時(shí)需要盡量貼近實(shí)際使用場(chǎng)景，以此來(lái)創(chuàng)建分區(qū)列和分桶列。這里將分享我們我們?cè)趧?chuàng)建表時(shí)的一些經(jīng)驗(yàn)。

• 分區(qū)：分區(qū)是建立一張大表時(shí)非常關(guān)鍵的因素，它直接影響到可以檢索到的數(shù)據(jù)大小和需要處理的數(shù)據(jù)量。如果一個(gè)分區(qū)的數(shù)據(jù)量太大，那么就需要更多的 CPU 和內(nèi)存來(lái)處理，從而導(dǎo)致查詢效率降低。如果利用時(shí)間分區(qū)，可以考慮使用動(dòng)態(tài)分區(qū)來(lái)讓 Doris 自行管理分區(qū)。動(dòng)態(tài)分區(qū)可以根據(jù)時(shí)間自動(dòng)創(chuàng)建新的分區(qū)，并刪除舊的分區(qū)，從而保持?jǐn)?shù)據(jù)的最新性和存儲(chǔ)效率。同時(shí)，動(dòng)態(tài)分區(qū)還可以幫助我們保留部分?jǐn)?shù)據(jù)或者區(qū)分冷熱數(shù)據(jù)，從而更好地管理數(shù)據(jù)存儲(chǔ)和查詢。
• 分桶：考慮在一個(gè)分區(qū)下如何讓分桶足夠均衡，是每個(gè)表必須要做的事情。如果分桶列數(shù)太多，可能會(huì)影響點(diǎn)查詢的性能，如果分桶不夠均衡，查詢速度會(huì)受到最大桶處理時(shí)間的影響。因此需要在性能和查詢需求之間做出取舍。另外，推薦大家使用Apache Doris 1.2.2 版本的 Auto Bucket 自動(dòng)分桶推算功能，分桶個(gè)數(shù)不再依賴于人工設(shè)置，通過(guò)規(guī)則的智能計(jì)算即可保證合理的數(shù)據(jù)劃分，降低用戶學(xué)習(xí)成本的同時(shí)還可以最大化提升用戶開發(fā)效率。

舉例來(lái)說(shuō)，當(dāng)我們需要記錄行為記錄寬表時(shí)，一般會(huì)使用 Duplicate 模型進(jìn)行記錄。在建表時(shí)，我們可以把report_time、event_id、product_id、plate_id、user_id 作為 Key 列，并使用 report_time 按月進(jìn)行動(dòng)態(tài)分區(qū)，每月記錄數(shù)據(jù) 1.5 TB 左右，使用 product_id、plate_id、event_id 進(jìn)行自動(dòng)分桶。

在使用過(guò)程中我們發(fā)現(xiàn)，當(dāng)某一類事件遠(yuǎn)遠(yuǎn)超過(guò)了其他事件的總數(shù)時(shí)，會(huì)嚴(yán)重導(dǎo)致數(shù)據(jù)傾斜嚴(yán)重。為了解決這個(gè)問(wèn)題，我們?cè)黾恿嗽诜滞傲泻笮略隽?code>user_id，從而達(dá)到了數(shù)據(jù)均衡的效果。通過(guò)這一優(yōu)化，查詢速度由原來(lái)的 13s 提升到 5s。另外我們?cè)谶@個(gè)基礎(chǔ)上使用了物化視圖進(jìn)一步對(duì)查詢性能進(jìn)行優(yōu)化，物化視圖介入之后，查詢速度從 5 秒提升到毫秒級(jí)別。

Doris 在約苗的應(yīng)用實(shí)踐

01 靈活組合查詢，提高廣告投放效率

由于疫苗的特殊性，業(yè)務(wù)側(cè)同學(xué)在推廣的過(guò)程中需要更精準(zhǔn)的用戶信息，例如年齡、性別、地區(qū)等業(yè)務(wù)同學(xué)指定的信息。這種情況下，數(shù)據(jù)平臺(tái)就需要提供詳細(xì)的用戶群體信息，以幫助業(yè)務(wù)同學(xué)實(shí)現(xiàn)精細(xì)化信息觸達(dá)。

在接入 Doris 后，我們主要利用 Doris 的 Join 實(shí)現(xiàn)了一套完全可以支持任意字段組合查詢的工具。類似于常見的 SQL 管理工具，不同的是，無(wú)需自行編寫 SQL，只需選擇需要的字段進(jìn)行組合配置即可查詢，得到想要的結(jié)果，以此來(lái)滿足需求多變的業(yè)務(wù)場(chǎng)景，從而提高業(yè)務(wù)側(cè)工作效率。同時(shí)，Doris 還具有高效的數(shù)據(jù)寫入和查詢能力，使得運(yùn)營(yíng)人員可以更加快速地獲取所需數(shù)據(jù)，進(jìn)行數(shù)據(jù)分析和應(yīng)用開發(fā)。

基于此，業(yè)務(wù)同學(xué)可以通過(guò)多種業(yè)務(wù)數(shù)據(jù)聯(lián)合檢索，快速篩選出滿足自己需求的用戶信息，并導(dǎo)出最終檢索結(jié)果。例如，可以對(duì)年齡在 19 歲至 45 歲之間，瀏覽過(guò) HPV 九價(jià)疫苗頁(yè)面并且頁(yè)面停留時(shí)長(zhǎng)大于 1 分鐘的用戶數(shù)據(jù)進(jìn)行檢索，并導(dǎo)出結(jié)果。通過(guò)這一方式，業(yè)務(wù)同學(xué)可以快速獲取目標(biāo)用戶信息，從而精準(zhǔn)地進(jìn)行營(yíng)銷推廣和活動(dòng)推送。

02 聯(lián)邦查詢實(shí)踐，百萬(wàn)數(shù)據(jù)分鐘級(jí)導(dǎo)入

在使用 Doris 之前，某些業(yè)務(wù)場(chǎng)景需要數(shù)據(jù)組的同事自行編寫大量復(fù)雜代碼來(lái)完成數(shù)據(jù)導(dǎo)入任務(wù)。在接入 Doris 之后，我們利用 Muti-Catalog 功能建立了 ES 和 MySQL 的外表，在遇到數(shù)據(jù)導(dǎo)入任務(wù)時(shí)，我們僅需要花幾分鐘時(shí)間編寫 SQL，依靠 Doris 快速完成數(shù)據(jù)導(dǎo)入任務(wù)。同樣的數(shù)據(jù)導(dǎo)入任務(wù)（80 萬(wàn)數(shù)據(jù)的）之前需要 1 -2 天的時(shí)間完成，而使用 Doris 之后，僅僅需要幾分鐘即可完成數(shù)據(jù)導(dǎo)入。

除此之外，Apache Doris 提供的 Multi Catalog 功能也幫助我們的統(tǒng)一了來(lái)自多種同步工具的數(shù)據(jù)源，成功統(tǒng)一了數(shù)據(jù)出口，使得數(shù)據(jù)處理變得更加簡(jiǎn)單和高效，同時(shí)我們也無(wú)需投入過(guò)多的人力和精力去維護(hù)大量其他數(shù)據(jù)相關(guān)的配置，極大的節(jié)約了成本的投入。

03 Join 能力加持，實(shí)現(xiàn) 300 倍查詢速度提升

除此之外，Doris 的 Join 性能十分優(yōu)異，當(dāng) Doris 集群完成業(yè)務(wù)數(shù)據(jù)的全同步后，我們對(duì) 1億 和近百億的兩張表進(jìn)行 Join 操作，可以在 5 秒內(nèi)輸出數(shù)據(jù)結(jié)果，相較之前有接近 300 倍的查詢速度提升。為了驗(yàn)證其是否偶然，我們接著對(duì) 10 張分別有 4000萬(wàn)數(shù)據(jù)的表進(jìn)行 Join，Doris 可以在 10s 內(nèi)返回查詢結(jié)果。而在物化視圖加持下，可以達(dá)到毫秒級(jí)別的查詢響應(yīng)。這充分說(shuō)明了 Doris 在處理大規(guī)模數(shù)據(jù)的優(yōu)勢(shì)。

04 極低運(yùn)維成本，助力降本提效

在之前的架構(gòu)中，我們使用 ClickHouse 進(jìn)行數(shù)據(jù)存儲(chǔ)和查詢，并且需要單獨(dú)維護(hù)Zookeeper 來(lái)管理集群的配置信息和狀態(tài)信息，這些都增加了系統(tǒng)的運(yùn)維成本和難度。而 Doris 架構(gòu)簡(jiǎn)單，只有 FE 和 BE 兩個(gè)進(jìn)程，擴(kuò)縮容快捷方便，運(yùn)維難度和成本得到極大的降低，此外，Doris 還提供了更加友好和易用的數(shù)據(jù)備份和恢復(fù)功能，可有效保障數(shù)據(jù)的安全性和完整性。

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

當(dāng)前約苗已經(jīng)基于 Apache Doris 搭建了一套完整的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)，并在消息系統(tǒng)、運(yùn)營(yíng)平臺(tái)、數(shù)據(jù)平臺(tái)、日志系統(tǒng)中得到廣泛的應(yīng)用，目前已經(jīng)接入百億級(jí)別的數(shù)據(jù)量，并且在持續(xù)增加中。未來(lái)我們將基于 Doris 不斷探索，擴(kuò)大 Doris 使用范圍，逐步推廣至秒殺、訂閱、黑名單、預(yù)約等各個(gè)業(yè)務(wù)場(chǎng)景，同時(shí)我們也將嘗試使用 Doris 的新特性，以實(shí)踐結(jié)果回饋社區(qū)，為社區(qū)發(fā)展獻(xiàn)一份力，為社區(qū)做出實(shí)質(zhì)性的貢獻(xiàn)。

最后，感謝 SelectDB 技術(shù)團(tuán)隊(duì)長(zhǎng)期以來(lái)快速響應(yīng)和技術(shù)支持，為我們穩(wěn)定高效應(yīng)用 Doris 保駕護(hù)航。