在最新的“2018年Gartner資料管理技術成熟度曲線”報告中，DataOps的概念被首次提出，Gartner標記其目前在“極為初級”這個階段裡面，並預計需要5-10年的達到一個技術成熟時期。

“極為初級”階段是報告描述的技術成熟曲線的五個階段之一，Gartner預計一項技術從出現到公眾熟知將經歷以下的五個階段：

“極為初級” 階段 一項潛在的技術突破可以解決問題。早期的概念驗證故事和媒體興趣引發了重要的宣傳。通常沒有可用的產品存在且商業可行性未經證實。

“爆發增長”階段 早期宣傳產生了許多成功故事 – 通常伴隨著許多失敗。一些公司採取行動; 大部分都沒有。

“幻滅的低谷” 階段 由於實驗和實施無法實現，早期的利好逐漸減弱。該技術的生產者放棄技術或宣告失敗。只有倖存的供應商改進其產品以滿足早期採用者的需求，投資才會繼續。

“啟蒙的斜坡”階段 更多關於技術如何使企業受益的例項開始明確並且得到更廣泛的理解。後期迭代的產品來自技術提供商。更多企業資助開始注資試點專案; 保守的公司仍然保持謹慎。

“生產力的高原”階段 技術開始被廣泛接受。評估技術提供者的可行性的標準更明確。該技術廣泛的市場適用性和相關性顯然得到了回報。如果該技術不僅僅是一個利基市場，那麼它將繼續增長。

基於上面的定義，Gartner報告基本上表明DataOps剛剛出現在資料管理領域，並且被認為是像在幾年前Spark和流處理一樣的潛在市場顛覆性技術之一。那麼DataOps到底意味著什麼？為什麼它只是在Hadoop引領大資料浪潮近10年後才出現？

我們將嘗試通過描述大資料專案的六個階段來回答這些問題，並瞭解DataOps真正帶來了什麼。

階段1 技術試驗階段

在此階段，你的團隊可能會安裝一個Hadoop叢集和Hive（可能帶有Sqoop），以便將一些資料傳輸到叢集並執行一些查詢。 近年來，包括Kafka和Spark在內的元件也被考慮在內。 如果要進行日誌分析，也可以安裝ELK（ElasticSearch，LogStash，Kibana）等套件。

但是，這些系統大多數都是複雜的分散式系統，其中一些系統需要資料庫支援。 雖然許多提供單節點模式供你使用，但你的團隊仍需要熟悉常見的Devops工具，如Ansible，Puppet，Chef，Fabric等。

由於開源社群的辛勤工作，對大多數工程團隊來說，使用這些工具和原型設計應該是可行的。 如果團隊裡面有一些優秀的工程師，你可能會在幾周內設定好一個可以聯通及執行的系統，具體的工作量一般取決於你要安裝的元件數量。

階段2 自動化階段

在這個階段，你已經擁有了一個基本的大資料系統，接下來你的需求可能有：

• 一些定期執行的Hive查詢，比如每小時一次或每天一次，以生成一些商業智慧報告;使用一些Spark程式執行機器學習程式，生成一些使用者分析模型，使你的產品系統可以提供個性化服務;

• 一些需要不時從遠端站點提取資料的爬蟲程式;

• 或一些流資料處理程式，用於建立實時資料儀表板，顯示在大螢幕上。

要實現這些需求，你需要一個作業排程系統，以根據時間或資料可用性來執行它們。像Oozie，Azkaban，Airflow等工作流系統允許你指定何時執行程式（類似Linux機器上的Cron程式）。

工作流系統之間的功能差異很大。例如，一些系統提供依賴關係管理，允許你指定排程邏輯，如作業A僅在作業B和作業C完成時執行；一些系統允許僅管理Hadoop程式，而另一些系統則允許更多型別的工作流程。你必須決定一個最符合你要求的。

