从头开始构建OLAP解决方案时,我应该考虑什么？

Question

我正在为一家运行基于MS SQL数据库服务器的软件产品的公司工作,多年来我用PHP开发了20-30个非常先进的报告,直接从数据库中获取数据.这非常成功,人们对此很满意.

但它有一些缺点:

• 对于新的变化,它可能是非常发展的
• 用户无法对数据进行多少实验 - 它被锁定到硬编码视图
• 大报告可能会很慢

我正在考虑逐步采用基于OLAP的方法,可以从Excel或某些基于Web的服务查询.但我想以一种在IT环境中引入最少量新复杂性的方式来实现这一点 - 最少量的不同服务,同步工作等!

我在这方面有一些问题:

1)与工作流程相关:

• 从"黑匣子SQL服务器"到"OLAP准备就绪"的良好发展路线是什么？
• 应该设置哪些服务器和服务,以及应该编写哪些脚本？
• 哪些是最难/最关键/最耗时的部分？

2)ETL:

• 我想最好为他们的数据仓库和生产SQL提供单独的服务器？
• 这些如何保持同步(推/拉)？使用哪些技术/语言？
• 对我来说,SSIS看起来过于复杂,而且图形工作流对我来说并不吸引人 - 我宁愿喜欢基于文本的脚本来完成这项工作.这可行吗？
• 或者仅使用一个源和一个目的地的图形客户端是否有利？

3)发展:

• 从CLI工具可以有效维护多少(数据集成,分析服务)？
• 设置是否可以轻松地在生产和开发之间来回切换？

我对任何涵盖其中一部分的答案感到满意 - 即使它是一个MS环境,我也很想知道其他技术的优势.

Answer 1

我只有使用Microsoft OLAP的经验,所以这里有关于我所知道的两分钱:

1. 如果要实现多维数据集,则将生产SQL Server与多维数据集的源分开.多维数据集需要大量的SELECT DISTINCT column_name FROM source.table.您不希望多维数据集处理阻止您的关键任务生产系统.

2. 虽然您可以使用标准关系表实现OLAP多维数据集,但您很快就会发现,除非您的数据是分类帐系统,否则您可能需要完全重新处理事实和维度表,这将需要反复重新查找源数据库.这是构建单独数据仓库的一个重要论据,该数据仓库使用事实表的分类帐式事务.例如,如果客户订购某些商品然后取消订单,您的源系统可能会将其作为状态更改进行跟踪.在您的事实表中,您可能需要将此行显示为具有正数量和收入流的订单行以及用于取消具有负数量和收入流的行.

3. OLAP对您的环境可能过度.您似乎提出的主要问题是您的报告是静态的,用户希望直接访问数据.您可以构建数据模型并在SSRS中为用户提供Report Builder访问权限,或者在Cognos,Business Objects等其他BI套件中报告写入权限.我通常不推荐这种方法,因为它超出了大多数用户应该拥有的范围.知道获取数据,但在小商店这可能就足够了,而且很容易实现.让我们面对现实 - 用户通常只想将数据导入Excel以进一步操作它.因此,如果您不想为他们提供Web前端,并且您只是希望他们从Excel获取数据,您可以直接访问数据库以访问生产数据的副本.这种方法的缺点是用户不喜欢 通常了解SQL或数据库关系.OLAP可以帮助您避免强迫用户学习SQL或关系,但是在您的最终实现起来并不容易.如果您只有几个需要这种访问权限的超级用户,那么可以很容易地向少数高级用户讲授如何在Excel中对数据库进行基本查询,他们将很乐意明天获得此信息.OLAP明天还没有准备好.

4. 如果您只有几种源数据系统,则可以构建超级动态静态报告.例如,我有一个用C#编写的报告,它基本上允许用户从30列的列表中选择任意数量的列,并过滤几个日期范围字段和字段筛选器列表中的数据.这份简单的报告涵盖了来自最终用户的所有临时报告请求的大约40%,因为它涵盖了所有基本的核心客户指标和字段.我们最近将此报告移至SSRS,这使我们可以将字段数量增加到大约100个,并改善了整体用户体验.无论报告平台如何,即使在静态报告系统的范围内,也可以为用户提供一些动态灵活性.

