Data Vault2.0方法论之项目定义

定义项目

讨论的职责之一是创建简单但可扩展的解决方案。要承担起这一责任，必须采用迭代方法开发数据仓库。而不是从一开始就规划完整的解决方案，只计划接下来的几个冲刺。这并不意味着我们没有一个总体的想法或数据仓库的总体目标。这只意味着我们不会立即计划每一项任务到达那里，也不会对交付最终解决方案所需的每一个可用的源或信息集市进行建模。 开发团队必须先问客户需要什么，什么对业务最有价值。这是首先交付的，因为交付的依赖关系是满足的。

有时，这需要首先构建一些依赖关系，例如设置初始数据仓库基础设施。然而，最初应该避免建立最终的数据仓库基础设施。起步要小，但要使其具有可扩展性。以不断增长的需求来增长基础设施。

通常，架构师试图逐层创建数据仓库解决方案：他们决定最初的一组源系统，以交付所有所需的报告或OLAP（在线分析处理）立方体。然后，它们实现整个集结区以捕获所有源表，包括加载表的ETL。一旦他们完成了集结区，他们就开始最大限度地建模企业数据仓库，因为以后接触它代价太高了。在实现ETL负载作业后，创建数据集市以最终满足业务用户。 这种方法通常需要几个月，如果不是几年完成，包括几个阶段的调试和错误修复。然而，当需求发生变化（本例中的架构师会说“太频繁”)或业务需要额外功能(在许多情况下，初始架构师已经离开组织)时，问题就会出现。

鉴于Data Vault2.0标准中的可扩展模型和架构以及敏捷方法，数据仓库架构师不再需要遵循这种方法。 数据仓库不是以一种水平的方式、一层一层地构建数据仓库，而是以一种垂直的方式按特征构建数据仓库。数据仓库倡议的总体目标是相同的，但现在是在逐步交付功能方面实现的。BI团队的目标是在快速和频繁的发布中交付所需的功能，如本章前面的章节所述。为了做到这一点，必须将功能范围限定为尽可能与其他功能分离的单个功能。
实现这一目标的建议方法是在需求工程和单个特性的实现中使用范围界定的方法，如图3.11所示。

图 3.11 界定报告

