作者：趙偉，思必馳大數(shù)據(jù)高級(jí)研發(fā)，10年大數(shù)據(jù)開發(fā)和設(shè)計(jì)經(jīng)驗(yàn)，負(fù)責(zé)大數(shù)據(jù)平臺(tái)基礎(chǔ)技術(shù)和OLAP分析技術(shù)開發(fā)。社區(qū)貢獻(xiàn)：Doris-spark-connector 的實(shí)時(shí)讀寫和優(yōu)化。

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

思必馳是國(guó)內(nèi)專業(yè)的對(duì)話式人工智能平臺(tái)公司，擁有全鏈路的智能語音語言技術(shù)，致力于成為全鏈路智能語音及語言交互的平臺(tái)型企業(yè)，自主研發(fā)了新一代人機(jī)交互平臺(tái) DUI 和人工智能芯片 TH1520，為車聯(lián)網(wǎng)、IoT 及政務(wù)、金融等眾多行業(yè)場(chǎng)景合作伙伴提供自然語言交互解決方案。

思必馳于 2019 年首次引入 Apache Doris ，基于 Apache Doris 構(gòu)建了實(shí)時(shí)與離線一體的數(shù)倉架構(gòu)。相對(duì)于過去架構(gòu)，Apache Doris 憑借其靈活的查詢模型、極低的運(yùn)維成本、短平快的開發(fā)鏈路以及優(yōu)秀的查詢性能等諸多方面優(yōu)勢(shì)，如今已經(jīng)在實(shí)時(shí)業(yè)務(wù)運(yùn)營(yíng)、自助/對(duì)話式分析等多個(gè)業(yè)務(wù)場(chǎng)景得到運(yùn)用，滿足了 設(shè)備畫像/用戶標(biāo)簽、業(yè)務(wù)場(chǎng)景實(shí)時(shí)運(yùn)營(yíng)、數(shù)據(jù)分析看板、自助 BI、財(cái)務(wù)對(duì)賬等多種數(shù)據(jù)分析需求。在這一過程中我們也積累了諸多使用上的經(jīng)驗(yàn)，在此分享給大家。

架構(gòu)演進(jìn)

早期業(yè)務(wù)中離線數(shù)據(jù)分析是我們的主要需求，近幾年，隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)場(chǎng)景對(duì)實(shí)時(shí)數(shù)據(jù)分析的要求也越來越高，早期數(shù)倉架構(gòu)逐漸力不從心，暴露出很多問題。為了滿足業(yè)務(wù)場(chǎng)景對(duì)查詢性能、響應(yīng)時(shí)間及并發(fā)能力更高的要求，2019年正式引入 Apache Doris 構(gòu)建實(shí)時(shí)離線一體的數(shù)倉架構(gòu)。

以下將為大家介紹思必馳數(shù)倉架構(gòu)的演進(jìn)之路，早期數(shù)倉存在的優(yōu)缺點(diǎn)，同時(shí)分享我們選擇 Apache Doris 構(gòu)建新架構(gòu)的原因以及面臨的新問題與挑戰(zhàn)。

早期數(shù)倉架構(gòu)及痛點(diǎn)

image.png

如上圖所示，早期架構(gòu)基于 Hive +Kylin 來構(gòu)建離線數(shù)倉，實(shí)時(shí)數(shù)倉架基于 Spark+MySQL 來構(gòu)建實(shí)時(shí)分析數(shù)倉。

