面向大資料的實用 DevOps/前言

大約在 2010 年，阿爾卡特-朗訊研發部門負責人向法國國家科研署（簡稱 ANR）的資訊通訊科技 (ICT) 科學委員會會議提出了“大資料”這個詞。他告訴我們，網路正在以指數級速度傳輸資料，因此，資訊通訊科技領域的科學問題必須在持久存在的“大資料”現象的背景下進行完全的重新思考和解決。事實上，網路運營商在日常業務中受到了 IT 客戶的困擾，這些客戶要求使用新的方法來從資料中創造價值（如果可能的話，要儘早從網路中獲取資料！）。如同金塊一樣，資料包含著“意義”，但是海量資料本身並不能促進理解，也不能在合理的時間尺度內進行智慧操作。更糟糕的是，眾所周知的儲存、格式化、搜尋、挖掘或任何其他資料技術都已不再適合“大資料”的需求！

我負責為法國公共和私營部門的資助研究專案定義相關研究方向，起初我對“大”這個形容詞持懷疑態度，因為它讓我聯想到“原始”、“粗粒度”、“非結構化”等概念。例如，雖然每個人都使用“大資料”作為流行語，但很少有人說明“大資料”更恰當的用法：是“大資料”集，TB 級、PB 級、EB 級、ZB 級… 資料集嗎？換句話說，哪種平均資料量才算得上是“大資料”？例如，EB 級 (10¹⁵) 或 ZB 級 (10¹⁸) 是“大資料++”集還是普通的“大資料”？

展望未來，並因此詢問了使用大規模平行計算基礎設施的高效能計算社群，我的感覺是，該社群的假設是所有資料都是可用的，是靠近的，是相當結構化的… 為了誇張地說，所有資料都可以在任何時候儲存在高效能記憶體中！這種雲計算的反概念讓我失望…

相比之下，詢問大規模資料集社群，他們提出了“資料方法”，在這種情況下，當然，資料量是“海量的”（“巨大的”？“大的”？還有什麼？）。“海量”（他們選擇的名稱）和“大資料”中的“大”之間的差異/等價性造成了歧義。我很快明白，他們的方法並不適用，因為他們沒有用高效能計算來解決問題：這證明了他們的資料量仍然“不夠大”。與這個漏洞相關，關於“資料方法”的假設系統地將 SQL、XML 等作為格式化框架，這往往與“大資料”的現實情況相去甚遠！

其他學科（電子商務、能源、健康、可持續性等）幫助我們擺脫了困惑。他們向資訊通訊科技領域的人員提出挑戰，關於他們所在行業不可阻擋的數字化程序，這再次要求重新思考和解決每個行業中系統的設計方式。

通常，在能源領域，智慧電網不是配備了硬體和軟體進行智慧監控和控制的能源分配系統。相反，智慧電網是“大資料”處理基礎設施，它與現實世界的緊密聯絡依賴於感測器和執行器。現實世界透過周圍的物理基礎設施來處理能量。那麼，作為一個能源領域的創新系統，智慧電網應該如何設計？整個系統的數字元件是核心，因此，它對剩餘部分（周圍的物理基礎設施）的組成方式產生了約束！這種觀點讓能源工程師不悅，但完美地說明了“大資料”問題如何解決：進步的代價！

事實上，“大資料”作為一門新的科學學科，是商業系統在以前從未見過的規模上的數字化。科學問題既不是計算機科學問題，也不是其他學科中現有的科學問題。解決方案取決於可擴充套件性問題得到解決的方式：可擴充套件性是“大資料”問題核心的關鍵。換句話說，用於“較低”規模（即“可控”資料量）的資料方法或技術在規模增加時就會變得過時。必須發明新的解決方案，包括軟體開發方法，這些方法可以有效地從軟體（開發工程師、運維工程師）和行業（IT 客戶、終端使用者等）方面突出協作的跨學科行為。

本書“面向大資料的實用 DevOps”，旨在解決這一目標。作者從經過驗證且相關的軟體工程正規化（即模型驅動工程和 DevOps）入手，展示了歐洲資訊通訊科技 DICE 專案 (http://www.dice-h2020.eu/) 的成果。DICE 專注於資料密集型應用程式的質量保證。由於“大資料”應用程式強調與 IT 客戶/終端使用者的緊密合作，採用更多跨學科的方法，因此 DICE 提出了諸如效能和信任之類的關鍵標準。這些標準驅動著軟體的設計和生產釋出方式。標準充當早期輸入約束或質量合同。作為不可避免的約束，DICE 質疑執行中的應用程式如何處理資料並提供“意義”，同時滿足端到端的約束。DICE 方法是基於迴環的，包括對生產環境中的應用程式進行監控和控制，以便例如可以將效能異常注入維護週期以保持質量。當然，本書還解釋了專用整合工具如何支援這種方法，以在成功的“大資料”世界中取得成功！