大資料實用 DevOps / 概述

大資料重要性

大資料是資訊與通訊技術 (ICT) 的主要趨勢。隨著全球範圍內移動裝置和感測器的不斷普及，社交網路上使用者生成內容不斷增長，以及物聯網的即將到來，我們的日常裝置（智慧手機、電器、車輛、住宅等）將透過物聯網進行通訊和資料交換，這種資料洪流的特點是我們的現代社會，它帶來了新的機遇，也帶來了有趣的挑戰。政府也傾向於更多地自動化公共服務。因此，高效處理海量且不斷增長的資料的能力變得至關重要。最後但同樣重要的是，大資料是一個創造就業機會的正規化轉變。僅在英國，從 2008 年到 2012 年，對大資料架構師、大資料分析師、大資料管理員、大資料專案經理和大資料設計師的需求分別增長了 157%、64%、186%、178% 和 329%。

大資料系統的特點

希望從大資料中獲益的組織必須重新考慮其資訊系統的架構。為了能夠適應大資料，系統必須在設計時始終牢記三個重要的關鍵特徵。首先是可擴充套件性：基礎設施可擴充套件性、資料平臺可擴充套件性和處理可擴充套件性。在基礎設施層面，可擴充套件性使組織能夠根據需要新增任意數量的儲存和計算資源。中小型企業 (SME) 通常自身沒有這種能力。但他們可以使用雲提供商的基礎設施，雲提供商可以為他們提供根據需要建立更多虛擬機器或容器的可能性（當然，需要付費）。在資料平臺層面，可擴充套件性是指採用本質上分散式的資料管理軟體，即在網路上分散資料，並能夠利用網路中新增計算機帶來的新可用儲存空間。在處理層面，可擴充套件性是指多個作業系統程序（通常執行在不同的機器上）協同工作，以並行化一項要完成的任務。當工作負載很高時，可以有無限數量的程序加入工作。

總而言之，大資料架構師的使命是協調各種可擴充套件資料平臺和處理技術的活動，這些技術部署在可擴充套件的基礎設施上，以滿足具體的業務需求。這些技術的組織方式以及它們之間的關係就是我們所說的架構。一些架構模式已經被發現和記錄，可以在文獻中找到。例如，Nathan Marz 的 Lambda 架構。雖然大資料系統的架構對終端使用者來說是透明的，但他們不可避免地期待著一件事：整體低延遲。因此，大資料系統的第二個重要特性是服務質量 (QoS)。QoS 是對特定效能指標（如 CPU 時間、輸入/輸出等待時間和響應時間）值的的一組要求。

大資料系統的第三個基本特徵是健壯性。當大資料架構中的某些機器或作業系統程序出現故障時，大資料系統必須繼續執行，並且從外部角度來看，問題不應被察覺。

中小型企業的 大資料

我們可以從上一節描述的功能中看出，許多希望開始在大資料市場上競爭的中小型企業無力構建大資料系統。首先，他們必須租用大型企業的基礎設施。其次，由於大資料技術的學習曲線很高（有時由同一家大型企業設計），因此他們很難在短時間內掌握這些技術。第三，協調這些技術並達到可接受的服務質量更加複雜。

我們認為這種情況並非不可改變。為了改變這種情況，我們確定並試圖消除以下障礙：

1. 缺乏用於推理大資料系統可能架構的工具。架構師需要一個工具來闡明他們關於如何組織大資料技術的思路。建模語言非常適合於此目的。
2. 缺乏能夠將架構大資料模型與生產環境連線起來的工具。模型不僅僅是抽象的表示；它們是基於具體現實的。就大資料而言，這種現實是生產環境，即構建大資料系統的雲基礎設施。整合開發環境 (IDE) 應該允許架構師以使用者友好的方式從模型（想法）遷移到生產環境（結果）。建模語言越正式（即它的概念越具有精確的，甚至是數學的意義），開發人員就越容易編寫程式來利用、分析和轉換模型、生成軟體、打包軟體並自動部署軟體。
3. 缺乏根據測量的執行時效能和預先計劃的目標重構已部署大資料架構的工具。當獲得的服務質量不如模型所承諾的那麼好時，應該提供重構工具來糾正架構錯誤。

本書解釋了我們克服這些障礙的工作。