可扩展的数仓架构

今天的数据仓库系统使得分析师可以很容易地访问集成的数据。为了实现这一点数据仓库开发团队必须根据用户的需求对数据进行处理和建模。开发数据仓库的最佳方法是迭代开发过程这意味着数据仓库的功能是按照业务用户的要求在迭代(有时称为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系统旨在协助解决安全问题利用在数据模型中提供直接的集成点利用实现层利用架构和项目组件的所有方法。