我們業(yè)務(wù)場(chǎng)景的數(shù)據(jù)源主要分為三類，業(yè)務(wù)數(shù)據(jù)庫如 MySQL，應(yīng)用系統(tǒng)如 K8s 容器服務(wù)日志，還有車機(jī)設(shè)備終端的日志。數(shù)據(jù)源通過 MQTT/HTTP 協(xié)議、業(yè)務(wù)數(shù)據(jù)庫 Binlog 、Filebeat日志采集等多種方式先寫入 Kafka 。在早期架構(gòu)中，數(shù)據(jù)經(jīng) Kafka 后將分為實(shí)時(shí)和離線兩條鏈路，首先是實(shí)時(shí)部分，實(shí)時(shí)部分鏈路較短，經(jīng)過 Kafka 緩沖完的數(shù)據(jù)通過 Spark 計(jì)算后放入 MySQL 中進(jìn)行分析，對(duì)于早期的實(shí)時(shí)分析需求，MySQL 基本可以滿足分析需求。而離線部分則由 Spark 進(jìn)行數(shù)據(jù)清洗及計(jì)算后在 Hive 中構(gòu)建離線數(shù)倉，并使用 Apache Kylin 構(gòu)建 Cube，在構(gòu)建 Cube 之前需要提前做好數(shù)據(jù)模型的的設(shè)計(jì)，包括關(guān)聯(lián)表、維度表、指標(biāo)字段、指標(biāo)需要的聚合函數(shù)等，通過調(diào)度系統(tǒng)進(jìn)行定時(shí)觸發(fā)構(gòu)建，最終使用 HBase 存儲(chǔ)構(gòu)建好的 Cube。

早期架構(gòu)的優(yōu)勢(shì)：

1. 早期架構(gòu)與 Hive 結(jié)合較好，無縫對(duì)接 Hadoop 技術(shù)體系。
2. 離線數(shù)倉中基于 Kylin 的預(yù)計(jì)算、表關(guān)聯(lián)、聚合計(jì)算、精確去重等場(chǎng)景，查詢性能較高，在并發(fā)場(chǎng)景下查詢穩(wěn)定性也較高。

早期架構(gòu)解決了當(dāng)時(shí)業(yè)務(wù)中較為緊迫的查詢性能問題，但隨著業(yè)務(wù)的發(fā)展，對(duì)數(shù)據(jù)分析要求不斷升高，早期架構(gòu)缺點(diǎn)也開始逐漸凸顯出來。

早期架構(gòu)的痛點(diǎn)：

1. 依賴組件多。Kylin 在 2.x、3.x 版本中強(qiáng)依賴 Hadoop 和 HBase ，應(yīng)用組件較多導(dǎo)致開發(fā)鏈路較長(zhǎng)，架構(gòu)穩(wěn)定性隱患多，維護(hù)成本比很高。
2. Kylin 的構(gòu)建過程復(fù)雜，構(gòu)建任務(wù)容易失敗。Kylin 構(gòu)建需要進(jìn)行打?qū)挶怼⑷ブ亓小⑸勺值洌瑯?gòu)建 Cube 等如果每天有 1000-2000 個(gè)甚至更多的任務(wù)，其中至少會(huì)有 10 個(gè)甚至更多任務(wù)構(gòu)建失敗，導(dǎo)致需要大量時(shí)間去寫自動(dòng)運(yùn)維腳本。
3. 維度/字典膨脹嚴(yán)重。維度膨脹指的是在某些業(yè)務(wù)場(chǎng)景中需要多個(gè)分析條件和字段，如果在數(shù)據(jù)分析模型中選擇了很多字段而沒有進(jìn)行剪枝，則會(huì)導(dǎo)致 Cube 維度膨脹嚴(yán)重，構(gòu)建時(shí)間變長(zhǎng)。而字典膨脹指的是在某些場(chǎng)景中需要長(zhǎng)時(shí)間做全局精確去重，會(huì)使得字典構(gòu)建越來越大，構(gòu)建時(shí)間也會(huì)越來越長(zhǎng)，從而導(dǎo)致數(shù)據(jù)分析性能持續(xù)下降。
4. 數(shù)據(jù)分析模型固定，靈活性較低。在實(shí)際應(yīng)用過程中，如果對(duì)計(jì)算字段或者業(yè)務(wù)場(chǎng)景進(jìn)行變更，則要回溯部分甚至全部數(shù)據(jù)。
5. 不支持?jǐn)?shù)據(jù)明細(xì)查詢。早期數(shù)倉架構(gòu)是無法提供明細(xì)數(shù)據(jù)查詢的，Kylin 官方給的解決方法是下推給 Presto 做明細(xì)查詢，這又引入了新的架構(gòu)，增加了開發(fā)和運(yùn)維成本。

