一个小型 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 更好).

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14366449/viewspace-1015992/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14366449/viewspace-1015992/