如何避免数据仓库项目失败

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

什么是数据仓库？

在深入研究不同的数据仓库概念之前，了解数据仓库的实际含义非常重要。

数据仓库通常被认为是商业智能系统，旨在帮助满足业务实体的日常报告需求。它们通常没有与 OLTP 数据系统相同的实时性能要求，并且 OLTP 系统仅包含与业务的一小部分相关的数据，而数据仓库希望包含与业务相关的所有数据。

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

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

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

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

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

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

第二个数据仓库原则：翻转精力投入三角形

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

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

在构建仓库时，您可以通过遵循增量开发方法来遵循此原则，以确保尽快交付生产功能。遵循 Kimball 的数据集市策略或 Linstedt 的数据保管库数据仓库设计方法将帮助您开发增量构建的系统，同时顺利考虑变化。在平台中使用语义层，为数据提供易于理解的业务界面。对于前者，您还可以为用户提供一种从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 相关）。

在所有这些情况下，您需要在眼前的好处和未来的迁移成本之间做出实际折衷，以确保仓库不会因为无法处理更改或因为更改需要太多时间、精力或投资而报废。

总结

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

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

​