除了工作流程系統，你還有其他需要自動化的任務。例如，如果你的HDFS上的某些資料需要在一段時間後刪除，假設資料只保留一年，那麼在第366天，我們需要從資料集中最早的一天中刪除資料，這稱為資料保留策略。你需要編寫一個程式，為每個資料來源指定並實施資料保留策略，否則你的硬碟將很快耗盡。

階段3 投入生產階段

現在你已經擁有了一個自動資料管道，資料終於可以在這個資料流水線上流動起來！大功告成？現實情況是你的生產環境會遇到下面這些棘手的問題：

• 第一年硬碟故障率為5.1％（與第一年伺服器故障率類似） 第4年伺服器的故障率為11％

• 大量使用的開源程式有很多bug，你的程式可能估計也會有一些bug

• 外部資料來源有延遲

• 資料庫有停機時間

• 網路有錯誤

• 有人在執行“sudo rm -rf / usr / local /”時使用了額外的空格

這些問題發生的次數會比你想象的要頻繁得多。假設你有50臺機器，每臺機器有8個硬碟驅動器，那麼一年內將有20個硬碟驅動器故障，一個月大約2個。經過幾個月的手動過程掙扎，你終於意識到你迫切地需要：

監控系統：你需要一個監控程式來監控硬體，作業系統，資源使用情況，程式執行; 系統探針：系統需要告訴你它的各種執行指標，以便它可以被監控;

警報系統：出現問題時，需要通知運維工程師;

SPOF：避免單點故障，如果你不想在凌晨3點被叫醒，最好系統裡不要出現SPOF;

備份：你需要儘快備份重要資料;不要依賴Hadoop的3份資料副本，它們可以通過一些額外的空格被輕鬆刪除;

恢復：如果你不希望每次發生時都手動處理所有錯誤，那麼這些錯誤最好儘可能自動恢復。

在這個階段你意識到建立一個企業級的系統並不像安裝一些開源程式那麼容易，可能我們要多下一點苦功了。

階段4 資料管理階段

一個企業級的大資料系統不僅要處理與任何標準系統操作類似的硬體和軟體故障問題，還要處理與資料相關的問題。對於一個真正資料驅動的IT系統，你需要確保你的資料完整，正確，準時，併為資料進化做好準備。

那麼這些意味著什麼？

• 需要知道在資料流水線的任何步驟中資料都不會丟失。因此，需要監控每個程式正在處理的資料量，以便儘快檢測到任何異常;

• 需要有對資料質量進行測試的機制，以便在資料中出現任何意外值時，你接收到告警資訊;

• 需要監控應用程式的執行時間，以便每個資料來源都有一個預定義的ETA，並且會對延遲的資料來源發出警報;

• 需要管理資料血緣關係，以便我們瞭解每個資料來源的生成方式，以便在出現問題時，我們知道哪些資料和結果會受到影響;

• 系統應自動處理合法的元資料變更，並應立即發現和報告非法元資料變更;

• 需要對應用程式進行版本控制並將其與資料相關聯，以便在程式更改時，我們知道相關資料如何相應地更改。

此外，在此階段，你可能需要為資料科學家提供單獨的測試環境來測試其程式碼。並給他們提供各種便捷和安全的工具，讓他們能快速驗證自己的想法，並能方便地釋出到生產環境。

階段5 重視安全性階段

在這個階段大資料已經與你密不可分：面向客戶的產品由資料驅動，你的公司管理層依靠實時的業務資料分析報告來做出重大決策。你的資料資產安全將變得非常最重要，你能確定你的資料只有合適的人員才能訪問嗎？並且你的系統擁有身份驗證和授權方案嗎？

一個簡單的例子是Hadoop的Kerberos身份驗證。如果你沒有使用Kerberos整合執行Hadoop，那麼擁有root訪問許可權的任何人都可以模擬Hadoop叢集的root使用者並訪問所有資料。其他工具如Kafka和Spark也需要Kerberos進行身份驗證。由於使用Kerberos設定這些系統非常複雜（通常只有商業版本提供支援），我們看到的大多數系統都選擇忽略Kerberos整合。

