為什麼說資料治理的下一站是DataOps？

根據信通院資料，2019 年，我國資料產量總規模為 3.9ZB，同比增加 29.3%，佔全球資料總產量(42 ZB)的 9.3%。而 IDC 中國預測，2025 年中國大資料產生量有望增長至 48.6 ZB，這已經超過了 2019 年全球資料量的水平。這對大資料行業來說，既是機遇，也是挑戰。

越來越大的資料量，加上資料敏感和脆弱等的特點，資料治理一直都是一個困擾企業發展的問題。有開發者表示，每個人都在談論資料治理，卻沒有人真正知道該怎麼辦。

— 01 —

資料治理有哪些難點?

Q：在現在的企業資料治理上存在哪些痛點? 為什麼會出現這些問題，以及當前情況下是怎麼解決的?

A：資料治理和資料開發一直都是困擾著企業的難題。Google 最近發了一篇文章表示，雖然 Google 在 AI 演算法上非常厲害，但如果大家都只想搞演算法，沒人想去搞資料，那演算法是沒有用的。比如進來個髒資料，演算法一點用都沒有。但搞資料的工作，大家都認為很“髒”、很費神，演算法更高大上。

資料的治理和資料質量非常重要，整個資料開發流程也非常重要。演算法是最後讓資料產生價值的很重要的一部分，但是如果沒有前面的準備工作，那麼資料質量和資料開發效率就無法保證，後面演算法也發揮不了作用。很多公司，包括 Google、Twitter 和 Facebook，他們的演算法之所以有那麼大的作用，就是因為他們資料的基礎架構做得好，所以他們才能保證演算法的有效性。

那麼這個難度在哪呢?現在，資料管理、治理工具和資料治理體系暫時還沒有一個成形的體系，所有公司的資料質量、資料開發工具基本都是拿開源元件自己臨時搭建。

整個資料的測試流程中，大家很少聽說資料有 CI/CD，資料有沒有 CI/CD?資料的 ETL 程式有沒有 CI/CD?資料開發完了在哪測試?能不能在生產資料上測試呢?如果程式是對的，那資料改變後我的程式語義還能夠保證它的正確性嗎?企業在實際生產時，這些問題都是在大規模使用資料時會經常碰到。由於資料的使用，大家覺得大資料好像搞了很多年，但其實到現在大資料的基礎才逐漸成熟，大家也才意識到，資料組織後的資料質量是更重要的。

所以，我覺得現在正是將資料質量、資料治理和整個資料開發體系的工具提到前臺的好時機。以前資料基礎還沒有成熟，提這個可能有點早，但現在越來越多的企業，特別是頭部企業發現了這個問題。

矽谷的很多公司，包括在國內的頭部公司，他們早就遇到了這些問題，他們自己內部肯定是有解決方案的。產品化的事情也有人在做，大家現在看到的開源工具裡像 Spark、Kafka 都很成熟，做得都很好。但是，像 DataOps 這種跟企業的底層資料情況和資料的基礎架構緊密相關的工具比較少，DataOps 工具剛剛出現，現在也才獲得大家的關注。

— 02 —

什麼是 DataOps?

Q：現在越來越多的技術和廠商都在產品中會提到 DataOps，但是可能目前大家對 DataOps 定義還沒有很統一的定義。那麼，到底什麼是 DataOps?為什麼它現在會被很多企業青睞?

A：DataOps 是從 DevOps 借鑑的一個理念。可以理解為 DataOps 是把 DevOps 的一些理念對映到了資料開發上，它們的很多觀點是可以一一對應的，如開發及運維、雲原生、微服務化、CI/CD，這些都可以在 DataOps 裡找到，如果你的 DevOps 裡沒有這些概念，就要考慮下你的開發流程是不是符合最佳實踐。

但 DataOps 與 DevOps 也有區別。DataOps 是想處理資料，而在 DevOps 裡是不需要處理資料的，它主要是做應用的開發，應用的 CI/CD、釋出及運維。但就像剛才說的，DataOps 實際上屬於一個比較早期的概念，大家對它的解讀還是會有不一樣。

