大数据实用 DevOps/方法论

在本章中，我们将介绍一种设计大数据应用程序的方法。其基本思想是将模型驱动工程技术融入 DevOps 开发生命周期。为什么这种方法适合且有利于数据密集型软件？这个问题是合理的，我们将首先回答它。我们将从倡导在 DevOps 中使用模型开始。然后我们将看看将模型驱动 DevOps 应用于大数据应用程序构建的一些好处。最后，我们将介绍我们的方法论建议以及 DICE IDE 如何支持它。

模型驱动 DevOps

在一个典型的组织中，开发人员在一个隔离的、临时的、开发环境中构建和测试软件——通过使用所谓的集成开发环境 (IDE)，例如 Eclipse 或 Visual Studio——而操作人员负责目标的、最终的、生产环境。后者从概念上包含应用程序计划与之交互的所有实体：操作系统、服务器、软件代理、人员等等。操作人员负责，除其他事项外，准备生产环境、控制它并监控它的行为，尤其是在应用程序部署到其中之后。

在 DevOps 之前，开发人员和操作人员通常组成两个独立的团队。结果，前者没有完全了解他们的开发环境与生产环境的不同。他们在开发环境中构建和测试应用程序时没有看到的问题，一旦操作人员将其安装到生产环境中，就会突然出现。DevOps 建议将开发人员——“DevOps”的“Dev”前缀——和操作人员——“DevOps”的“Ops”后缀——放到同一个团队中。这样，现在这两者之间存在持续的协作，极大地增加了对创建的每个软件组件都已真正准备好投入生产的信心。实际上，由于操作人员是那些非常了解生产环境的人，他们对开发人员的积极和持续支持导致了以生产意识为导向的程序设计。当构建、单元测试、集成、集成测试、交付、系统测试、部署和验收测试阶段完全自动化时，这种合作的连续性体现了其全部价值。

DevOps：从集成到部署

在 DevOps 中，由不同的 DevOps 团队构建的软件组件被隔离地测试（单元测试）。然后将它们组装在一起以创建一个单一软件（集成）。之后，对软件进行测试（集成测试）并将其放入一种形式——通常称为包——以方便其分发（交付）。接下来，对包进行测试（系统测试）并将其安装到生产环境中（部署）以进行最后一次测试（验收测试）。DevOps 规定操作人员应协助开发人员以完全自动化这些阶段。完成后，分别实现持续集成、持续交付、持续部署和持续测试。

模型驱动实践已被证明对其设计程序和生成其源代码有用。因此，模型驱动工程已经很好地涵盖了软件组件的构建和单元测试。我们的想法是使用模型来自动化集成、交付和部署。DICE 联盟为此目的发明了一种建模语言。（该语言不处理集成。）已经开发出工具让开发人员和操作人员共同对应用程序及其生产环境进行建模，并在不同的抽象级别上进行建模。这些工具解释模型以自动准备和配置生产环境，以及将应用程序部署到其中。以下是这种方法的一些优势

1. 模型不仅指定应用程序，还指定适合它的生产环境。
2. 更重要的是，由于描述了生产环境的属性，因此有时可以利用模型在任何部署之前正式地模拟或验证（即抽象地和数学地）应用程序在其生产环境中的行为。
3. 开发人员和操作人员通用的建模语言有助于他们之间更好地沟通。由于模型中使用的概念定义明确，因此消除了歧义和误解。
4. 可以通过它们的模型直接重构应用程序及其生产环境。
5. 应用程序的上市时间缩短，因为现在计算机执行了一些开发和运营任务。

DICE 联盟已经对这五个要点进行了试验，并发现该方法相关。大数据应用程序通常依赖于大数据技术，这些技术大多以难以学习而闻名。从我们的角度来看，模型驱动 DevOps 可能会有所帮助。

大数据模型驱动 DevOps

术语大数据用于描述传统数据系统无法有效处理新数据集的能力，这些数据集是海量的（容量）、快速到达的（速度）、来自各种来源且格式多样（多样性），以及其流速可能突然变化（可变性）。容量、速度、多样性和可变性被称为大数据的四个 V。处理它们的一种正统方法是垂直扩展，即加快算法或硬件（例如处理器或磁盘）的速度。这种方法显然有限，而且毫无意外地失败了。大数据是向水平可扩展的并行处理系统的转变，其能力通过向现有集合中添加更多机器而增长。