除了身份驗證問題，以下是你在此階段需要處理的一些問題：

審計：系統必須審計系統中的所有操作，例如，誰訪問了系統中的內容 多租戶：系統必須支援多個使用者和組共享同一個叢集，具有資源隔離和訪問控制功能;他們應該能夠安全，安全地處理和分享他們的資料;

端到端安全性：系統中的所有工具都必須實施正確的安全措施，例如，所有Hadoop相關元件的Kerberos整合，所有網路流量的https / SSL;

單點登入：系統中的所有使用者在所有工具中都應具有單一身份，這對於實施安全策略非常重要。

由於大多數開源工具都沒有在其免費版本中提供這些功能，因此許多專案在安全問題上採用“撞大運”的方法並不奇怪。我們同意安全的價值對不同的專案來說有不同的理解，但人們必須意識到潛在的問題並採取適當的方法。

階段6 雲基礎架構的大資料階段

在這個階段隨著業務的不斷增長，越來越多的應用程式被新增到大資料系統中。除了像Hadoop / Hive / Spark這樣的傳統大資料系統，你現在需要使用TensorFlow執行深度學習，使用InfluxDB執行一些時間序列分析，使用Heron來處理流資料，或者一些Tomcat程式來提供資料服務API。每當你需要執行一些新程式時，你會發現配置機器和設定生產部署的過程非常繁瑣，並且有很多的坑要踩。此外，有的時候你需要臨時搞到一些機器來完成一些額外的分析工作，例如，可能是一些POC，或者要對一個比較大的資料集進行訓練。

這些問題是你首先需要在雲基礎架構上執行大資料系統的原因。像Mesos這樣的雲平臺為分析工作負載和一般工作負載提供了極大的支援，並提供了雲端計算技術提供的所有好處：易於配置和部署，彈性擴充套件，資源隔離，高資源利用率，高彈性，自動恢復。

在雲端計算環境中執行大資料系統的另一個原因是大資料工具的發展。傳統的分散式系統（如MySQL叢集，Hadoop和MongoDB叢集）傾向於處理自己的資源管理和分散式協調。但是現在由於Mesos / Yarn這樣的分散式資源管理器和排程程式的出現，越來越多的分散式系統（如Spark）將依賴底層分散式框架來提供這些資源分配和程式協調排程的分散式操作原語。在這樣的統一框架中執行它們將大大降低複雜性並提高執行效率。

總結

我們看到過處於各種階段的實際的大資料專案。在Hadoop被採用了10多年之後，我們看到的大部分專案仍然停留在第1階段或第2階段。這裡主要的問題是在第3階段實施系統需要大量的專業知識和大量投資。 Google的一項研究表明，構建機器學習系統所花費的時間中只有5％用於實際的機器學習程式碼，另外95％的時間用於建立正確的基礎架構。由於資料工程師因難以培訓而非常昂貴（由於需要對分散式系統有很好的理解），因此大多數公司都很不幸的沒能走進大資料時代的快車道。

與DevOps一樣，DataOps是一個需要正確工具和正確思維的持續過程。 DataOps的目標是使以正確的方式更容易地實現大資料專案，從而以更少的工作從資料中獲得最大的價值。 Facebook和Twitter等公司長期以來一直在內部推動類似DataOps的做法。然而，他們的方法通常與他們的內部工具和現有系統相繫結，因此很難為其他人推廣。

在過去幾年中，通過Mesos和Docker等技術，大資料操作的標準化成為可能。結合更加廣泛的採用資料驅動的文化，DataOps終於準備好可以進入到大家的視野。我們相信這一運動將降低實施大資料專案的障礙，使每個企業和機構都更容易獲取資料的最大價值。

作者簡介：

彭鋒 博士 – 智領雲科技（LinkTime Cloud）CEO，聯合創始人； – 大規模分散式系統和大資料基礎架構領域的資深專家; – 前Twitter大資料架構師及大資料平臺技術負責人 ； – 前Ask.com工程總監；