在 DataOps 裡面有很重要的一點，就是要處理資料的各種不可預知性。資料語義是一個難題，它沒辦法在 CI/CD 裡被容易定義，不是沒有辦法，但很困難。之前大部分原生大資料元件開發時並沒有考慮到這個規範。

DevOps 也經過了很長一段時間的演變，像 Git 逐漸成為規範，微服務基本上都是標準的元件。大資料元件體系架構特別多、選擇特別多，發展也特別快，現在的 Spark、流資料，Flink，卡夫卡，底層基本上也是 K8S、Hadoop 和 Hdefs，這些基本上可以形成標準化。那麼，現在就是做 DataOps 一個比較好的時候。

DataOps 的工作主要有五個方向：

第一個是任務排程。主要包括雲原生排程、容器的排程，這跟 DevOps 是一樣的。

第二個是資料安全。資料安全以前基本不在 DataOps 的考慮範圍，也不在資料開發的範圍內，但現在資料安全很重要。

第三個就是資料管理和資料門戶。大家可能會說原資料管理不都好多年了，但以前的原資料管理主要是針對關係型資料庫，關係型資料庫對原資料的管理相對容易，只要到資料庫裡把原資料爬出來就可以。但現在有流資料、非結構化資料，還有 TaiDB 等，各種各樣的原資料怎麼樣去管理?血緣管理更復雜了。之前是幾個 SQL 之間的血緣管理，現在關係到各種各樣的查詢、各種各樣的系統、資料門戶跟 MapDatas 是一樣的。

第四是資料檢測的視覺化。DevOps 裡有很多可監測到的指標，資料層面也一樣。用多少資源、花多少時間、創造了多少價值，之前都是一個黑盒子，但 DataOps 的整個資料都是端到端的，相關指標可觀測、可管理。

第五就是整合開發。所有的工具必須是可整合的，不可能做一個工具負責血緣管理，再做一個工具負責排程。

我認為，DataOPS 裡面必須具備這五個工具體系，如果你的 DataOps 體系裡面缺了任何一個，我都覺得是不完善的。

Q：DataOps 如何做持續測試?

A：資料開發、資料程式的測試一直是老大難問題，甚至頭部大廠整套流程做下來也是現在非常困難的。現在 DevOps 裡有一個很有意思的觀念，就是把集訓資源的管理全部用 Code 來管理，大資料也一樣。美國有一個很火的公司叫 DTB，它是要把所有的 ETL(資料倉儲技術)流程做成程式碼管理，將 SQL 的所有轉換變數化、程式碼化，將所有 ETL 程式間的關係、血緣全部用程式碼的形式來進行管理。可以說，不只 SQL 是程式碼，整個排程也都是程式碼。所以，DBT 的整個 ETL 程式可以被放到 Git 裡面。

使用者可以在指定的 data source 的測試環境中可以測試，可以到 Data 生態環境中直接切換一個 Data source，將其變成生產環境，所以它允許支撐 ETL 流程的 CI/CD。將所有 ETL 程式之間的依賴全部程式碼化，這就是 DTB 的一個思路。

除了 ETL 之外，我們現在做的事就是把所有大資料元件裡面的關係、程式全部程式碼化，這是未來的必然趨勢。

— 03 —

DataOps 與雲原生資料中臺的關係

Q：DataOps 與雲原生資料中臺是什麼樣的關係?他們目前各自的發展情況如何?

A：國內資料中臺也提了兩三年了，有成功的案例也有失敗的。我們在這方面也做了很多探索。我們的觀點是，資料中臺絕對要做，但 DataOps 是實現資料中臺的一個最好的方法論和工具體系。

這跟 DevOps 是一樣的。一個業務系統可以使用 DevOps 方法來做，也可以使用傳統方法去做，兩種方法最後做成的業務系統可能都差不多，但這只是開始的時候差不多，後面的持續迭代、持續運維的時候，就能看出來 DevOps 的優勢了。