架構(gòu)選型

為解決以上問題，我們開始探索新的數(shù)倉架構(gòu)優(yōu)化方案，先后對(duì)市面上應(yīng)用最為廣泛的 Apache Doris、Clickhouse 等 OLAP 引擎進(jìn)行選型調(diào)研。相較于 ClickHouse 的繁重運(yùn)維、各種各樣的表類型、不支持關(guān)聯(lián)查詢等，結(jié)合我們的 OLAP 分析場(chǎng)景中的需求，綜合考慮，Apache Doris 表現(xiàn)較為優(yōu)秀，最終決定引入 Apache Doris 。

新數(shù)倉架構(gòu)

image.png

如上圖所示，我們基于 Apache Doris 構(gòu)建了實(shí)時(shí)+離線一體的新數(shù)倉架構(gòu)，與早期架構(gòu)不同的是，實(shí)時(shí)和離線的數(shù)據(jù)分別進(jìn)行處理后均寫入 Apache Doris 中進(jìn)行分析。

因歷史原因數(shù)據(jù)遷移難度較大，離線部分基本和早期數(shù)倉架構(gòu)保持一致，在Hive上構(gòu)建離線數(shù)倉，當(dāng)然完全可以在Apache Doris 上直接構(gòu)建離線數(shù)倉。

相對(duì)早期架構(gòu)不同的是，離線數(shù)據(jù)通過 Spark 進(jìn)行清洗計(jì)算后在 Hive 中構(gòu)建數(shù)倉，然后通過 Broker Load 將存儲(chǔ)在 Hive 中的數(shù)據(jù)寫入到 Apache Doris 中。這里要說明的， Broker Load 數(shù)據(jù)導(dǎo)入速度很快，天級(jí)別 100-200G 數(shù)據(jù)導(dǎo)入到 Apache Doris 中僅需要 10-20 分鐘。

實(shí)時(shí)數(shù)據(jù)流部分，新架構(gòu)使用了 Doris-Spark-Connector 來消費(fèi) Kafka 中的數(shù)據(jù)并經(jīng)過簡(jiǎn)單計(jì)算后寫入 Apache Doris 。從架構(gòu)圖所示，實(shí)時(shí)和離線數(shù)據(jù)統(tǒng)一在 Apache Doris 進(jìn)行分析處理，滿足了數(shù)據(jù)應(yīng)用的業(yè)務(wù)需求，實(shí)現(xiàn)了實(shí)時(shí)+離線一體的數(shù)倉架構(gòu)。

新架構(gòu)的收益：

