可扩大的数仓架构

明天的 数据仓库 零碎使得分析师能够很容易地拜访集成的 数据 。为了实现这一点， 数据仓库 开发团队必须依据用户的需要对 数据 进行解决和建模。开发 数据仓库 的最佳办法是迭代开发过程，这意味着 数据仓库 的性能是依照业务用户的要求在迭代 (有时称为 sprint 或 cycle) 中设计、开发、实现和部署的。

在每次迭代中，更多的性能被增加到 数据仓库 中。这与“大爆炸”办法相同，“大爆炸”办法是在一个大流程中开发所有性能，最初作为一个整体部署。

然而，在执行我的项目时，即便应用迭代办法，增加另一个性能的工作量 (以及与之相干的老本) 通常也会减少，因为必须思考现有的依赖关系。

图 2.1 显示，实现第一个 信息集市 的工作量绝对较低。然而在实现第二个 信息集市 时，开发团队必须保护现有的解决方案并解决现有的依赖关系，例如数据源的集成是利用第一个 信息集市 的数据或者应用现有的业务零碎的数据表。为了确保以前构建的性能在为第二个 信息集市部 署新性能时不会中断，必须从新测试旧性能。在许多状况下，当将新资源增加到整个解决方案时，须要重构现有解决方案以保护各个 信息集市 的性能。所有这些流动都减少了创立第二个 信息集市 的工作量，同样也减少了创立任何后续 信息集市 或其余新性能的工作量。

图 2.1 保护的噩梦

图 2.1 形容了这一额定工作: 一旦创立了第一个 信息集市 ，该解决方案便会进入所有现有性能的保护模式。下一个我的项目施行另一个 信息集市 。要实现第二个 信息集市 ，工作包含增加新性能和保护现有性能。因为依赖关系，现有的性能须要定期重构和从新测试。
换句话说，许多 数据仓库架构 的可扩展性，包含在《数据仓库架构 》中介绍的那些架构，并不是最优的。此外，典型的 数据仓库架构 通常短少可扩展性的架构维度，而不是所形容的可扩展性的数据维度。咱们将在下一节中探讨这些 架构维度。

可扩大数据仓库架构维度

数据仓库 零碎的业务用户心愿加载和筹备越来越多的数据，包含数据的品种、数量和速度。此外，典型 数据仓库 环境的工作负载也在一直减少，特地是当 数据仓库 的初始版本取得了第一批用户的胜利时。因而，可扩展性具备多个架构维度。

工作负载

企业数据仓库 (EDW) 是一个典型企业中“迄今为止规模最大、计算量最大的业务利用”。EDW零碎由宏大的数据库组成，蕴含从多个 GB 到 TB 存储的历史数据。胜利的 EDW 零碎在零碎的工作负载方面有两个问题：第一，它们经验了数据量和利用工作负载的快速增长；第二，并发用户数量的减少，为了满足性能要求，EDW 零碎在大规模并行计算机上实现，例如大规模并行处理 (MPP) 或对称多处理器 (SMP) 零碎环境和集群以及并行数据库软件。事实上，如果没有大规模的并行硬件和并行数据库软件来反对它们，大多数的大型 数据仓库 就无奈实现。

为了解决申请的工作负载，须要更多的并行硬件或并行数据库软件。数据库的逻辑和物理设计必须针对数据量进行优化。

数据复杂性

企业数据仓库 可扩大的另一个维度是数据复杂性。以下因素有助于数据复杂性的增长：

• 数据的多样性：现在，企业组织获取的不仅仅是传统的数据 (例如：关系或主机) 主数据或事务数据。有越来越多的半结构化数据，例如电子邮件、电子表格或 HTML 和 XML 文件，以及非结构化数据，如文档收集、社交网络数据、图像、视频和声音文件。另一种类型的数据是传感器和机器生成的数据，这可能须要特定的解决。在许多状况下，企业试图从非结构化或半结构化数据中获取结构化信息来减少有业务价值的数据。尽管文件可能有一个构造，但文件的内容没有构造。例如，如果不齐全解决视频的所有帧并构建元数据标签来批示内容中的人脸呈现在哪里，就不可能在视频中找到特定人物的脸。
• 数据量：公司生成和积攒新数据的速度正在减少。例子包含来自网站或社交网络的内容、文档和电子邮件收集、网络日志数据和机器生成的数据。数据量的减少导致更大的数据集，这些数据集能够运行到数百 TB，甚至能够进入 PB 或更高的数据。
• 数据的速度：不仅数据的品种和规模减少，而且数据创立的速度也迅速减少。例如，来自证券交易所等金融市场的金融数据。这些数据是以十分高的速度生成的，并立刻进行剖析，以应答市场的变动。其余例子包含用于欺诈检测的信用卡交易数据和来自闭路电视 (CCTV) 的传感器数据或数据，这些数据用于实时或近实时的主动视频和图像剖析。
• 数据的真实性（可信度）：为了对数据有信念，它必须具备弱小的可追溯的数据治理谱系和强壮的数据集成。