資料中臺也是一樣，它是給大家提供一個資料開發和運營的底座，開始你可以用各種各樣的方法去做一個資料平臺，但是後續迭代和不斷髮展的時候，DataOps 就成為最合適的一種方法。

DevOps 提倡的是賦能和自助，透過 CI/CD 持續釋出，開發工程師自己來做運維測試，DataOps 也一樣，也是提供工具讓各個業務部門等資料使用者，能夠在中臺上拿到自己需要的功能。我們認為這是 DataOps 和資料中臺的關係。

Q：企業如何去做雲原生資料平臺的改造?整個過程可能會面臨哪些問題?

A：我覺得，現在雲原生的資料中臺還是一個比較有挑戰性的課題，但也是個必然的趨勢。很多企業的資料平臺效率非常低，因為傳統大資料平臺使用的 Hadoop、卡夫卡等都不是在雲原生的方式下開發，資源使用效率低、管理複雜，但云原生會大大降低整個系統的管理複雜度，提高系統的使用效率和運營效率。

這個過程中會面臨的困難，主要是人才問題。這個技能的門檻比較高，需要研發既懂雲原生又懂新技術，這樣的人才缺口還是挺大的。但這也有個好處就是，雲原生產品的標準化程度比較高，這樣容易做出標準化的產品讓大家使用。

舉個例子，以前裝一個大資料平臺需要直接面對底下的物理及虛擬機器，但各種各樣的配置，不同的作業系統、環境和網路，所有這些都得去管理。K8S 的出現就讓大家不必再考慮所有的底層元件，只要跟雲原生這個體系對接就可以了。這是一個很好的機會，所有的企業一定會看到，但這個過程肯定是需要時間的。

Q：您之前多次提到過“資料中臺方法論”，這個方法論具體都包含哪些內容?

A：這個方法論的主要目的就是追求效率。我們國內很多客戶的大資料平臺的資源使用率大概都是 15%-20%，但 Twitter 的自然使用率一般能達到 50%-60%，而且還有各種各樣的彈性擴充套件、自動容錯等雲原生功能。

瞭解這個之後，需要做到以下四點：

第一，選擇合適的工具和平臺。這個是基礎，選不到合適的架構工具，也就不存在效率了，所以如何選擇合適的平臺工具很重要。

第二，要有一個完善的頂層架構設計。因為資料平臺要把大家的資料接進來，與業務系統對接起來才能產生效果。DevOps 分散式的開發，集中式的管理，但這個集中式管理不是靠人，而是靠體系和工具。

第三，業務驅動。為了大資料而大資料一般成功不了，一定是可以解決業務問題的才能走到最後，解決不了業務問題的資料平臺是偽命題。解決業務痛點之後，還要賦能業務。要把業務部門引入進來，不斷使用這個資料平臺，獲得業務部門認可後這個東西才能走。

第四，要有價值衡量體系。如何量化產生的價值，很困難但是也很重要。我們一般要求決策方、業務方，技術方和資料平臺等各方面職責明確，避免後面出現越來越多的問題。

— 04 —

DataOps 的應用

Q：2018 年，高德納把 DataOps 納入了技術管理成熟體系曲線裡面，DataOps 被正式接納和推廣。三年過去了，目前有什麼成熟的應用案例出來嗎?

A：DataOps 在雲原生出來之前就有，但可能沒有叫這個名字。頭條、騰訊等大廠們都有自己的一套 DataOps 體系，Twitter 等矽谷公司也有，那為什麼現在才提出來?因為這個東西要產品化。雖然大廠都有 DataOps 體系，但是將近一百人的資料團隊，eBay 大概有三百多人，一般企業很難請得起這麼多高薪的人才。