1. 極簡(jiǎn)運(yùn)維，維護(hù)成本低，不依賴 Hadoop 生態(tài)組件。Apache Doris 的部署簡(jiǎn)單，只有 FE 和 BE 兩個(gè)進(jìn)程， FE 和 BE 進(jìn)程都是可以橫向擴(kuò)展的，單集群支持到數(shù)百臺(tái)機(jī)器，數(shù)十 PB 的存儲(chǔ)容量，并且這兩類進(jìn)程通過一致性協(xié)議來保證服務(wù)的高可用和數(shù)據(jù)的高可靠。這種高度集成的架構(gòu)設(shè)計(jì)極大的降低了一款分布式系統(tǒng)的運(yùn)維成本。在使用 Doris 三年時(shí)間中花費(fèi)的運(yùn)維時(shí)間非常少，相比于基于 Kylin 搭建的早期架構(gòu)，新架構(gòu)花費(fèi)極少的時(shí)間去做運(yùn)維。
2. 鏈路短，開發(fā)排查問題難度大大降低。基于 Doris 構(gòu)建實(shí)時(shí)和離線統(tǒng)一數(shù)倉，支持實(shí)時(shí)數(shù)據(jù)服務(wù)、交互數(shù)據(jù)分析和離線數(shù)據(jù)處理場(chǎng)景，這使得開發(fā)鏈路變的很短，問題排查難度大大降低。
3. 支持 Runtime 形式的 Join 查詢。Runtime 類似 MySQL 的表關(guān)聯(lián)，這對(duì)數(shù)據(jù)分析模型頻繁變更的場(chǎng)景非常友好，解決了早期結(jié)構(gòu)數(shù)據(jù)模型靈活性較低的問題。
4. 同時(shí)支持 Join、聚合、明細(xì)查詢。解決了早期架構(gòu)中部分場(chǎng)景無法查詢數(shù)據(jù)明細(xì)的問題。
5. 支持多種加速查詢方式。支持上卷索引，物化視圖，通過上卷索引實(shí)現(xiàn)二級(jí)索引來加速查詢，極大的提升了查詢響應(yīng)時(shí)間。
6. 支持多種聯(lián)邦查詢方式。支持對(duì) Hive、Iceberg、Hudi 等數(shù)據(jù)湖和 MySQL、Elasticsearch 等數(shù)據(jù)庫的聯(lián)邦查詢分析。

問題和挑戰(zhàn)：

在建設(shè)新數(shù)倉架構(gòu)過程中，我們遇到了一些問題：

• 高并發(fā)場(chǎng)景對(duì) Apache Doris 查詢性能存在一定影響。我們分別在 Doris 0.12 和 Doris 1.1版本上進(jìn)行測(cè)試，同一時(shí)間同樣的 SQL，10 并發(fā)和 50 并發(fā)進(jìn)行訪問，性能差別較大。
• 在實(shí)時(shí)寫入場(chǎng)景中，當(dāng)實(shí)時(shí)寫入的數(shù)據(jù)量比較大時(shí)，會(huì)使得 IO 比較密集，導(dǎo)致查詢性能下降。
• 大數(shù)據(jù)量下字符串精確去重較慢。目前使用的是 count distinct 函數(shù)、Shuffle 和聚合算子去重，此方式算力比較慢。當(dāng)前業(yè)內(nèi)常見的解決方法一般是針對(duì)去重列構(gòu)建字典，基于字典構(gòu)建 Bitmap 索引后使用 Bitmap 函數(shù)去重。目前 Apache Doris 只支持?jǐn)?shù)字類型的 Bitmap 索引，具有一定的局限性。

業(yè)務(wù)場(chǎng)景的應(yīng)用

Apache Doris 在思必馳最先應(yīng)用在實(shí)時(shí)運(yùn)營(yíng)業(yè)務(wù)場(chǎng)景以及自助/對(duì)話式分析場(chǎng)景，本章節(jié)將介紹兩個(gè)場(chǎng)景的需求及應(yīng)用情況。

實(shí)時(shí)運(yùn)營(yíng)業(yè)務(wù)場(chǎng)景

image.png

首先是實(shí)時(shí)運(yùn)營(yíng)業(yè)務(wù)場(chǎng)景，如上圖所示，實(shí)時(shí)運(yùn)營(yíng)業(yè)務(wù)場(chǎng)景的技術(shù)架構(gòu)和前文所述的新版數(shù)倉架構(gòu)基本一致：

