数据仓库开发的三项原则

本文概述

• 商业智能数据仓库实施
• 什么是数据仓库？
• 第一数据仓库原则：数据质量至高无上
• 第二个数据仓库原理：翻转三角形
• 第三数据库仓库原理：即插即用
• 本文总结

Gartner估计, 新启动的商业智能项目中有将近70％至80％会失败。这是由于各种原因造成的, 从错误的工具选择到IT与业务涉众之间缺乏沟通。在跨行业成功实施BI项目之后, 我希望在本博文中分享我的经验, 并重点介绍商业智能项目失败的关键原因。本文将基于应控制数据仓库构建方式的三个原则, 提出针对故障的对策。遵循这些数据仓库概念, 应该可以帮助你作为数据仓库开发人员导航开发过程, 从而避免BI实施中常见的漏洞甚至是陷阱。

商业智能数据仓库实施

尽管成功的商业智能数据仓库的标准因项目而异, 但在所有项目中都需要并要求某些最低要求。以下是通常在成功的商业智能数据仓库中发现的主要属性的列表：

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

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

什么是数据仓库？

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

数据仓库通常被认为是商务智能系统, 旨在帮助满足企业实体的日常报告需求。它们(在标准实现中)对实时性能的要求与OLTP数据系统不同, 并且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结合)。

在所有这些情况下, 你都需要在即时收益和未来迁移成本之间做出实际的折中选择, 以确保不会因为无法处理变更或因为变更需要太多时间而报废仓库, 努力或投资。

本文总结

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

本文概述的数据仓库基础知识旨在帮助你进行这些重要考虑时进行指导。当然, 考虑这些原则并不能保证成功, 但是它们无疑会帮助你避免失败。