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

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

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

什么是数据仓库

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

数据仓库通常被认为是商业智能系统旨在帮助满足业务实体的日常报告需求。它们通常没有与 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 相关。

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