每一個大數(shù)據(jù)團(tuán)隊可能都嘗試過市面上許多OLAP工具。以下內(nèi)容是一個汽車大數(shù)據(jù)團(tuán)隊對四個OLAP工具的看法，包括優(yōu)缺點和實際的OLAP經(jīng)驗。

一、將討論的OLAP工具

• Apache Druid（和Apache Kylin）
• TiDB
• ClickHouse
• Apache Doris

1.1 Apache Druid（和Apache Kylin）

回到2017年，在市場上尋找OLAP工具就像在非洲大草原上尋找樹一樣——寥寥無幾。目光鎖定在Apache Druid和Apache Kylin上。首先選擇了Druid，而Kylin雖然在預(yù)計算查詢效率上非常出色，但還是有一些缺點。

Kylin的缺點：

• Kylin的最佳存儲引擎為HBase，但引入HBase會帶來新的運維負(fù)擔(dān)。
• Kylin會預(yù)計算維度和指標(biāo)，但它帶來的維度爆炸會給存儲帶來很大壓力。

至于Apache Druid，它使用列式存儲，支持實時和離線數(shù)據(jù)攝取，并提供快速查詢。

但是Druid也有一些缺點：

• 不使用標(biāo)準(zhǔn)協(xié)議如JDBC等，因此對初學(xué)者不太友好。
• 對Join支持較弱。
• 精確去重可能較慢，從而影響性能。
• 由于組件眾多，需要各種安裝方法和依賴，因此需要大量維護(hù)工作。
• 數(shù)據(jù)攝取時需要改變Hadoop集成和JAR包依賴。

1.2 TiDB

嘗試TiDB后，它的優(yōu)缺點如下。

優(yōu)點：

• 是一個支持輕松更新的OLTP+OLAP數(shù)據(jù)庫。
• 具有大數(shù)據(jù)團(tuán)隊需要的功能，包括聚合和分組查詢、指標(biāo)計算和儀表板。
• 支持標(biāo)準(zhǔn)SQL，易于掌握。
• 維護(hù)要求不高。

缺點：

• TiFlash依賴OLTP，可能給存儲帶來更大壓力。作為非獨立OLAP，分析處理能力并不理想。
• 性能在不同場景下的表現(xiàn)參差不齊。

1.3 ClickHouse與Apache Doris的比較

接下來，對比研究ClickHouse和Apache Doris。

ClickHouse出色的獨立性能給此團(tuán)隊留下了深刻印象，但經(jīng)過研究發(fā)現(xiàn)它有以下缺點。

• 在多表Join方面無法滿足團(tuán)隊的需求(這是一個重要使用場景)。
• 并發(fā)性相對較低。
• 會帶來較高的運維成本。

相比之下，Apache Doris似乎更符合大數(shù)據(jù)團(tuán)隊的需求。

• 支持高并發(fā)查詢，這是大數(shù)據(jù)團(tuán)隊最大的關(guān)注點。
• 能夠同時處理實時和離線數(shù)據(jù)。
• 支持聚合和分組查詢。
• Unique模型(Doris中的一種數(shù)據(jù)模型，可確保鍵的唯一性)支持更新。
• 可以通過物化視圖大幅加速查詢。
• 兼容MySQL協(xié)議，開發(fā)和使用都很順暢。
• 查詢性能滿足需求。
• 運維要求簡單。

總之，Apache Doris似乎是Apache Druid+TiDB的理想替代方案。

二、OLAP實踐經(jīng)驗

下圖展示了OLAP系統(tǒng)中數(shù)據(jù)的流動方式：

圖片

2.1 數(shù)據(jù)源

此團(tuán)隊將業(yè)務(wù)系統(tǒng)、事件跟蹤、設(shè)備和車輛的數(shù)據(jù)匯集到大數(shù)據(jù)平臺。

2.2 數(shù)據(jù)導(dǎo)入

此團(tuán)隊為業(yè)務(wù)數(shù)據(jù)啟用CDC，這些數(shù)據(jù)的任何變化都會被轉(zhuǎn)換成數(shù)據(jù)流存儲在Kafka中，以便進(jìn)行流式計算。至于只能分批導(dǎo)入的數(shù)據(jù)，會直接進(jìn)入分布式存儲。

2.3 數(shù)據(jù)處理

他們采用Lambda架構(gòu)，而不是集成、流式和批處理。他們的業(yè)務(wù)現(xiàn)狀決定了他們的實時數(shù)據(jù)和離線數(shù)據(jù)來自不同的環(huán)節(jié)，特別是以下幾種情況。

• 部分?jǐn)?shù)據(jù)以流的形式出現(xiàn)。
• 部分?jǐn)?shù)據(jù)可以存儲在流中，而部分歷史數(shù)據(jù)不會存儲在Kafka中。
• 某些場景需要高數(shù)據(jù)精度，為此有一個離線管道可以重新計算并刷新所有相關(guān)數(shù)據(jù)。

2.4 數(shù)據(jù)倉庫

