本文由36氪企服點評專家團呂品原創。
36氪企服點評專家團——呂品
————正文————
BI 工具不是可以直接拖拉拽取數嗎 ？為什麼還要寫 SQL 取數 ? 這是很多初次接觸商業智慧 BI 的朋友會提到的一個問題，因為在他們接觸到一些 BI 市場或者產品宣傳的時候，很多人就是這麼來介紹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 產品從實際的業務系統中取數來驗證一下是否那麼容易就明白了。
以下面一個小 DEMO 為例，可以使用任意的國內外 BI 視覺化分析工具嘗試一下當直連到這張表的時候，是不是就可以直接、任意的進行拖拉拽分析。
案例：統計外包業務的人工效率（時長）
背景：某金融公司把一部分貸款業務外包出去給第三方公司，第三方公司業務人員每與客戶聯絡一次，就會根據溝通的狀態記錄一下，形成了以下的業務資料表 DurationTime，有以下三個核心欄位：
ID - 客戶的身份證號，唯一標識 ID
Operation - 一個操作記錄，重點節點有 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 表
為了得到上面的最終結果，通常往往會建立一些中間轉換表，用來記錄轉換的過程，便於檢查和糾正邏輯，這種表我們通常叫做 Transformation 表。
業務系統中的原始資料表的資料規範嗎 ？非常規範。但是適合分析嗎 ？並不適合。所以在 BI 分析之前要做什麼？那就是寫 SQL、ETL 取數，把這種在業務系統中規範的不可分析的、或不規範的不可分析的變成規範的、可分析的資料格式 —— 結果表。
在實際的 BI 專案開發過程中，來自各個業務系統資料來源的資料大部分情況下就是一種不可直接分析的狀態，與分析思維不同，他們是描述業務過程的。
還會有一種說法是：可以直連業務資料來源，透過寫 SQL 查詢一個數據集再透過前端 BI 視覺化分析工具來呈現做視覺化分析報表行不行？ 我們的建議是，除了以下幾種情況，不要這樣做：
第一，這類視覺化分析報表基本上就是一次性的，一年可能就改不了幾回。
第二，本身資料量不大，使用頻率也不會非常的高。
原因在於：沒有合理的建模、指標計算複用性太差、影響業務系統性能、無法應對後續日益增長和不斷變化的業務分析需求，按照這種方式做的 BI 基本上不會超過兩年就會面臨推翻重做的風險。
所以，在使用 BI 的時候，不管是直連業務系統資料來源的表進行表間關係建模，還是透過寫 SQL 查詢資料結果集的方式直連業務系統，在大多數情況下都不合理，BI 開發人員應極力避免採用這樣的資料操作方式，這些還都是在沒有涉及到多異構資料來源取數、主資料檔案不一致、組織架構缺失補位、緩慢漸變維度等問題的前提下。
BI 直接取數分析什麼樣的情況下是可行的 ？
也有朋友說到，我們公司就是直連資料庫取數做視覺化分析的。我們讓朋友回去問了一下，原來連線的是企業已經構建好的資料倉庫。在這種情況下，底層的資料模型相對比較標準，資料也經過了非常良好的格式轉換，可以直接使用一些前端 BI 視覺化分析工具進行快速的分析，這樣的一種搭配就非常好。
所以，BI 直連資料庫不是不可行，但得分清楚直連的是業務系統的資料來源資料庫，還是直連的是已經透過 SQL 從業務系統的資料來源取數和建模處理後的資料倉庫、資料集市。
派可資料自助開發平臺包括資料倉庫與BI視覺化分析
IT 和業務的邊界就在這裡，IT 負責底層資料建模、資料倉庫的構建，業務基於已經建好的基礎分析模型透過 BI 前端視覺化分析工具來進行拖拉拽的視覺化分析操作。倘若是這樣，也確實實現了不透過 SQL 取數使用 BI 前端工具就可以做報表的目標。但絕對不能認為，不透過 SQL 取數就可以對接任何業務系統資料來源做任何 BI 視覺化分析。
所以，當一家企業底層已經有架構非常良好的資料倉庫，這個時候使用一個輕量的 BI前端視覺化分析工具基本上就夠用了。但如果所在企業底層還沒有良好的資料倉庫系統，只寄希望單純的使用一個 BI 前端視覺化報表工具解決一切分析問題，這個時候就需要認真思考一下是否可行。
想要了解更多行業知識、軟體推薦、功能對比、工具測評，敬請關注36kr企服點評官方網站（www.36dianping.com）。輕點滑鼠，發現更多高效率的企服軟體！
www.36dianping.com
[免責宣告]
原文標題：《BI 不是可以拖拉拽取數嗎？為什麼還要 SQL 取數 ? | 專家視角》
作者： 呂品
本文來源於36氪企服點評