現在 DataOps 火了是因為大家都需要，資料價值不是大廠獨有的。但橫梗在前的成本問題怎麼解決?這就需要 DataOps 工具將資料價值開發平移化。為什麼稱為雲原生的 DataOps?因為只有雲原生技術統一了各種各樣的硬體環境、開發環境、釋出環境、運維流程等等之後，DataOps 才可以將聚焦在資料開發、資料監控、資料管理、原資料和資料安全上。

Q：您在 Twitter 的時候，一個主要職責就是讓公司所有的人避免重複開發資料元件。這個需求是在一個什麼樣的背景下產生的?

A：這個就是很重要的不要重複造輪子的問題。重新造輪子會造成資源消耗，然後減慢開發速度。要避免不重新造輪子，那麼就必須知道現在有什麼“輪子”，但很多企業並不知道自己有什麼“輪子”。DataOps 很重要的一點就是原資料管理，它的原資料管理比原來的要更廣泛，它可以知道整個企業有什麼樣的資料功能。

更重要的是，企業重新造輪子，一旦兩個輪子造得不一樣，會把這個車開垮。我們原來做資料門戶，就要求所有的業務部門和資料分析師必須做統一的介面，然後發現有兩個部門就在重複造輪

Q：DataOps 會有開源生態嗎?

A：目前是逐漸成熟的過程中，還沒有成熟到大家都可以使用的端到端產品。

我們之前公眾號有篇文章講到，矽谷的大概十幾家公司，每個公司都有自己的資料門戶和產品，但是沒有成熟的產品。今年 6 月份左右，Linking 將自己的資料門戶產品開源了，也有人在做血緣管理，但都是這兩年才起來的公司。這個生態在逐漸形成，但是遠遠沒有到達成熟的階段。

Q：現在，DataOps 還解決不了哪些問題?

A：我覺得，當前 DataOps 沒辦法解決業務價值的挖掘問題。DataOps 實際是降低了資料使用門檻，讓更多的業務人員可以直接開發他們需要的資料並將這個開發成果給大家使用，這在以前必須要依賴資料科學家或者資料工程師。但是，如何把這些資料與業務結合起來、用資料去促進業務，這不是 DataOps 能回答的問題。我們只是賦能，但是真正怎麼樣讓你的資料去促進企業的業務發展，那一定需要企業懂自己的業務。

— 05 —

資料行業人才缺乏

Q：企業在使用 DataOps 的時候，應該如何組建這樣的一個團隊呢?

A：DataOps 工具並不是要取代資料工程師、資料科學家，或者 DBA 和資料分析師，它讓他們更有效率，我知道在座的不知道有多少是這個資料科學家，或者是資料工程師。

除了 DBA，資料行業一般有三個比較重要的角色：資料工程師，負責搭建資料平臺;資料科學家，研究資料的潛在價值，用學習模型來形成使用者畫像、產品推薦或自動異常檢測等;資料分析師，更多從業務角度做資料分析。但是最近出現了一種職業叫機器學習工程師，他們的任務是提高演算法效率，把資料科學家們開發的模型以生態化的形式，更高效地完成。

Q：這些人對 DataOps 是什麼態度呢?

A：他們當然歡迎。以前資料科學家和資料分析師釋出任務時要依靠資料工程師幫他們寫 ETL 任務，現在 DataOps 可以幫助他們自動完成。我們就是讓大家可以睡個好覺，讓每個人的聰明才智可以發揮在他最能發揮的地方，而不是整天吐槽後臺、吐槽系統。

Q：資料管理這一類的崗位，人才供給情況怎樣?

A：現在很缺，非常缺。這個行業需求本來就比較大，加上要做數字化轉型，同時門檻比較高，進入這個行業基本不愁找不到工作。同時這個行業裡，經驗非常重要，越有經驗越吃香。中國美國都一樣，所有想做資料專案的第一個問題就是找不到人。

— 06 —

資料安全還是要靠規範

Q：中國和美國的大資料市場有哪些不同?

