BI 工具不是可以直接拖拉拽取數嗎?為什麼還要寫 SQL 取數?


「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 - 一個操作記錄的時間日期(實際上是時間,為了簡化用日期表示)