從ClickHouse遷移到Apache Doris后發(fā)生了什么？

作者：布加迪 2023-11-02 08:00:00

不妨了解從ClickHouse遷移到Apache Doris的過程，看看這是否適合您和您的數(shù)據(jù)。

譯者 | 布加迪

審校 | 重樓

從一個OLAP數(shù)據(jù)庫遷移到另一個OLAP數(shù)據(jù)庫是個大工程。即使您對當(dāng)前的數(shù)據(jù)工具不滿意，并且已經(jīng)找到了一些大有前途的候選工具，可能仍然會猶豫是否要對數(shù)據(jù)架構(gòu)進(jìn)行一番大動作，因?yàn)槟淮_定事情會如何進(jìn)展。所以您需要過來人分享一下經(jīng)驗(yàn)。

幸運(yùn)的是，Apache Doris的一個用戶已經(jīng)撰文寫下了從ClickHouse遷移到Doris的過程，包括他們?yōu)槭裁葱枰?/span>遷移，需要注意什么，以及如何在環(huán)境中比較兩種數(shù)據(jù)庫的性能。

為了要決定是否繼續(xù)讀下去，請檢查您是否符合以下其中一項(xiàng)：

您需要更快地執(zhí)行連接查詢
您需要靈活的數(shù)據(jù)更新
您需要實(shí)時數(shù)據(jù)分析
您需要最小化組件

如果符合上述任何一項(xiàng)，本文對您可能會有所幫助。

把Kylin、ClickHouse和Druid換成Apache Doris

經(jīng)歷這番變化的用戶是一家電子商務(wù)SaaS提供商。其數(shù)據(jù)系統(tǒng)提供實(shí)時和離線報告、客戶細(xì)分以及日志分析。最初，他們?yōu)檫@些不同的目的使用不同的OLAP引擎：

用于離線報告的Apache Kylin：該系統(tǒng)為500余萬賣家提供離線報告服務(wù)。其中規(guī)模較大的賣家有1000余萬注冊會員和100000個單品，詳細(xì)信息被存儲在該平臺上的400多個數(shù)據(jù)立方體（Data Cube）中。
用于客戶細(xì)分和Top-N日志查詢的ClickHouse：這需要高頻更新、每秒查詢（QPS）次數(shù)高以及復(fù)雜的SQL。
用于實(shí)時報告的Apache Druid：賣家通過結(jié)合不同的維度提取自己需要的數(shù)據(jù)，這種實(shí)時報告需要數(shù)據(jù)更新快速、查詢響應(yīng)迅速和系統(tǒng)極其穩(wěn)定。

圖1. 這三大部分有各自的痛點(diǎn)

面對固定的表模式，Apache Kylin可以很好地運(yùn)行。但每當(dāng)您想要添加一個維度，就需要創(chuàng)建一個新的數(shù)據(jù)立方體，并往里面重新填充歷史數(shù)據(jù)。
ClickHouse不是為多表處理而設(shè)計(jì)的，因此您可能需要為聯(lián)合查詢和多表連接查詢提供另外的解決方案。而在本文這個例子中，它在高并發(fā)場景下未達(dá)到預(yù)期。
Apache Druid實(shí)現(xiàn)了冪等寫入，因此它本身不支持?jǐn)?shù)據(jù)更新或刪除。這意味著當(dāng)上游出現(xiàn)問題時，您將需要完整的數(shù)據(jù)替換。如果您考慮到所有的數(shù)據(jù)備份和移動，這種數(shù)據(jù)修復(fù)是一個涉及多步驟的過程。此外，新攝取的數(shù)據(jù)將無法供查詢訪問，除非它被放在Druid的片段中。這意味著窗口較長，從而使得上游和下游之間的數(shù)據(jù)不一致。

當(dāng)這些組件協(xié)同工作時，這個架構(gòu)可能要求太高而無法導(dǎo)航，因?yàn)樗枰陂_發(fā)、監(jiān)控和維護(hù)方面了解所有這些組件。此外，每當(dāng)用戶擴(kuò)展集群，必須停止當(dāng)前集群，并遷移所有數(shù)據(jù)庫和表，這不僅僅是一項(xiàng)大工程，還會嚴(yán)重干擾業(yè)務(wù)的正常運(yùn)營。

圖2. Apache Doris填補(bǔ)了這些空白

查詢性能：Doris擅長高并發(fā)查詢和連接查詢，現(xiàn)在它配備了一個反向索引，以加速日志中的搜索。
數(shù)據(jù)更新：Doris的獨(dú)特鍵（Unique Key）模型支持大容量更新和高頻實(shí)時寫入，重復(fù)鍵（Duplicate Key）模型和獨(dú)特鍵模型支持部分列更新。它還在數(shù)據(jù)寫入時提供了精確一次（exact-once）保證，并確保基礎(chǔ)表、物化視圖和副本之間的一致性。
維護(hù)：Doris與MySQL兼容。它支持簡易擴(kuò)展和輕量級模式更改。它自帶集成工具，比如Flink-Doris-Connector和Spark-Doris-Connector。

于是他們計(jì)劃遷移。

替換過程

ClickHouse是舊數(shù)據(jù)架構(gòu)的主要性能瓶頸，也是用戶最初希望改變的原因，于是他們開始從ClickHouse入手。

SQL語句的變化

表創(chuàng)建語句

圖3

用戶構(gòu)建了自己的SQL重寫工具，該工具可以將ClickHouse表創(chuàng)建語句轉(zhuǎn)換成Doris表創(chuàng)建語句。該工具可以自動執(zhí)行以下更改：

