「BI 工具不是可以直接拖拉拽取數嗎 ？ 為什麼還要寫 SQL 取數 ？」 這是很多初次接觸商業智慧 BI 的朋友會提到的一個問題。
簡單來說，這個問題背後的邏輯等同於：拿著碗和筷子不是可以直接吃飯嗎 ？ 為什麼還要自己動手做飯 ？ 有沒有想過，即使是直接吃飯，飯總是要有人來做的吧，無論這個人是自己還是別人，"做飯"這個過程並不會少。
所以，從這個問題背後能看出來還是有很多人對於 BI 的理解還是存在一定的誤區，我們可以從以下這幾個角度來分析講解一下。
視覺化 ≠ BI
很多人對於 BI 的印象就停留在數據的可視化圖表，但視覺化圖表只是 BI 的最終呈現，可視化的拖拉拽並不是 BI 的全部。 一個完整的商業智慧 BI 解決的應該是端到端（ End to End ） 的問題，需要從各個業務系統的資料源取數，通過 ETL （ Extract 抽取、Transformation 轉換、Loading 載入 ）的過程 將要分析的數據從規範的不可分析的、或不規範不可分析的數據最終變為規範的、可分析的形式，最終通過 BI 可視化拖拉拽的方式將資料進行有效的、帶有邏輯性的組織形成可視化分析報表。
而大部分的 BI 工具如果重在強調前端視覺化的能力，這類 BI 工具的定位就是解決數據視覺化分析展現的問題，屬於 BI 前端視覺化報表工具，但並不能代表 BI 的全部。
如何形象的理解 BI
如果把 BI 可視化實現的過程比作到餐廳出菜的過程，那就是： 數據源環節 vs 菜市場
從各個業務系統取數—— 按照餐廳營業需求準備所需菜品的原材料，就需要到各個市場買菜。 不同的業務系統對應不同的菜市場，不同的菜市場有不同的攤位對應的就是業務系統資料庫中不同的數據表。 攤位上的菜就可以理解為數據表中的數據，要分析什麼就取什麼樣的基礎數據。
數據倉庫 vs 後廚倉庫
數據倉庫環節 —— 從各個市場買回來的菜堆在哪裡呢？ 後廚倉庫。 有的菜是今天要用的，有的菜是明天要用的，所以先買回來堆起來。 從各個系統抽取上來的數據也是如此，這些數據有的來源於 Oracle 系統，有的來源於 MySQL 或者 SQL Server，按照分析需求從不同的資料庫抽取之後放到自己的數據倉庫中集中管理起來。 ETL 過程 —— 廚師做一道菜也不可能把整塊肉、一整顆蔬菜丟到鍋里，一定是將肉塊切片，蔬菜去除壞掉的葉子，菜和肉分別切一切。 同時，還會備好一些輔助的佐料等原材料，最後把所有的原材料放到操作臺上，這個就是備菜（ 擇菜、洗菜、切菜 ）的過程。
數據也是如此，把數據從各個業務系統先抽取（ Extract ） 上來，等同於把放在不同倉庫格子的菜拿過來。 數據要做轉換（ Transformation ） ，比如一些臟資料的處理、格式的轉換、資料計算口徑的統一、指標的計算等等，就如同洗菜、擇菜、切菜的過程。 最後將處理之後的數據按照一定的模型或者格式載入（ Loading）到指定的可被前端調用的資料表中，就如同把所有備好的菜放到一起準備下鍋。 報表視覺化 Reporting vs 上菜
Reporting 報表視覺化就是最後的呈現，也通常視為 BI 的前端，所以也叫做 BI 前端視覺化。 使用者需要什麼樣的視覺化報表，就如同使用者點菜一樣可以高度定製化，前提是基於已有的原材料（數據）。
所以，大家可以看到從業務系統數據取數到最後的報表呈現實際上經歷了很多的階段。 在商業智慧 BI 開發過程中，80% 的時間在處理底層數據（ 跑菜市場、買菜、運菜、擇菜、洗菜、切菜到備好菜 ），20% 的時間在做可視化分析報表（ 做菜 ）。 底層數據的處理重點就是 ETL 過程，而實現 ETL 過程的主要方式就是通過 ETL 工具（ 例如：Kettle、Informatica、Pentaho、IBM DataStage、Microsoft SSIS 等 ）或其它 ETL 框架結合 SQL 查詢語句、Stored Procedure 儲存過程等方式來組織和管理數據處理的先後順序。 特別是企業級 BI 專案建設，不僅僅是簡單的 ETL 過程還需要涉及非常專業的數據架構設計、數據倉庫建模、分層設計等數據倉庫的構建，這裡面最常用的開發語言就是 SQL。
BI 直接取數分析並不可行
很多 BI 工具會經常強調直連取數，這樣就不需要寫 SQL，直接通過表與表之間的關係進行表間建模，形成一個大寬表，文本類型的就是維度 Dimension，數值類型的變成度量Measure，通過 BI 前端可視化進行拖拉拽操作形成很多 Ad-hoc Report 即席報表。 在實際演示案例的時候也是如此，最常見的就是一個標準的、數據格式極為標準規範EXCEL 表上傳一下按照上面的方式來一遍;要麼就是銷售訂單表和銷售明細表關聯一下，算算訂單數量、訂單金額等等。 其實驗證一下 BI 工具的這種直連且拖拉拽的能力到底有多強非常簡單，讓營業單位提幾個實際的分析需求，現場拿 BI 產品從實際的業務系統中取數來驗證一下是否那麼容易就明白了。
案例：統計外包業務的人工效率（時長）背景：某金融公司把一部分貸款業務外包出去給第三方公司，第三方公司業務人員每與客戶聯繫一次，就會根據溝通的狀態記錄一下，形成了以下的業務數據表 DurationTime，有以下三個核心字段：
ID - 客戶的身份證號，唯一標識
IDOperation - 一個 操作操作記錄，重點節點有 0034、0036、0048
Date - 一個操作記錄的時間日期（實際上是時間，為了簡化用日期表示）
計算規則如下：
1） 計算0034-0036，0036-0048，0034-0048的時間間隔。
2） 如0036之前沒有0034，不可單獨計算0036-0048的時間間隔。
3） 如0036后跟著多個0048，則取到最晚的一個0048的時間間隔。
4） 如0034后跟著多個0048，則取到最早的一個0048的時間間隔。
5) ....
實際的計算規則多達 20 多種，就以上面 4 條計算規則為例，最後的計算結果是：為了得到上面的最終結果，通常往往會創建一些中間轉換表，用來記錄轉換的過程，便於檢查和糾正邏輯，這種表我們通常叫做 Transformation 表。 商務系統中的原始資料表的資料規格嗎 ？ 非常規範。 但是適合分析嗎 ？ 並不適合。 所以在 BI 分析之前要做什麼？
那就是寫 SQL、ETL 取數，把這種在業務系統中規範的不可分析的、或不規範的不可分析的變成規範的、可分析的數據格式 —— 結果表。 在實際的 BI 專案開發過程中，來自各個業務系統數據源的數據大部分情況下就是一種不可直接分析的狀態，與分析思維不同，他們是描述業務過程的。 還會有一種說法是：可以直連業務數據源，通過寫 SQL 查詢一個數據集再通過前端 BI 可視化分析工具來呈現做可視化分析報表行不行？ 我們的建議是，除了以下幾種情況，不要這樣做：第一，這類可視化分析報表基本上就是一次性的，一年可能就改不了幾回。 第二，本身數據量不大，使用頻率也不會非常的高。 原因在於： 沒有合理的建模、指標計算複用性太差、影響業務系統性能、無法應對後續日益增長和不斷變化的業務分析需求，按照這種方式做的 BI 基本上不會超過兩年就會面臨推翻重做的風險。 所以，在使用 BI 的時候，不管是直連業務系統數據源的表進行表間關係建模，還是通過寫 SQL 查詢數據結果集的方式直連業務系統，在大多數情況下都不合理，BI 開發人員應極力避免採用這樣的數據操作方式。 這些還都是在沒有涉及到多異構數據源取數、主數據檔案不一致、組織架構缺失補位、緩慢漸變維度等問題的前提下。
BI 直接取數分析在什麼樣的情況下是可行？
也有朋友說到，我們公司就是直連資料庫取數做可視化分析的。 我們讓朋友回去問了一下，原來連接的是企業已經構建好的數據倉庫。 在這種情況下，底層的數據模型相對比較標準，數據也經過了非常良好的格式轉換，可以直接使用一些前端 BI 可視化分析工具進行快速的分析，這樣的一種搭配就非常好。 更多的時候，我們對這類前端 BI 可視化分析工具的定位應該是服務於個人或者部門級的分析工具，而非企業級的 BI。 個人或部門的分析基於數據格式相對良好的數據源來做日常業務的一些分析工作基本上就夠用了，但是上升到企業級，面臨的挑戰就會很大。 所以，BI 直連資料庫不是不可行，但得分清楚直連的是業務系統的數據源資料庫，還是直連的是已經通過 SQL 從業務系統的數據源取數和建模處理後的數據倉庫、數據集市。
IT 和業務的邊界就在這裡，IT 負責底層數據建模、數據倉庫的構建，業務基於已經建好的基礎分析模型通過 BI 前端可視化分析工具來進行拖拉拽的可視化分析操作。 倘若是這樣，也確實實現了不通過 SQL 取數使用 BI 前端工具就可以做報表的目標。 但絕對不能認為，不通過 SQL 取數就可以對接任何業務系統數據源做任何 BI 可視化分析。 所以，當一家企業底層已經有架構非常良好的數據倉庫，這個時候使用一個羽量的 BI 前端可視化分析工具基本上就夠用了。 但如果所在企業底層還沒有良好的數據倉庫系統，只寄希望單純的使用一個 BI 前端可視化報表工具解決一切分析問題，這個時候就需要認真思考一下是否可行。