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

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

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

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

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

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

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

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

image.png

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

我們業(yè)務(wù)場景的數(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í)時部分鏈路較短攀细，經(jīng)過 Kafka 緩沖完的數(shù)據(jù)通過 Spark 計算后放入 MySQL 中進(jìn)行分析箫踩，對于早期的實(shí)時分析需求，MySQL 基本可以滿足分析需求谭贪。而離線部分則由 Spark 進(jìn)行數(shù)據(jù)清洗及計算后在 Hive 中構(gòu)建離線數(shù)倉境钟，并使用 Apache Kylin 構(gòu)建 Cube，在構(gòu)建 Cube 之前需要提前做好數(shù)據(jù)模型的的設(shè)計俭识，包括關(guān)聯(lián)表慨削、維度表、指標(biāo)字段套媚、指標(biāo)需要的聚合函數(shù)等缚态，通過調(diào)度系統(tǒng)進(jìn)行定時觸發(fā)構(gòu)建，最終使用 HBase 存儲構(gòu)建好的 Cube堤瘤。

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

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

早期架構(gòu)解決了當(dāng)時業(yè)務(wù)中較為緊迫的查詢性能問題，但隨著業(yè)務(wù)的發(fā)展地梨，對數(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ā)鏈路較長捌显，架構(gòu)穩(wěn)定性隱患多扶歪，維護(hù)成本比很高善镰。
2. Kylin 的構(gòu)建過程復(fù)雜炫欺，構(gòu)建任務(wù)容易失敗。Kylin 構(gòu)建需要進(jìn)行打?qū)挶砟ν啊⑷ブ亓懈ㄕ濉⑸勺值涫快瑯?gòu)建 Cube 等如果每天有 1000-2000 個甚至更多的任務(wù)酵幕，其中至少會有 10 個甚至更多任務(wù)構(gòu)建失敗裙盾，導(dǎo)致需要大量時間去寫自動運(yùn)維腳本庐完。
3. 維度/字典膨脹嚴(yán)重门躯。維度膨脹指的是在某些業(yè)務(wù)場景中需要多個分析條件和字段讶凉，如果在數(shù)據(jù)分析模型中選擇了很多字段而沒有進(jìn)行剪枝懂讯，則會導(dǎo)致 Cube 維度膨脹嚴(yán)重褐望，構(gòu)建時間變長瘫里。而字典膨脹指的是在某些場景中需要長時間做全局精確去重谨读，會使得字典構(gòu)建越來越大劳殖，構(gòu)建時間也會越來越長闷尿，從而導(dǎo)致數(shù)據(jù)分析性能持續(xù)下降谬晕。
4. 數(shù)據(jù)分析模型固定誉简，靈活性較低。在實(shí)際應(yīng)用過程中瓮钥，如果對計算字段或者業(yè)務(wù)場景進(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)化方案，先后對市面上應(yīng)用最為廣泛的 Apache Doris橙喘、Clickhouse 等 OLAP 引擎進(jìn)行選型調(diào)研饰潜。相較于 ClickHouse 的繁重運(yùn)維彭雾、各種各樣的表類型薯酝、不支持關(guān)聯(lián)查詢等，結(jié)合我們的 OLAP 分析場景中的需求者填，綜合考慮幔托，Apache Doris 表現(xiàn)較為優(yōu)秀重挑，最終決定引入 Apache Doris 谬哀。

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

image.png

如上圖所示，我們基于 Apache Doris 構(gòu)建了實(shí)時+離線一體的新數(shù)倉架構(gòu)篇梭，與早期架構(gòu)不同的是恬偷，實(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ù)倉沮翔。

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

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

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

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

問題和挑戰(zhàn)：

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

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

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

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

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

image.png

首先是實(shí)時運(yùn)營業(yè)務(wù)場景栈雳，如上圖所示护奈，實(shí)時運(yùn)營業(yè)務(wù)場景的技術(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ù)據(jù)導(dǎo)入使用 Doris-Spark-Connector 。
• 數(shù)據(jù)存儲與開發(fā)：幾乎所有的實(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)營的實(shí)時看板建椰、用戶畫像、BI 看板等岛马。

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

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

自助/對話式分析場景

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

image.png

如上圖所示沟蔑，在一般的 BI 場景中湿诊，用戶方比如商務(wù)、財務(wù)瘦材、銷售厅须、運(yùn)營、項(xiàng)目經(jīng)理等會提出需求給數(shù)據(jù)分析人員食棕，數(shù)據(jù)分析人員在 BI 平臺上做數(shù)據(jù)看板朗和，最終把看板提供給用戶，用戶從 BI 看板上獲取所需信息簿晓，但是有時候用戶想要查看明細(xì)數(shù)據(jù)眶拉、定制化的看板需求，或者在某些場景需做任意維度的上卷或者下鉆的分析憔儿，一般場景下 BI 看板是不支持的的忆植，基于以上所述用戶需求，我們打造了自助對話式 BI 場景來解決用戶定制化的需求谒臼。

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

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

• 查詢靈活肖爵，模型不固定，支持自由定制場景臀脏。
• 支持表關(guān)聯(lián)劝堪、聚合計算、明細(xì)查詢揉稚。
• 響應(yīng)時間要快速秒啦。

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

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

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

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