美国国家标准与技术研究院 (NIST) 发布了一个有价值的大数据分类。下图显示了一个略微修改的版本。从上到下是服务提供链：系统协调器期望大数据应用程序具有一些功能，这些功能由大数据应用程序提供商实现，并在大数据框架提供商设计的大数据框架的帮助下实现。从左到右显示了信息流链：数据所有者向数据提供商提供信息片段，数据提供商对其进行数字化并将它们传输到大数据应用程序以进行处理。数据消费者获得其输出，这些输出可以以用户友好的方式传达给数据查看器。这九种功能角色的不同活动都包含在安全和隐私问题中。

修改后的 NIST 大数据分类

大数据总是具有社会方面。系统协调器、大数据应用程序提供商、大数据框架提供商、数据所有者和数据查看器通常是个人或组织。这就是为什么一个专用符号代表它们的原因。数据所有权特别是一个法律概念，很难进行全面定义。一个基本定义可能是

数据所有者

数据所有者是指拥有某条数据并行使对其权利的个人或组织。它有法律权力阻止其他人利用其数据，并且可以采取法律行动来做到这一点——通常在某些条件下。

个人、科学家、研究人员、企业和公共机构显然是数据所有者。数据所有权是可以共享的。实际上，在使用大数据系统——例如 Facebook——之前，数据所有者通常必须接受一项协议，他们自己和系统协调器将受该协议约束。有时，使用该系统隐含地表示接受该协议。在某种程度上，该协议可能会将数据所有权让与系统协调器。例如，每个填写过要求提供个人数据的在线表格的网民可能都曾在某个场合看到过一个“我同意条款和条件”复选框。通常，这些条款和条件会要求用户允许对他的数据执行特定操作。例如，通过单击复选框，用户可以授予系统协调器将数据披露给业务合作伙伴的自由。系统协调器的角色可以是以下角色

系统协调器

系统协调器是指其职位允许其参与关于大数据系统需求的决策过程，以及参与监控或审核活动以确保构建或正在构建的系统符合这些需求的个人或组织。

系统协调器例如解决数据策略、数据导入要求、数据导出要求、软件要求、硬件要求和可扩展性要求。我们在系统协调器中发现了：业务所有者、业务领导者、业务利益相关者、客户、项目经理、顾问、需求工程师、软件架构师、安全架构师、隐私架构师和网络架构师。

数据查看器

数据查看器是指大数据系统向其传达一些信息的人或组织。

在图中，方框代表硬件或软件。数据提供者、数据消费者、大数据应用和大数据框架都是数字实体。他们的工作是处理数据。当我们说数据时，我们总是指数字数据。我们使用术语信息来表示非数字数据。我们称知识为所有真实的的信息。真实性——另一个 V——是大数据中一个重要的关注点。

数据提供者

数据提供者是指提供自身或他人可用数据的硬件或软件。它负责访问权限，并确定谁可以读取或修改其数据，通过何种方式，以及哪些是允许的和禁止的利用。

数据库管理系统符合此定义。数据提供者拥有许多可用的数据传输方法：事件订阅和事件通知、应用程序编程接口、文件压缩、互联网下载等等。他们也可以选择创建查询语言或其他机制，让用户在不获取数据的情况下导入处理。这种做法被称为将计算移至数据而不是将数据移至计算，并在上图中以有向弧表示。数据提供者可以将从数据所有者输入或获取的信息转换为计算机可以处理的数字数据。在这种情况下，它是大数据系统与非数字世界之间的界限。例如，这是对话框或在线表单的功能。所有捕获设备，例如摄像机和传感器，也是数据提供者。

大数据应用和大数据应用提供者

大数据应用是指从数据提供者提供的數據中提取新数据的软件。它由大数据应用提供者设计和开发。

