文章图片

【商业智能BI在面向报表和模型开发时，有什么不同？】


文章图片




企业在面试商业智能BI技术开发人员 ， 发现基本上90%的人分不清什么是面向报表开发 ， 什么是面向模型开发 ， 不明白这个问题背后的意思 。 10%左右的人稍微暗示一下 ， 大概就懂你想了解的是什么了 ， 这10%的是真正有过完整的数据仓库设计开发经验的人 。
所以 ， 企业在以后招聘的商业智能BI开发人员的时候也可以拿这个问题问的试试看 ， 可以很容易筛选出来候选人之前做BI是怎么做的 ， 或者到底有没有数据仓库设计开发经验 。

这个差异就在于面向报表开发的形式基本上就是用户给什么报表 ， 就写SQL拼接数据集去展现什么样的报表 。 在底层数据架构中大概率就是将各个业务系统数据源的数据拉通整合到一个数据库中 ， 该清洗的还是会清洗 ， 但是在架构上考虑的很少 。 这一类的商业智能BI开发人员的经验大概率做的都是报表取数、报表开发一类的工作 。
通常会有两个明显的短板：
第一 ， 业务敏感度不高 。 即使做了很多的报表开发 ， 但是让讲下具体的业务是讲不出来的 ， 或者讲的很散、深度不够 ， 非体系化输出 。 这就是因为业务报表本身就是一张一张甩过来的 ， 看完表样就取数开发了 ， 是以报表结果为导向的 ， 很少从整体上去思考业务的关联性 ， 自然也就不会注意到业务本身 。
第二 ， 不太懂底层数据架构 ， 对数据仓库有了解但不会很深入 。 这个并不是因为大家不努力或者技术真的就不行 ， 而是因为身边的人做BI报表开发都是这么做的 ， 从入行开始接触的就是这种方式 ， 所以在经验上很难有所突破 。

在面试工作五六年、七八年、上十年的 ， 都会碰到这样的一类人 ， SQL写的很溜 ， 报表出的也很快 ， 但让体系化的讲讲这些业务就很难 ， 对底层数据仓库架构理解的不够深入 ， 碰到一些大项目、长周期的项目还是会有一些认知上的盲区和瓶颈 。
面试的时候觉得自己的技术怎么着都很牛了 ， 做了那么多的项目 ， 开发了那么多的报表 。 但是过来一面试 ， 把一些实际的场景一摆出来 ， 10个问题可能只能答上2个 。 知道自己还有不会的东西 ， 想学习 。 其实 ， 技术上一般问题都不会太大 ， 只是看问题的思维层次、面上够不够的问题 。
就像面向模型开发 ， 这就是一种思维方式 。 只是把用户给的报表作为梳理指标和维度的参考 ， 在实际设计底层数据架构的时候 ， 除了数据的拉通和清洗之外 ， 重点考虑的是数据分析模型的通用性和可扩展性 。

换句话说 ， 在设计底层数据仓库架构的时候根本就不受用户报表的影响 。 怎么出报表这是以后的事 ， 这个阶段不考虑这个问题 。 我们要考虑的是怎么样用一个模型或者几个模型支撑到更多的分析报表 ， 而不是一个SQL一个数据集的去支撑用户的报表 。
这两者的思维方式差别是非常大的 ， BI项目落地的结果自然也是完全不同的 。 特别是体现在BI项目的二期、三期 ， 差别会非常的明显 。 按照面向报表开发思维的设计方式 ， BI项目大概率是很难继续下去的 ， 因为架构不具备高度的扩展性 ， 底层模型不规范 ， 复用度低 ， 基本上是以用户提出的报表为引导进行开发的 。 就跟装修房子一样 ， 用户想要什么效果就设计装修成什么效果 ， 但是忽略了底层的架构 。 当用户的需求在二期、三期不断增加的时候、经常性调整的时候 ， 这种架构就很难支撑起来 ， 一动底层架构就是破坏性的 。

还有一点也是我们商业智能BI开发人员需要注意的：就算很多商业智能BI开发人员在设计数据仓库的时候是按照Kimball维度建模架构去搭建的 ， 但是仍然很容易受到业务人员给到的报表的影响 ， 做着做着数据仓库的底层模型就又变成了跟业务报表字段对应的报表开发模式 ， 这种做法也是错的 。
记住一点：在Kimball维度建模中 ， 对事实表的设计是完全依赖于业务物理活动的度量事件 ， 不会受到可能产生的最终报表的影响 ， 这就是面向模型开发思维的核心思想之一 。 所以在标准的DW层 ， 事实表的设计一定是描述最基础性的事实动作 ， 构建基础的事实表 。 在DM数据集市层 ， 可以为了一些查询性能、便利性等原因建立一些表来适配一些报表要求 。