高德纳公司估计，近70%到80%的新创业者 商业智能项目失败. 这是由于无数的原因, 从糟糕的工具选择到IT和业务涉众之间缺乏沟通. 成功实现了跨行业的BI项目, 我希望在这篇博文中分享我的经验，并强调商业智能项目失败的关键原因. 本文将根据管理数据仓库构建方式的三个原则，提出针对失败的对策. 遵循这些数据仓库概念可以帮助作为数据仓库开发人员的您在开发过程中导航，避免BI实现中常见的坑洼甚至是陷坑.
成功的商业智能数据仓库的标准因项目而异, 在所有项目中都期望和要求一定的最低要求. 下面是一个成功的商业智能数据仓库中常见的主要属性列表:
通过我建立成功解决方案的经验, 也许更重要的是, 参与失败的项目, 我得出的结论是，要提高成功实现商业智能系统的可能性，有三个关键原则是至关重要的. 然而，在详细介绍它们之前，让我们从一些上下文开始.
在深入研究不同的数据仓库概念之前, 理解数据仓库实际上是什么是很重要的.
数据仓库通常被认为是为帮助满足业务实体的日常报告需求而创建的商业智能系统. 它们没有与OLTP数据系统相同的实时性能要求(在标准实现中), 而OLTP系统将只包含与业务的一小部分相关的数据, 数据仓库看起来包含 与业务有关的所有数据.
只有当数据仓库被视为“所有数据”的中心枢纽，而不仅仅是生成操作报告的工具时，数据仓库模型才能为业务提供好处. 所有操作系统都应该与数据仓库进行双向通信，以便向其提供数据并接收有关如何提高操作效率的反馈. 任何业务变化, 例如价格上涨或供应/库存减少，应该首先在您的数据仓库环境中进行原型化和预测，以便您的业务可以可靠地预测和量化结果. 在这种情况下，所有 数据科学和数据分析 功能将以数据仓库为中心.
数据仓库有许多组件，它不仅仅是一个数据库:
下面是数据库和数据库仓库结构之间区别的更直观的表示. 数据库或新的逻辑数据元存储(如Hive)构成了数据仓库恒星系统的中心恒星, 所有其他组成部分都是旋转的行星. 然而, 不像恒星系统, 数据仓库可以有一个或多个数据库，这些数据库应该可以与新技术互换, 我们将在本文后面讨论.
数据仓库只有在业务涉众信任其中的数据时才有用和有价值. 为了确保这一点, 必须构建自动捕获和纠正(在可能的情况下)数据质量问题的框架. 数据清理应该是数据集成过程的一部分，并定期进行数据审计或数据分析，以识别任何数据问题. 在实施这些积极措施的同时, 当不良数据越过这些门并由用户报告时，您还需要考虑响应性措施.
确保用户对数据仓库系统的信任, 业务用户突出显示的任何不良数据都应作为优先级进行调查. 来帮助这些努力, 数据沿袭和数据控制框架应该内置到平台中，以确保支持人员能够快速识别和修复任何数据问题. 大多数数据集成平台都集成了某种程度的数据质量解决方案, 例如MS SQL Server中的DQS或Informatica中的IDQ.
如果您在数据集成管道中使用商业工具，请充分利用这些内置平台, 但是除此之外, 确保您构建了能够帮助您维护数据质量的机制. 例如，大多数数据集成工具缺乏跟踪数据沿袭的良好功能. 为了克服这个限制, 可以使用一系列控制表来构建自定义批处理控制框架，以跟踪系统中发生的每个数据流.
如果你的业务利益相关者在你的平台上遇到糟糕的质量问题，他们很难重新获得他们的信任, 因此，对数据质量框架的前期投资应该是物有所值的.
该图说明了大多数数据仓库的实现和使用中的工作分工.
大多数工作都投入到构建和维护仓库上，而拥有一个业务仓库的增值 分析 是努力的一小部分吗. 这是商业智能项目经常失败的另一个原因. 有时, 在项目周期中，向客户展示任何有意义的价值花费的时间太长了, 当系统最终到位的时候, 它仍然需要大量的it工作才能从中获得任何业务价值. 正如我们在介绍中所说的, 设计和部署商业智能系统可能是一个昂贵而漫长的过程. 因此, 利益相关者将理所当然地期望通过他们的商业智能和数据仓库工作迅速获得增值. 如果没有增加价值, 或者，如果结果只是太迟而没有任何实际价值, 没有什么能阻止他们拔掉插头.
第二个原则 数据仓库开发 是像这里所示的那样翻转三角形.
您选择的业务智能工具和框架需要确保进入仓库的大部分工作是提取业务价值，而不是构建和维护业务价值. 这将确保您的业务涉众的高度参与，因为他们将立即看到投资项目的价值. 更重要的是，您使业务能够自给自足 提取价值 没有如此强烈的IT依赖.
在构建仓库时，您可以遵循增量开发方法来遵循这一原则，以确保您尽可能快地交付产品功能. 遵循Kimb所有的数据集市战略 Linstedt的数据仓库 数据仓库设计方法将帮助您开发增量构建的系统，同时平稳地考虑变更. 在您的平台中使用语义层，例如MS SSAS多维数据集，甚至是Business Objects Universe，为您的数据提供易于理解的业务接口. 就前者而言, 你还将为用户提供一种简单的机制来从excel中查询数据——excel仍然是最流行的数据分析工具.
整合支持自助式BI的BI工具，例如 表 or PowerBI 只会帮助提高用户粘性, 因为与编写SQL相比，查询数据的接口现在已经大大简化了.
将源数据存储在 数据湖 在填充数据库之前，将有助于在入门过程的早期向用户公开源数据. 至少像商业量化这样的高级用户现在可以通过在文件之上连接Hive/Impala等工具来消化源数据(通过原始文件). 这将有助于将业务分析新数据点所需的时间从数周减少到数天甚至数小时.
数据即将成为数字时代的石油. 近年来, 我们见证了可作为数据仓库平台一部分的工具数量和创新速度的爆炸式增长. 引领潮流的是目前可用的无数可视化工具, 与先进的选项后端紧随其后. 鉴于这种环境和业务需求不断变化的倾向, 重要的是要记住，随着时间的推移，您需要更换技术堆栈的组件，甚至引入/删除其他组件, 随着商业和技术的变化.
根据个人经验, 如果一个平台能够在不发生任何重大变化的情况下维持12个月，那就太幸运了. A reasonable amount of 努力 is unavoidable in these situations; however, 改变技术或设计应该始终是可能的, 您的平台应该设计为满足这种最终需求. 如果仓库的迁移成本太高, 企业可以简单地决定成本不合理，放弃您构建的内容，而不是将现有解决方案迁移到新工具.
建立一个系统来迎合 所有 想象未来的需求是不可能的. 因此, 在构建数据仓库时，需要一定程度的认识到，无论您现在设计和构建什么，都可能随着时间的推移而被取代. 为此目的, 我主张尽可能使用通用工具和设计，而不是将您的平台与其运行的工具紧密耦合. 当然, 这需要在仔细规划和考虑之后完成，因为许多工具都具有这种功能, 尤其是数据库, 是在他们的个性和密切的补充.
例如, 与使用Python或SSIS在数据库外提取和处理数据相比，使用数据库中的存储过程创建新的业务分析数据可以显著提高ETL的性能. 关于报告层, 可视化工具将提供某些在其他工具中不容易获得的功能.g., 权力BI 支持自定义MDX查询，但是 表 不. 我的观点并不是要提倡抛弃存储过程，或者在系统中避免使用SSAS多维数据集或表. 我的目的只是要强调，在做出任何将平台与其工具紧密结合的决定时，保持谨慎是非常重要的.
另一个潜在的漏洞是在集成层. 使用像SSIS这样的工具是非常容易的 数据集成 因为它的调试能力和SQL Server平台的易用性. 然而，将数百个SSIS包迁移到另一个工具将成为一个非常昂贵的项目. 在您主要使用“EL”的情况下，请使用通用工具来执行处理. 使用Python或Java之类的编程语言编写一个通用加载器来加载您的登台层，这将有助于减少您原本需要的单个SSIS包. 这种方法不仅有助于减少维护和未来的迁移成本，而且还有助于自动化数据导入过程的更多方面，而不必编写新的单独的包(与原则2结合在一起)。.
在所有这些情况下，你都需要 在当前收益和未来迁移成本之间做出一个实际的妥协 确保仓库不会因为无法应对变化而被废弃, 或者因为改变需要花费太多时间, 努力, 或投资.
商业智能系统失败的原因有很多, 还有一些常见的疏忽可能导致最终的失败. 不断变化的技术格局, 数据系统的预算有限，因为错误地考虑了操作系统的第二优先级, 处理数据的复杂性和难度意味着，在设计和构建数据仓库组件时，不仅要仔细考虑当前目标，还要仔细考虑未来的计划.
本文中概述的数据仓库基础知识旨在帮助指导您进行这些重要的考虑. 当然, 考虑到这些原则并不能保证成功, 但它们肯定会在很大程度上帮助你避免失败.
数据仓库开发人员(现在通常称为数据工程师)负责数据仓库的整体开发和维护. 这将取决于他们决定技术堆栈以及任何自定义框架和处理，并为消费者准备好数据.
各种技术的使用意味着大多数数据仓库彼此之间非常不同. 一个基本的例子包括一个SQL server数据库, 与SSIS形成数据集成层, 权力BI和SSRS位于数据库之上，以满足可视化和报告需求.
数据仓库是由无数的工具和框架组成的，这些工具和框架整体地协同工作，使数据为获得见解做好准备. 数据仓库的核心是数据库或数据的逻辑元存储，由数据集成框架构成主干.
数据仓库为组织提供了一种机制，可以将来自不同部门的所有数据存储并建模到一个内聚结构中. 由此，可以为公司数据的各种消费者提供服务，包括内部和外部. 数据仓库能够成为唯一的事实来源.
Chamitha是一位精通数据仓库系统架构的IT老手, 工程数据, 业务分析, 项目管理.
作者都是各自领域经过审查的专家，并撰写他们有经验的主题. 我们所有的内容都经过同行评审，并由同一领域的Toptal专家验证.
世界级的文章，每周发一次.
世界级的文章，每周发一次.