A：我覺得現在的差別已經不大了。現在國內的新型企業很追求效率的追求，對先進的方法論也很認可，這個跟美國的公司基本上沒有太多區別。雖然我也沒有太多接觸過美國的傳統企業，但是美國傳統企業接觸這種理念其實也都比較緩慢。但國內新興的企業、企業家們，都很認可資料價值，認可雲原生理念，也認可專業的企業服務。

要說區別的話，主要還是體現在兩邊的商務模式上。在美國，資料工程師、資料科學家有很大的採購權，幾萬美元、十幾萬美元產品都是實際做事的人來採購。但在中國，採購的決定權是從上往下的。這也是為什麼美國的開源比中國的更賺錢，開源打的就是中間這層真正使用的人，他們可以直接報告說需要這個開源公司來提供服務，上面一批就完了。但中國企業要申請個幾十萬的專案，就得從上往下批。

Q：國內市場發生了哪些變化?

A：以前大家做大資料好像是因為這個是一個風口，現在沒人是為了大資料而大資料，大家都認可了大資料真的能夠產生價值，沒有人會懷疑大資料的價值。但是大家對大資料怎麼落地還不是很清楚。所以，我覺得如何做出更好的工具降低門檻，更快地產生資料價值是現在企業面臨的一個挑戰。

這幾年，因為大家對雲原生技術的認可、對開源體系的擁抱，國內的技術生態比以前更加有活力。大家尤其認識到了開源對整個行業的推動作用，很多開源公司也取得了很好的成績。我們雖然現在沒有產品開源，但我們也有開源計劃，希望能夠為整個技術發展做一些貢獻。

Q：去年的大資料藍皮書也顯示了一個資料，中國的數字經濟指數在 G20 國家中排名第一，但安全指數排到了 14。據您的觀察，目前國內在資料安全治理方面存在哪些問題?

A：資料安全費錢，不產生直接價值，一般企業都不願意做這個事。比如要把幾千臺機器裡面所有關係到使用者私有資訊的資料集全部找出來，這件事產生不了任何積極價值，但它是非常重要的。Twitter 上市的時候，我負責做資料合規時，整個團隊花半年多的時間做資料治理，投入相當大。

這就一定需要用規範來要求企業資料必須合規，這也是行業發展到一定階段需要處理的事情。資料不規範可能無法出國做生意，老百姓也就沒有安全感。

對 DataOps 來說，企業可以直接把合規的規則實現在 DataOps 體系裡，讓資料質量等工具幫助企業完成一些合規檢查。但合規是與行業緊密相關的，比如銀行的資料要合規，那麼就會有專業團隊把銀監會合規的標準轉換成 ETL 查詢工具，再轉成合規報告。所以，合規會納入到 DataOps 這個體系裡面來，但是需要專業的團隊來做。

Q：最近釋出的《資料安全法》對大資料企業有什麼影響?企業如何加固資料安全?

A：我覺得是好事。所有的企業必須要注重自己的資料合規和資料使用方式。這對大資料企業來說是好事。

傳統方式做資料合規管理比較困難。我們觀察到，很多企業使用的 Hadoop 是不安全的，因為一旦用了安全的 Hadoop，還得用安全的卡夫卡、安全的 Spark 等，所有的元件都要是安全化的，那麼管理的複雜度要高很多。企業在建設之前，就應該把資料安全、資料合規問題考慮進去，後面補課是比較困難的。

Q：大資料行業現在面臨著哪些挑戰?未來的發展形勢如何?

A：大資料還是需要規範，需要一把手的認可和支援。現在很多企業的一把手知道資料的價值，但是不知道該招什麼樣的人，該怎麼樣去推進資料專案的落地，使其真正產生價值。國內現在對資料平臺價值的衡量還是一個黑盒子，一個大資料平臺到底產生了多少價值沒有辦法衡量。所以一把手的思路和對整個資料架構的規範體系建設，決定了很多大資料平臺的發展。

未來是 AI 的世界，AI 的底層就是資料。不管是個人成長還是公司的成長、企業的成長，基本上都是資料驅動，資料驅動讓生活更高效、生產更高效，放大個人價值。這是一個很值得投入的行業。