• 數(shù)據(jù)源：數(shù)據(jù)源新版架構(gòu)圖中一致，包括 MySQL 中的業(yè)務(wù)數(shù)據(jù)，應(yīng)用系統(tǒng)埋點(diǎn)數(shù)據(jù)以及設(shè)備和終端日志。
• 數(shù)據(jù)導(dǎo)入：離線數(shù)據(jù)導(dǎo)入使用 Broker Load，實(shí)時(shí)數(shù)據(jù)導(dǎo)入使用 Doris-Spark-Connector 。
• 數(shù)據(jù)存儲(chǔ)與開發(fā)：幾乎所有的實(shí)時(shí)數(shù)倉全部在 Apache Doris 構(gòu)建，有一部分離線數(shù)據(jù)放在 Airflow 上執(zhí)行 DAG 跑批任務(wù)。
• 數(shù)據(jù)應(yīng)用：最上層是業(yè)務(wù)側(cè)提出的業(yè)務(wù)分析需求，包括大屏展示，數(shù)據(jù)運(yùn)營(yíng)的實(shí)時(shí)看板、用戶畫像、BI 看板等。

在實(shí)時(shí)運(yùn)營(yíng)業(yè)務(wù)場(chǎng)景中，數(shù)據(jù)分析的需求主要有兩方面：

• 由于實(shí)時(shí)導(dǎo)入數(shù)據(jù)量比較大，因此對(duì)實(shí)時(shí)數(shù)據(jù)的查詢效率要求較高
• 在此場(chǎng)景中，有 20+ 人的團(tuán)隊(duì)在運(yùn)營(yíng)，需要同時(shí)開數(shù)據(jù)運(yùn)營(yíng)的看板，因此對(duì)實(shí)時(shí)寫入的性能和查詢并發(fā)會(huì)有比較高的要求。

自助/對(duì)話式分析場(chǎng)景

除以上之外，Apache Doris 在思必馳第二個(gè)應(yīng)用是自助/對(duì)話式分析場(chǎng)景。

image.png

如上圖所示，在一般的 BI 場(chǎng)景中，用戶方比如商務(wù)、財(cái)務(wù)、銷售、運(yùn)營(yíng)、項(xiàng)目經(jīng)理等會(huì)提出需求給數(shù)據(jù)分析人員，數(shù)據(jù)分析人員在 BI 平臺(tái)上做數(shù)據(jù)看板，最終把看板提供給用戶，用戶從 BI 看板上獲取所需信息，但是有時(shí)候用戶想要查看明細(xì)數(shù)據(jù)、定制化的看板需求，或者在某些場(chǎng)景需做任意維度的上卷或者下鉆的分析，一般場(chǎng)景下 BI 看板是不支持的的，基于以上所述用戶需求，我們打造了自助對(duì)話式 BI 場(chǎng)景來解決用戶定制化的需求。

與一般 BI 場(chǎng)景不同的是，我們將自助/對(duì)話式 BI 場(chǎng)景從數(shù)據(jù)分析人員方下沉到用戶方，用戶方只需要通過打字，描述數(shù)據(jù)分析的需求。基于我們公司自然語言處理的能力，自助/對(duì)話式 BI 場(chǎng)景會(huì)將自然語言轉(zhuǎn)換成SQL，類似 NL2SQL 技術(shù)，需要說明的是這里使用的是定制的自然語言解析，相對(duì)開源的 NL2SQL 命中率高、解析結(jié)果更精確。當(dāng)自然語言轉(zhuǎn)換成 SQL 后，將 SQL 給到 Apache Doris 查詢得到分析結(jié)果。由此，用戶通過打字就可以隨時(shí)查看任意場(chǎng)景下的明細(xì)數(shù)據(jù)，或者任意字段的上卷、下鉆。

相比 Apache Kylin、Apache Druid 等預(yù)計(jì)算的 OLAP 引擎，Apache Doris 符合以下幾個(gè)特點(diǎn)：

• 查詢靈活，模型不固定，支持自由定制場(chǎng)景。
• 支持表關(guān)聯(lián)、聚合計(jì)算、明細(xì)查詢。
• 響應(yīng)時(shí)間要快速。

因此我們很順利的運(yùn)用 Apache Doris 實(shí)現(xiàn)了自助/對(duì)話式分析場(chǎng)景。同時(shí)，自助/對(duì)話式分析在我們公司多個(gè)數(shù)據(jù)分析場(chǎng)景應(yīng)用反饋非常好。

