BI 系統的前置計算

某機構上了一套分佈式數據倉庫，歷史數據逐步裝進了倉庫，然後，基於數據倉庫構建了 BI 系統（主要是多維分析）。剛開始，一切都順利，但隨著時間推移，基於中央數據倉庫的應用越來越多，幾年下來積累了數十個應用。這些應用都需要依賴數據倉庫計算，導致中央數據倉庫的負擔越來越重，BI 系統的響應開始變得遲鈍起來。對於交互性很強的多維分析業務來講，這是很難容忍的。

咋辦呢？

擴容？這已經是個分佈式系統了，節點數也差不多到了 MPP 型數據倉庫的極限，再增加節點並不會有明顯的性能提升了。

更換數據倉庫？就算有測試出性能更好的產品，敢換嗎？幾十個應用起碼要全部重新測試一輪，否則誰能保證換了數據倉庫後這些應用還能正常工作？這要協調多少部門才能動起來？對多維分析測試表現好的產品，對其它應用也會更好嗎？如果導致其它應用的響應速度變得更惡劣又怎麼辦？

央數據倉庫的選擇，對於很多機構而言是個重大的政治任務，不大可能僅為某一個應用的問題而輕易更換。

中央數據倉庫暫不能動，就只能從應用端想辦法。一個常見方案是採用前端計算，即把需要的數據放到應用端，由應用程序直接計算，不再請求中央數據倉庫。技術上經常採用的手段是在應用端放一個前置數據庫用來提供存儲和計算能力。

但是，簡單放一個普通數據庫卻解決不了這裡的問題：

1. BI 系統需要分析過去多年的全量數據，如果把涉及 BI 業務的數據都搬出來，那將會是和中央數據倉庫規模在同一個數量級上的數據，這相當於要再重建一個分佈式數據系統了，這個成本不可能接受了。

2. 如果只放較頻繁訪問的近期數據，那麼確實可以用單個數據庫存儲。不過，我們卻不能預測用戶方要分析什麼時段的數據，雖然不頻繁，但遠期歷史數據仍然有被訪問的可能性。除非在 BI 應用端做較大改動，要求用戶根據訪問時段選擇不同的數據庫，禁止跨時段分析，但這樣的用戶體驗就有點惡劣了，而且要對 BI 系統做較大改動。

3. 還有個 SQL 翻譯的問題。這裡採用的 BI 系統是第三方廠商提供的半商品化軟件，一次分析任務只能同時接一個數據庫，也就只會根據這個數據庫生成相應語法的 SQL 語句。如果要同時接入兩個數據庫，則需要同時生成兩套 SQL 語法。雖然用於多維分析的 SQL 語句都很規整，但仍然會有部分數據庫特有的函數語法（特別是日期時間相關的），這又需要改造前端 BI 系統了。

4. 該機構慣用的商業數據庫採用的是行式存儲方案，而多維分析業務背後一般是個大寬表，採用列存存儲才能獲得更好的性能，這又要更換相對專業一些的列存數據倉庫，想尋找一個輕量級的解決方案並不很容易。

在這種場景就適合使用集算器來充當前端計算引擎。

頻繁訪問的近期數據量不大，單臺服務器已經足夠存儲，不必採用複雜的分佈式體系；集算器的組表提供了列存壓縮方案，可以提供高性能的遍歷統計運算；集算器提供了簡單 SQL 接口，可以直接和 BI 系統接駁；上面這些都是常規數據庫也能提供的，只是集算器更輕量級一些（它甚至可以直接嵌入到 BI 應用中工作）。

關鍵的是，集算器提供了開放的計算能力，程序員可以拿到 SQL 語句後用SPL分拆其中 WHERE 子句中的時間段參數，識別出該查詢涉及的數據範圍是哪些。如果只用到本地數據，則由集算器實施計算；如果還涉及更遠期的歷史數據，則仍將查詢發給中央數據倉庫完成計算，過程還可以用 SPL 將 SQL 語句翻譯成數據倉庫接受的語法，完美地實現了可編程的數據網關功能。

這樣，前端 BI 系統幾乎不用做修改就可以實現後臺數據的冷熱分離。由於絕大多數頻繁訪問被集算器接管，要繼續轉給中央數據倉庫的查詢請求變得非常少，整體運算性能會有大幅度提高，前端交互響應變得很順暢。

這是個真實的案例（有個別特徵進行了整理以突出典型性）。不過，這裡的性能優化並沒有涉及到算法層面，主要是應用結構方面的調整。實現這個方案，是不是採用了集算器這個產品並不重要，我們一直提倡的、要把計算從數據庫中解放出來的理念才是關鍵的。開放的計算本身就是一個重要能力，而不是一定要和數據庫綁在一起，數據計算需要自己的中間件。