深度比較Druid、TiDB、ClickHouse、Doris四大OLAP工具
每一個大數據團隊可能都嘗試過市面上許多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架構。如果你也面臨著和此團隊類似的問題，這可能會為你提供一些參考。