實(shí)踐經(jīng)驗(yàn)

基于上面的兩個(gè)場(chǎng)景，我們使用過程當(dāng)中積累了一些經(jīng)驗(yàn)和心得，分享給大家。

數(shù)倉 表設(shè)計(jì)：

1. 千萬級(jí)(量級(jí)供參考，跟集群規(guī)模有關(guān)系)以下的數(shù)據(jù)表使用 Duplicate 表類型，Duplicate 表類型同時(shí)支持聚合、明細(xì)查詢，不需要額外寫明細(xì)表。
2. 當(dāng)數(shù)據(jù)量比較大時(shí)，使用 Aggregate 聚合表類型，在聚合表類型上做上卷索引，使用物化視圖優(yōu)化查詢、優(yōu)化聚合字段。由于 Aggregate 表類型是預(yù)計(jì)算表，會(huì)丟失明細(xì)數(shù)據(jù)，如有明細(xì)查詢需求，需要額外寫一張明細(xì)表。
3. 當(dāng)數(shù)據(jù)量又大、關(guān)聯(lián)表又多時(shí)，可用 ETL 先寫成寬表，然后導(dǎo)入到 Doris，結(jié)合 Aggregate 在聚合表類型上面做優(yōu)化，也可以使用官方推薦Doris 的 Join 優(yōu)化：https://doris.apache.org/zh-CN/docs/dev/advanced/join-optimization/doris-join-optimization

寫入：

1. 通過 Spark Connector 或 Flink Connector 替代 Routine Load： 最早我們使用的是 Routine Load 實(shí)時(shí)寫入 BE 節(jié)點(diǎn)， Routine Load 的工作原理是通過 SQL 在 FE 節(jié)點(diǎn)起一個(gè)類似于 Task Manager 的管理，把任務(wù)分發(fā)給 BE 節(jié)點(diǎn)，在 BE 節(jié)點(diǎn)起 Routine Load 任務(wù)。在我們實(shí)時(shí)場(chǎng)景并發(fā)很高的情況下，BE 節(jié)點(diǎn) CPU 峰值一般會(huì)達(dá)到 70% 左右，在這個(gè)前提下，Routine Load 也跑到 BE 節(jié)點(diǎn)，將嚴(yán)重影響 BE 節(jié)點(diǎn)的查詢性能，并且查詢 CPU 也將影響 Routine Load 導(dǎo)入， Routine Load 就會(huì)因?yàn)楦鞣N資源競(jìng)爭(zhēng)死掉。面對(duì)此問題，目前解決方法是將 Routine Load 從 BE 節(jié)點(diǎn)拿出來放到資源調(diào)度上，用 Doris-Spark/Flink-Connector 替換 Routine Load。當(dāng)時(shí) Doris-spark-Connector 還沒有實(shí)時(shí)寫入的功能，我們根據(jù)業(yè)務(wù)需求進(jìn)行了優(yōu)化，并將方案貢獻(xiàn)給社區(qū)。
2. 通過攢批來控制實(shí)時(shí)寫入頻率：當(dāng)實(shí)時(shí)寫入頻率較高時(shí)，小文件堆積過多、查詢 IO 升高，小文件排序歸并的過程將導(dǎo)致查詢時(shí)間加長(zhǎng)，進(jìn)而出現(xiàn)查詢抖動(dòng)的情況。當(dāng)前的解決辦法是控制導(dǎo)入頻次，調(diào)整 Compaction 的合并線程、間隔時(shí)間等參數(shù)，避免 Tablet 下小文件的堆積。

查詢：

