大型数据/技术特定建模的实用DevOps
介绍
当所有必要的架构元素通过 DPIM 层中的架构推理到位时，它可以使解析 DPIM 模型并生成等效 DTSM 模型的即席模型转换可用，其中指定的数据处理需求被展开（如果可能）到使用适当技术的可能配置中（例如，Spark 用于流式传输或 Hadoop 用于批处理）。在此层，应为架构师和开发人员提供几个关键的技术框架包，这些包可以评估技术映射和逻辑实现的可能替代方案，即选择与当前问题相匹配的技术框架并为该框架实现所需的处理逻辑。一旦设计人员选择适当的技术替代方案，DICE 将提供模型转换来实例化该替代方案（如果可用），例如，通过实例化预制的、即席的包，其中包含：(a) 用于“链接”数据密集型应用程序逻辑所需的框架元素（例如，通过继承）；(b) 包含（可选）配置详细信息的框架元素 (c) 表示可部署实体和节点的框架元素（例如，Hadoop Map-Reduce 的主节点和资源管理器）。软件架构师通过填写任何所需的配置详细信息来运行选定的框架，可能与基础设施工程师协作。
DTSM 建模解释：Apache Storm 示例
数据密集型技术特定配置文件 (DTSM) 包含几个技术特定子配置文件，包括 DTSM::Storm 配置文件、DTSM::Hadoop 配置文件以及 DICE::DICE_Library 的改进。Hadoop 和 Storm 配置文件完全整合了质量和可靠性方面。其他 DTSM 配置文件，如 Spark 配置文件，目前正在进行进一步的实验，将在不久的将来完成。总之，Apache Storm 配置文件核心元素、构造型和标记值在以下表格中定义。
Storm 概念
| # | 概念 | 含义 |
|---|---|---|
| 1. | Spout (任务) | 信息来源 |
| 2. | 发射率 | Spout 每单位时间产生的元组数量 |
| 3. | Bolt (任务) | 数据细化和结果产生 |
| 4. | 执行时间 | Bolt 产生输出所需的时间 |
| 5. | 比率 | 所需或产生的元组数量 |
| 6. | 异步策略 | Bolt 等待从任何传入流接收元组 |
| 7. | 同步策略 | Bolt 等待从所有传入流接收元组 |
| 8. | 并行性 | 每个任务的并发线程数 |
| 9. | 分组 | 元组传播策略（shuffle/all/field/global） |
Storm 是一个用于处理大量高速数据的分布式实时计算系统。Storm 应用程序通常被设计为一个有向无环图 (DAG)，其节点是信息生成或处理的位置，边定义了从一个节点到另一个节点的数据传输连接。拓扑中考虑了两类节点。一方面，Spout 是信息源，以一定的发射率将数据流注入拓扑。另一方面，Bolt 消费输入数据并产生结果，这些结果反过来又会发射到拓扑中的其他 Bolt。
Bolt 代表一个通用的处理组件，需要 n 个元组来产生 m 个结果。这种不对称性由比率 m/n 捕捉。Spout 和 Bolt 需要一定的时间来处理单个元组。
此外，应考虑不同的同步策略。从两个或多个源接收消息的 Bolt 可以选择 1) 如果来自任何源的至少一个元组可用，则进行（异步），或 2) 等待来自所有源的消息（同步）。
Storm 应用程序还可以通过节点的并行性和流分组进行配置。并行性指定执行相同类型节点（Spout 或 Bolt）的并发任务数。通常，每个任务对应一个执行线程。流分组确定消息传播到接收节点的方式以及接收节点处理消息的方式。默认情况下，消息广播到当前节点的所有后继节点。一旦消息到达 Bolt，它就会被随机重定向到多个内部线程中的任何一个（shuffle），复制到所有内部线程（all），或者根据某些标准（例如，field、global 等）重定向到特定内部线程子集。
根据其自身定义，DTSM 配置文件包含一个构造型列表，这些构造型解决了 Apache Storm 技术的主要概念。特别是，我们强调那些直接影响系统性能的概念。因此，这些参数对于 Storm 应用程序的性能分析至关重要，并且对 DICE 模拟、验证和优化工具很有用。
此外，Storm 框架可以通过各种参数进行高度配置，这些参数会影响应用程序的最终性能。这些概念被转换为构造型和标签，它们是 UML 提供的扩展机制。因此，我们设计了一个新的 Storm UML 配置文件。在我们的案例中，我们使用 Storm 概念扩展 UML。Storm 的构造型和注释基于 MARTE、DAM、DICE::DPIM 和 Core 配置文件。DICE::DTSM::Storm 配置文件提供真正的构造型。
Spout 和 Bolt 具有独立的构造型，因为它们在概念上是不同的，但是 <<StormSpout>> 和 <<StormBolt>> 通过 DTSM::-Core::-Core-DAG-Node 和 CoreDAGSourceNode 从 MARTE::GQAM::GaStep 构造型继承，因为它们是计算步骤。此外，它们共享并行性，或者执行任务的并发线程数，由标签并行性指定。
另一方面，Spout 添加了标签 avgEmitRate，它表示 Spout 产生元组的发射率。最后，Bolt 使用来自 GaStep 的 hostDemand 标签来定义任务执行时间。处理单个元组所需的时间也可以通过 alpha 标签表示，以防未指定时间单位。从故障中恢复的最小和最大时间由 minRebootTime 和 maxRebootTime 标签表示。
Storm 的流概念由构造型 <<StormStreamStep>> 捕捉。此构造型也从 MARTE::GQAM::GaStep 构造型继承，这使得它可以应用于 UML 活动图的控制流弧。此构造型有两个标签，grouping 和 numTuples，分别对应 Storm 中的 grouping 和 ratio 概念。分组的类型是 StreamPolicy，它是 Basic_DICE_Types 包的枚举类型，具有 all、shuffle、field、global 的值，用于指示消息传递策略。Bolt 的 m/n 比率可以通过 Bolt 构造型中的属性 sigma 表示，或者通过流构造型指定 Bolt 的传入和传出的 numTuples 表示。
最后，引入了 <<StormScenarioTopology>> 构造型来定义 Storm 应用程序的上下文执行信息。也就是说，应用程序的可靠性或每个任务交换消息的缓冲区大小。所有这些构造型都在以下图片中总结，该图片描述了用于 UML 环境的 DTSM::Storm 配置文件。
如前所述 建模介绍，DTSM 配置文件，特别是 DTSM::Storm 配置文件，依赖于标准 MARTE 和 DAM 配置文件。这是因为 DAM 是一个专门用于可靠性和可靠性分析的配置文件，而 MARTE 提供了 GQAM 子配置文件，这是一个用于定量分析的完整框架。因此，它们完全符合我们的目的：数据密集型应用程序的质量评估。此外，MARTE 提供了 NFP 和 VSL 子配置文件。NFP 子配置文件旨在描述系统的非功能属性，在本例中为性能。后者，VSL 子配置文件，提供了一种具体的文本语言，用于指定与性能相关的度量、约束、属性和参数的值。VSL 表达式用于带 Storm 配置文件的模型，具有两个主要目标：(i) 指定模型的输入参数，以及 (ii) 指定将为模型计算的性能指标（即输出结果）。VSL 表达式示例，用于类型为 NFP_Duration 的主机需求标记值是
expr=$b_1 (1), unit=ms (2), statQ=mean (3), source=est (4)
此表达式指定 bolt_1 需要 $b_1 (1) 毫秒 (2) 的处理时间，其平均值 (3) 将从实际系统 (4) 中的估计值获得。$b_1 是一个变量，可以在分析模型期间设置具体的值。另一个有趣的 VSL 表达式是性能指标的定义，该指标将被计算出来，即下一个示例图像中的利用率
expr=$use (1), statQ=mean (2), source=calc (3)
此表达式指定我们要计算 (3) 整个系统或特定资源的利用率，作为时间的百分比，其平均值 (2) 将分配给变量 $use (1)。该值通过与该带 Storm 配置文件的 UML 图相关的性能模型的评估获得。图片的其余部分对应于一个 UML 活动图，它表示 Storm DAG。每个 UML 元素都带有一个 DTSM::Storm 构造型，与之前表格中介绍的概念之一相匹配。所有配置文件元素的配置参数（$_）都是变量。
UML 活动图中的节点按分区分组（例如，Partition1 和 Partition2）。每个分区都映射到 UML 部署图中的一个计算资源，遵循为拓扑定义的调度策略。下一张图片显示了部署图，它补充了之前的活动图。每个计算资源都带有一个 GaExecHost 构造型，并定义其资源多重性，即内核数。部署还允许人们知道任务之间交换的消息可能导致网络延迟，即在不同物理机器上的内核之间交换的元组，这对于最终的性能模型很重要。因此，我们使用 GaCommHost 构造型。这两种构造型都继承自 MARTE GQAM。
