從一個OLAP數(shù)據(jù)庫遷移到另一個數(shù)據(jù)庫是一項艱巨的工程。即使能找到一些有用的數(shù)據(jù)工具，您可能仍會猶豫是否對數(shù)據(jù)架構(gòu)進行大手術(shù)，因為不確定如何運作。
本文分享如何從ClickHouse遷移到Doris的過程，包括為什么需要更改，需要注意什么以及如何比較兩個數(shù)據(jù)庫在各自環(huán)境中的性能。
1 使用Doris替換Kylin、ClickHouse和Druid
這里有一家電子商務(wù)SaaS提供商，其數(shù)據(jù)系統(tǒng)提供實時和離線報告、客戶分割和日志分析服務(wù)。最初，他們?yōu)檫@些不同的目的使用了不同的OLAP引擎：
- Apache Kylin用于離線報告：該系統(tǒng)為超過500萬個賣家提供離線報告服務(wù)。其中的大型賣家擁有超過1000萬注冊會員和100,000個SKU，詳細(xì)信息放在平臺上的400多個數(shù)據(jù)立方體中。
- ClickHouse用于客戶分割和Top-N日志查詢：這需要高頻更新、高QPS和復(fù)雜的SQL。
- Apache Druid用于實時報告：賣家通過組合不同的維度提取所需的數(shù)據(jù)，這種實時報告需要快速的數(shù)據(jù)更新、快速的查詢響應(yīng)和系統(tǒng)的強大穩(wěn)定性。
這三個組件都有各自的痛點：
- Apache Kylin在固定表模式下運行良好，但每次添加維度時，需要創(chuàng)建一個新的數(shù)據(jù)立方體并在其中重新填充歷史數(shù)據(jù)。
- ClickHouse不適用于多表處理，因此需要額外的解決方案來進行聯(lián)合查詢和多表連接查詢。在高并發(fā)場景下，它的表現(xiàn)低于預(yù)期。
- Apache Druid實現(xiàn)了冪等寫入，因此它本身不支持?jǐn)?shù)據(jù)更新或刪除。這意味著當(dāng)上游出現(xiàn)問題時，需要進行完整的數(shù)據(jù)替換。如果您從頭到尾考慮所有數(shù)據(jù)備份和移動，這樣的數(shù)據(jù)修復(fù)是一個多步驟的過程。此外，新攝入的數(shù)據(jù)在放入Druid中的段之前將無法用于查詢。這意味著存在更長的時間窗口，從而導(dǎo)致上下游之間的數(shù)據(jù)不一致。
由于它們共同工作，這種架構(gòu)可能太難以導(dǎo)航，因為它需要在開發(fā)、監(jiān)控和維護方面了解所有這些組件。此外，每次用戶擴展集群時，他們必須停止當(dāng)前集群并遷移所有數(shù)據(jù)庫和表，這不僅是一個巨大的任務(wù)，而且會對業(yè)務(wù)造成巨大的干擾。
圖片
Apache Doris填補了這些空白。
- 查詢性能：Doris擅長高并發(fā)查詢和連接查詢，并且現(xiàn)在配備了倒排索引以加速日志搜索。
- 數(shù)據(jù)更新：Doris的唯一鍵模型支持大容量更新和高頻實時寫入，而重復(fù)鍵模型和唯一鍵模型支持部分列更新。它還提供數(shù)據(jù)寫入的恰好一次保證，并確保基表、物化視圖和副本之間的一致性。
- 維護：Doris與MySQL兼容。它支持輕松擴展和輕量級模式更改。它配備了自己的集成工具，如Flink-Doris-Connector和Spark-Doris-Connector。
因此，計劃進行遷移。
2 替換手術(shù)
ClickHouse是舊數(shù)據(jù)架構(gòu)中的主要性能瓶頸，也是最初想要進行更改的原因，因此從ClickHouse開始。
2.1 SQL語句的更改
表創(chuàng)建語句
圖片
這里構(gòu)建了自己的SQL重寫工具，可以將ClickHouse表創(chuàng)建語句轉(zhuǎn)換為Doris表創(chuàng)建語句。該工具可以自動執(zhí)行以下更改：
- 映射字段類型：它將ClickHouse字段類型轉(zhuǎn)換為Doris中對應(yīng)的字段類型。例如，它將String作為Key轉(zhuǎn)換為Varchar，將String作為分區(qū)字段轉(zhuǎn)換為Date V2。
- 在動態(tài)分區(qū)表中設(shè)置歷史分區(qū)的數(shù)量：某些表具有歷史分區(qū)，應(yīng)在Doris表創(chuàng)建時指定分區(qū)數(shù)，否則將拋出“無分區(qū)”錯誤。
- 確定桶的數(shù)量：它根據(jù)歷史分區(qū)的數(shù)據(jù)量來決定桶的數(shù)量；對于非分區(qū)表，它根據(jù)歷史數(shù)據(jù)量來確定桶的配置。
- 確定TTL：它確定動態(tài)分區(qū)表中分區(qū)的生存時間。
- 設(shè)置導(dǎo)入順序：對于Doris的唯一鍵模型，它可以根據(jù)Sequence列指定數(shù)據(jù)導(dǎo)入順序，以確保數(shù)據(jù)攝入的有序性。
圖片
查詢語句
同樣，也有工具可以將ClickHouse查詢語句轉(zhuǎn)換為Doris查詢語句。這是為了準(zhǔn)備ClickHouse和Doris之間的比較測試。轉(zhuǎn)換中的關(guān)鍵考慮因素包括：
- 表名的轉(zhuǎn)換：這很簡單，只需按照表創(chuàng)建語句中的映射規(guī)則進行即可。
- 函數(shù)的轉(zhuǎn)換：例如，ClickHouse中的
COUNTIF函數(shù)等價于SUM(CASE WHEN_THEN 1 ELSE 0)，Array Join等價于Explode和Lateral View，而ORDER BY和GROUP BY應(yīng)轉(zhuǎn)換為窗口函數(shù)。 - 語義上的差異：ClickHouse按照自己的協(xié)議進行操作，而Doris兼容MySQL，因此需要為子查詢設(shè)置別名。在這種情況下，子查詢在客戶分割中很常見，因此他們使用
sqlparse。
2.2 數(shù)據(jù)攝入方法的變化
圖片
Apache Doris提供了廣泛的數(shù)據(jù)寫入方法。對于實時鏈接，采用Stream Load從NSQ和Kafka攝取數(shù)據(jù)。
對于大型離線數(shù)據(jù)，測試了不同的方法，以下是結(jié)論：
- Insert Into 使用Multi-Catalog讀取外部數(shù)據(jù)源并使用Insert Into進行攝取可以滿足此用例中的大多數(shù)需求。
- Stream Load
Spark-Doris-Connector是一種更通用的方法。它可以處理大量數(shù)據(jù)并確保寫入穩(wěn)定性。關(guān)鍵是找到正確的寫入速度和并行性。
Spark-Doris-Connector還支持Bitmap。它允許您將Bitmap數(shù)據(jù)的計算工作負(fù)載移動到Spark集群中。
Spark-Doris-Connector和Flink-Doris-Connector都依賴于Stream Load。CSV是推薦的格式選擇。用戶的數(shù)十億行測試表明，CSV比JSON快40%。
- Spark Load
Spark Load方法利用Spark資源進行數(shù)據(jù)洗牌和排名。計算結(jié)果放在HDFS中，然后Doris直接從HDFS讀取文件（通過Broker Load）。這種方法非常適合大規(guī)模數(shù)據(jù)攝入。數(shù)據(jù)越多，攝入速度越快，資源利用率越高。
3 壓力測試
這里比較了兩個組件在SQL和連接查詢方案上的性能，并計算了Apache Doris的CPU和內(nèi)存消耗。
3.1 SQL查詢性能
Apache Doris在16個SQL查詢中的10個中表現(xiàn)優(yōu)于ClickHouse，最大的性能差距比例接近30。總體而言，Apache Doris比ClickHouse快2~3倍。
圖片
3.2 連接查詢性能
對于連接查詢測試，使用了不同大小的主表和維表。
- 主表：用戶活動表（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比ClickHouse快10倍以上；對于大于1億行的維表，ClickHouse會拋出OOM錯誤，而Doris則正常運行。
主表（250億行）：
- 完全連接查詢：Doris在所有維表的完全連接查詢中均優(yōu)于ClickHouse。ClickHouse在維表大于5000萬行時會產(chǎn)生OOM錯誤。
- 過濾連接查詢：過濾器從主表中篩選出了5.7億行。Doris在幾秒鐘內(nèi)響應(yīng)，而ClickHouse在連接大型維表時完成時間為幾分鐘，并在此過程中崩潰。
主表（960億行）：
Doris在所有查詢中都表現(xiàn)出相對較快的性能，而ClickHouse無法執(zhí)行所有查詢。
在CPU和內(nèi)存消耗方面，Apache Doris在所有大小的連接查詢中都保持穩(wěn)定的集群負(fù)載。
