大型資料/技術特定建模的實用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。