映射字段類型：它將ClickHouse字段類型轉(zhuǎn)換成Doris中相應(yīng)的字段類型。比如說，它將作為鍵字段的String轉(zhuǎn)換成Varchar，將作為分區(qū)字段的String轉(zhuǎn)換成Date V2。
設(shè)置動態(tài)分區(qū)表中的歷史分區(qū)數(shù)：一些表有歷史分區(qū)，在Doris中創(chuàng)建表時應(yīng)該指定分區(qū)數(shù)，否則將會拋出“無分區(qū)”錯誤。
確定存儲桶數(shù)：根據(jù)歷史分區(qū)的數(shù)據(jù)量確定存儲桶數(shù)；針對非分區(qū)表，它根據(jù)歷史數(shù)據(jù)量確定存儲桶配置。
確定TTL：它確定動態(tài)分區(qū)表中分區(qū)的存活時間。
設(shè)置導(dǎo)入順序：針對Doris的獨(dú)特鍵模型，可以根據(jù)序列這列指定數(shù)據(jù)導(dǎo)入順序，以確保數(shù)據(jù)攝取的有序性。

圖4

查詢語句

同樣，他們有自己的工具將ClickHouse查詢語句轉(zhuǎn)換成Doris查詢語句。這是為ClickHouse和Doris的對比測試做準(zhǔn)備。轉(zhuǎn)換中的關(guān)鍵考慮因素包括如下：

表名的轉(zhuǎn)換：根據(jù)表創(chuàng)建語句中的映射規(guī)則，這很簡單。
函數(shù)的轉(zhuǎn)換：比如說，ClickHouse中的COUNTIF函數(shù)相當(dāng)于SUM(CASE WHEN_THEN 1 ELSE 0)，Array Join相當(dāng)于Explode和Lateral View，而ORDER BY和GROUP BY應(yīng)該轉(zhuǎn)換成窗口函數(shù)。
語義上的區(qū)別：ClickHouse使用自己的協(xié)議，而Doris與MySQL兼容，所以子查詢需要有一個別名。在這個用例中，子查詢在客戶細(xì)分中很常見，因此它們使用sqlparse。

數(shù)據(jù)攝取方法的變化

圖5

Apache Doris為數(shù)據(jù)寫入方法提供了眾多選項(xiàng)。對于實(shí)時鏈路，用戶采用Stream Load從NSQ和Kafka中攝取數(shù)據(jù)。

針對龐大的離線數(shù)據(jù)，用戶測試了不同的方法，以下是一些建議：

1. Insert Into

使用Multi-Catalog讀取外部數(shù)據(jù)源，并使用Insert Into攝取數(shù)據(jù)，可以滿足該用例中的大多數(shù)需求。

2. Stream Load

Spark-Doris-Connector是一種更通用的方法。它可以處理龐大數(shù)據(jù)量，保證寫入穩(wěn)定性。關(guān)鍵在于找到合適的寫入節(jié)奏和并發(fā)處理。

Spark-Doris-Connector還支持位圖。它允許您在Spark集群中移動位圖數(shù)據(jù)的計(jì)算工作負(fù)載。

Spark-Doris-Connector和Flink-Doris-Connector都依賴Stream Load。CSV是推薦的格式選擇。針對該用戶數(shù)十億行的測試表明，CSV比JSON快40%。

3. Spark Load

Spark Load方法利用Spark資源進(jìn)行數(shù)據(jù)混排和排序。計(jì)算結(jié)果放在HDFS中，然后Doris直接從HDFS中讀取文件（通過Broker Load）。這種方法非常適合大量數(shù)據(jù)的攝取。數(shù)據(jù)越多，攝取的速度越快，資源效率也越高。

壓力測試

用戶比較了兩個組件在SQL連接查詢場景下的性能，并計(jì)算了Apache Doris的CPU和內(nèi)存消耗情況。

SQL查詢性能

就性能而言，Apache Doris在16個SQL查詢中有10個優(yōu)于ClickHouse，性能最多相差近30倍。總的來說，Apache Doris比ClickHouse快2~3倍。

圖6

連接查詢性能

針對連接查詢測試，該用戶使用了不同大小的主表和維度表。

主表：用戶活動表（40億行）、用戶屬性表（250億行）和用戶屬性表（960億行）。
維度表：100萬行、1000萬行、5000萬行、1億行、5億行、10億行和25億行。

測試包括全連接查詢和過濾連接查詢。全連接查詢連接主表和維度表的所有行，而過濾連接查詢使用WHERE過濾器檢索某個賣家ID的數(shù)據(jù)。研究結(jié)果如下：

主表（40億行）：

全連接查詢：Doris在所有維度表的全連接查詢中性能優(yōu)于ClickHouse。性能差距隨著維度表的增大而增大，最多相差5倍。
過濾連接查詢：基于賣家ID，過濾器從主表中篩選出4100萬行。針對小型維度表，Doris的速度比ClickHouse快2~3倍；針對大型維度表，Doris的速度要快十倍以上；針對大于1億行的維度表，ClickHouse拋出了OOM錯誤，而Doris可以正常運(yùn)行。

主表（250億行）：

全連接查詢：Doris在所有維度表的全連接查詢中性能優(yōu)于ClickHouse。ClickHouse在維度表大于5000萬行的情況下拋出了OOM錯誤。
過濾連接查詢：過濾器從主表中篩選出5.7億行。Doris在幾秒鐘內(nèi)做出響應(yīng)，ClickHouse在幾分鐘內(nèi)完成，在連接大型維度表時出現(xiàn)了崩潰。