1. 增加 SQL 黑名單，控制異常大查詢。個(gè)別用戶在查詢時(shí)沒有加 where 條件，或者查詢時(shí)選擇的時(shí)間范圍較長(zhǎng)，這種情況下 BE 節(jié)點(diǎn)的 SQL 會(huì)把磁盤的負(fù)載和 CPU 拉高，導(dǎo)致其他節(jié)點(diǎn)的 SQL 查詢變慢，甚至出現(xiàn) BE 節(jié)點(diǎn)宕機(jī)的情況。目前的解決方案是使用 SQL 黑名單禁止全表及大量分區(qū)實(shí)時(shí)表的查詢。
2. 使用 SQL Cache 和 SQL Proxy 實(shí)現(xiàn)高并發(fā)訪問。同時(shí)使用 SQL Cache 和 SQL Proxy 的原因在于，SQL Cache的顆粒度到表的分區(qū)，如果數(shù)據(jù)發(fā)生變更， SQL Cache 將失效，因此 SQL Cache 緩存適合數(shù)據(jù)更新頻次較低的場(chǎng)景（離線場(chǎng)景、歷史分區(qū)等）。對(duì)于數(shù)據(jù)需要持續(xù)寫到最新分區(qū)的場(chǎng)景， SQL Cache 則是不適用的。當(dāng) SQL Cache 失效時(shí) Query 將全部發(fā)送到 Doris 造成重復(fù)的 Runtime 計(jì)算，而 SQL Proxy 可以設(shè)置一秒左右的緩存，可以避免相同條件的重復(fù)計(jì)算，有效提高集群的并發(fā)。

存儲(chǔ)：

使用 SSD 和 HDD 做熱溫?cái)?shù)據(jù)存儲(chǔ)周期的分離，近一年以內(nèi)的數(shù)據(jù)存在 SSD，超過一年的數(shù)據(jù)存在 HDD。Apache Doris 支持對(duì)分區(qū)設(shè)置冷卻時(shí)間，但只支持創(chuàng)建表分區(qū)時(shí)設(shè)置冷卻的時(shí)間，目前的解決方案是設(shè)置自動(dòng)同步邏輯，把歷史的一些數(shù)據(jù)從 SSD 遷移到 HDD，確保 1年內(nèi)的數(shù)據(jù)都放在 SSD 上。

升級(jí)：

升級(jí)前一定要備份元數(shù)據(jù)，也可以使用新開集群的方式，通過 Broker 將數(shù)據(jù)文件備份到 S3 或 HDFS 等遠(yuǎn)端存儲(chǔ)系統(tǒng)中，再通過備份恢復(fù)的方式將舊集群數(shù)據(jù)導(dǎo)入到新集群中。

升級(jí)前后性能對(duì)比

image.png

思必馳最早是從 0.12 版本開始使用 Apache Doris 的，在今年我們也完成了從 0.15 版本到最新 1.1 版本的升級(jí)操作，并進(jìn)行了基于真實(shí)業(yè)務(wù)場(chǎng)景和數(shù)據(jù)的性能測(cè)試。

從以上測(cè)試報(bào)告中可以看到，總共 13 個(gè)測(cè)試 SQL 中，前 3 個(gè) SQL 升級(jí)前后性能差異不明顯，因?yàn)檫@ 3 個(gè)場(chǎng)景主要是簡(jiǎn)單的聚合函數(shù)，對(duì) Apache Doris 性能要求不高，0.15 版本即可滿足需求。而在 Q4 之后的場(chǎng)景中 ，SQL 較為復(fù)雜，Group By 有多個(gè)字段、多個(gè)字段聚合函數(shù)以及復(fù)雜函數(shù)，因此升級(jí)新版本后帶來的性能提升非常明顯，平均查詢性能較 0.15 版本提升 2-3 倍。由此，非常推薦大家去升級(jí)到 Apache Doris 最新版本。

總結(jié)和收益

