数据仓库开发的三大原则

Gartner 估计，近 70% 到 80% 的新启动的商业智能项目都失败了。 这是由多种原因造成的，从错误的工具选择到 IT 和业务利益相关者之间缺乏沟通。 在成功实施跨行业的 BI 项目后，我希望在这篇博文中分享我的经验，并强调商业智能项目失败的关键原因。 本文将根据应管理数据仓库构建方式的三个原则提出故障应对措施。 遵循这些数据仓库概念应该可以帮助您作为数据仓库开发人员在开发过程中导航，避免常见的坑洼甚至 BI 实施的天坑。

商业智能数据仓库实施

虽然成功的商业智能数据仓库的标准会因项目而异，但所有项目都需要满足某些最低要求。 以下是成功的商业智能数据仓库中通常存在的主要属性列表：

• 价值：商业智能项目可以跨越数月甚至数年的过程。 但是，重要的是要在项目的早期向您的业务利益相关者展示数据仓库的好处，以确保持续的资金和兴趣。 理想情况下，利益相关者应该在项目的前三周内从新系统中获得一些有意义的商业价值。
• 自助式 BI：等待 IT 完成数据请求或进行数据分析的时代已经结束。 现在，任何 BI 项目的成功都是通过它使业务用户自己从系统中提取价值的能力来衡量的。
• 成本： BI 项目通常具有较高的前期实施成本。 为了平衡和抵消高昂的初始成本，设计维护成本低的仓库非常重要。 如果客户需要一个成熟的 BI 开发人员团队来确保/诊断数据质量问题，对数据模型进行例行更改或处理 ETL 故障，则系统的预算成本将很高，并且有可能在一段时间后关闭.
• 适应性：适应不断变化的业务需求的能力至关重要。 重要的是要牢记市场上提供的无数 BI 工具以及它们发展以包含更多功能和特性的速度。 再加上业务不断发展，对仓库的要求也会发生变化； 适应性要求数据仓库的设计能够在未来使用替代的 BI 工具，例如不同的后端或可视化工具，并且能够适应经常无法预见的需求变化。

通过我构建成功解决方案的经验，或许更重要的是，参与失败的项目，我得出的结论是，三个关键原则对于增加成功实施商业智能系统的可能性至关重要。 但是，在详细介绍它们之前，让我们从一些上下文开始。

什么是数据仓库？

在深入研究不同的数据仓库概念之前，了解数据仓库实际上是什么很重要。

数据仓库通常被认为是为帮助满足业务实体的日常报告需求而创建的商业智能系统。 它们没有与 OLTP 数据系统相同的实时性能要求（在标准实现中），而 OLTP 系统将只包含与业务的一小部分相关的数据，而数据仓库则希望包含与业务相关的所有数据。业务。

只有当仓库被视为“万物数据”的中心枢纽，而不仅仅是生成运营报告的工具时，数据仓库模型才能为企业带来好处。 所有运营系统都应与数据仓库进行双向通信，以输入数据并接收有关如何提高运营效率的反馈。 任何业务变化，例如价格上涨或供应/库存减少，都应首先在您的数据仓库环境中进行原型设计和预测，以便您的业务能够可靠地预测和量化结果。 在这种情况下，所有数据科学和数据分析功能都将以数据仓库为中心。

数据仓库有很多组件，它不仅仅是一个数据库：

• 数据库是您存储数据的媒介。
• 数据仓库不仅包括从数据中提取业务价值所需的工具和组件，还可以包括集成管道、数据质量框架、可视化工具甚至机器学习插件等组件。

这是数据库和数据库仓库结构之间差异的更直观表示。 数据库或新的逻辑数据元存储（如 Hive）形成了数据仓库恒星系统的中心恒星，所有其他组件作为其旋转行星。 但是，与星型系统不同，数据仓库可以有一个或多个数据库，并且这些数据库应该可以与新技术互换，正如我们将在本文后面讨论的那样。

第一数据仓库原则：数据质量至高无上

数据仓库只有在业务利益相关者信任其中的数据时才有用和有价值。 为了确保这一点，必须构建自动捕获和纠正（在可能的情况下）数据质量问题的框架。 数据清理应该是数据集成过程的一部分，定期进行数据审计或数据分析以识别任何数据问题。 在实施这些主动措施的同时，您还需要在不良数据滑过这些门并由用户报告时考虑采取被动措施。

为确保用户对数据仓库系统的信心，应优先调查业务用户突出显示的任何不良数据。 为了帮助完成这些工作，应在平台中构建数据沿袭和数据控制框架，以确保支持人员能够快速识别和修复任何数据问题。 大多数数据集成平台都集成了一定程度的数据质量解决方案，例如 MS SQL Server 中的 DQS 或 Informatica 中的 IDQ。

如果您在数据集成管道中使用商业工具，请利用这些内置平台，但除此之外，请确保构建有助于保持数据质量的机制。 例如，大多数数据集成工具缺乏跟踪数据沿袭的良好功能。 为了克服这个限制，可以使用一系列控制表构建自定义批处理控制框架，以跟踪系统内发生的每个数据流。

如果您的业务利益相关者在您的平台中遇到质量不佳的情况，很难重新获得他们的信任，因此对数据质量框架的前期投资应该是值得的。

第二个数据仓库原则：翻转三角形

该图说明了大多数数据仓库的实施和使用中的工作分工。

