大数据/质量优化实用DevOps
如第1节所述，近年来全球数据生成量急剧增加，同时开发并广泛采用了多个针对大数据范式的软件项目。许多公司目前将其核心业务活动的一部分纳入大数据分析，然而，尚无工具和技术来支持设计支持此类系统底层硬件配置。DICE优化工具（代号D-SPACE4Cloud）是一个支持此任务的软件工具。它能够支持软件架构师和系统运营人员在共享Hadoop云的容量规划过程中。
如今，数据密集型应用程序的采用已从实验项目转变为提供竞争优势和业务创新的关键型企业级部署。大数据集群的部署和设置是一项耗时的活动。最初，MapReduce作业旨在在专用集群上运行。现在，数据密集型应用程序已经发展，不同用户提交的大型查询需要在共享集群上执行，并且可能需要对其持续时间进行一些保证。容量分配成为最重要的方面之一。确定在执行异构任务的多个用户之间共享的集群中的节点最佳数量是一个重要且困难的问题。
据作者所知，目前尚无可用的工具提供专门针对DICE参考技术开发的此类特性。
D-SPACE4Cloud是一个新颖的工具，它实现了多种优化和预测技术，以便有效地评估多种替代资源配置，以确定满足服务质量 (QoS) 约束的最低成本集群部署。简而言之，该工具实现了一个搜索空间探索，能够确定一组并发应用程序的最佳虚拟机 (VM) 类型和实例副本数量。底层优化问题被证明是NP难的，并且是启发式解决的，而应用程序执行时间或吞吐量则通过排队网络 (QN) 或随机良构网络 (SWN) 模型进行估计。
使用D-SPACE4Cloud可以进行两种主要分析
- 公有云分析：在这种情况下，软件架构师或系统运营人员希望分析整个大数据集群在公有云上配置的情况。此选择带来的第一个结果是，可用于配置集群的虚拟化资源（即VM）可以被认为是无限的。这也意味着，在拒绝作业的成本远高于VM租赁成本的常见假设下，在这种情况下，它不会应用任何作业拒绝策略。因此，每个作业的并发级别（即运行数据密集型应用程序的并发用户数量）可以任意设置，因为（理论上）始终有可能配置能够处理负载的集群。在这种情况下，系统运营人员可能想知道要选择哪种机器类型以及要选择多少台机器才能以一定的并发级别执行应用程序，这意味着考虑在集群中同时运行多个类似的应用程序。她/他可能还想了解选择哪个云提供商更便宜，因为提供商也具有不同的定价模型。
- 私有云分析：在这种情况下，集群在内部配置。在某种意义上，此选择从根本上改变了问题。实际上，用于构成集群的资源通常受可用硬件的限制。因此，资源配置问题必须考虑在能够配置能够满足一定并发级别和截止日期的集群之前耗尽计算能力（内存和CPU）的可能性。在这种情况下，软件架构师或系统运营人员可以考虑两种子场景
- 允许作业拒绝，即考虑拒绝一定数量的作业（从而降低并发级别）的可能性，即引入准入控制 (AC) 机制。在这种情况下，由于总容量有限，系统通过拒绝作业来应对过载；这会影响执行成本，因为认为可以将经济处罚与拒绝相关联似乎是合理的。
- 拒绝作业拒绝，即强制执行必须遵守的特定并发级别。这转化为问题的强烈约束，该约束可能无法使用现有的资源来满足。
在这种情况下，D-SPACE4Cloud 估计支持数据密集型应用程序执行所需的内部集群的总容量，最大限度地减少系统的总拥有成本 (TCO)，其中包括物理服务器采购成本、电力成本以及可能因作业拒绝而产生的罚款。
D-SPACE4Cloud是一个分布式软件系统，能够利用多核架构并行执行优化，它包含不同的模块，这些模块通过遵循面向服务架构 (SOA) 范式的RESTful接口或SSH进行通信。特别是，它具有表示层（Eclipse插件）、编排服务（称为前端）和横向可扩展的优化服务（称为后端），后者利用第三方服务作为RDBMS、模拟器和数学求解器。该工具实现了能够有效探索可能配置空间的优化机制，此后称为解决方案空间。图1描述了优化场景中发挥作用的D-SPACE4Cloud架构的主要元素。Eclipse插件允许软件架构师指定输入模型和性能约束，并将输入DICE UML图转换为性能求解器（GreatSPN或JMT）的输入性能模型。前端提供了一个图形界面，旨在方便下载优化结果（通过批处理作业计算），而后端实现了一种旨在识别最低成本部署的策略。多个DTSM作为输入提供，每个VM都作为候选部署。VM可以与不同的云提供商关联。D-SPACE4Cloud将识别满足性能约束并最大限度地降低成本的VM类型及其数量。该工具还将DDSM模型作为输入，该模型使用找到的最终解决方案进行更新，并且可以通过DICER工具自动部署。此外，该工具需要输入执行环境的描述（提供商列表、VM类型列表或内部可用计算能力的描述）和性能约束。用户可以通过向导指定输入文件和参数。D-SPACE4Cloud利用DICE Simulation工具中实现的模型到模型转换机制来生成合适的性能模型，即SWN或QN，用于预测Hadoop MapReduce或Spark DIA的预期执行时间或Storm的集群利用率。初始解决方案构建器使用混合整数非线性规划 (MINLP) 公式生成问题的起始解决方案，其中作业持续时间通过凸函数表示：图1提供了更多详细信息。快速MINLP模型用于确定所有应用程序最具成本效益的VM类型。然而，返回的解决方案的质量仍然可以得到改善，因为MINLP问题只是一个近似模型。出于这个原因，采用了更精确的QN或SWN来获得每个应用程序更准确的执行时间评估：提高的准确性为进一步降低成本提供了空间。但是，由于QN或SWN模拟非常耗时，因此必须以最有效的方式探索可能的集群配置空间，避免评估没有希望的配置。
鉴于上述考虑，我们采用了启发式方法并设计了一个名为并行LS优化器的组件。在内部，它实现了并行爬山（HC）技术来优化每个应用程序分配资源的副本数量；目标是找到满足QoS要求的最小资源数量。此过程独立地、并行地应用于所有应用程序类别，并在进一步减少副本数量会导致不可行解决方案时终止。特别是，HC是一种基于局部搜索的过程，它对当前解决方案进行操作，在解决方案的结构中进行更改（通常称为移动），以便新生成的解决方案可能显示改进的目标值。如果移动成功，则将其再次应用于新解决方案，并重复此过程，直到不再可能进一步改进。当找到局部最优时，HC算法停止；但是，如果要优化的目标是凸的，则HC能够找到问题的全局最优。这是所考虑的成本函数的情况，因为它线性依赖于集群中VM的数量，因为在基于MINLP技术的优化过程的第一阶段，要使用的VM类型是固定的。换句话说，VM类型的联合选择及其数量是NP难的，但是当在第一阶段固定VM类型时，HC可以在多项式时间内获得所有类别的最终解决方案。HC移动包括增加/减少和更改每个DIA的VM类型。此任务在可能的情况下并行执行，将SLA和可用资源（在私有云的情况下）视为约束。并行性尤其重要，因为在优化过程中产生的每个解决方案都通过仿真进行评估，这是一项耗时的任务。因此，为了使DICE优化工具可用，我们专注于尽可能提高并行级别。然后，找到的最终最小成本配置将返回到D-SPACE4Cloud Eclipse插件，并转换为DDSM，该DDSM已准备好进行由DICER工具实现的TOSCA模型到文本的转换和部署。
即使D-Space4Cloud实现了高效的并行搜索，仿真仍然很耗时。一个能够显著加快设计空间探索时间的专用模拟器的开发正在进行中。这样，我们预计优化时间可以从当前实现中的数小时减少到数分钟。此外，对复杂应用程序DAG的建模也需要大量工作。一个日志处理器的开发也在进行中，该处理器可以从应用程序日志（一旦早期DIA代码实现可用）自动构建所需的DICE UML模型，以简化此过程。
D-SPACE4Cloud支持运行MapReduce或Spark应用程序（具有截止日期保证）或Storm拓扑（具有集群利用率保证）的共享Hadoop云集群的容量规划过程。
Netfective Technology已使用D-SPACE4Cloud来评估某些隐私机制对纳税人数据实施的影响。如第20节所述，Cassandra数据库中填充了纳税人的详细信息、历史纳税申报单、纳税记录等等。
为了实现匿名化，应用的第一个隐私机制是屏蔽（例如，参见Vieria，M.；Madeira，H。“面向数据库管理系统的安全基准”。，在DSN 2015年论文集）。为此，引入了一个字典表，该表实现了明文ID和屏蔽ID之间的一对一映射。换句话说，Cassandra表存储纳税人的屏蔽ID，而明文ID仅在具有受限访问权限的字典表中可用。例如，图2显示了我们在DICE项目期间考虑的三个参考查询，即查询1、5和7，以及匿名查询的示例。查询1访问两个表以执行其分析：Declare和TaxPayer。它旨在衡量纳税人在连续两年内获得的收入之间的差异。这是通过根据某些标准比较两种收入来检测欺诈者而进行的。例如，如果某一年获得的收入低于前一年收入的20%（此百分比可以设置为参数），则该纳税人可疑。由于收入存储在Declare表中，因此查询1执行两次连接：第一次是为了确保两个纳税申报单与同一纳税人相关；第二次是为了获取有关其/他的完整信息集。此查询的结果被保存并通过传递预期参数（例如收入下降的百分比和要考虑的年数）由其他查询使用。查询5仅涉及Declare表。此表包含所有必要的信息，以了解每个人的收入和其他有助于证明应缴税款的有用凭证。查询7涉及三个表：TaxPayer、TaxDeclaration和Signatory。每个纳税申报单必须在纳税人将其提交给税务机构之前由纳税人签署。
查询3派生自查询1，并添加了一个连接以读取明文ID。类似地，查询6和查询8分别派生自查询5和查询7（但此处为简单起见省略了）。考虑的第二个隐私机制是使用AES进行128位和256位加密。在这种情况下，存储在Cassandra表中的ID和敏感数据被加密，并且在运行时（例如，查询1）上下文地执行解密。
| 查询1 SELECT tp.id, , tp.gender, tp.birthdate, tp.birthdepartment, tp.birthcommune, d1.taxdeclaration, d1.declarationdate, d1.income, d2.taxdeclaration AS D2TAXDECLARATION, d2.declarationdate AS D2DECLARATIONDATE, d2.income AS D2INCOME FROM Declare d1 INNER JOIN Declare d2 ON d1.taxpayer = d2.taxpayer INNER JOIN taxpayer tp ON d1.taxpayer = tp.id |
| 查询5 SELECT * FROM Declare d1 |
| 查询7 SELECT tp.id,s.location, td.roomcount FROM taxdeclaration td, signatory s, taxpayer tp WHERE s.taxpayer = tp.id AND s.taxdeclaration = td.id |
| 查询3 SELECT dic.und_id, , tp.gender, tp.birthdate, tp.birthdepartment, tp.birthcommune, d1.taxdeclaration,d1.declarationdate, d1.income, d2.taxdeclaration AS D2TAXDECLARATION,d2.declarationdate AS D2DECLARATIONDATE, d2.income AS D2INCOME FROM Declare d1 INNER JOIN Declare d2 ON d1.taxpayer = d2.taxpayer INNER JOIN taxpayer tp ON d1.taxpayer = tp.id INNER JOIN dictionary dic ON dic.id=tp.id |
图2中报告的查询已在Spark 2.0中实现，并在具有8个核心和28GB内存的Microsoft Azure HDInsight上的D12v2 VM上运行。每个节点（虚拟机）的执行器数量为2或4。我们将最大执行器内存设置为8 GB，驱动程序内存也为8 GB，而执行器分配了2个或4个核心。节点数量在3到12之间变化。总的来说，我们在多达48个核心上运行了实验。运行时考虑了默认的HDInsight配置。此性能测试活动已执行以识别查询配置文件。在下文中，将比较基线查询5及其匿名版本，同时考虑相同的配置。
在这里，我们介绍了使用UML图对Spark应用程序进行性能评估建模的方法。Spark应用程序由转换和操作组成。D-SPACE4Cloud将UML活动图解释为Spark应用程序的DAG，即活动图表示应用程序RDD上的执行工作流。Spark应用程序管理一个或多个RDD，因此，我们的UML活动图接受多个初始节点和最终节点。每个阶段都显示为每个RDD执行的操作。
图3显示了查询8的活动图，它包含8个转换。UML fork和join节点也支持遵循标准UML建模语义。UML活动图中的活动节点（操作、fork和join）按UML分区（例如，转换和操作）分组。
需要在UML表示中的每个活动和分区节点上应用UML配置文件。UML配置文件是一组可以应用于UML模型元素以扩展其语义的构造型。
Spark配置文件严重依赖于标准MARTE配置文件。这是因为MARTE提供了GQAM子配置文件，这是一个用于定量分析的完整框架，它确实专门用于性能分析，因此完全符合我们的目的。此外，MARTE提供了NFP和VSL子配置文件。NFP子配置文件旨在描述系统的非功能特性，在本例中为性能。后者，VSL子配置文件，提供了一种具体的文本语言来指定与性能相关的指标、约束、属性和参数的值，在本例中为特定情况。
VSL表达式在Spark配置文件模型中用于两个主要目标：（i）指定模型中NFP的值（即指定输入参数）和（ii）指定将为当前模型计算的指标/s（即指定输出结果）。一个主机需求标记值为NFP Duration类型的VSL表达式示例为
(expr=$mapT1, unit=ms, statQ=mean, source=est)
此表达式指定图3中的map1平均需要$mapT1毫秒的处理时间（statQ=mean），并将从实际系统中的估计值（source=est）获得。$mapT1是一个变量，可以在模型分析期间设置具体值。
RDD 的初始化在 UML 活动图中由一个初始节点描述。初始节点使用 SparkWorkloadEvent 构造型进行标记。此构造型捕获了 RDD 创建的基本细节。主要地，初始化由两个参数表示。第一个是 sparkPopulation 标签。它对应于生成 RDD 结构时输入数据被划分的块数。转换 (SparkMap) 和操作 (SparkReduce) 具有独立的构造型，因为它们在概念上是不同的，但它们继承自 SparkOperation 构造型，并且间接地继承自 MARTE::GQAM::GaStep 构造型，因为它们是计算步骤。事实上，它们共享并行度，即每个操作的并发任务数，由 SparkOperation 构造型的 numTasks 标签指定。每个任务都有一个关联的执行时间，由标签 hostDemand 表示，这是一个从 GaStep 继承的属性。标签 OpType 指定 Spark 操作的类型（例如，枚举 SparkOperation= {转换，操作}），在使用 SparkOperation 构造型对 UML 图进行建模时。Spark 中的调度概念由 SparkScenario 构造型捕获。为了简化第一个版本，我们只支持以静态分配资源给 Spark 作业的方式部署的 Spark 集群（例如，YARN 或独立模式）；以及内部 fifo 策略（任务调度程序）。因此，CPU 内核和内存的数量在启动时静态分配给应用程序。此配置反映在标签 nAssignedCores、nAssignedMemory 和 sparkDefaultParallelism 中。它们分别表示调度程序分配给当前应用程序的计算核心和内存资源数量；以及集群配置的默认并行度。属性 sparkDefaultParallelism 在 SparkWorkloadEvent!sparkPopulation 未定义时指定 RDD 中的默认分区数。它还在转换和操作（如 count、join 或 reduceByKey）返回的 RDD 中确定分区数，前提是用户没有显式设置 numTasks 的值。
SparkScenario 构造型继承自 MARTE::GQAM::GaScenario。它收集应用程序其余的上下文信息；例如，将在模拟中计算的响应时间或吞吐量。SparkScenario 构造型应用于活动图。
每个 UML 分区都映射到 UML 部署图中的计算资源，遵循为拓扑定义的调度策略。图 4 显示了部署图，它补充了先前的活动图。每个计算资源都被构造成 SparkNode（等效于 GaExecHost）并定义其资源多重性，即内核数。此构造型继承自 MARTE GQAM。
最后，SparkNode 构造型应用于 UML 部署图中的计算设备。它表示 Spark 集群中运行任务的资源。主要属性是 nCores 和 Memory。第一个标签对应于设备中可用 CPU 的数量。第二个标签是一个布尔值，指示 RDD 中分区的尺寸是否适合服务器的内存，或者它们是否必须存储在临时文件中。SparkNode 构造型继承自 DICE::DTSM::-Core::CoreComputationNode，并且等效于 MARTE 中的 GaExecHost 构造型。Spark 配置文件已为 Eclipse 的 Papyrus 建模环境实现。
实验结果
作为一个说明性示例，这里我们报告了查询 5 和 6 在 150 万数据集和 85 秒初始截止时间下隐私机制的成本影响分析。截止时间以 20 秒为增量递减，以考虑 10 个优化实例。结果报告在图 5 中。从实验结果可以看出，在 45 秒以上以及 20 秒时没有产生额外成本，而在 25 秒和 15 秒的截止时间下，由于掩蔽技术导致的成本开销在 50% 到 66% 之间。低于 15 秒的截止时间过于严格，D-SPACE4Cloud 找不到任何可行的解决方案。总的来说，这些结果有力地支持了 D-SPACE4Cloud 中实现的优化程序，因为它们证明了为部署做出正确的选择可以带来整个应用程序生命周期中的大量节省，此外，软件架构师可以做出更明智的决策并预先评估不同 QoS 水平对云操作成本的影响。
从实验结果可以看出，在 45 秒以上以及 20 秒时没有产生额外成本，而在 25 秒和 15 秒的截止时间下，由于掩蔽技术导致的成本开销在 50% 到 66% 之间。低于 15 秒的截止时间过于严格，D-SPACE4Cloud 找不到任何可行的解决方案。
图 6 报告了当考虑 1000 万条条目数据集进行性能分析时，查询 1 和 3 的结果。初始截止时间设置为 3500 秒，这是在实际集群上注册的两个查询的执行时间最大值，并且以 500 秒为增量递减。
结果表明，由于掩蔽技术导致的成本开销在 33% 到 40% 之间，并且对于大于 2500 秒的截止时间没有产生额外成本。低于 1500 秒的截止时间过于严格，没有找到可行的解决方案。
进一步的实验针对加密。对于加密，我们选择了 1000 万数据集，并评估了查询 7，AES 256 位加密和未加密，我们为此注册了最大的性能下降，即 5%。这样，我们获得的结果将是保守的。80 秒被设置为初始截止时间，然后以 5 秒为增量递减。
结果报告在图 7 中，该图显示在 40 秒时实现了 50% 的成本开销，这也是系统可以支持的最小截止时间（否则找不到可行的解决方案）。
最后，我们报告了通过考虑最大的数据集，即 3000 万，对于查询 5 获得的结果。对于性能分析，我们考虑了 13 个节点的配置，该配置注册了最大的性能下降。80 秒被设置为初始截止时间，然后以 20 秒为增量递减。图 8 报告了 AES 256 位加密的成本。
实验表明，由于加密导致的成本比率最多只有 13%。而在 40 秒以下，D-SPACE4Cloud 找不到任何可行的解决方案。图 9 报告了查询 5 的 AES 128 位加密的结果，运行使用 13 个节点。这里我们考虑 88000 毫秒作为初始截止时间，因为它是实验中关于性能下降的实际系统中测量的最大值。
平均而言，加密仅导致成本开销增加 8%，并且当截止时间设置为 48 秒时，会获得更大的开销。这是由于 D-SPACE4Cloud 工具的异常行为，它识别了一个局部最优解并停止其爬山算法。
虽然我们进行了许多实验，但这里只列出了决定性的实验。从上面的实验结果可以得出结论，掩蔽比加密导致更多的开销，而 128 位和 256 位加密之间没有显着差异。发现由于匿名化导致的成本开销约为 66%，而由于加密导致的成本开销在最坏情况下仅为 50%。
结论
对于 NETF 案例研究，已经考虑了三种隐私机制。通常，对于 NETF 案例研究，匿名化导致的开销大于加密，两种不同的加密技术的性能和系统成本影响方面差异可以忽略不计。NETF 基准测试由于掩蔽导致的成本影响约为 66%，而由于加密导致的成本增加了约 50%。