每一個大數據團隊可能都嘗試過市面上許多OLAP工具。以下內容是一個汽車大數據團隊對四個OLAP工具的看法，包括優缺點和實際的OLAP經驗。

一、將討論的OLAP工具

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

1.1 Apache Druid（和Apache Kylin）

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

Kylin的缺點：

• Kylin的最佳存儲引擎為HBase，但引入HBase會帶來新的運維負擔。
• Kylin會預計算維度和指標，但它帶來的維度爆炸會給存儲帶來很大壓力。

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

但是Druid也有一些缺點：

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

1.2 TiDB

嘗試TiDB后，它的優缺點如下。

優點：

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

缺點：

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

1.3 ClickHouse與Apache Doris的比較

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

ClickHouse出色的獨立性能給此團隊留下了深刻印象，但經過研究發現它有以下缺點。

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

相比之下，Apache Doris似乎更符合大數據團隊的需求。

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

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

二、OLAP實踐經驗

下圖展示了OLAP系統中數據的流動方式：

圖片

2.1 數據源

此團隊將業務系統、事件跟蹤、設備和車輛的數據匯集到大數據平臺。

2.2 數據導入

此團隊為業務數據啟用CDC，這些數據的任何變化都會被轉換成數據流存儲在Kafka中，以便進行流式計算。至于只能分批導入的數據，會直接進入分布式存儲。

2.3 數據處理

他們采用Lambda架構，而不是集成、流式和批處理。他們的業務現狀決定了他們的實時數據和離線數據來自不同的環節，特別是以下幾種情況。

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

2.4 數據倉庫

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

2.5 數據服務

在數據服務層，通過數據源注冊和靈活配置實現API自動生成，從而可以通過API管理流量和權限。結合K8s無服務器解決方案，整個系統運行得很好。

2.6 數據應用

在數據應用層，此團隊有兩類應用場景。

• 面向用戶的場景，如儀表盤和指標。
• 面向車輛的場景，將車載數據收集到Apache Doris進行進一步處理。即使經過聚合，仍有以十億計的數據量，但總體計算性能已經達標。

三、CDP實踐

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

圖片

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

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

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

3.1 實時+離線

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

為了實現這一點，使用Apache Doris的Routine Load方法更新實時數據，使用Broker Load方法批量導入離線數據，還可以利用這兩種方法分別更新同一張表的不同列。

3.2 快速分組

分組的本質是將某些標簽組合在一起，找到重疊數據。這可能會很復雜，Doris通過SIMD優化加快了這一過程。

3.3 快速聚合

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

3.4 多表連接

由于此團隊的基礎數據存儲在多個數據表中，因此當CDP用戶自定義需要的標簽時，需要進行多表連接。Doris出色的多表連接能力是選擇它的一個重要因素。

3.5 聯合查詢

目前，此團隊將客戶接觸相關記錄存儲在TiDB中，將積分和優惠券等數據也在TiDB中處理，因為TiDB是一個更好的OLTP工具。對于更復雜的分析，如監控客戶運營的有效性，需要整合任務執行和目標群體的信息，這就需要在Doris和TiDB之間進行聯合查詢。

四、結論

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