大数据应用是一种特殊的数据提供者——即依赖其他数据提供者的数据提供者。但并非所有数据提供者都是大数据应用。例如，数据库管理系统不是大数据应用，因为它本身不会生成新数据。大数据应用通常执行以下任务：从数据提供者收集数据、数据准备和分析。传统的工具和基础设施无法有效地处理大型、多样化且快速生成的数据集。为了让组织能够利用此类数据的全部潜力，找到一种新的数据捕获、存储和分析方法非常重要。数据准备发生在分析过程之前和之后。事实上，正如俗语所说，垃圾进，垃圾出。同样，糟糕的数据，糟糕的分析。因此需要准备数据。例如，来自不可信数据提供者的数据和格式不正确的数据应该被丢弃。分析之后，大数据应用可能会整理结果，以便数据消费者能够更轻松、更有意义地在屏幕上显示它们。所有这些任务都存在于传统的数据处理系统中。然而，大数据的规模、速度、多样性和可变性维度彻底改变了它们的实施。在DevOps中，开发人员和运营人员是大数据应用提供者。

大数据框架和大数据框架提供者

大数据框架是指基础设施或技术资源或服务，它赋予大数据应用处理不断增长的海量数据集合所需的效率和水平扩展能力。它由大数据框架提供者提供。

NIST 将大数据框架分类为基础设施框架、数据平台框架或处理框架。基础设施框架提供者为大数据系统提供所需的硬件部件：存储设备、计算机、网络设备、冷却设施等。基础设施可能隐藏——云化——在通过应用程序编程接口提供的服务背后。例如，此服务可能允许用户按需远程创建、启动、停止和删除虚拟机或容器。数据中心和云提供商属于此类大数据框架提供者。数据平台框架是数据存储程序，它利用网络将数据以可扩展的方式分布到多台机器上。因此，连接的机器越多，获得的存储空间就越大。Hadoop 分布式文件系统 (HDFS) 和 Apache Cassandra 都是数据平台框架。处理框架，如 Hadoop MapReduce 和 Apache Spark，将处理分布在数据的位置。增加机器不应损害数据检索和处理的效率。相反，应该观察到更好的性能。开源社区在改进数据平台和处理框架方面进行了大量的创新。

数据消费者

数据消费者是指使用或接收来自大数据应用的输出的软件或硬件。

九种功能角色并不相互排斥。理论上，可以同时成为系统协调者、数据所有者、数据查看者、大数据应用提供者和大数据框架提供者。一个程序可以同时是大数据应用、数据提供者、数据消费者和大数据框架。例如，让我们考虑以下图中所示的虚构场景

NIST 大数据系统示例

两个用户用户 1 和用户 2 连接到一个大数据系统。他们都通过图形用户界面与之交互。让我们想象GUI 1 是用户 1 浏览的网站，GUI 2 是用户 2 运行的桌面应用程序。应用 1 和应用 2 是两个大数据应用。存储 和分析器 分别是数据平台框架和处理框架。用户 1 输入的信息通过GUI 1 传输到应用 1。应用 1 将其保存到存储 中，并将其转发到应用 2。分析器 不断分析存储 中包含的数据，并将分析结果也发送到应用 2。拥有所有这些输入，应用 2 执行某个算法并将结果传输到GUI 1 和GUI 2，最后将其揭示给他们的用户。在这个场景中，许多参与者扮演着多个角色。例如，用户 1 是数据所有者和数据查看者，而存储 是数据提供者、数据消费者和大数据框架。

我们可以将 NIST 的分类法视为一种与技术无关的建模语言，并将上图视为使用它设计的模型。技术选择没有被指出：存储 可以由 Apache Cassandra 或 HDFS 实现，而分析器 可以是 MapReduce 或 Spark 作业。这种建模语言的一些规则非正式地可以是

