作者：陳榮耀 阿裡雲全球技術服務團隊
一、背景&挑戰
數字化時代，企業希望借助數字化的技術能力來提升企業的經營能力，從最終業務目标上來看，一般分三類：
1. 增加收入：基于經營資料的智能分析來提升産品競争力，更快速的産出産品創新；
2. 降低成本：通過對資源的盤點分析，性能的優化，降低資源成本，通過企業内建立管理制度和标準，降低人力管理成本；
3. 減少損失：一種是基于數字的回報，不斷的優化使用者體驗，減少客戶流失，另一種是通過采集全域的資料并加以分析，降低生産鍊路的故障風險。
為了幫助企業實作這些業務目标，衍生出了許多新技術，雲廠商往往也會向客戶介紹各種高精尖技術和解決方案。但現實是，很多企業在數字化轉型的過程中會感覺到效果并不明顯，或者說企業并沒有“用好數”，這裡面的問題點在哪？個人覺得有以下幾個主要挑戰：
1.1 組織文化
做數字化轉型，首先需要組織層面啟動資料驅動的文化建設，并明确定義出可數字度量的業務目标。企業的業務決策需要依賴于數字，需要不斷提升組織中人員的數字素養，需要讓組織中的各類人員具備基礎的大資料知識、資料分析知識、統計知識，具備通過資料向其他人傳達資訊的能力。
1.2 技術鴻溝
建立完整的資料鍊路需要許多軟體和硬體結合起來，架構師必須全面了解資料生命周期各個角色，各個階段的需求，但現實是往往人們更關注于拼圖的一部分，而忽視其他部分。比如大型企業由于資料體量較大，往往更關注于大資料的處理技術，如何建構資料中台，如何加快查詢速度，如何降低資源成本，但對于資料科學家們如何更快擷取資料，如何更好地管控權限，更快地産出業務價值等等存在缺失，而中小企業往往更關注資料科學家需要的分析軟體，但對于資料管道缺少投資，這使得許多分析工作局限在個人計算機上。另一方面，大部分的項目會引入多家公司，多種資料産品，不同産品之間必然存在資料和服務的隔離，如何更好地利用好各方的能力，打破技術之間的鴻溝是每個企業都要面對的痛點問題。
1.3 知識鴻溝
企業中圍繞資料有很多的角色，各個角色之間存在較大的知識鴻溝。比如對于資料科學家，他們擅長從資料中挖掘價值、建立模型，但将模型投入生産的經驗往往不足，比如代碼的版本控制、測試、文檔等等，缺少端到端的技能來生産資料産品并獲得回報，而對于資料工程師，他們比較擅長資料管道的搭建，但對于資料如何被使用，如何産出最終的業務價值往往不太清晰，是以在資料工程師和資料科學家之間往往會出現一些分歧。
1.4 資料連續性
技術能力需要考慮時間這樣一個重要變量，特别是對于資料技術，解決當下的資料問題相對簡單，想要資料持續的産出業務價值就需要大量的工程工作群組織保障，需要量身定制适合于業務的資料域CI/CD能力，需要持續性地對資料進行治理，需要對資料安全和合規進行持續性檢測，需要具備全鍊路的可觀測能力，保障資料服務的連續性并持續優化資源成本。
1.5 小結
企業想要“用好數”隻制定長期的戰略并依賴于産品的技術能力是遠遠不夠的，亟需一種戰術指導思想，指導企業如何圍繞資料鍊路，從全局的視角去保障數字化戰略的落地，提升組織的數字素養，打破技術和知識的鴻溝，優化資料架構，保障資料服務的連續性。
二、DataOps理念
2.1 起源
為了解決上述問題和挑戰，DataOps理念應運而生，DataOps的概念在2014年由Lenny Liebmann提出，在《3 reasons why DataOps is essential for big data success》這篇文章中，Lenny提出DataOps是優化資料科學和營運團隊之間協作的一些實踐集。經過多年的發展，2018年Gartner将其納入到資料管理的技術成熟度曲線，标志着DataOps正式被業界所接納并推廣起來。
在最新的Gartner: Hype Cycle for Data Management, 2022報告中，DataOps的概念已經進入第二階段的“過熱期”，2021年的時候DataOps還屬于第一階段的“創新萌芽期”。
業界各廠商對于DataOps有着不同的了解：
- IBM：IBM将DataOps定義為 DataOps 是人員、流程和技術的有機結合，用于快速向資料公民提供可信的高品質資料。
-
Gartner：DataOps是一種協作性的資料管理實踐，專注于改善整個組織的資料管理者和消費者之間的溝通、整合和資料流的自動化。
DataOps is an agile and collaborative data management practice focused on improving the communication, integration, automation, observability and operations of data flows between data managers and data consumers.The goal is operational excellence in data delivery.
- Wikipedia：DataOps是一套實踐、流程和技術，它将綜合的、面向流程的資料觀點與靈活軟體工程中的自動化和方法相結合，以提高品質、速度和協作，促進資料分析領域的持續改進文化。
- 中國信通院：資料研發營運一體化（DataOps）是一種面向資料全生命周期，以價值最大化為目标的最佳實踐。聚焦于協同從資料需求輸入到傳遞物輸出的全過程。明确研發營運目的，細化實施步驟，在價值營運、系統工具、組織模式、安全風險管理的支撐下，實作資料研發營運的一體化、靈活化、精益化、自動化、智能化、價值顯性化理念。
DataOps業界目前尚缺少統一的、細化的定義和實踐，本文将結合個人近期的學習，談下個人的看法。希望可以抛磚引玉，讓大家對DataOps有個初步認識。
2.2 目标
首先DataOps的Ops是很容易被混淆的一個概念：
- ☒ 錯誤：Ops在目前語境下并不是運維的意思也不是操作的意思，DataOps在目前語境下不是指基于資料挖掘和分析後去運維業務系統或PAAS平台。
- ☑ 正确：Ops指的是營運，DataOps指的是對資料的營運，即如何讓資料為業務發揮更大的價值。
DataOps的目标個人覺得可以這樣定義：更快速的傳遞更高品質資料
具體來說：
- 建設組織文化：重視資料文化的建設，為企業定制如何用數的組織設計建議，幫助企業明确資料戰略的業務目标，提供提升組織人員數字素養的教育訓練課程。
- 填補技術鴻溝：聚焦資料的流向，而不是單項技術或組織功能，定義出完整的資料技術大圖，提供各個資料子產品的咨詢服務，橫向去連接配接各個資料産品和服務，為企業制定最優的“用好數”技術方案，填補技術鴻溝。
- 填補知識鴻溝：基于資料技術大圖，明确定義出組織内各個資料角色需要的知識地圖，提供資料鍊路上各類資料标準和規章制度的建議，為組織培養“T”形人才，填補人員的知識鴻溝。對于資料科學家而言，可以更直覺了解到資料管道是如何搭建的，如何自助取數，對于資料工程師，可以更清晰了解資料的用途，這對于他們如何優化資料管道，如何講清楚管道價值有較大的幫助，也能讓工程師和科學家之間互相了解，提升組織協同效率。對于企業管理者而言，高效的資料流有利于更快發掘資料的業務價值。
- 保障資料連續性：提供如何保障資料生産鍊路，提升研發效率，降低資料風險的标準，實踐和技術方案。宣揚系統性思維（精益思維和靈活協作），從全局優化整體系統，定制适合的資料産品研發政策。
系統思維的重點是了解一個系統的組成部分如何互相關聯，如何随着時間的推移而工作，如何與其他系統互動，以确定模式，解決問題并提高業績。靈活思維和精益思維是系統思維的典型子集。靈活思維旨在使系統更容易适應不确定性，而精益思維則是緻力于将浪費從系統重剔除。 ---《DataOps實踐手冊》第五章 建構回報和度量
從目标來看，DataOps是一個很大範疇的理念，技術隻是其中一部分，核心是幫助企業圍繞“用好數”，聚焦資料鍊路，建構完整的組織和資料能力。
2.3 DataOps和DevOps的關系
DataOps的概念本身是從DevOps借鑒過來的，最核心的差異點就是面向的對象不同，DevOps的理念是為了更快的傳遞軟體，而DataOps的理念是為了更快的傳遞資料。
DevOps改變了軟體部署的速度和規模，使得代碼可以随時處于可以釋出到生産中的狀态，為了實作這個目标，DevOps定義了一系列宣言和價值觀，業界也沉澱了大量的靈活能力，比如CI/CD的研運能力、靈活架構、度量體系、自動化測試等能力。和軟體開發一樣，資料類的産品也是需要對業務的變化進行快速的回報，是以DataOps的概念也被提出來。
DataOps的許多原則和概念都是從DevOps中衍生出來，不過DataOps更關注于資料的傳遞，比如針對軟體的傳遞是不會強調資料管道（ETL/ELT）的搭建和維護，資料品質的持續性治理，資料層的可觀測性監測，資料分析層的優化和展現等等。
兩者關系大緻如下，參考連結What the Ops are you talking about?
(https://towardsdatascience.com/what-the-ops-are-you-talking-about-518b1b1a2694)
DevOps面向的角色主要是軟體的研發、測試、運維等角色，DataOps面向的角色在前者之上還有資料分析師、資料科學家、資料開發、BI分析師等等，涉及的部門更多，技術棧更多，組織間協同的成本也更高，從這個角度來看，DataOps面臨的挑戰更大。
有些企業把DataOps籠統的定義為資料域的CI/CD能力或是資料管道（資料內建/ETL/ELT等等），我覺得是不準确的，就像DevOps并不是隻定義一個CI/CD能力一樣，DevOps核心還是靈活的開發理念，技術是服務于理念的，是一種上下的支撐關系。同理，DataOps在資料域技術能力之上，更需要的是如何指導組織“用好數”的方法/标準/制度/實踐等等。
2.4 DataOps原則&宣言
DataOps的原則借鑒了DevOps，基于資料的特性，進行了一些修改，官方連結：
1. 個人與互動重于流程與工具：強調團隊間的協作，提倡面對面的溝通，這點和靈活宣言一緻。
2. 可用的分析重于詳盡的檔案：提倡分析即代碼，這意味着需要有較好的版本管理，CI/CD，可重用環境等能力，這對資料的基建要求還是很高的。
3. 與客戶合作重于合約協商：希望和客戶建立一個合作關系，而不僅僅隻是雇傭關系，DataOps的落地強依賴客戶組織的協同，對資料鍊路持續性的優化，和客戶之間其實是一種能力互補。個人覺得未來資料域的合同條款，商務流程也可能會發生變化。
4. 實驗、疊代以及回應重于大量的前期設計：借鑒了軟體MVP版本疊代的模式，引入靈活的思想進行資料研發。
5. 跨部門的營運所有權重于獨立的責任：傳統企業内資料是一個個的孤島，每個部門掌管自己的那一部分資料權限，DataOps的核心在于讓資料更快的流動，是以提倡在保障安全的前提下，通過流程和機制的優化讓資料的權限控制更加靈活。
宣言共有18條，對原則進行了一定程度的拆分細化，感興趣可以看下。
2.5 DataOps架構師畫像
企業為了加快軟體的研發效率往往會有DevOps架構師這樣的角色，但目前還沒有明确定義DataOps架構師這樣的角色，個人覺得DataOps架構師需要具備以下能力：
1. 精通DevOps理論；
2. 精通DataOps理論；
3. 熟練掌握各類資料産品，某幾個資料領域需要有較深入的研究，T型人才；
4. 對資料流有較深入研究，具備靈活和精益的思維，具備從全局優化資料鍊路的技術沉澱；
5. 可以幫助企業制定資料戰略，明确業務目标，有一定行業經驗，有幫助多個企業落地DataOps的實踐經驗。
2.6 DataOps評測
之前有幸參加信通院組織的某大型銀行的DataOps能力成熟度評測，這是國内首次明确定義出DataOps的成熟度模型并進行正式評測，詳情請參考連結，下圖列了資料內建這個子產品的部分評測條款：
可以看到，除了技術能力，DataOps重視制度、規範、标準的制定，重視技術的教育訓練，重視資料鍊路上不同環節之間資料的互通，互動的關聯等等，從全局的視角去提升資料的使用效率，即更快速的傳遞更高品質資料。
三、DataOps核心技術能力
前文介紹了DataOps的理念，要解決的問題和目标，本章重點聚焦在前文提到的DataOps資料技術大圖。
強調：資料技術能力并非DataOps的全部，它是支撐DataOps理念的重要組成部分
企業的資料鍊路很長，涉及的技術棧也非常多，下圖列了一些資料域的技術（位址連結，根據最近的一些調研，實際的複雜度會比下圖還高很多）。
無論是填補技術鴻溝還是知識鴻溝，最關鍵的一點是需要聚焦資料鍊路，定義出最核心的資料能力，将零散的資料能力整合連接配接在一起，業界有很多組織或個人整理了一些資料鍊路的架構圖，篩選了兩個：
A glimpse into DataOps
(https://www.valdas.blog/2019/04/17/data-ops/)
Diving into DataOps: The Underbelly of Modern Data Pipelines
(https://www.eckerson.com/articles/diving-into-dataops-the-underbelly-of-modern-data-pipelines)
3.1 DataOps資料能力大圖
在上文一些前輩的基礎上，我們對DataOps資料能力做了一些細化，嘗試更清楚的定義出資料鍊路裡核心的技術能力，希望可以更好的将我們自研的以及業界一些好用的資料工具有序組合在一起，建立索引，便于企業或個人更快速的找到并學習自己需要的技術能力。
圍繞中間最核心的資料流向，整體分成三個部分：資料研發（圖中上半部分），資料管理（圖中下半部分），資料應用（圖中右側）：
1. 資料研發：取好數
資料研發聚焦資料的開發者，對這類角色而言，我認為最重要的痛點是如何高效的擷取資料。
在一個項目中往往最頭疼的就是如何清洗和搬遷資料，資料進入大資料平台後如何降低模組化成本，如何更低成本的拿到自己想要的資料。是以我們将整個研發流程分成資料內建、資料模組化、資料開發三個大類，每個大類中又定義了各自的核心能力。
以大家最為熟悉資料遷移為例，阿裡雲上不同的産品都會有各自配套的一些資料遷移能力，但在項目裡經常會遇到不支援的一些資料源，這時候我們往往會臨時寫一些腳本去做支援，如果研發力量充足可能會定制一些工具，如果我們能有一個平台集中去管理這類工具，那自然可以降低研發成本。更進一步，如果可以将資料遷移領域業界一些好用的工具，新的遷移技術、實踐案例、資料遷移的标準&制度都能展現出來，甚至如果客戶有需要，還可以将我們的遷移能力內建到客戶内部的系統裡，這肯定是提升了客戶“用數”的能力。另外，通過DataOps大圖的指引，使用者會知道遷移的下一步需要去驗證資料和業務的一緻性，在這個步驟内，又會有相關的工具能力和行業實踐推薦，以此類推，最終從整個資料鍊路上為使用者提供技術能力支撐。
2. 資料管理：管好數
資料管理主要面向資料的管理者和開發者，重點是去保障高品質的資料供給，這裡面分了兩塊，一塊是以靈活的思想去管理資料的生産，實作靈活的資料傳遞，一塊是通過建立并維護可靠的資料服務，保障使用者可以持續獲得高品質的資料。中繼資料服務、資料品質、資料可靠性這些概念經常有相關讨論，暫不贅述，本文重點提一下資料域的CI/CD能力。
一提到CI/CD大家肯定都會想到DevOps：代碼版本管理、流水線打包、釋出管理等等，其實在資料研發管理的領域也是需要類似的CI/CD能力的，比如我們的内部的資料産品研發時就遇到過以下問題：
- 版本更新時遇到工作流不适配：新舊工作流中table_id、column_id的拼接規則不一緻。
- 有時候表模型不适配，導緻導入任務、加工任務、導出任務失敗。公共層、應用層因為字段缺失或者字段類型對不上而報錯。
而這類問題往往都是出在研發管理上：
1. 代碼版本缺乏控制：
a.DDL版本依托于人工上傳git管理，但很多時候都維護在本地。無法做到在開發工具上傳。
b.DDL版本收版後，因為臨時業務需求或者前期探查不全面等問題，需要臨時增加一些新的字段、修改字段類型，修改DDL後(繁雜且瑣碎)，往往會忘記同步到文檔和Git倉庫。
2. 工作流版本缺乏控制：
a.目前是隻有一套最新版本的開發環境工作流，區分不出舊版本工作流。
b.加工邏輯變動頻繁。
3.煙囪式開發：大量重複的計算加工，無法設定變量，寫函數等。
資料産品項目中涉及到各種資料源，擷取方式、名額定義、資料處理邏輯等各類資訊的複雜度已經完全不亞于正常的軟體系統。不借助優秀的工程實踐，僅僅靠項目規範把控會很容易積累起資料産品的技術債，效率低下且難以持續。業界也已經有一些成功的技術實踐，比如DBT，除了提供ELT的能力之外，還提供了資料域的部署&內建能力。我們目前在試點使用中，待有進一步實踐後再分享。
3. 資料應用：用好數
資料應用主要面向的是資料的使用者：資料分析師，資料科學家，新的資料工作者（非技術人員），比如各個業務線的營運人員，企業管理者，甚至最終使用者。通過打造更加簡單易用的資料應用，結合配套的教育訓練管理制度，組織設計，最終希望實作“全民資料科學家”（Citizen Data Scientist），加速企業決策和創新。
這塊的産品比較多，差異性較大，業務價值的出口也是集中在這塊，往往也需要結合行業屬性進行定開，将資料域技術和行業經驗結合才能比較好的落地，本文暫不展開。
3.2 資料能力實踐：Modern Data Stack
業界最近又有一個新的概念叫Modern Data Stack，我了解其實就是将資料域的各種能力根據業務場景的實際需要分層組裝在一起（stack）打包輸出, 如下圖：
在我們内部之前也做了類似的嘗試，不過沒有這麼高大上的名稱，我們制定了一些工具的建設标準，可将我們沉澱的工具結合業務場景打包輸出去解決一線的問題，工具之間可以互相內建：
主要分成兩個應用場景：
- 傳遞工具：面向傳遞提效，将工具的技術能力嵌入到業務傳遞的SOP(标準操作流程)中，為不同的業務域定制自己的傳遞工作台，提升傳遞的标準化率，降低一線人員的操作門檻，提升傳遞品質。
- 資料産品：面向外部客戶售賣，将工具能力內建到産品中，降低産品的研發成本，通過産品的打磨，也提升了工具的成熟度。
四、總結
我們作為研發團隊支撐了阿裡雲GTS内大部分資料域項目的傳遞，包含資料上雲、資料庫、大資料、資料中台等等，過程中沉澱了大量工具，為了友善工具的管理和使用，我們建立了 “星軌工具中心”進行工具的統一納管，但工具功能比較零散，總是處于補業務窟窿的狀态，顯得“東一榔頭西一棒”，缺少主線将工具能力串聯在一起，技術缺少“牽引”，這在過去給我們帶來很多困擾。
在不斷的摸索中，我們發現，我們沉澱的工具大部分都是圍繞資料鍊路，去彌補産研和項目需求的GAP，去幫助使用者更高效的使用我們資料域的雲産品，這和DataOps提倡的聚焦資料鍊路，從全局提效很比對。另一方面，我們過去更偏向于建設單點技術能力解決問題，缺少理論的支撐，而DataOps在理論和實踐層給了我們很多啟發，讓我們從全局角度去思考如何建構技術深度，建立行業影響力，如何将技術更好地和業務場景結合，提供整套的解決方案，思考方式從解決問題轉向從業務角度去定義清楚問題和度量标準，幫助客戶更快地獲得高品質的資料，為企業建構更Modern的資料架構。
接下來我們團隊會針對定義出的DataOps技術能力大圖，每個子產品組織同學進行深入調研，整理相關的工具能力和項目實踐，形成DataOps的知識庫。我們也在和信通院深度合作，一起建設DataOps白皮書，為DataOps在業界的發展貢獻一部分力量，歡迎大家一起參與讨論和交流。
最後，資料域相關的内容較多，感謝李林洋、楊陽、王磊、郭晨瑞、龐興華、何強、樂攀、陳旭等同學的建議和指導。