大資料/質量最佳化實用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%。