1. 千萬級(量級供參考暴氏，跟集群規(guī)模有關(guān)系)以下的數(shù)據(jù)表使用 Duplicate 表類型延塑，Duplicate 表類型同時支持聚合、明細(xì)查詢答渔，不需要額外寫明細(xì)表关带。
2. 當(dāng)數(shù)據(jù)量比較大時，使用 Aggregate 聚合表類型沼撕，在聚合表類型上做上卷索引，使用物化視圖優(yōu)化查詢务豺、優(yōu)化聚合字段。由于 Aggregate 表類型是預(yù)計算表笼沥，會丟失明細(xì)數(shù)據(jù)娶牌，如有明細(xì)查詢需求馆纳，需要額外寫一張明細(xì)表。
3. 當(dāng)數(shù)據(jù)量又大鲁驶、關(guān)聯(lián)表又多時鉴裹，可用 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í)時寫入 BE 節(jié)點(diǎn)， Routine Load 的工作原理是通過 SQL 在 FE 節(jié)點(diǎn)起一個類似于 Task Manager 的管理寿羞，把任務(wù)分發(fā)給 BE 節(jié)點(diǎn)猖凛，在 BE 節(jié)點(diǎn)起 Routine Load 任務(wù)。在我們實(shí)時場景并發(fā)很高的情況下绪穆，BE 節(jié)點(diǎn) CPU 峰值一般會達(dá)到 70% 左右辨泳，在這個前提下，Routine Load 也跑到 BE 節(jié)點(diǎn)玖院，將嚴(yán)重影響 BE 節(jié)點(diǎn)的查詢性能菠红，并且查詢 CPU 也將影響 Routine Load 導(dǎo)入， Routine Load 就會因?yàn)楦鞣N資源競爭死掉难菌。面對此問題试溯，目前解決方法是將 Routine Load 從 BE 節(jié)點(diǎn)拿出來放到資源調(diào)度上，用 Doris-Spark/Flink-Connector 替換 Routine Load郊酒。當(dāng)時 Doris-spark-Connector 還沒有實(shí)時寫入的功能遇绞，我們根據(jù)業(yè)務(wù)需求進(jìn)行了優(yōu)化，并將方案貢獻(xiàn)給社區(qū)燎窘。
2. 通過攢批來控制實(shí)時寫入頻率：當(dāng)實(shí)時寫入頻率較高時摹闽，小文件堆積過多、查詢 IO 升高褐健，小文件排序歸并的過程將導(dǎo)致查詢時間加長付鹿，進(jìn)而出現(xiàn)查詢抖動的情況。當(dāng)前的解決辦法是控制導(dǎo)入頻次蚜迅，調(diào)整 Compaction 的合并線程舵匾、間隔時間等參數(shù)，避免 Tablet 下小文件的堆積谁不。

查詢：

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

存儲：

使用 SSD 和 HDD 做熱溫數(shù)據(jù)存儲周期的分離芒涡，近一年以內(nèi)的數(shù)據(jù)存在 SSD卖漫，超過一年的數(shù)據(jù)存在 HDD羊始。Apache Doris 支持對分區(qū)設(shè)置冷卻時間突委，但只支持創(chuàng)建表分區(qū)時設(shè)置冷卻的時間，目前的解決方案是設(shè)置自動同步邏輯闷旧，把歷史的一些數(shù)據(jù)從 SSD 遷移到 HDD忙灼，確保 1年內(nèi)的數(shù)據(jù)都放在 SSD 上该园。

升級：

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

升級前后性能對比

image.png

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

從以上測試報告中可以看到幕垦，總共 13 個測試 SQL 中先改，前 3 個 SQL 升級前后性能差異不明顯蒸走，因?yàn)檫@ 3 個場景主要是簡單的聚合函數(shù)比驻，對 Apache Doris 性能要求不高别惦，0.15 版本即可滿足需求。而在 Q4 之后的場景中 氯庆，SQL 較為復(fù)雜堤撵，Group By 有多個字段实昨、多個字段聚合函數(shù)以及復(fù)雜函數(shù)荒给，因此升級新版本后帶來的性能提升非常明顯志电，平均查詢性能較 0.15 版本提升 2-3 倍长酗。由此夺脾，非常推薦大家去升級到 Apache Doris 最新版本咧叭。

總結(jié)和收益

1. Apache Doris 支持構(gòu)建離線+實(shí)時統(tǒng)一數(shù)倉，一個 ETL 腳本即可支持實(shí)時和離線數(shù)倉吉挣，大大縮短開發(fā)周期睬魂，降低存儲成本镀赌，避免了離線和實(shí)時指標(biāo)不一致等問題喉钢。
2. Apache Doris 1.1.x 版本開始全面支持向量化計算良姆，較之前版本查詢性能提升 2-3 倍玛追。經(jīng)測試伯复，Apache Doris 1.1.x 版本在寬表場景的查詢性能已基本與 ClickHouse 持平邢笙。
3. 功能強(qiáng)大氮惯，不依賴其他組件妇汗。相比 Apache Kylin杨箭、Apache Druid捣郊、ClickHouse 等呛牲，Apache Doris 不需要引入第 2 個組件填補(bǔ)技術(shù)空檔。Apache Doris 支持聚合計算着茸、明細(xì)查詢涮阔、關(guān)聯(lián)查詢澎语，當(dāng)前思必馳超 90% 的分析需求已移步 Apache Doris實(shí)現(xiàn)擅羞。 得益于此優(yōu)勢义图，技術(shù)人員需要運(yùn)維的組件減少娃承，極大降低運(yùn)維成本怕篷。
4. 易用性極高廊谓，支持 MySQL 協(xié)議和標(biāo)準(zhǔn) SQL蒸痹，大幅降低用戶學(xué)習(xí)成本叠荠。

未來計劃

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

更多資訊

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

詳情請查看：https://mp.weixin.qq.com/s/7Gxl