一個小型 BI 專案的總結

最近在做一個小型 BI 專案，專案的工期很緊,現在專案一期已經接近尾聲，趁這個機會做個專案總結.

專案背景:
該專案的需求方是一家大型的跨國銷售類企業, 在世界各地都有銷售網點, 每個銷售網點會將當日銷售/庫存等資料上報到業務系統.
資料分析人員定期(日/周/月/季)分析這些資料,並結合其它來源的資料(如銷售目標,訂單等), 形成相應的報表,用於管理者的決策支援.

具體需求:
1. 構建 Data Mart , 根據目前在用的報表( Excel 格式), 設計出相應的Fact Table 和 Dimension Table.
2. 每天將業務系統中的資料抽取到Fact Table中, 保證Fact Table中的資料和業務系統(Operational System)中一致.
[@more@]3. 在抽取的同時要完成資料清洗的工作, 將合格資料入庫, 不合格的資料轉移到業務系統的相應資料表中,並標記狀態.
4. 除了業務系統中的資料,還要抽取其它的資料來源的資料(如銷售目標/生產資料,一般都儲存在 EXCEL 檔案中)
5. 不定期的更新維度表.
6. 在資料展現上, 需要提供 WEB 服務, 使用者可以透過 WEB 頁面瀏覽多維報表和相應的圖表, 支援上卷/下鑽等基本操作
7. 在資料展現上, 除了 WEB 方式外, 還要將報表以郵件正文和 EXCEL 附件的方式, 定時傳送到指定的郵箱.
8. 需要支援許可權功能, 不同的許可權的使用者檢視不同國家或區域的資料.
9. 抽取資料,生成報表,傳送郵件全過程每日自動完成, 全過程不能超過一小時.


開發流程:
1. 理解需求
理解需求階段是 BI 專案的第一個階段,也是最重要的一個階段. Kimball 在 <> 一書裡, 從實踐的角度,用了大量的篇幅來介紹這一階段的工作.
包括調查方式,調查問卷的設計,調查中可能遇到的各種情況等都做了很詳細地說明.除了用到這些方法外, 我們在該 BI 專案的開發/實施中,儘量和使用者一起工作,以便及時溝通,更好地理解需求.
2. 模型設計:
為了便於理解和交流, 資料倉儲的模型採用了簡單的星型模型.主要的維度時間維度, 區域維度, 銷售渠道型別維度, 產品維度, 銷售方式維度等等.
事實表也就是在上述維度下的銷售/庫存等資料. 這樣即使是業務人員,也能理解資料倉儲的模型結構.

2.1 時間維度:
時間維度是最基本的維度, 在 PDI 的 samples 目錄下有一個專門產生時間維度的 ktr 檔案, 用來產生一個標準的時間維度.
但在實際中, 年/季/月/周等時間週期可能和標準都會有差異, 如周/月可以對日算, 季以財季代替自然季,年以財年代替了自然年等等.
所以這個檔案一般需要根據實際情況來修改.

2.2 區域維度:
區域維度也是一個基本維度, 用來描述區域的層次關係,如 AP (亞太區) 包括ANZ,ASEAN..., ANZ(澳新) 又包括Australia,NewZland,...

2.3 產品維度:
產品維度描述了產品種類的層次關係...

2.4 其它維度
銷售型別維度, 銷售渠道維度,...

2.4 維度更新:
維度表需要不定時的更新 (Slowly Changed Dimension/SCD), PDI 中提供了"維度更新/查詢"步驟來更新維度, 透過該步驟可以在每次更新維度時記錄維度的有效期限和版本號.

3. 資料抽取:
資料抽取在策略上可以有多種方式來實現,如增量抽取/全量抽取, 實時/非實時抽取等. 因為本專案的資料量比較小(一天不到 50 萬條),因此採用了每日定時的全量抽取方式,這裡的全量抽取也不是抽取全部的歷史資料, 而是抽取 frozen date 之後的資料(frozen date 是業務上的概念, 表示這個時間點前的資料將不會再被修改).

4. web 展現
web 展現有兩種方法可以選擇,可以使用 Pentaho BI Platform, 或者手寫嵌入 JPivot 標籤 的 JSP 頁面. 第一種方式自動化程度更高,可以自動釋出. 第二種方式在頁面樣式上可以更靈活一些,由於頁面數量不多, 另外使用者對頁面的樣式/外觀有一定要求, 我們使用了第二種方式,

5. 自動傳送報表檔案
每日生成的報表既要作為 Excel 附件也要嵌入到郵件正文裡並自動傳送.
為實現該需求,我們擴充套件了 mail job entry, 並新增加了一個 Mondrian output job entry.
擴充套件後的 mail job entry 可以在正文裡嵌入報表內容,
新增加的 Mondrian output job entry 裡, 可以將 MDX 的查詢結果輸出到一個 Excel 檔案中,這個 Excel 檔案可以作為郵件的附件.

6. 全部流程
全部流程都設計成為 kettle 作業, 作業每日自動執行: 先設定相關變數, 再刪除資料倉儲裡 frozen date 之後的資料, 再從業務系統裡抽取 frozen date 之後的資料插入到資料倉儲. 最後生成/傳送報表.
同時 web 使用者也可以web 方式來瀏覽報表.　流程圖如下：

7. 效能
ETL: PDI 的效能完全能滿足該專案的需要, 在實際抽取和載入時,可以達到 5000-8000條/秒的速度,
OLAP: 如果沒有做過最佳化, Mondrian 的效能並不高,在鑽取時,往往相應的時間比較長,一般可以有三個方法來提高查詢效能:
1. 建立 Aggregation table.
2. 給維度表和事實表都建立適當的索引.
3. 分析 Mondrian 提交的 sql 的查詢計劃, 找出該 sql 的執行瓶頸, 在資料庫一級採取相應的方法.

使用的軟體列表:
1. ETL/傳送報表 : PDI(KETTLE)
2. OLAP : Mondrian
3. 模型設計: Modrian Workbench
4. WEB 展現: JPivot
5. 資料庫: mysql ( 從效能考慮 PostGre 更好).