剖析的复杂性

因为大量的可用的 数据 具备高速和多样性，企业须要不同和更简单的剖析工作来取得解决业务问题的洞察力。其中一些剖析要求以原始 数据仓库 开发人员无奈预感的形式编制数据。例如，应该输出 数据挖掘算法 的数据应该在数据的多样性、规模和速度方面具备不同的个性。
思考批发营销的例子：当从批发商店转移到须要更具体的客户洞察力的在线渠道时，流动的准确性和及时性须要进步：

• 穿插销售机会能够通过剖析市场篮子来确定，这些篮子显示了能够一起销售的产品。

  • 要理解客户的在线行为，须要点击流剖析。这能够帮忙向网站的访问者提供高卖的优惠。
  • 鉴于大量的社交网络数据和用户生成的内容，企业能够利用这些数据，即对产品审查、评级、好恶、评论、客户服务互动等数据进行剖析。

这些例子应表明，为了解决这种新的和简单的剖析工作，须要不同复杂性的数据源。此外，混合结构化和非结构化 数据 变得越来越常见。

查问复杂性

当 商业智能 (BI) 供应商抉择 关系型数据库 管理系统 (RDBMS) 来存储和治理仓库 数据 时，这是一个天经地义的抉择。关系型数据库 提供了简略的数据结构和高级的、面向汇合的语言，使它们成为 数据仓库 应用程序的现实抉择。数据库引擎中的 SQL 语言处理器将 SQL 语句映射到并行的低级别操作中，以实现更好的查问性能（减速)，并在满足所需性能程度 (扩大) 的同时，为减少的工作负载启用增量增长。许多 RDBMS，如 SQLServer，都是针对 数据仓库 应用程序进行优化的，例如通过利用启发式办法来定义 星型模型 查问模式，即应用 SQL 优化器来进步 数据仓库 应用程序的查问性能。SQLServer 还应用先进的筛选技术，通过应用位图显示打算操作符等个性来进步查问性能。然而，这些个性中的一些只有在查问语句遵循某些准则时才可用(例如仅在 INNER 连贯上应用 equi-join 条件)。

然而，在某些状况下，对 数据仓库 的查问可能变得复杂，而且，思考到 数据仓库 的规模，可能须要很长时间能力实现。例子包含工夫序列剖析和对关系 OLAP 立方体的查问。对于业务分析师来说，数据仓库 的迟缓响应工夫是不可承受的，因为这重大限度了生产力。

可用性

数据仓库 团队负责整个 数据仓库 的可用性，包含业务用户应用的 数据集市 、报表、OLAP 立方体和任何其余前端。在大多数状况下，单方都签订了服务级别协定(SLA)，该协定记录了业务的需要，是 数据仓库 团队的任何可用性布局的根底。

减少的性能可能影响 数据仓库 零碎的可用性。一个例子是增加新的数据源，这些数据源必须加载并集成到一个新的 数据集市 中。然而，这将缩短加载所有数据源和构建 数据集市 所需的工夫。负载的并行化是解决问题的一个办法，因为减少更多的计算资源可能会确保零碎的可用性。然而，“仅仅增加新的计算能力”的能力必须设计到 数据仓库 中。

此外，所有次要的关系数据库管理系统，包含 SQLServer2014 的企业版，都提供了许多性能，如分区和快照，能够帮忙您满足业务用户的可用性要求。另一种抉择是创立故障转移集群，以便在产生紧急时提供代替服务器。

平安

随着 数据集 的增长，对 数据安全 的需要也在增长，事实上，对 数据安全 的需要绝对于数据集的大小和数据的多样性呈指数增长。安全性减少了零碎的复杂性，无论是存储数据还是检索数据。数据集 越大，就越有可能有人在世界其余中央没有留神到的状况下毁坏平安。明天和今天都最优最可扩大的 数据仓库 会从我的项目开始就具备正确的 安全级别 。简略地向这个畛域抛出 NoSQL 并不能解决这些问题；事实上，它会加剧这些问题。
商业智能 的DataVault2.0零碎旨在帮助解决平安问题，利用在 数据模型 中提供间接的集成点，利用实现层，利用架构和我的项目组件的所有办法。