大資料實用 DevOps/方法論

在本章中，我們將介紹一種設計大資料應用程式的方法。其基本思想是將模型驅動工程技術融入 DevOps 開發生命週期。為什麼這種方法適合且有利於資料密集型軟體？這個問題是合理的，我們將首先回答它。我們將從倡導在 DevOps 中使用模型開始。然後我們將看看將模型驅動 DevOps 應用於大資料應用程式構建的一些好處。最後，我們將介紹我們的方法論建議以及 DICE IDE 如何支援它。

模型驅動 DevOps

在一個典型的組織中，開發人員在一個隔離的、臨時的、開發環境中構建和測試軟體——透過使用所謂的整合開發環境 (IDE)，例如 Eclipse 或 Visual Studio——而操作人員負責目標的、最終的、生產環境。後者從概念上包含應用程式計劃與之互動的所有實體：作業系統、伺服器、軟體代理、人員等等。操作人員負責，除其他事項外，準備生產環境、控制它並監控它的行為，尤其是在應用程式部署到其中之後。

在 DevOps 之前，開發人員和操作人員通常組成兩個獨立的團隊。結果，前者沒有完全瞭解他們的開發環境與生產環境的不同。他們在開發環境中構建和測試應用程式時沒有看到的問題，一旦操作人員將其安裝到生產環境中，就會突然出現。DevOps 建議將開發人員——“DevOps”的“Dev”字首——和操作人員——“DevOps”的“Ops”字尾——放到同一個團隊中。這樣，現在這兩者之間存在持續的協作，極大地增加了對建立的每個軟體元件都已真正準備好投入生產的信心。實際上，由於操作人員是那些非常瞭解生產環境的人，他們對開發人員的積極和持續支援導致了以生產意識為導向的程式設計。當構建、單元測試、整合、整合測試、交付、系統測試、部署和驗收測試階段完全自動化時，這種合作的連續性體現了其全部價值。

DevOps：從整合到部署

在 DevOps 中，由不同的 DevOps 團隊構建的軟體元件被隔離地測試（單元測試）。然後將它們組裝在一起以建立一個單一軟體（整合）。之後，對軟體進行測試（整合測試）並將其放入一種形式——通常稱為包——以方便其分發（交付）。接下來，對包進行測試（系統測試）並將其安裝到生產環境中（部署）以進行最後一次測試（驗收測試）。DevOps 規定操作人員應協助開發人員以完全自動化這些階段。完成後，分別實現持續整合、持續交付、持續部署和持續測試。

模型驅動實踐已被證明對其設計程式和生成其原始碼有用。因此，模型驅動工程已經很好地涵蓋了軟體元件的構建和單元測試。我們的想法是使用模型來自動化整合、交付和部署。DICE 聯盟為此目的發明了一種建模語言。（該語言不處理整合。）已經開發出工具讓開發人員和操作人員共同對應用程式及其生產環境進行建模，並在不同的抽象級別上進行建模。這些工具解釋模型以自動準備和配置生產環境，以及將應用程式部署到其中。以下是這種方法的一些優勢

1. 模型不僅指定應用程式，還指定適合它的生產環境。
2. 更重要的是，由於描述了生產環境的屬性，因此有時可以利用模型在任何部署之前正式地模擬或驗證（即抽象地和數學地）應用程式在其生產環境中的行為。
3. 開發人員和操作人員通用的建模語言有助於他們之間更好地溝通。由於模型中使用的概念定義明確，因此消除了歧義和誤解。
4. 可以透過它們的模型直接重構應用程式及其生產環境。
5. 應用程式的上市時間縮短，因為現在計算機執行了一些開發和運營任務。

DICE 聯盟已經對這五個要點進行了試驗，並發現該方法相關。大資料應用程式通常依賴於大資料技術，這些技術大多以難以學習而聞名。從我們的角度來看，模型驅動 DevOps 可能會有所幫助。

大資料模型驅動 DevOps

術語大資料用於描述傳統資料系統無法有效處理新資料集的能力，這些資料集是海量的（容量）、快速到達的（速度）、來自各種來源且格式多樣（多樣性），以及其流速可能突然變化（可變性）。容量、速度、多樣性和可變性被稱為大資料的四個 V。處理它們的一種正統方法是垂直擴充套件，即加快演算法或硬體（例如處理器或磁碟）的速度。這種方法顯然有限，而且毫無意外地失敗了。大資料是向水平可擴充套件的並行處理系統的轉變，其能力透過向現有集合中新增更多機器而增長。

