選擇正確的工具，還是堆積人力？
報表效能優化背後的組織反思
最近在工作上有一些好消息，我在客戶那邊協助客戶導入現代資料棧 （Modern Data Stack），用新的架構來做商業智慧報表 (Business intelligence report) ，而新的架構比原先既有的作法，報表生成的速度快了整整 100 倍。
為什麼可以有這麼顯著的數字呢？這跟既有的作法極有關系。
既有的作法是這樣子：
客戶並沒有將營運資料庫 (operational database) 與資料倉儲 (data warehouse) 分開。
客戶生成報表的作法，基本上採用「應用軟體開發」(application programming) 的作法。也就是說，用後端語言 (Java, C#, nodejs, Python, PHP, blah blah blah) 不斷地將資料從資料庫取出，在後端的程式裡做完處理之後，再寫回資料庫。然後不斷地反覆這個過程，直到報表的邏輯被完整地實現為止。
簡而言之，既有的作法是典型的用 OLTP 的解法來解 OLAP 的問題。
相對合理的作法
為什麼用「相對」一詞呢？老實說，因為現在最新的科技，其實已經有像 Rama 這樣子 OLTP/OLAP 整合性的解決方案。不過，由於整合性的解法更難導入，通常我還是建議客戶先用 Modern Data Stack 就好。
作法如下：
先做 EL (extract and load) 將資料從營運資料庫，拷貝到資料倉儲裡。
報表邏輯完全用 SQL 來實現，並且用一些機制，將 SQL 全數串接起來。此外，實現報表邏輯的 SQL 需要可以透過 git 來管理。
極度複雜的商業邏輯，有可能需要會寫 SQL window functions, union, lateral join 或 Rollup expression 才容易實現。
由於用了適合 OLAP 問題的解法，大量的資料並不需要不斷地在後端程式與資料庫裡不停地反覆傳輸，也因此，此一解法可以帶來極為顯著的改進。
對組織架構的反思
就我對我多數客戶 (80%) 的觀察，其實多數的客戶在 Modern Data Stack 專案開始之前，資料團隊 (data team) 往往就是一人，同時也還沒有建立資料倉儲 (data warehouse)。換言之，用 OLTP 作法硬解 OLAP 問題的，就佔了 80% 。
從組織分工的角度來看，一人資料團隊在資源極度受限之下，最後先選擇了暴力解 (brute force) ，實屬合理。在還不了解問題的本質前，不多做假設，先解看看再說。另一方面，當發現既有的作法有根本的問題之後，他們直接昇級 Modern Data Stack ，這就帶來了極大的改進。同時，在昇級之後，合理的資料團隊分工架構也呼之欲出。
另一方面，也有很多我之前談不成的案子，這類型的公司，資源相對充足，因此資料團隊至少還有三到五人，通常也已經有了資料倉儲的建置，然而既有的解法通常未及當代最佳技術。這類型的公司，往往在導入 Modern Data Stack 方面，前進的速度緩慢；此外，在導入之後，也無法大刀闊斧地直接做組織架構的改組。
而我從上述這兩種對比，觀察到了一個模式：「組織在遭遇產能問題時，多數組織的作法是單純地加人，而這類型的解法往往只能緩解產能症狀；少數的組會對造成產能的問題做深入的思考，積極尋找正確的解法，一次做出百倍的產能突破。」
結論
這個一百倍的改進，表面上看起來是技術層面的收穫——從 OLTP 的架構轉向 Modern Data Stack。但本質上，它反映的是一種更深層的思維轉變。
關鍵洞察有二。首先，選擇合適的工具至關重要。不是所有的問題都該用通用的程式語言來蠻力解決；有時候，用對了專門為這類問題設計的工具與作法，效能差異可以是一百倍。這提醒我們，在面對新問題時，應該花時間理解問題的本質，而不是急著用慣用的手段硬幹。
其次，組織的靈活性決定了改進的上限。資源受限的小團隊，正因為被迫審視問題的本質，往往能做出更大膽的決定。而資源充足的組織，卻常被既有的架構、人力配置所綁架，導致遲遲無法做出根本性的改變。這不是簡單的「加人」或「投入更多資源」能解決的。
如果你的組織正面臨報表效能或產能的瓶頸，問題可能不在人手不足，而在於是否找到了真正解決問題的方法。一次百倍的突破，往往始於願意重新思考問題本身。