前言
在大部分的公司里,数据部门的产出主要都是提取数据和 数据可视化(BI);提数工作无需多说,写好SQL即可。但BI则不同,即使在BAT等非常重视数据的公司中,它也是数据部门非常重要的产出;
而一个好的BI开发过程中,离不开良好的项目管理。
本文将会对 BI 的开发流程进行简单的介绍,并就其中可能遇到的问题进行探讨。
什么是BI?
在开始介绍前,笔者想先简单介绍下BI,以帮助大家对BI有一个基本的认识。
商业智能(Business Intelligence,简称:BI),又称商业智慧或商务智能,指用现代数据仓库技术、线上分析处理技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。
当然,读者也可以简单地讲BI理解为可快速实现的数据可视化图表,如下图。
![](https://img.haomeiwen.com/i15810645/ae2130781a21fb35.png)
项目流程
正如所有的项目流程一样,BI项目主要分为 3个部分:梳理需求,技术设计,实际开发。每个部分都有一个项目里程碑。
-
梳理需求:需求调研、需求确认。
项目里程碑:需求确认书
-
技术设计:CUBE设计、结果表设计、ETL设计、DEMO设计
项目里程碑:BI设计文档
-
实际开发:后端开发、前端UI调整、CUBE构建、数据源替换
项目里程碑:BI项目文档
详细过程如下
![](https://img.haomeiwen.com/i15810645/4df9451bfa0621d9.png)
笔者会逐一进行介绍。
梳理需求
对需求的梳理,是所有项目开发的第一步,也是最重要的一步。为了避免开发完成后需求方表示“这根本不是我们要的东西”的惨剧。对需求的梳理一定要谨慎、完善。
需求调研
需求调研,即与需求方、相关干系人进行需求确认。从而保证双方对需求理解无误,及该需求是否可实现。
-
项目干系人
项目干系人是指与本次项目可能相关的人,不局限于产品、业务、研发。
在BI项目中,项目干系人大多如下。
-
需求发起者
-
项目管理者:即常说的PM
-
BI实施:大多数情况1个就够
-
后台研发:提供数据的获取逻辑
-
相关业务方:需求发起者有时并非需求业务的负责人,于情于理都应该请该业务的实际负责业务参与。
-
高层:视必要程度
-
-
清晰的分析思路
需求发起方,大多只有模糊的分析思路。数据分析师需要协助业务人员理清逻辑。并制定涉及的指标、维度及展示图表。
-
数据的查询逻辑
需求调研中,需要研发确保数据有记录。并在后续向数据部门提供涉及到的库表和查询逻辑。
需求确认
在需求调研结束后,为了防止双方的理解误差。数据方必须出具需求确认书;
需求确认书应包含以下内容:
-
需求调研的时间、参与的人及角色。
-
指标、维度的定义(清晰明了不会引起歧义)。
-
底层数据的存储位置和查询逻辑。
-
需求变更流程(核心是增加需求就需要更长的开发时间)。
需求确认书大多以电子文档方式存储(如有必要也可以打印出来)。一定要获得所有干系人的确认再开始下一步的设计流程。
阶段里程碑
此阶段的项目里程碑为 需求确认书。主要起到3个作用
-
帮助业务梳理需求,理清思路。
-
确认数据的查询方式。
-
明确需求范围,避免无限制的需求拓展。
技术设计
在需求梳理后,就可以开始进行技术设计。
该步骤可以进行前后端并行设计;前端根据假数据开发DEMO,后端整理CUBE、底层表、ETL的逻辑。
DEMO设计
可以先根据假数据开发DEMO。以让需求提出方更快的看到成品。
后端设计
-
cube设计
cube是多维立方体,即从多个方面来分析对象。 以订单为例:
timg.jpg
一维,如日期:年、季度
二维,如产品:不同品种、类型
三维,如地域:省份、城市等合理的BI,应直接读取CUBE里的数据。这里需要保证CUBE的构建合理、膨胀率不能过大。
-
结果表设计
CUBE的构建,其实就是 事实表 和 维度表 的关联。
这里说的结果表、主要就是事实表的开发。需要制定其字段含义等信息
-
ETL设计
设计ETL时,要注意以下内容:
-
初始化的方式。
-
每个周期数据抽取的方式。
-
数据量是否过大。
-
阶段里程碑
该阶段的项目里程碑,就是TD文档。
一个好的设计文档应该有以下内容:
-
DEMO
-
CUBE设计:表关联关系的ER图
-
结果表设计:建表语句
-
ETL设计:ETL流程图
在设计文档完成后应进行技术评审,参与评审的技术人员、项目管理者应根据以上内容进行把关。
评审通过后再进行实际的开发
实际开发
开发的具体注意点基本都在设计部分处理掉了,但还有一些遗漏。
需注意点
-
BI的配色:每个好的BI开发者,都应有一套自己常用的配色方案(SUPERSET就算了)。
-
BI的查询速度:直接打开的速度、和不同图表间联动的速度都需要注意。
-
CUBE的膨胀率:设计阶段只能尽可能的减少膨胀率,只有接入实际数据后才知道具体。
-
结果表的数据量:避免过大
-
ETL的执行效率:应稳定在1h内。
阶段里程碑
在BI通过最终验收后,BI开发者/项目经理 应腾出一些时间来,对过去的BI项目进行回顾整理。
BI项目文档应包括以下内容:
-
项目背景、预计开发时长、实际开发时长、实际结项日期等 项目信息。
-
需求确认书 内容
-
TD设计文档 内容
-
需求变更记录
-
项目开发中遇到的各种问题等
-
其他内容
其他杂谈
很明显,本文的重心在于BI的开发流程,而非项目管理。实际项目中,还有其他要注意的部分。
项目排期
BI项目的项目预期,应在需求确认之后,由实际开发人员给出。并获得PM、需求确认方的认可。
个人建议给出的时间要是真实预计时间的2倍以上——你永远猜不到过程可能碰到什么幺蛾子、也永远猜不到底层数据有多离谱。
多人合作
在小型公司里,BI往往只能1个人开发。但在重视数据的公司里,一个BI往往需要多个开发人员的协力配合。如何分配工作给不同的开发人员,是对项目经理的一个考验。
软硬件环境
如果你并非在自家公司开发BI,而是以乙方的身份在甲方执行BI项目。则还需调研甲方的软硬件环境。这里也是要预留一部分时间。
BI测试
在大部分的公司里,BI需要经过QA部门的测试。如果没有的话实施人员需要自行简单测试。测试的核心是数据的准确性。
项目运维
如果BI的后续运维直接属于开发者的话可以绕过这一段。但在部分公司中,开发和运维属于不同的部门。实施人员将BI交接给运维人员时,也需要一些运维的文档——当然如果你的第三个项目文档写的很规范的话,可以节省很大的工作量。
网友评论