大部分精力都花在了构建和维护仓库上，而拥有用于业务分析的仓库所带来的增值只是一小部分工作量。 这是商业智能项目经常失败的另一个原因。 有时，项目周期需要很长时间才能向客户展示任何有意义的价值，当系统最终到位时，仍然需要大量的 IT 工作才能从中获得任何业务价值。 正如我们在介绍中所说，设计和部署商业智能系统可能是一个昂贵且漫长的过程。 因此，利益相关者理所当然地期望迅速开始从他们的商业智能和数据仓库工作中获得附加值。 如果没有实现附加值，或者如果结果为时已晚而没有任何实际价值，那么没有什么能阻止他们拔掉插头。

数据仓库开发的第二个原则是翻转三角形，如图所示。

您选择的商业智能工具和部署的框架需要确保进入仓库的大部分工作是提取业务价值，而不是构建和维护它。 这将确保您的业务利益相关者的高度参与，因为他们将立即看到投资该项目的价值。 更重要的是，您使企业能够自给自足地提取价值，而无需如此强烈地依赖 IT。

您可以通过在构建仓库时遵循增量开发方法来遵守此原则，以确保您尽快交付生产功能。 遵循 Kimball 的数据集市策略或 Linstedt 的 Data Vault 数据仓库设计方法将帮助您开发可增量构建的系统，同时顺利应对变化。 在您的平台中使用语义层，例如 MS SSAS 多维数据集，甚至是 Business Objects Universe，为您的数据提供易于理解的业务接口。 在前者的情况下，您还将为用户提供一种从 Excel 查询数据的简单机制——它仍然是最流行的数据分析工具。

结合支持自助式 BI 的 BI 工具（如 Tableau 或 PowerBI）只会有助于提高用户参与度，因为与编写 SQL 相比，查询数据的界面现在已大大简化。

在填充数据库之前将源数据存储在数据湖中将有助于在入职流程的早期向用户公开源数据。 至少高级用户（例如商业量化分析师）现在可以通过在文件顶部连接 Hive/Impala 等工具来消化源数据（通过原始文件）。 这将有助于将企业分析新数据点所需的时间从数周减少到数天甚至数小时。

数据库仓库原则之三：即插即用

数据即将成为石油的数字等价物。 近年来，我们见证了可用作数据仓库平台一部分的工具数量和创新速度呈爆炸式增长。 引领潮流的是目前可用的无数可视化工具，后端的高级选项紧随其后。 鉴于这种环境和业务需求不断变化的倾向，请务必记住，随着业务和技术的变化，您需要更换技术堆栈的组件，甚至随着时间的推移引入/删除其他组件。

根据个人经验，如果一个平台能够持续 12 个月而不发生某种重大变化，那将是幸运的。 在这些情况下，合理的努力是不可避免的； 但是，应该始终可以更改技术或设计，并且您的平台应设计为满足这种最终需求。 如果仓库的迁移成本太高，企业可以简单地认为成本不合理并放弃您构建的内容，而不是将现有解决方案迁移到新工具。

建立一个能够满足所有可以想象的未来需求的系统是不可能的。 因此，在构建数据仓库时，需要一定程度的理解，即您现在设计和构建的任何东西都可以被时间取代。 为此，我主张尽可能使用通用工具和设计，而不是将您的平台与运行它的工具紧密耦合。 当然，这需要经过仔细规划和考虑后才能完成，因为许多工具（尤其是数据库）的强大之处在于它们的个性和紧密的互补性。

例如，与使用 Python 或 SSIS 在数据库外部提取和处理数据相比，使用数据库中的存储过程创建新的业务分析数据时，ETL 性能得到显着提高。 关于报告层，可视化工具将提供其他工具无法提供的某些功能——例如，Power BI 支持自定义 MDX 查询，但 Tableau 不支持。 我的意思不是提倡在您的系统中抛弃存储过程或避免使用 SSAS 多维数据集或 Tableau。 我的目的只是为了宣传在证明任何将您的平台与其工具紧密耦合的决定时要注意的重要性。

另一个潜在的天坑是在集成层中。 使用 SSIS 之类的工具进行数据集成非常容易，因为它具有调试功能或易于与 SQL Server 平台一起使用。 然而，将数百个 SSIS 包迁移到另一个工具将成为一个非常昂贵的项目。 如果您主要在做“EL”，请使用通用工具进行处理。 使用 Python 或 Java 之类的编程语言编写一个通用加载器来加载暂存层将有助于减少您原本需要的单个 SSIS 包。 这种方法不仅有助于降低维护和未来迁移成本，而且有助于自动化数据载入过程的更多方面，而无需编写新的单个包（与原则 2 一致）。

在所有这些情况下，您需要在直接收益和未来迁移成本之间做出实际折衷，以确保仓库不会因为无法处理变更或变更需要太多时间而报废，努力，或者投资。

包起来

某个商业智能系统可能失败的原因有很多，也有一些常见的疏忽可能导致最终失败。 不断变化的技术环境、由于误解为操作系统的次要优先级而导致的数据系统预算有限，以及处理数据的绝对复杂性和困难性意味着在设计和设计时不仅需要仔细考虑近期目标，还需要仔细考虑未来计划。构建数据仓库的组件。

本文中概述的数据仓库基础知识旨在帮助您在考虑这些重要事项时提供指导。 当然，考虑到这些原则并不能保证成功，但它们肯定会大大帮助您避免失败。