大数据实用DevOps/UML图概述
大数据架构的文档化可能需要重新使用经典的软件架构描述符号，并辅以适当的符号来隔离和识别大数据应用程序的数据密集型特性。从这个角度来看，DICE生态系统提供了大量现成的工具和符号来解决各种质量问题（性能、可靠性、正确性、隐私设计等）。为了利用这些工具，用户必须使用我们定义的显式符号来支持他们的场景。所讨论的符号包括构建特定的UML图，并使用特定的配置文件对其进行丰富，即标准UML机制用于设计特定领域的扩展——在我们的案例中，该机制用于在DICE配置文件中定义构造型和标记值，并且特定于建模数据密集型结构、功能和特性。DICE配置文件将UML元模型调整到大数据应用程序领域。例如，类的通用概念可以变得更具体，即具有更多语义，方法是将其映射到一个或多个具体的大数据概念和技术特征，例如，从更抽象的角度来看的计算和存储节点或Storm Nimbus节点。除了表达能力之外，由于我们使用UML标准定义的元模型及其关系，DICE配置文件背后的模型的一致性仍然得到保证。从本质上讲，这些图及其各自配置文件的作用是双重的
- 提供大数据领域（例如，集群、节点……）和大数据技术（例如，Cassandra、Spark……）特定概念的高级抽象；
- 定义一组由工具检查/评估的技术（低级）属性。
上述活动所包含的方法步骤至少包括以下建模和文档活动
- 详细说明数据密集型应用程序的高级结构架构视图的基于组件的表示（即DPIM组件图）——在DICE范围内，这是使用UML配置文件的简单且熟悉的符号完成的，用户从中绘制必要的构造型和结构来指定其数据密集型应用程序节点（源节点、计算节点、存储节点等）；
- 用关于该表示的属性和非功能规范来增强基于组件的表示；
- 使用技术决策来细化同一个基于组件的表示——这些决策本身代表了选择哪种技术来实现哪个数据密集型应用程序节点。例如，<<CassandraDataStore>>概念构造型与DPIM架构视图中的<<StorageNode>>相关联；
- 关联几个数据密集型技术特定的图，这些图表示每个数据密集型节点的技术结构和属性。这些图本质上“分解”了技术节点并包含特定于这些技术节点的信息。例如，DPIM架构表示中的<<StorageNode>>可以在其DTSM对应物中成为<<CassandraDataStore>>；最后，DTSM层将包含另一个图，更具体地说，是Cassandra集群的数据模型。这些单独的技术特定“图像”用于允许数据密集型应用程序分析和验证；
- 详细说明一个部署特定的组件部署图，其中几个技术特定的图根据其基础设施需求到位。该图属于DDSM层，包含构建可部署和可分析TOSCA蓝图的所有必要的抽象和属性。遵循我们的<<CassandraDataStore>>示例，在此级别，从之前的DPIM <<StorageNode>>结构细化的DTSM <<CassandraDataStore>>节点最终与DDSM图相关联，其中集群的配置完全指定（即VM类型和数量、软件组件到VM的分配等）；
- 最后，一旦数据密集型部署特定的组件图可用，就可以使用DICE部署建模和连接的生成技术（DICE部署建模）来实现该图的TOSCA蓝图。
模型驱动开发（MDD）是一种众所周知的方法，并且已在软件工程的许多领域得到广泛应用。例如，Web和移动应用程序开发，例如WebRatio[1]方法，以及多云应用程序的开发，例如MODAClouds项目，该项目提供了一种名为MODACloudsML的建模方法来指定建模和部署云应用程序及其基础设施需求（例如，VM、资源等）所需的结构和概念。
此外，最近在文献中提出了许多工作，试图在Big Data应用程序的上下文中利用MDD的概念和技术。在其他相关文献中，提出了一种有趣的方法，旨在允许Hadoop MR应用程序的MDD。在定义了Hadoop MR应用程序的元模型（可用于定义应用程序模型）之后，该方法提供了一种自动代码生成机制。输出是一个完整的代码框架，数据密集型应用程序的开发人员必须通过实现主要的应用程序级Hadoop MR组件（Map和Reduce函数）来详细说明该代码框架，以根据生成代码中的占位符进行说明。主要目标是演示MDD如何能够显着减少开发Hadoop MR应用程序的偶然复杂性。Stormgen[2]提供了类似的支持，其目标是提供一种用于定义基于Storm的架构（称为拓扑）的DSL。
这项工作利用Ecore构建元模型，利用Xtext生成语言的语法。Stormgen还使用Xtend语言（Java的一种方言）提供自动代码生成。同样在这种情况下，用户必须为Storm拓扑的每个元素（Bolt和Spout）指定所需的实现，因为主要重点是设计拓扑。该方法的作者计划使用eclipse GMF（图形建模框架）将图形DSL与文本DSL耦合。
虽然这些方法提供了MDD在数据密集型应用程序上下文中实用性的初步证据，但它们都专注于依赖于单一底层技术。此外，它们侧重于开发阶段，并且不针对部署方面，这将需要开发和运营团队对支持技术组件执行的平台节点及其对具体计算和存储资源的分配进行推理。
相比之下，在DICE技术空间中，利用UML建模进行数据密集型应用程序设计的开发人员将需要为其架构结构视图（DICE DPIM）生成（至少）一个组件图，并为其技术特定结构和行为视图（DICE DTSM）生成两个（或更多）图，并注意为其架构结构视图（DICE DPIM）中的每个技术节点生成两个图（结构视图和行为视图），只要需要分析即可。DICE UML建模不鼓励生成许多图，例如出于重新记录的目的——DICE的重点是数据密集型应用程序的质量感知设计和分析。因此，DICE UML建模促进了所有且仅对需要特定分析关注和质量意识的技术节点的建模。最后，设计人员将需要使用部署特定的结构和决策来细化其架构结构视图（DICE DDSM）。
例如，对于一个简单的WordCount应用程序，它包含一个源节点、一个计算节点和一个存储节点，所有三个节点都需要特定的分析和质量改进。因此，设计人员需要在（DICE IDE）中生成总共7个图：(1) 应用程序的整体架构结构视图，包含三个节点（存储、计算和源）以及它们的属性和QoS/QoD注释；(2) 每个需要分析的技术的结构和行为技术特定视图 - 让我们假设分别为存储、计算和源节点技术生成一个类图和一个活动图。最后，需要使用适当的部署特定构造、映射和注释来细化在(1)中生成的图。
下一节将提供上述建模过程的实际使用场景，以阐明DICE建模过程。
作为一个玩具示例，我们参考我们自己设备的一个简单的Storm应用程序，称为WikiStats，它将压缩的20GB XML格式网页流作为输入，其中包含维基百科所有文章的快照。然后，应用程序处理该流以得出文章统计信息。让我们假设我们最初对尽快部署我们的应用程序感兴趣，而不是分析其行为；
我们玩具示例的DPIM模型是两个节点的基于组件的聚合：一个计算节点（负责处理维基页面）和一个存储节点（负责存储和呈现结果）。为了节省空间，我们不提供此简化的DPIM层。
此时，DPIM模型被用作细化DIA建模的基础，并进行适当的技术决策；在我们的例子中，代表DIA节点的DPIM组件图组件使用额外的特定于技术的构造型进行刻板印象，在我们的例子中，即DPIM中唯一计算节点的<<StormApplication>>构造型；这意味着该组件被设置为Storm计算节点。类似地，代表存储节点的DPIM组件图组件使用额外的构造型进行刻板印象，即<<CassandraDataStore>>构造型；这意味着该组件被设置为Cassandra集群。
此时，我们需要“展开”我们使用技术决策细化的DPIM中的两个节点 - 我们需要做的就是创建一个新的类图，并进一步详细说明两个节点的技术细节内部（例如，<<StormApplication>>的Storm拓扑细节和<<CassandraDataStore>>的模式）。因此，我们准备一个新的类图，其中创建一个带有<<StormApplication>>构造型的新类，并立即将其与WikiStats所需的bolt和spout关联；类似地，为bolt准备数据模式并链接到一个<<CassandraDataStore>>类，我们假设不需要进一步的内部细节。
此时，DTSM中使用的技术被映射到物理资源，并应用自动化部署以获得可部署的TOSCA蓝图（有关其他部署功能，请参阅DICER工具和DICE交付服务）。此步骤中的DDSM创建涉及使用DDSM配置文件构造型创建或细化UML部署图。可以使用持续的OCL辅助建模以半自动方式细化UML部署图。在典型场景中，DICE用户从DTSM图中随机选择一项技术，并实例化一个部署节点以在其上应用该技术构造型。随后，DICE用户可以检查该图是否满足DICE-DDSM OCL约束，解决该技术的任何缺失依赖项以及任何缺失的部署规范（例如，其他节点、防火墙、缺失的特性和属性等）。DICE用户应重复此过程，直到DTSM中的所有技术也在DDSM级别建模。最后，一个表示DIA可运行实例本身的部署工件应结束DICE DDSM层的建模。现在开始使用DICER工具的“一键部署”功能创建自动TOSCA蓝图 - 此功能允许在准备好的DDSM工件上激活DICER +部署服务管道，以便可以立即进行部署。
DICE UML建模旨在使用标准UML图提供对质量感知和数据密集型应用程序的连贯且完整的概述，以充分表达和阐明所需的细节。在这些细节中，我们包括：(a) 数据密集型架构的结构视图；(b) 同一架构的行为视图；(c) 架构的技术特定构造的结构和行为视图；(d) 所述架构的基础设施设计。
上述模型旨在记录和支持数据密集型应用程序的质量感知设计和操作。