隨著企業(yè)擁抱數(shù)字化轉(zhuǎn)型，并將關(guān)鍵的基礎(chǔ)設(shè)施和應(yīng)用程序遷移到云端，作為關(guān)鍵組成部分的“數(shù)據(jù)云”已經(jīng)開始成形。這些數(shù)據(jù)云建立在多云數(shù)據(jù)基礎(chǔ)設(shè)施(如Databricks或Snowflake的數(shù)據(jù)平臺)之上，使企業(yè)能夠擺脫應(yīng)用程序和存儲豎井的束縛，在內(nèi)部、私有、公共和混合云環(huán)境中共享數(shù)據(jù)。

伴隨而來的數(shù)據(jù)量突飛猛進。大數(shù)據(jù)應(yīng)用越來越多地從人工智能(AI)、機器學(xué)習(xí)(ML)和物聯(lián)網(wǎng)(IoT)等各種技術(shù)中生成和吸收更多不同類型的數(shù)據(jù)，數(shù)據(jù)本身的性質(zhì)正在從根本上改變數(shù)據(jù)集的體積和形狀。

隨著數(shù)據(jù)從約束中解放出來，數(shù)據(jù)生命周期的可見性變得模糊，傳統(tǒng)的質(zhì)量控制工具很快就會過時。

壞數(shù)據(jù)和好數(shù)據(jù)一樣容易通過數(shù)據(jù)管道

對于典型的企業(yè)，數(shù)據(jù)監(jiān)測和管理仍然由來自不同時代設(shè)計的工具來處理。這些工具原本被設(shè)計用來監(jiān)視豎井式的靜態(tài)數(shù)據(jù)，當(dāng)然它們做得很好。然而，隨著大數(shù)據(jù)、云計算和數(shù)據(jù)倉庫/數(shù)據(jù)湖/數(shù)據(jù)管道等新技術(shù)開始進入主流，數(shù)據(jù)需求發(fā)生了變化。

傳統(tǒng)的數(shù)據(jù)工具從未被設(shè)計用來對今天這種復(fù)雜的連續(xù)數(shù)據(jù)管道進行質(zhì)量控制。這些管道將數(shù)據(jù)從一個應(yīng)用程序移動到另一個應(yīng)用程序，從云到云。然而，數(shù)據(jù)管道經(jīng)常將數(shù)據(jù)直接輸入到客戶體驗和商業(yè)決策軟件中，這帶來了巨大的風(fēng)險。

“錯誤的機票價格”是一個很好的例子，可以說明糟糕的數(shù)據(jù)如何逃過人們的注意并破壞業(yè)務(wù)目標(biāo)。錯誤的貨幣轉(zhuǎn)換、人為輸入錯誤，甚至是軟件故障，都經(jīng)常導(dǎo)致錯誤的票價，以至于一些旅游達人專門尋找這些“抄底”票價來“薅羊毛”。

錯誤的數(shù)據(jù)同樣可能導(dǎo)致不正確的信用評分、發(fā)送到錯誤地址的貨物、產(chǎn)生產(chǎn)品缺陷等等。市場研究公司Gartner發(fā)現(xiàn)：企業(yè)認(rèn)為，糟糕的數(shù)據(jù)質(zhì)量平均每年造成1500萬美元的損失。

管道數(shù)據(jù)的安全檢查員和清理人員在哪里?

當(dāng)開發(fā)人員急于應(yīng)對大規(guī)模維護和管理動態(tài)數(shù)據(jù)的挑戰(zhàn)時，大多數(shù)人首先想到了他們用來構(gòu)建現(xiàn)代軟件應(yīng)用程序的DevOps(開發(fā)運營)和CI/CD(持續(xù)集成/持續(xù)部署)方法。然而，要將這些實踐移植到數(shù)據(jù)中，有一個關(guān)鍵的挑戰(zhàn)：開發(fā)人員必須理解數(shù)據(jù)的彈性與應(yīng)用程序和基礎(chǔ)程序不同。