美國國家標準與技術研究院 (NIST) 釋出了一個有價值的大資料分類。下圖顯示了一個略微修改的版本。從上到下是服務提供鏈：系統協調器期望大資料應用程式具有一些功能，這些功能由大資料應用程式提供商實現，並在大資料框架提供商設計的大資料框架的幫助下實現。從左到右顯示了資訊流鏈：資料所有者向資料提供商提供資訊片段，資料提供商對其進行數字化並將它們傳輸到大資料應用程式以進行處理。資料消費者獲得其輸出，這些輸出可以以使用者友好的方式傳達給資料檢視器。這九種功能角色的不同活動都包含在安全和隱私問題中。

修改後的 NIST 大資料分類

大資料總是具有社會方面。系統協調器、大資料應用程式提供商、大資料框架提供商、資料所有者和資料檢視器通常是個人或組織。這就是為什麼一個專用符號代表它們的原因。資料所有權特別是一個法律概念，很難進行全面定義。一個基本定義可能是

資料所有者

資料所有者是指擁有某條資料並行使對其權利的個人或組織。它有法律權力阻止其他人利用其資料，並且可以採取法律行動來做到這一點——通常在某些條件下。

個人、科學家、研究人員、企業和公共機構顯然是資料所有者。資料所有權是可以共享的。實際上，在使用大資料系統——例如 Facebook——之前，資料所有者通常必須接受一項協議，他們自己和系統協調器將受該協議約束。有時，使用該系統隱含地表示接受該協議。在某種程度上，該協議可能會將資料所有權讓與系統協調器。例如，每個填寫過要求提供個人資料的線上表格的網民可能都曾在某個場合看到過一個“我同意條款和條件”複選框。通常，這些條款和條件會要求使用者允許對他的資料執行特定操作。例如，透過單擊複選框，使用者可以授予系統協調器將資料披露給業務合作伙伴的自由。系統協調器的角色可以是以下角色

系統協調器

系統協調器是指其職位允許其參與關於大資料系統需求的決策過程，以及參與監控或稽核活動以確保構建或正在構建的系統符合這些需求的個人或組織。

系統協調器例如解決資料策略、資料匯入要求、資料匯出要求、軟體要求、硬體要求和可擴充套件性要求。我們在系統協調器中發現了：業務所有者、業務領導者、業務利益相關者、客戶、專案經理、顧問、需求工程師、軟體架構師、安全架構師、隱私架構師和網路架構師。

資料檢視器

資料檢視器是指大資料系統向其傳達一些資訊的人或組織。

在圖中，方框代表硬體或軟體。資料提供者、資料消費者、大資料應用和大資料框架都是數字實體。他們的工作是處理資料。當我們說資料時，我們總是指數字資料。我們使用術語資訊來表示非數字資料。我們稱知識為所有真實的的資訊。真實性——另一個 V——是大資料中一個重要的關注點。

資料提供者

資料提供者是指提供自身或他人可用資料的硬體或軟體。它負責訪問許可權，並確定誰可以讀取或修改其資料，透過何種方式，以及哪些是允許的和禁止的利用。

資料庫管理系統符合此定義。資料提供者擁有許多可用的資料傳輸方法：事件訂閱和事件通知、應用程式程式設計介面、檔案壓縮、網際網路下載等等。他們也可以選擇建立查詢語言或其他機制，讓使用者在不獲取資料的情況下匯入處理。這種做法被稱為將計算移至資料而不是將資料移至計算，並在上圖中以有向弧表示。資料提供者可以將從資料所有者輸入或獲取的資訊轉換為計算機可以處理的數字資料。在這種情況下，它是大資料系統與非數字世界之間的界限。例如，這是對話方塊或線上表單的功能。所有捕獲裝置，例如攝像機和感測器，也是資料提供者。

大資料應用和大資料應用提供者

大資料應用是指從資料提供者提供的資料中提取新資料的軟體。它由大資料應用提供者設計和開發。