1. 每个节点都有一个名称（例如“分析器”）、一个图标和标签——至少一个。
2. 节点名称和节点图标可以自由选择。
3. 允许的节点标签是：数据所有者 (DO)、数据查看者 (DV)、系统协调者 (SO)、大数据应用提供者 (BDAP)、大数据框架提供者 (BDFP)、数据提供者 (DP)、大数据应用 (BDA)、数据消费者 (DC)、大数据框架 (BDF)、基础设施框架 (IF)、数据平台框架 (DPF) 和处理框架 (PF)。
4. 由于大数据应用是数据提供者，因此标记为 BDA 的节点也必须标记为 DP。类似地，标记为 IF、DPF 或 PF 的节点也必须标记为 BDF。
5. 信息流仅允许：(a) 从数据所有者到数据提供者；以及 (b) 从数据消费者到数据查看者。
6. 数据流仅允许：(a) 从数据提供者到大数据应用；(b) 从大数据应用到数据消费者或大数据框架；以及 (c) 从大数据框架到大数据应用或其他大数据框架。
7. “提供”关联仅允许：(a) 从大数据应用提供者到大数据应用；以及 (b) 从大数据框架提供者到大数据框架。
8. “使用”关联仅允许：(a) 从系统协调者到大数据应用；(b) 从数据所有者到数据提供者；(c) 从大数据应用到数据提供者或大数据框架；(d) 从大数据框架到另一个大数据框架；(e) 等等。
9. 等等。

元对象设施 (MOF) 是对象管理组 (OMG) 的一个标准，适合严格定义建模语言。著名的统一建模语言 (UML) 本身就是用 MOF 规范的。UML 的情况很突出，因为 UML 具有一个配置文件机制，使设计人员能够专门为特定领域定制所有 UML 图表的含义。在实践中，语言发明者有两个选择：要么从头开始，直接使用 MOF，要么将 UML 适应感兴趣的主题。Eclipse 支持这两种方法。Eclipse 建模框架 (EMF) 是 Eclipse IDE 的一组插件，它包含了名为 Ecore 的 MOF 实现。而 Eclipse 项目 Papyrus 提供了基于 Ecore 的 UML 实现。

在上一节中，我们介绍了模型驱动 DevOps 的五个优势。在大数据环境下，还有更多内容需要说明。大数据框架——基础设施框架、数据平台框架和处理框架——通常难以学习、配置和管理，主要是因为它们涉及无限数量的计算资源的可扩展集群。使用模型驱动 DevOps，事情变得更容易。运营人员只需在他们的模型中声明他们在生产环境中想要哪些技术，以及性能要求。他们让模型到生产工具自动以满足服务质量 (QoS) 要求的方式安装和配置集群。部分负担由工具承担。

方法建议

现在，我们已经阐明了什么是模型驱动 DevOps 以及它对大数据的便利性，现在是时候详细介绍我们的软件开发方法论了。参与该方法论的行动者是大数据应用程序提供者——开发人员和运营人员——以及一些系统协调者——架构师和项目经理——因为他们实际上是唯一构建、监督或监控大数据应用程序构建的人。简而言之，通过遵循我们的方法，这些行动者可以轻松地使用建模语言来试验大数据系统的架构，并用这种语言来塑造他们的想法。一个包含所有大数据技术的架构模型，可以由模型到生产工具自动且具体地复制到云基础设施上。因此，他们可以比较他们所设想的内容和他们所得到的内容。任何为了提高性能或质量而对模型进行的更改，也可以自动传播到云基础设施上（持续部署）。我们将该方法论分为三种场景，这些场景说明了利用模型驱动 DevOps 实践大数据的替代方法：架构建模、架构分析和架构实验。

架构建模

如今，建模已成为软件工程的标准。无论是用于架构决策、文档、代码生成还是逆向工程，今天软件专家都会绘制模型，并且他们可以使用多种工业标准符号。建模是我们方法论的基石。DICE 联盟的建模语言遵循 OMG 的模型驱动架构 (MDA) 的理念：它包含三个抽象层：平台无关层、技术特定层和部署特定层。使用平台无关的概念，架构师可以根据计算节点、源节点、存储节点等描述一个大数据系统，而无需明确说明底层技术。DICE 平台无关模型 (DPIM) 类似于使用 NIST 分类法进行的模型，只是概念的命名不同。以下是一些部分概念对应关系：

DPIM 概念	NIST 分类法中的对应概念
数据密集型应用程序 (DIA)	大数据系统
计算节点	处理框架和大数据应用程序
源节点	数据提供者
存储节点	数据平台框架

