提升BI架构

Kimball的生命周期方法论描述了构建丰富的业务智能（BI）环境所需的支持：

a) 发布标准化的报表和平衡计分卡：描述业务现状如何？
b) 识别异常：有哪些异常情况？
c) 探究因果关系：为什么会产生异常情况？这一步骤特别具有挑战性，因为新查询可能会需要新的数据源。
d) 模型预测或者What-if分析：下一年度业务会怎样？
e) 跟进行动：所做出的决策影响如何？

我们的方法论描述了如何从头开始迭代的构建BI技术设施：从项目规划、需求收集、架构和设计到实施、部署和运营。

如果你在各阶段遇到麻烦该怎么办？如果你已经有了支持基本报表的基础设施，但是错误的架构是否会导致复杂的分析或用户自助服务？你能否能找对方向？从某些 角度看，从零开始比较容易，一开始就把事情作对，从零开始更容易成功。但是在大公司和越来越多的中型公司甚至小公司里，已经有一些业务智能的应用。在维护 已有系统和用户的同时，迁移至新的架构更具挑战。这里列出了三种常见的不成功的BI架构：

● 不具备面向用户发布层的标准化数据仓库。
组织已经在BI架构上有了投入，但是缺少业务客户。数据仓库已经标准化，意味着更简单的数据装载和维护，但查询不易。如果报表直接在标准化的结构上生成， 通常需要通过非常复杂的查询和存储过程。在某些案例中，只有专业的IT团队能够写报表。
● 基于标准化数据仓库的数据集市。
解决数据模型过于复杂的通用方法是应用数据集市解决特定的业务问题。通常这些集市是多维的（或者至少部分应用维度）。不幸的是，由于范围所限，数据集市只 包含汇总数据，而并没有其它架构。新的业务问题需要构建新的集市解决。数据仓库打下的基础越好，建构新的数据集市越容易。用户的Ad hoc访问将受限于某些独立数据集市的场景。
● 基于业务系统的数据集市。
没有中间DW层，而把数据集市植根于OLTP系统，是种没什么效率的架构。每个数据集市都需要开发复杂的ETL过程。通常，我们会看到链接起来的集市，即 一个集市导入另一个集市。

在任何情况下，恰当的解决方案是构建一致的维度数据发布区域。收集需求并按照Kimball的拥有一致维度的数据仓库理论构建逻辑模 型。

如果你已经有了标准化的企业级数据仓库，而在业务需求和DW内容间存在分析的障碍。你可能需要构建相对简单的ETL过程来执行从标准化 数据仓库迁移到多维数据仓库的运算。针对任何新增的业务流程和数据，要确认在你的环境中标准化的数据仓库是否提供数据。如果可能，需要多维化标准企业级数 据仓库，并在维度结构中再次集成和存储数据。此外，你也可以在单个ETL过程中多维化和集成数据，并逐步淘汰标准化的数据仓库。一旦数据进入一致的维度模 型中，你将会发现业务用户将拥有更加成功的自助服务用来开发ad hoc查询。其中一些ad hoc查询将会用来进行异常分析、因果分析、甚至是预测分析，这将会把BI应用推向更广泛的用户。

如果你还没有标准化的数据仓库，那正好，你可以使用Kimball的方法论从头开始。你将需要收集需求，设计维度模型，开发抽取、转换、多维化和装载程 序，构建企业级维度数据仓库。

构建一个升级架构可能面临的最大挑战是用户的期望过高。你将需要在新系统开发过程中适度提升已有系统。如果你从零开始，你可以通过小步开发新系统逐步满足 客户的需求。在BI升级或替代项目中，初期的项目范围比我们通常建议的要大。
你需要在进行新开发的同时，规划人员和资源来维护原系统。我们建议你为新开发投入一个团队，如果把同样的人员投入新旧系统的开发，他们将会发现缺乏精力持 续跟进客户需求。整个团队都需要拓展，新旧两个团队都需要具备业务技能和技术技能。

如果你在升级环境中已经掌握了核心数据，这里有两条可选的路线。你可以通过构建比发布基本报表更加深入的分析应用探究初始数据集；或者，你可以从附加业务 过程中得到数据。如果有足够的资源，你可以同时进行。

 

译者介绍：

甄浩，北京迈思奇BI开发工程师，资深BI咨询顾问，软件工程专业硕士。
主攻数据仓库、OLAP建模、数据挖掘、企业绩效管理等技术领域，具有6年的BI项目实施和咨询经验。