隨著應(yīng)用程序越來越多地采用來自云的數(shù)據(jù)湖、數(shù)據(jù)倉庫和流數(shù)據(jù)源的數(shù)據(jù)管道，需要對這些數(shù)據(jù)源的質(zhì)量進行持續(xù)監(jiān)控，以防止出現(xiàn)中斷。

我們必須問，誰負責(zé)在數(shù)據(jù)進入數(shù)據(jù)管道之前的數(shù)據(jù)檢查，誰負責(zé)出現(xiàn)數(shù)據(jù)泄漏或錯誤數(shù)據(jù)時的混亂的數(shù)據(jù)管道清理。到目前為止，典型的業(yè)務(wù)處理管道問題和中斷的方法是一種純粹的反應(yīng)性方法，在應(yīng)用程序中斷后修復(fù)。

為什么企業(yè)需要數(shù)據(jù)DevOps

今天典型的多云、數(shù)據(jù)驅(qū)動的企業(yè)希望用敏捷技術(shù)來擴展數(shù)據(jù)平臺，特別注意的是將DevOps(開發(fā)運營)方法移植到數(shù)據(jù)業(yè)務(wù)中。

軟件領(lǐng)域的DevOps之所以能夠成功，是因為有一個強大的安全網(wǎng)絡(luò)SRE(Site Reliability Engineering 站點可靠性工程)與之一起成熟起來。SRE的原則確保組織可以在部署后監(jiān)控軟件的行為，確保在實踐中滿足生產(chǎn)的應(yīng)用，而不僅僅是理論。如果沒有SRE，對于業(yè)務(wù)關(guān)鍵型應(yīng)用程序和基礎(chǔ)設(shè)施來說，依賴敏捷方法風(fēng)險太大，而且容易出錯。

數(shù)據(jù)業(yè)務(wù)同樣需要類似方法保障，有人稱之為DRE((Data Reliability Engineering 數(shù)據(jù)可靠性工程))。一些組織已經(jīng)對他們的數(shù)據(jù)軟件進行了開發(fā)/階段測試，但標(biāo)準(zhǔn)的開發(fā)/階段測試僅僅是對動態(tài)大數(shù)據(jù)的質(zhì)量檢查。數(shù)據(jù)具有無法通過傳統(tǒng)測試實踐進行管理的特性。對于初學(xué)者來說，測試數(shù)據(jù)比較困難，因為數(shù)據(jù)是動態(tài)的。在你的管道中流動的數(shù)據(jù)——通常是通過應(yīng)用程序獲取的實時信息生成——甚至在開發(fā)或管道部署時可能是不可用的。

如果只依賴于開發(fā)/階段測試，那么大量的不良數(shù)據(jù)可能會流經(jīng)數(shù)據(jù)管道，從而導(dǎo)致中斷和錯誤，而質(zhì)量控制工具直到出現(xiàn)問題后才能夠發(fā)現(xiàn)問題。

數(shù)據(jù)DevOps和數(shù)據(jù)可靠性工程入門

對于已經(jīng)接受敏捷和DevOps實踐的組織來說，開發(fā)數(shù)據(jù)DevOps能力不應(yīng)該是一個沉重的負擔(dān)。關(guān)鍵在于根據(jù)當(dāng)今龐大、不斷變化、高容量、云計算數(shù)據(jù)的獨特特點，打造新的角色和能力。

如果遵循下面的六個步驟來奠定適當(dāng)?shù)馁|(zhì)量控制基礎(chǔ)，企業(yè)組織將會很好地控制失控的數(shù)據(jù)。

1.接受數(shù)據(jù)DevOps并明確定義角色