1. Apache Doris 支持構(gòu)建離線+實(shí)時(shí)統(tǒng)一數(shù)倉，一個(gè) ETL 腳本即可支持實(shí)時(shí)和離線數(shù)倉，大大縮短開發(fā)周期，降低存儲(chǔ)成本，避免了離線和實(shí)時(shí)指標(biāo)不一致等問題。
2. Apache Doris 1.1.x 版本開始全面支持向量化計(jì)算，較之前版本查詢性能提升 2-3 倍。經(jīng)測(cè)試，Apache Doris 1.1.x 版本在寬表場(chǎng)景的查詢性能已基本與 ClickHouse 持平。
3. 功能強(qiáng)大，不依賴其他組件。相比 Apache Kylin、Apache Druid、ClickHouse 等，Apache Doris 不需要引入第 2 個(gè)組件填補(bǔ)技術(shù)空檔。Apache Doris 支持聚合計(jì)算、明細(xì)查詢、關(guān)聯(lián)查詢，當(dāng)前思必馳超 90% 的分析需求已移步 Apache Doris實(shí)現(xiàn)。 得益于此優(yōu)勢(shì)，技術(shù)人員需要運(yùn)維的組件減少，極大降低運(yùn)維成本。
4. 易用性極高，支持 MySQL 協(xié)議和標(biāo)準(zhǔn) SQL，大幅降低用戶學(xué)習(xí)成本。

未來計(jì)劃

1. Tablet 小文件過多的問題。Tablet 是 Apache Doris 中讀寫數(shù)據(jù)最小的邏輯單元，當(dāng) Tablet 小文件比較多時(shí)會(huì)產(chǎn)生 2 個(gè)問題，一是 Tablet 小文件增多會(huì)導(dǎo)致元數(shù)據(jù)內(nèi)存壓力變大。二是對(duì)查詢性能的影響，即使是幾百兆的查詢，但在小文件有幾十萬、上百萬的情況下，一個(gè)小小的查詢也會(huì)導(dǎo)致 IO 非常高。未來，我們將做一個(gè) Tablet 文件數(shù)量/大小比值的監(jiān)控，當(dāng)比值在不合理范圍內(nèi)時(shí)及時(shí)進(jìn)行表設(shè)計(jì)的修改，使得文件數(shù)量和大小的比值在合理的范圍內(nèi)。
2. 支持基于 Bitmap 的字符串精確去重。業(yè)務(wù)中精確去重的場(chǎng)景較多，特別是基于字符串的 UV 場(chǎng)景，目前 Apache Doris 使用的是 Distinct 函數(shù)來實(shí)現(xiàn)的。未來我們會(huì)嘗試的在 Apache Doris 中創(chuàng)建字典，基于字典去構(gòu)建字符串的 Bitmap 索引。
3. Doris-Spark-Connector 流式寫入支持分塊傳輸。Doris-Spark-Connector 底層是復(fù)用的 Stream Load，工作機(jī)制是攢批，容易出現(xiàn)兩個(gè)問題，一是攢批可能會(huì)會(huì)出現(xiàn)內(nèi)存壓力導(dǎo)致 OOM，二是當(dāng)Doris-Spark-Connector 攢批時(shí)，Spark Checkpoint 沒有提交，但 Buffer 已滿并提交給 Doris，此時(shí) Apacche Doris 中已經(jīng)有數(shù)據(jù)，但由于沒有提交 Checkpoint，假如此時(shí)任務(wù)恰巧失敗，啟動(dòng)后又會(huì)重新消費(fèi)寫入一遍。未來我們將優(yōu)化此問題，實(shí)現(xiàn) Doris-Spark-Connector 流式寫入支持分塊傳輸。

更多資訊

近期，在 ClickHouse 發(fā)起的分析型數(shù)據(jù)庫性能測(cè)試排行榜 ClickBench 中，新一代云原生數(shù)倉 SelectDB 強(qiáng)勢(shì)登頂，性能表現(xiàn)超越一眾國(guó)內(nèi)外產(chǎn)品，多項(xiàng)指標(biāo)排行前列，并在業(yè)界最為通用的 c6a.4xlarge, 500gb gp2 機(jī)型下排行全球第一！

詳情請(qǐng)查看：https://mp.weixin.qq.com/s/7Gxl