大資料應用是一種特殊的資料提供者——即依賴其他資料提供者的資料提供者。但並非所有資料提供者都是大資料應用。例如，資料庫管理系統不是大資料應用，因為它本身不會生成新資料。大資料應用通常執行以下任務：從資料提供者收集資料、資料準備和分析。傳統的工具和基礎設施無法有效地處理大型、多樣化且快速生成的資料集。為了讓組織能夠利用此類資料的全部潛力，找到一種新的資料捕獲、儲存和分析方法非常重要。資料準備發生在分析過程之前和之後。事實上，正如俗語所說，垃圾進，垃圾出。同樣，糟糕的資料，糟糕的分析。因此需要準備資料。例如，來自不可信資料提供者的資料和格式不正確的資料應該被丟棄。分析之後，大資料應用可能會整理結果，以便資料消費者能夠更輕鬆、更有意義地在螢幕上顯示它們。所有這些任務都存在於傳統的資料處理系統中。然而，大資料的規模、速度、多樣性和可變性維度徹底改變了它們的實施。在DevOps中，開發人員和運營人員是大資料應用提供者。

大資料框架和大資料框架提供者

大資料框架是指基礎設施或技術資源或服務，它賦予大資料應用處理不斷增長的海量資料集合所需的效率和水平擴充套件能力。它由大資料框架提供者提供。

NIST 將大資料框架分類為基礎設施框架、資料平臺框架或處理框架。基礎設施框架提供者為大資料系統提供所需的硬體部件：儲存裝置、計算機、網路裝置、冷卻設施等。基礎設施可能隱藏——雲化——在透過應用程式程式設計介面提供的服務背後。例如，此服務可能允許使用者按需遠端建立、啟動、停止和刪除虛擬機器或容器。資料中心和雲提供商屬於此類大資料框架提供者。資料平臺框架是資料儲存程式，它利用網路將資料以可擴充套件的方式分佈到多臺機器上。因此，連線的機器越多，獲得的儲存空間就越大。Hadoop 分散式檔案系統 (HDFS) 和 Apache Cassandra 都是資料平臺框架。處理框架，如 Hadoop MapReduce 和 Apache Spark，將處理分佈在資料的位置。增加機器不應損害資料檢索和處理的效率。相反，應該觀察到更好的效能。開源社群在改進資料平臺和處理框架方面進行了大量的創新。

資料消費者

資料消費者是指使用或接收來自大資料應用的輸出的軟體或硬體。

九種功能角色並不相互排斥。理論上，可以同時成為系統協調者、資料所有者、資料檢視者、大資料應用提供者和大資料框架提供者。一個程式可以同時是大資料應用、資料提供者、資料消費者和大資料框架。例如，讓我們考慮以下圖中所示的虛構場景

NIST 大資料系統示例

兩個使用者使用者 1 和使用者 2 連線到一個大資料系統。他們都透過圖形使用者介面與之互動。讓我們想象GUI 1 是使用者 1 瀏覽的網站，GUI 2 是使用者 2 執行的桌面應用程式。應用 1 和應用 2 是兩個大資料應用。儲存 和分析器 分別是資料平臺框架和處理框架。使用者 1 輸入的資訊透過GUI 1 傳輸到應用 1。應用 1 將其儲存到儲存 中，並將其轉發到應用 2。分析器 不斷分析儲存 中包含的資料，並將分析結果也傳送到應用 2。擁有所有這些輸入，應用 2 執行某個演算法並將結果傳輸到GUI 1 和GUI 2，最後將其揭示給他們的使用者。在這個場景中，許多參與者扮演著多個角色。例如，使用者 1 是資料所有者和資料檢視者，而儲存 是資料提供者、資料消費者和大資料框架。

我們可以將 NIST 的分類法視為一種與技術無關的建模語言，並將上圖視為使用它設計的模型。技術選擇沒有被指出：儲存 可以由 Apache Cassandra 或 HDFS 實現，而分析器 可以是 MapReduce 或 Spark 作業。這種建模語言的一些規則非正式地可以是