與傳統(tǒng)的靜態(tài)數(shù)據(jù)(以及支持它的系統(tǒng))相比，現(xiàn)代數(shù)據(jù)帶來了不同的挑戰(zhàn)，所以一定要清楚地將數(shù)據(jù)DevOps角色與密切相關(guān)的職位區(qū)分開來。例如，數(shù)據(jù)工程師不是質(zhì)量控制專家，也不應(yīng)該是。他們有不同的優(yōu)先事項。數(shù)據(jù)分析師和其他軟件工程師也是如此。

2.確定DRE將如何以及在何處匹配業(yè)務(wù)流程

DRE應(yīng)該與DataOps(數(shù)據(jù)運營)/DevOps(開發(fā)運營)團隊緊密合作，但該角色應(yīng)該在數(shù)據(jù)團隊中創(chuàng)建。為了確保持續(xù)的質(zhì)量，DRE必須參與數(shù)據(jù)創(chuàng)建和管理過程中的所有關(guān)鍵步驟。

3.提供幫助DevOps團隊成功的工具

數(shù)據(jù)DevOps應(yīng)該有自己的一組工具、專業(yè)知識和最佳實踐，其中一些來自相關(guān)領(lǐng)域(比如軟件測試)，其他的開發(fā)是為了應(yīng)對移動中的高容量、高基數(shù)數(shù)據(jù)的獨特挑戰(zhàn)。

4.確定如何編寫及維護質(zhì)量檢查和控制

許多數(shù)據(jù)質(zhì)量程序失敗的原因是，用于編寫質(zhì)量檢查的遺留工具和自己開發(fā)的工具難以處理復(fù)雜性。這些工具本身很復(fù)雜，難以使用，最終成為擱置的軟件。隨著數(shù)據(jù)的發(fā)展，必須考慮更新和維護數(shù)據(jù)質(zhì)量檢查的過程，依靠直觀的工具來輕松地完成工作。

5.開始映射過程

隨著數(shù)據(jù)DevOps團隊的發(fā)展，不要忘記規(guī)劃流程。確保數(shù)據(jù)DevOps團隊知道發(fā)生數(shù)據(jù)中斷時應(yīng)遵循的程序。DRE可能需要引入其他專家，如數(shù)據(jù)工程師、數(shù)據(jù)分析師甚至業(yè)務(wù)利益相關(guān)者，他們可以解釋數(shù)據(jù)，并消除質(zhì)量問題對合法變更的歧義。

6.為成功的補救措施描繪一幅清晰的畫面

大數(shù)據(jù)補救是一個獨特的挑戰(zhàn)。對于動態(tài)數(shù)據(jù)，某些類型的補救是沒有意義的。例如，如果正在糾正導(dǎo)致http請求失敗或頁面加載緩慢的問題，那么這些進程就會丟失。

現(xiàn)代數(shù)據(jù)驅(qū)動的應(yīng)用程序需要數(shù)據(jù)DevOps來確保關(guān)鍵任務(wù)數(shù)據(jù)的可靠性

現(xiàn)代云計算、數(shù)據(jù)驅(qū)動的企業(yè)需要可靠、高質(zhì)量的數(shù)據(jù)來滿足其業(yè)務(wù)目標(biāo)。然而，現(xiàn)代環(huán)境中數(shù)據(jù)的復(fù)雜性意味著，企業(yè)不僅需要DevOps用于IT和應(yīng)用程序，還需要DevOps用于數(shù)據(jù)。數(shù)據(jù)DevOps是一門學(xué)科,需要方法對連續(xù)數(shù)據(jù)進行質(zhì)量監(jiān)控。

對于大多數(shù)企業(yè)來說，控制數(shù)據(jù)的下一步就是采取步驟，確保持續(xù)質(zhì)量的任何步驟。將數(shù)據(jù)質(zhì)量控制作為優(yōu)先事項，擁抱數(shù)據(jù)DevOps，并開始規(guī)劃如何將這些新功能與您現(xiàn)有的DevOps、數(shù)據(jù)和測試團隊相適應(yīng)，這樣就有機會領(lǐng)先于競爭對手。