為什麼需要OLAP DSL？

• 2019 年 10 月 3 日
• 筆記

OLAP（On-Line Analytical Processing，聯機分析處理）是大數據場景中，數據價值探索與挖掘的重要環節。這個領域內，開源社區呈現百花齊放的現象，Elasticsearch、Druid、Clickhouse、Pinot、Kylin、Presto等，各自在業界都有著廣泛的應用場景。實際使用過程中，通常會經歷以下三個階段：

• 業務初期，面臨多種選擇，如何做技術選型？這時場景較單一，需要解決的問題相對固定，這時簡單比較下開源組件各自的特性，參考下業界的使用情況；再或者部署測試環境，模擬業務驗證；通常都能夠選取出其中一個組件，投入實際生產環境；

• 業務中期，隨著數據需求的不斷豐富變化，開源組件需要支撐的應用場景也越來越多，比如：多維統計查詢、可視化、報表、監控報警等；本質上，不管是什麼樣的開源組件，還是為解決「某一類」場景問題設計實現的，這種「大而全」的一站式打包服務是完全不能夠勝任的；隨著時間推移，服務自身特性的局限與日益豐富的需求場景之間的矛盾愈演愈烈，解決方案也比較簡單：嘗試引入多個開源組件；

• 業務後期，大家會不約而同地處於這樣的一個現狀：生產環境中運行著多個開源組件，服務於業務場景中的多個需求；

 
綜上所述，使用某一個組件，寄希望於它能夠應對各種需求（「All In One」）的方式是不可行的，每種組件各有利弊，有的擅長檢索，有的擅長統計；最好的方式是結合實際需求，選取若干個合適的組件，每個組件服務於自身最適用的業務場景。

 
既然是「最好的方式」，且需求已經得到解決，為什麼仍然需要OLAP DSL？這裡以常見的「多維指標統計」為例，從業務、工程兩個視角進行說明。

業務視角

• 多個開源組件並存的場景下，業務指標會分散至不同的組件中，開發/分析人員需要明確知曉指標與組件的對應關係；
• 不同的組件提供不同的API，開發/分析人員需要掌握多種組件的領域概念及相應API使用方法，且不斷來回切換；
• 指標可能需要依賴多個組件的複合查詢進行計算，開發/分析人員需要清晰了解數據設計、存儲資訊，且工程能力要求較高；
• 指標的計算實現程式碼需要在可視化、報表、監控、數據介面等服務中重複編寫，如果規則變化，很難做到全覆蓋更新，保證數據一致性；

工程視角

如前所述，開發/分析人員需要掌握不同類型的API，且業務系統與這些API緊密集成，已有組件版本升級或者引入新組件時，都會遇到比較大的阻力，靈活性較差；

 
OLAP DSL需要解決哪些問題？

• 開發/分析人員只需要面對一種統一的API，不需要直接面對多種類型的組件API；
• 開發/分析人員只需要輸入查詢條件，即可獲取計算結果，不需要關心指標數據的計算過程；

 
OLAP DSL需要提供哪些能力？

• 獲取查詢系統中有哪些主題；
• 主題下有哪些維度，每個維度下有哪些取值；
• 主題下有哪些指標；
• 可按主題名稱、指標名稱、時間範圍、時間粒度、維度過濾、維度分組等條件進行多維度指標統計查詢；

OLAP DSL實現引擎需要負責構建指標計算規則的邏輯/物理執行計劃，以及多個組件之間的數據交互。