1. 每個節點都有一個名稱（例如“分析器”）、一個圖示和標籤——至少一個。
2. 節點名稱和節點圖示可以自由選擇。
3. 允許的節點標籤是：資料所有者 (DO)、資料檢視者 (DV)、系統協調者 (SO)、大資料應用提供者 (BDAP)、大資料框架提供者 (BDFP)、資料提供者 (DP)、大資料應用 (BDA)、資料消費者 (DC)、大資料框架 (BDF)、基礎設施框架 (IF)、資料平臺框架 (DPF) 和處理框架 (PF)。
4. 由於大資料應用是資料提供者，因此標記為 BDA 的節點也必須標記為 DP。類似地，標記為 IF、DPF 或 PF 的節點也必須標記為 BDF。
5. 資訊流僅允許：(a) 從資料所有者到資料提供者；以及 (b) 從資料消費者到資料檢視者。
6. 資料流僅允許：(a) 從資料提供者到大資料應用；(b) 從大資料應用到資料消費者或大資料框架；以及 (c) 從大資料框架到大資料應用或其他大資料框架。
7. “提供”關聯僅允許：(a) 從大資料應用提供者到大資料應用；以及 (b) 從大資料框架提供者到大資料框架。
8. “使用”關聯僅允許：(a) 從系統協調者到大資料應用；(b) 從資料所有者到資料提供者；(c) 從大資料應用到資料提供者或大資料框架；(d) 從大資料框架到另一個大資料框架；(e) 等等。
9. 等等。

元物件設施 (MOF) 是物件管理組 (OMG) 的一個標準，適合嚴格定義建模語言。著名的統一建模語言 (UML) 本身就是用 MOF 規範的。UML 的情況很突出，因為 UML 具有一個配置檔案機制，使設計人員能夠專門為特定領域定製所有 UML 圖表的含義。在實踐中，語言發明者有兩個選擇：要麼從頭開始，直接使用 MOF，要麼將 UML 適應感興趣的主題。Eclipse 支援這兩種方法。Eclipse 建模框架 (EMF) 是 Eclipse IDE 的一組外掛，它包含了名為 Ecore 的 MOF 實現。而 Eclipse 專案 Papyrus 提供了基於 Ecore 的 UML 實現。

在上一節中，我們介紹了模型驅動 DevOps 的五個優勢。在大資料環境下，還有更多內容需要說明。大資料框架——基礎設施框架、資料平臺框架和處理框架——通常難以學習、配置和管理，主要是因為它們涉及無限數量的計算資源的可擴充套件叢集。使用模型驅動 DevOps，事情變得更容易。運營人員只需在他們的模型中宣告他們在生產環境中想要哪些技術，以及效能要求。他們讓模型到生產工具自動以滿足服務質量 (QoS) 要求的方式安裝和配置叢集。部分負擔由工具承擔。

方法建議

現在，我們已經闡明瞭什麼是模型驅動 DevOps 以及它對大資料的便利性，現在是時候詳細介紹我們的軟體開發方法論了。參與該方法論的行動者是大資料應用程式提供者——開發人員和運營人員——以及一些系統協調者——架構師和專案經理——因為他們實際上是唯一構建、監督或監控大資料應用程式構建的人。簡而言之，透過遵循我們的方法，這些行動者可以輕鬆地使用建模語言來試驗大資料系統的架構，並用這種語言來塑造他們的想法。一個包含所有大資料技術的架構模型，可以由模型到生產工具自動且具體地複製到雲基礎設施上。因此，他們可以比較他們所設想的內容和他們所得到的內容。任何為了提高效能或質量而對模型進行的更改，也可以自動傳播到雲基礎設施上（持續部署）。我們將該方法論分為三種場景，這些場景說明了利用模型驅動 DevOps 實踐大資料的替代方法：架構建模、架構分析和架構實驗。

架構建模

如今，建模已成為軟體工程的標準。無論是用於架構決策、文件、程式碼生成還是逆向工程，今天軟體專家都會繪製模型，並且他們可以使用多種工業標準符號。建模是我們方法論的基石。DICE 聯盟的建模語言遵循 OMG 的模型驅動架構 (MDA) 的理念：它包含三個抽象層：平臺無關層、技術特定層和部署特定層。使用平臺無關的概念，架構師可以根據計算節點、源節點、儲存節點等描述一個大資料系統，而無需明確說明底層技術。DICE 平臺無關模型 (DPIM) 類似於使用 NIST 分類法進行的模型，只是概念的命名不同。以下是一些部分概念對應關係：

DPIM 概念	NIST 分類法中的對應概念
資料密集型應用程式 (DIA)	大資料系統
計算節點	處理框架和大資料應用程式
源節點	資料提供者
儲存節點	資料平臺框架