如图所示的示例中要实现的特性是报表，但可能是用户所需的任何其他工件。例如，它可以是OLAP立方体中的一个新维度或属性、一个单独的新OLAP立方体（具有最小维数）或用于文本挖掘的语料库。一旦业务对该工件进行了范围划分和描述，IT就开始识别构建此单一报表所需的源(源系统中的表。接下来，确定信息集市目标，以评估已经到位的内容，以交付所需的报告（或其他功能）。一旦执行了此标识，工程师就可以对所需的数据进行分级、构建和加载Data Vault实体，并构建集市。在遵循此过程时，源表中的所有数据都在Data Vault中加载和建模，而不是部分属性集。因此，源表只能接触一次，而不是多次。为了评估数据的可用性，应该可以跟踪哪些数据已经加载到企业数据仓库中。部分加载的数据使此评估更加复杂，这是我们想要避免的。此外，只从源表加载部分数据会产生更复杂的Data Vault卫星。

定义迭代中要开发的工件（即需求变更）是迭代成功的重要前提。适当的范围界定减少了团队无法在一个冲刺的时间框架内完成和部署更改的风险。如果不确定所需的变化范围，也不可能实现两周甚至一周的短冲刺。此外，由于Data Vault2.0模型，团队现在能够跨业务行增量地构建解决方案——因此它们可以在实现范围内具有灵活性。

应该注意两个共同的反对意见：第一个反对意见是从一个源实现所有表，以保持集成源系统的成本低-在这种情况下，加载当前解决方案不需要的数据。加载这些数据需要额外的ETL容量，这需要更大的初始基础设施。此外，从一个源系统实现所有源表可能不会在一个sprint中完成，并绑定可以用于实现要交付给业务的特性的人力。这种努力往往超过了评估Data Vault中已经存在的数据的复杂性（在关注表时很容易）。另一个问题是，当将源表实现到集结区时，将数据集成到Data Vault中也是一个很好的实践。否则，当两个系统都可能不同步时，就需要额外的复杂性来评估数据仓库的当前状态。加载所有源表完全需要完整的建模和加载相应的Data Vault表，如果应该遵循这种做法。

第二个反对意见是，为了实现最终解决方案，多次接触目标是代价高昂的。这可能是正确的，但最终的目标是在一个sprint中为业务提供可运行和有用的功能，因为它降低了失败的风险：业务不接受解决方案，例如因为不满足书面要求，需求在此期间发生了变化，或者一旦业务用户实际使用了解决方案，解决方案就会被证明是错误的。

这种垂直的信息传递方法是在一个sprint中执行的。根据组织能力的不同，这可能是两到三周的时间。因此，Data Vault的建模不应该需要几个月。相反，模型应该在sprint的持续时间内创建。如果需要更长的时间，这是一个很好的指标，冲刺的范围太大。在这种情况下，应该从sprint中删除功能。 删除所有不需要以单一特性交付的内容，这是本次冲刺的重点。 确保业务用户理解此功能仍有待交付——但在以后的冲刺阶段。通常情况下，业务用户认为功能完全被删除是因为它在计划中从sprint中删除。然而，这是错误的，因为缺失的功能将在下一次或下一次迭代后很快交付。一旦业务用户看到了项目的进展，他们自然会接受这个程序。

敏捷需求收集

在sprint中实现新功能之前，需要定义它。然而，需求收集过程与实施过程非常相似。通常，业务对要在数据仓库中实现的功能有一个大致的想法。但是IT还有很多问题需要回答，比如关于数据源的问题，聚合或转换数据的业务规则，数据类型，用例等。为了回答这些问题，使用了需求集合。

为了支持需求收集的敏捷方法，需求是沿着过程收集的，与传统的数据仓库不同，这些需求是在项目开始时收集的。在我们的项目中最有效的方法是使用Raw Marts（原始集市）并将数据快速推出到需求会议以供审查。 这些Raw Marts（原始集市）用于向出席需求会议的有限数量的业务用户创建报告或立方体，而不是用于分发。这是因为Raw Marts（原始集市）包含有或不完全实现业务规则的原始数据。通过演示，向用户展示这些报告，并问他们：“这个报告有什么问题？”事实证明，业务用户可以很容易地指出报告中的问题，并通过这样做，提供IT实现最终报告所需的所有业务规则。

这种需求收集方法的程序如下：

1. 确定所需的数据：如上一节所述，第一步是确定Raw Mart及其报告的数据来源。 再次，只应将范围内的数据加载到集结区并进入企业数据仓库。如果可能，甚至应减少数据以实现快速输出。例如，在第一步中，应只保留最终报告所需要的数据，而不包括中间原始报告所需要的数据。
2. 生成Raw Mart（原始集市）：一旦数据被加载到Raw Data Vault（原始Data Vault），就会从这些原始数据中创建Raw Mart。在加载Raw Mart时没有实现业务规则。取而代之的是，数据的格式简单地从Data Vault模型更改为维度模型。虚拟视图最适合这种方法，因为它们可以很容易地构建。
3. 生成原始报表：一旦数据在维度Raw Mart中，就可以创建原始报表。 由于没有对数据应用业务规则，所以报告包含好数据、坏数据和脏数据。

到目前为止，IT控制了交付时间。他们有责任敏捷到这一点。下一步从项目的业务方面驱动：

4. 在墙上张贴原始报告：当原始报告已经从Raw Mart（原始集市）创建时，报告将提交给需求会议的与会者。好的方法是打印，把它们贴在房间的一边。如果这是不可能或不可行的，也可以使用液晶投影仪向小组展示报告。然而，墙上张贴报告的优点是与会者可以花时间审查报告，并将他们的评论或更正直接添加到打印件中。报告中的大多数问题都很容易得到。他们可以向IT解释报告有什么问题，以及为什么他们不能在这种状态下使用它们。
5. 收集业务规则和其他要求：IT应该直接询问与会者是什么使报告无法使用，以及如何使该报告对业务有用。为了使数据正确，需要对数据进行哪些修改？业务方面的答案是缺少的业务规则，这些规则需要记录在需求文档中，并应用于进入原始报告的数据。请注意，应该更少关注报告的安排，因为这种讨论应该由业务方面驱动，在最好的情况下，不依赖于IT。

一旦需求被收集，至少部分地，IT通过执行业务规则和其他需求再次驱动项目：

6. 转换业务规则和其他需求：最后一步是将业务规则和其他需求，由业务给出并记录在需求文档中，转换为程序逻辑。这可以在ETL流中完成，也可以在SQL视图中完成。业务规则将原始数据转换为从原始Data Vault到业务仓库或信息集市的途中的信息。

在这些业务规则由IT实现后，项目的业务方可以对输出进行审查和测试，如果它们还不满意最终结果，则要求进一步修改。然而，这些修改成为需求变更，并在随后的sprint中实现。所描述的敏捷需求收集过程帮助业务用户表达他们的业务规则。对其中许多人来说，传统上对需求文档的关注过于抽象，并阻止了所需的标识与报告草稿一起识别问题。

建议的做法是记录这些要求会议，并建立一个Wiki网站，供组织中的每个人使用。会议记录，包括对已发现的业务规则的说明，应登记在网站上，以确保需求收集过程的透明度。 Web2.0机制使参与者能够根据自己的理解发布评论甚至修改业务规则。这种方法首先确保需求是正确的。如果在网站上进行了大量的讨论，可能需要另一次需求会议来澄清任何开放的问题，然后才能开始实施。在实际实施之前进行这些讨论意味着对本组织的巨大好处和生产力的提高，是项目总体成功的一个促进因素。为了对团队的功能做出正确的假设能够在一个冲刺中完成，这对于范围界定很重要，团队必须能够对完成某些功能所需的努力做出正确的估计。本专题将在下篇文章中讨论。