5. 如果您只有几个数据库,则可以将数据库备份和还原为ETL.但是,如果你想做任何事情,那么你也可以咬紧牙关并使用SSIS(或其他一些ETL工具).进入ETL进行数据仓库后,您将使用面向图形的设计工具.编码适用于应用程序,但ETL更多地是关于工作流程,这就是工具倾向于在图形用户界面上融合的原因.您可以解决此问题,并尝试从文本编辑器编写数据仓库代码,但最终您将失去很多. 有关从代码加载数据和从SSIS加载数据之间的差异的更多详细信息,请参阅此文章.

关于如何使用关系数据存储的多维数据集的反馈

可以在关系数据存储上实现多维数据集,但使用此方法存在一些主要问题.技术上可行的主要原因与您配置DSV的方式有关.DSV本质上是物理数据库和多维数据集/维度定义之间的逻辑层.您可以定义命名查询或在数据库中创建展平数据的视图,而不是将关系表导入DSV.

这种方法的优点如下:

1. 它实现起来相对容易,因为您不必构建整个ETL子系统来开始使用OLAP.

2. 这种方法适用于您希望如何构建更长期解决方案的原型.您可以在1-2天内对其进行原型设计,并展示OLAP今天的一些优势.

3. 为了支持OLAP多维数据集,一些非常非常大的表不必完全重复.我有几十亿个几乎完全标准化的事实表的行表.它们没有的唯一列是日期键,它们还包含一些不应该具有空值的字段上的NULL值.您可以创建代理日期键,并为视图或命名查询中的空值设置值,而不是复制这些非常大的表.如果你不会看到重复表的巨大性能,那么这可能是在数据库本身中以更原始的格式离开的候选者.

这种方法的缺点如下:

1. 如果您尚未构建真正的Kimball方法数据仓库,那么您可能不会以分类帐样式跟踪事务.Kimball方法事实表(至少我理解它们)总是通过添加和减去行来改变值.如果有人取消订单的一部分,则无法更新单个事务的多维数据集中的值.相反,您必须使用负值平衡交易.如果必须更新事务,则必须完全重新处理多维数据集的分区以替换可能是非常昂贵的操作的值.除非您的源系统是分类帐式交易系统,否则您可能必须在ETL子系统中构建分类帐样式的副本.

2. 如果您不构建Kimball方法数据仓库,那么您可能在数据库中使用了不显眼且可能非整数的主键.这直接影响多维数据集内的查询性能.它还为您提供了理论上不灵活的数据仓库.例如,如果您的产品订购系统使用整数密钥并且您开始使用第二个产品订购系统作为遗留系统的替代品或与遗留系统一起使用,您可能很难将数据合并到一起DSV,因为每个系统都有不同的数据点,指标,工作流,数据类型等.更糟糕的是,如果订单ID具有相同的数据类型,并且订单ID值在系统之间重叠,那么您必须声明一个代理键,即您可以跨两个系统使用.这可能很难,

3. 如果从关系数据存储开始,则可能必须构建系统两次,然后转到展平数据库.坦率地说,我认为重复工作的数量是微不足道的.您从关系数据存储中构建多维数据集所学到的大部分内容都将转换为设置新的OLAP多维数据集.但主要的问题是,您可能会完全创建一个新的多维数据集,然后旧多维数据集的任何用户都必须迁移到新的多维数据集.在SSRS或Excel中构建的任何报告都可能在此时中断,需要从头开始重写.因此,重建多维数据集的主要成本实际上是重建依赖对象 - 而不是重建多维数据集本身.

如果您希望我扩展上述任何一点,请与我们联系.祝好运.