与 NIST 分类法相反，DPIM 概念是相互排斥的。（DPIM 源节点不提供持久性功能；因此，存储节点不能是源节点。）此外，DPIM 没有基础设施框架的概念，因为基础设施是部署特定层处理的低级问题。完整的 DPIM 概念列表将在后续章节中解释。

DPIM 模型对应于 OMG MDA PIM 层，并描述应用程序的行为，作为一个有向无环图，它表示计算和数据之间的依赖关系。

——DICE 联盟

DICE 技术特定模型 (DTSM) 通过为每个计算节点、源节点、存储节点等采用一种技术来细化 DPIM。例如，架构师可以选择 Apache Cassandra 或 HDFS 作为他们的一个存储节点。同样，DTSM 对这些技术将被部署到的基础设施没有说明。DICE 部署特定模型 (DDSM) 的作用是指定它们。DDSM 通过基础设施选择来细化 DTSM。这里，基础设施一词应理解为基础设施即服务 (programmable) (IaaS)。它实际上是指通过互联网访问的基础设施的计算能力。虽然用户看不到底层硬件，但有一个应用程序编程接口，使他能够以编程方式创建虚拟机或容器，选择操作系统并运行软件。一个图形用户界面可以让他交互地完成相同的工作。模型到生产工具依赖于 DDSM 和基础设施的 API 来运行。

以下是本场景的步骤：

1. 绘制一个使用 DPIM 概念进行配置的 UML 对象图，以描述大数据系统中的组件。
2. 绘制一个使用 DPIM 概念进行配置的 UML 活动图，以描述这些组件的操作。
3. 使用 DTSM 概念细化前面两个图。
4. 绘制一个使用 DDSM 概念进行配置的 UML 部署图，以描述这些技术将如何部署到基础设施中。
5. 生成使用基础设施 API 的脚本，并运行这些脚本以获得生产环境。

架构分析

以下是本场景的步骤：

1. 绘制一个使用 DPIM 概念进行配置的 UML 对象图，以描述大数据系统中的组件。
2. 绘制一个使用 DPIM 概念进行配置的 UML 活动图，以描述这些组件的操作。
3. 绘制一个使用 DPIM 概念进行配置的部署图，以描述组件在模拟环境中的部署。
4. 运行模拟。
5. 使用 DTSM 概念细化前面三个图。
6. 运行模拟或验证。
7. 运行优化以生成一个优化的 UML 部署图，该图使用 DDSM 概念进行配置。
8. 生成使用基础设施 API 的脚本，并运行这些脚本以获得生产环境。

架构实验

监控和测试生产环境中大数据系统的质量，并重构模型。

DICE 方法论在 IDE 中

DICE IDE 基于 Eclipse，它是基于 MDE 方法创建软件工程模型的事实标准。DICE 使用合适的插件定制 Eclipse IDE，这些插件集成不同 DICE 工具的执行，以最大程度地减少学习曲线并简化采用。并非所有工具都以相同的方式集成。已定义了多个集成模式，这些模式侧重于 Eclipse 插件体系结构。它们允许非常快速地实现和合并应用程序功能。DICE 工具可以通过 DICE 工具菜单访问。

DICE IDE 提供了通过 UML 模型指定 DIA 的能力。从这些模型中，工具链指导开发人员完成不同的质量分析阶段，其中形式化验证是其中之一。

IDE 作为方法论的前端，在集成框架中的 DICE 工具方面发挥着至关重要的作用。DICE IDE 可用于方法论中描述的任何场景。IDE 是一个用于模型驱动工程 (MDE) 的集成开发环境工具，设计人员可以在不同的级别（DPIM、DTSM 和 DDSM）创建模型，以描述数据密集型应用程序及其底层技术栈。

DICE IDE 最初提供了使用 DICE 配置文件进行立体化的 UML 模型来指定数据密集型应用程序的能力。从这些模型中，工具链指导开发人员完成不同的质量分析阶段（例如，模拟和/或形式化验证）、部署、测试和通过监控数据收集和连续数据仓库获取反馈数据。基于运行时数据，一个迭代质量增强工具链检测质量事件和设计反模式。然后，将反馈用于指导开发人员完成迭代质量增强的循环。