他們沒有使用Flink/Spark-Doris連接器，而是采用Routine Load從Flink向Doris傳輸數(shù)據(jù)，Broker Load從Spark向Doris傳輸數(shù)據(jù)。Flink和Spark生成的批數(shù)據(jù)會備份到Hive，以滿足其他場景的需求，這是提高數(shù)據(jù)利用率的方式。

2.5 數(shù)據(jù)服務(wù)

在數(shù)據(jù)服務(wù)層，通過數(shù)據(jù)源注冊和靈活配置實現(xiàn)API自動生成，從而可以通過API管理流量和權(quán)限。結(jié)合K8s無服務(wù)器解決方案，整個系統(tǒng)運行得很好。

2.6 數(shù)據(jù)應(yīng)用

在數(shù)據(jù)應(yīng)用層，此團(tuán)隊有兩類應(yīng)用場景。

• 面向用戶的場景，如儀表盤和指標(biāo)。
• 面向車輛的場景，將車載數(shù)據(jù)收集到Apache Doris進(jìn)行進(jìn)一步處理。即使經(jīng)過聚合，仍有以十億計的數(shù)據(jù)量，但總體計算性能已經(jīng)達(dá)標(biāo)。

三、CDP實踐

和大多數(shù)公司一樣，此團(tuán)隊也建立了他們自己的客戶數(shù)據(jù)平臺（customer data platform，CDP）。

圖片

通常情況下，CDP由以下幾個模塊組成：

• 標(biāo)簽（tags）：基礎(chǔ)的組成模塊，包括基本標(biāo)簽和客戶行為標(biāo)簽。也可以根據(jù)需要定義其他標(biāo)簽。
• 分組（groups）：根據(jù)標(biāo)簽將客戶劃分為不同的分組。
• 洞察（insights）：對每個客戶群體的特征進(jìn)行分析。
• 接觸（reach）：客戶接觸方式，包括短信、電話、APP通知和即時通訊。
• 效果分析（effect analysis）：對CDP運行情況的反饋。

此團(tuán)隊希望在CDP中實現(xiàn)實時+離線集成、快速分組、快速聚合、多表連接和聯(lián)合查詢。下面是具體實現(xiàn)這些功能的方法。

3.1 實時+離線

有實時標(biāo)簽和離線標(biāo)簽，需要將它們結(jié)合在一起使用。同時，對于同一份數(shù)據(jù)的不同列，更新頻率也可能不一樣。一些基本標(biāo)簽(客戶身份相關(guān))需要實時更新，而其他標(biāo)簽(年齡、性別)則可以每日更新。他們希望將客戶的所有基礎(chǔ)標(biāo)簽放在同一張表中，因為這樣可以減少維護(hù)成本，并且在添加自定義標(biāo)簽時大大減少所需表的數(shù)量。

為了實現(xiàn)這一點，使用Apache Doris的Routine Load方法更新實時數(shù)據(jù)，使用Broker Load方法批量導(dǎo)入離線數(shù)據(jù)，還可以利用這兩種方法分別更新同一張表的不同列。

3.2 快速分組

分組的本質(zhì)是將某些標(biāo)簽組合在一起，找到重疊數(shù)據(jù)。這可能會很復(fù)雜，Doris通過SIMD優(yōu)化加快了這一過程。

3.3 快速聚合

需要更新所有標(biāo)簽，重新計算客戶群體分布，并分析效果，這需要快速高效的處理。因此，他們根據(jù)時間將數(shù)據(jù)劃分為多個Tablet，以減少數(shù)據(jù)傳輸，提高計算速度。在計算客戶群體分布時，在每個節(jié)點預(yù)先聚合數(shù)據(jù)，然后收集它們進(jìn)行進(jìn)一步聚合。此外，Doris的向量化執(zhí)行引擎也大大提高了性能。

3.4 多表連接

由于此團(tuán)隊的基礎(chǔ)數(shù)據(jù)存儲在多個數(shù)據(jù)表中，因此當(dāng)CDP用戶自定義需要的標(biāo)簽時，需要進(jìn)行多表連接。Doris出色的多表連接能力是選擇它的一個重要因素。

3.5 聯(lián)合查詢

目前，此團(tuán)隊將客戶接觸相關(guān)記錄存儲在TiDB中，將積分和優(yōu)惠券等數(shù)據(jù)也在TiDB中處理，因為TiDB是一個更好的OLTP工具。對于更復(fù)雜的分析，如監(jiān)控客戶運營的有效性，需要整合任務(wù)執(zhí)行和目標(biāo)群體的信息，這就需要在Doris和TiDB之間進(jìn)行聯(lián)合查詢。

四、結(jié)論

這就是從Apache Druid、TiDB到Apache Doris（中間對ClickHouse進(jìn)行了短暫的了解）的轉(zhuǎn)變歷程，研究了各自的性能、SQL語義、系統(tǒng)兼容性和維護(hù)成本，最終形成了現(xiàn)在的OLAP架構(gòu)。如果你也面臨著和此團(tuán)隊類似的問題，這可能會為你提供一些參考。