與 NIST 分類法相反，DPIM 概念是相互排斥的。（DPIM 源節點不提供永續性功能；因此，儲存節點不能是源節點。）此外，DPIM 沒有基礎設施框架的概念，因為基礎設施是部署特定層處理的低階問題。完整的 DPIM 概念列表將在後續章節中解釋。

DPIM 模型對應於 OMG MDA PIM 層，並描述應用程式的行為，作為一個有向無環圖，它表示計算和資料之間的依賴關係。

——DICE 聯盟

DICE 技術特定模型 (DTSM) 透過為每個計算節點、源節點、儲存節點等採用一種技術來細化 DPIM。例如，架構師可以選擇 Apache Cassandra 或 HDFS 作為他們的一個儲存節點。同樣，DTSM 對這些技術將被部署到的基礎設施沒有說明。DICE 部署特定模型 (DDSM) 的作用是指定它們。DDSM 透過基礎設施選擇來細化 DTSM。這裡，基礎設施一詞應理解為基礎設施即服務 (programmable) (IaaS)。它實際上是指透過網際網路訪問的基礎設施的計算能力。雖然使用者看不到底層硬體，但有一個應用程式程式設計介面，使他能夠以程式設計方式建立虛擬機器或容器，選擇作業系統並執行軟體。一個圖形使用者介面可以讓他互動地完成相同的工作。模型到生產工具依賴於 DDSM 和基礎設施的 API 來執行。

以下是本場景的步驟：

1. 繪製一個使用 DPIM 概念進行配置的 UML 物件圖，以描述大資料系統中的元件。
2. 繪製一個使用 DPIM 概念進行配置的 UML 活動圖，以描述這些元件的操作。
3. 使用 DTSM 概念細化前面兩個圖。
4. 繪製一個使用 DDSM 概念進行配置的 UML 部署圖，以描述這些技術將如何部署到基礎設施中。
5. 生成使用基礎設施 API 的指令碼，並執行這些指令碼以獲得生產環境。

架構分析

以下是本場景的步驟：

1. 繪製一個使用 DPIM 概念進行配置的 UML 物件圖，以描述大資料系統中的元件。
2. 繪製一個使用 DPIM 概念進行配置的 UML 活動圖，以描述這些元件的操作。
3. 繪製一個使用 DPIM 概念進行配置的部署圖，以描述元件在模擬環境中的部署。
4. 執行模擬。
5. 使用 DTSM 概念細化前面三個圖。
6. 執行模擬或驗證。
7. 執行最佳化以生成一個最佳化的 UML 部署圖，該圖使用 DDSM 概念進行配置。
8. 生成使用基礎設施 API 的指令碼，並執行這些指令碼以獲得生產環境。

架構實驗

監控和測試生產環境中大資料系統的質量，並重構模型。

DICE 方法論在 IDE 中

DICE IDE 基於 Eclipse，它是基於 MDE 方法建立軟體工程模型的事實標準。DICE 使用合適的外掛定製 Eclipse IDE，這些外掛整合不同 DICE 工具的執行，以最大程度地減少學習曲線並簡化採用。並非所有工具都以相同的方式整合。已定義了多個整合模式，這些模式側重於 Eclipse 外掛體系結構。它們允許非常快速地實現和合並應用程式功能。DICE 工具可以透過 DICE 工具選單訪問。

DICE IDE 提供了透過 UML 模型指定 DIA 的能力。從這些模型中，工具鏈指導開發人員完成不同的質量分析階段，其中形式化驗證是其中之一。

IDE 作為方法論的前端，在整合框架中的 DICE 工具方面發揮著至關重要的作用。DICE IDE 可用於方法論中描述的任何場景。IDE 是一個用於模型驅動工程 (MDE) 的整合開發環境工具，設計人員可以在不同的級別（DPIM、DTSM 和 DDSM）建立模型，以描述資料密集型應用程式及其底層技術棧。

DICE IDE 最初提供了使用 DICE 配置檔案進行立體化的 UML 模型來指定資料密集型應用程式的能力。從這些模型中，工具鏈指導開發人員完成不同的質量分析階段（例如，模擬和/或形式化驗證）、部署、測試和透過監控資料收集和連續資料倉庫獲取反饋資料。基於執行時資料，一個迭代質量增強工具鏈檢測質量事件和設計反模式。然後，將反饋用於指導開發人員完成迭代質量增強的迴圈。