[[420500]]

|0x00 質(zhì)量VS效率

我一直有一個觀點：“數(shù)據(jù)模型設(shè)計的是商業(yè)模式，是產(chǎn)品邏輯;數(shù)據(jù)結(jié)果反映的是業(yè)務(wù)實操，是實際現(xiàn)狀。”

數(shù)據(jù)開發(fā)的效率，是如何盡快的將產(chǎn)品設(shè)計、業(yè)務(wù)過程，轉(zhuǎn)換為數(shù)據(jù)模型;數(shù)據(jù)開發(fā)的質(zhì)量，則是如何盡快的將數(shù)據(jù)加工過程中的問題，識別出來。向業(yè)務(wù)交付的內(nèi)容，是開發(fā)的內(nèi)容;而如果開發(fā)的時候，忽略質(zhì)量的問題，雖然交付的時候不會有感知，但往往會在排查問題階段，把這些時間加倍的補償回來。

很多時候，開發(fā)同學會覺得，做這么多質(zhì)量工作是“無效”的，因為很多問題，并不需要數(shù)據(jù)同學對業(yè)務(wù)有太深入的了解，如果發(fā)現(xiàn)了，會覺得業(yè)務(wù)就這么設(shè)置的，跟我有啥關(guān)系;如果沒發(fā)現(xiàn)，那就是開發(fā)工期太緊張了，我做不過來。

比如，按照規(guī)定，我們要向1萬用戶發(fā)放優(yōu)惠券，但因為人群選擇錯了，導致發(fā)出去了10萬張優(yōu)惠券;再比如，商品綁定錯了貨品，或者是發(fā)貨發(fā)錯了，但大家的第一想法是數(shù)據(jù)算錯了。這些情況的出現(xiàn)，導致數(shù)據(jù)和業(yè)務(wù)出現(xiàn)一些對立的情緒。

但幸運的是，數(shù)據(jù)質(zhì)量問題的排查，要遠比業(yè)務(wù)系統(tǒng)問題的排查，容易不少，因為我們有章可循。

所以，如何在保證開發(fā)速度的情況下，做好質(zhì)量保障，是一個很重要的問題。效率和質(zhì)量，哪個都不能放棄，是數(shù)據(jù)開發(fā)的兩條生命線。

本文我們分開講講，質(zhì)量體系的事情，效率體系的事情，以及兩者如何兼顧平衡。

|0x01 數(shù)據(jù)質(zhì)量體系

數(shù)據(jù)的作用可以從三個比較宏觀的維度來描述，一個是豐富、一個是準確、一個是及時。豐富的數(shù)據(jù)可以為業(yè)務(wù)提供更多可以描述業(yè)務(wù)的方法，準確的數(shù)據(jù)意味著交付結(jié)果及分析結(jié)論是可靠的，及時的是數(shù)據(jù)代表我們面對市場變化所能夠做出的反應(yīng)時間。因此，數(shù)據(jù)質(zhì)量的體系，要以保障這三條為主。

從這個角度來講，我們能夠總結(jié)出一些常見的數(shù)據(jù)問題，而這些都是我們需要關(guān)注的。

首先是唯一性，也就是常講的“主鍵唯一”，公共層的表主鍵必須唯一，例如訂單表中的訂單號、倉庫表中的倉庫編碼，等等;如果是DWS層，那么統(tǒng)計的維度也是要唯一的，例如商品 + sku的統(tǒng)計表中，這兩個ID的組合結(jié)果就要唯一。

其次是異常值，最常見的異常值是“空值”，如果一個字段的取值都是空，那么就需要考慮廢棄該字段;同時，還有一些比較常見的場景，比如支付金額一般情況下不能是負值，這些都考驗開發(fā)對于業(yè)務(wù)的熟練掌握程度;

再次是格式類型，比如日期的格式是否都是yyyyMMdd，再比如身份證號是不是有不符合位數(shù)的情況，不一而足;

最后是波動性，對于GMV、商品數(shù)這種全局性的指標，如果波動太大那么出現(xiàn)問題的可能性就很大。

所以平時就要從各個數(shù)據(jù)的關(guān)鍵環(huán)節(jié)，與業(yè)務(wù)或者服務(wù)端、客戶端一起，解決這些問題。

在業(yè)務(wù)側(cè)，要規(guī)范運營的操作，比如該填寫的信息沒有寫，商品名稱沒有錄入;或者是填寫的信息存在問題，比如把小二的信息填錯了。

在工程側(cè)，問題產(chǎn)生的可能性最多，比如訂單號記錄重復了、數(shù)據(jù)精度轉(zhuǎn)換時出錯、數(shù)據(jù)存在空格導致與null產(chǎn)生差異，等等。

在消費側(cè)，同步任務(wù)重啟導致數(shù)據(jù)重復，或者是某些數(shù)據(jù)庫任務(wù)掛掉導致少同步數(shù)據(jù)，都可能造成數(shù)據(jù)缺失或者重復。

通常情況下，不論是哪個環(huán)節(jié)發(fā)現(xiàn)了問題，都要及時的止損，因為把錯誤數(shù)據(jù)放給了下游，導致大范圍的數(shù)據(jù)問題、數(shù)據(jù)重新刷新的成本，都是不可承受的。

當然，我們保障數(shù)據(jù)質(zhì)量的方法，也都大同小異，主要包括：

數(shù)據(jù)規(guī)范：有道是“無規(guī)矩不成方圓”，規(guī)范并不是方便小二開發(fā)的，而是為了方便其他人閱讀和接手代碼的，排查問題時能夠更快的定位，因此是團隊必須遵守的規(guī)范;

項目文檔：大多數(shù)時候，僅僅通過看代碼，我們是無法還原這么設(shè)計的意圖，因此整理下項目文檔，記錄背景、需求的詳情，以及建模的思考過程與流程圖，也是團隊要強制的內(nèi)容;

DQC：為每一個關(guān)鍵任務(wù)，加上基本的數(shù)據(jù)校驗，如主鍵唯一、數(shù)據(jù)字段空值校驗，等等，這也是任務(wù)自測的關(guān)鍵環(huán)節(jié);

自動化測試：很多測試部門會寫好任務(wù)回歸用例，常見的一些問題會總結(jié)成自動化的任務(wù)，能夠有效識別一些不常見的錯誤。

以上，就是數(shù)據(jù)質(zhì)量體系的常見內(nèi)容。

|0x02 數(shù)據(jù)效率體系

數(shù)據(jù)開發(fā)講求產(chǎn)出，不光要有“量”的結(jié)果，也要有“質(zhì)”的思考。如果一味的做基礎(chǔ)工作，被替代的可能性非常高。

因此，我們非常希望業(yè)務(wù)來提需求，因為這樣才能貼近業(yè)務(wù)去走，體現(xiàn)個人或者團隊的價值;但同時，我們又希望更快的交付這些需求，這樣才能有時間，來把解決問題的過程或者方法，總結(jié)并沉淀下來。

開發(fā)的效率的提升方法，大體有四種：一是借助基礎(chǔ)平臺提供的工具，二是憑借完善的公共層，三是良好的業(yè)務(wù)Sense，四是多方順利的合作模式。

先講一下基礎(chǔ)平臺提供的工具，大數(shù)據(jù)的發(fā)展，從早期的靠工程師手動搭建集群、手動運維，發(fā)展到后來CDH這種有完善管理功能的集群，再發(fā)展到以阿里云為代表的完善商業(yè)化方案，工具提供的生產(chǎn)力已經(jīng)不同于往日。因此，市面上的崗位，也從早期的“大數(shù)據(jù)開發(fā)”，逐步的過渡到了“數(shù)據(jù)倉庫”，再到如今的“數(shù)據(jù)技術(shù)”，本質(zhì)還是用數(shù)據(jù)來做需求開發(fā)，但其本質(zhì)內(nèi)核已經(jīng)發(fā)生了比較大的變化?？梢哉f，正是因為工具的不斷完善，使得開發(fā)從偏后臺的職能，走向了前臺業(yè)務(wù)的職能。

在這個基礎(chǔ)上，SQL開發(fā)有工作臺、數(shù)據(jù)分析有在線文檔、運維有監(jiān)控平臺、元數(shù)據(jù)有數(shù)據(jù)地圖、任務(wù)執(zhí)行有像海豚調(diào)度這種完善的工具、數(shù)據(jù)庫有TiDB這種融合了OLAP和OLTP的工具、實時開發(fā)Flink統(tǒng)一天下。可以講，數(shù)據(jù)開發(fā)如何使用好工具，已經(jīng)成為了提升開發(fā)效率的不二法寶。

再講一下完善的公共層，公共層是互聯(lián)網(wǎng)數(shù)據(jù)倉庫的核心理念，將復雜的業(yè)務(wù)由專門的團隊，統(tǒng)一進行管理和建模，降低了下游理解數(shù)據(jù)、使用數(shù)據(jù)的難度。因此，不論團隊規(guī)模有多大、數(shù)據(jù)團隊的發(fā)展到了怎樣的一個階段，把公共層做好，都是一件非常有必要的事情。

按照分層理論，公共層是DWD/DIM/DWS三者的統(tǒng)稱，也正好反映了Kimball所提出的一致性維度+一致性事實。因此，公共層也是最考驗建模水平的階段，它是解決業(yè)務(wù)復雜性、保障準確性的最重要基石。

其次講一下良好的業(yè)務(wù)Sense，因為建模所反映的是業(yè)務(wù)應(yīng)有的邏輯，但它不代表業(yè)務(wù)想看到的邏輯，比如在電商場景中，優(yōu)惠券的發(fā)放是一件比較復雜的事情，各種優(yōu)惠策略可以設(shè)置的很靈活。但因為策略設(shè)置的很靈活，因此公共層不太可能把運營的玩法記錄清楚，只是記錄發(fā)生了什么事情。因此，當你想從應(yīng)用層建模的時候，會發(fā)現(xiàn)每年的玩法都在變，每年的模型都要改了重新做。最重要的是，如果沒有貼近業(yè)務(wù)，一不留神，數(shù)據(jù)沒按照玩法算，結(jié)果就是錯的，會被人追問數(shù)據(jù)準確性問題。

這其實也是關(guān)系到開發(fā)效率的核心因素，即你能不能準確理解業(yè)務(wù)的意圖，因為不會所有的需求都寫的一清二楚，很多邏輯還是需要自己來做判斷。

最后說一下多方順利的合作模式，雖然SQL開發(fā)是效率最高的交付語言了，但很多基礎(chǔ)性的工作，少不了和其他部門打交道，比如OLAP引擎、比如前端頁面、比如報表工具、比如工程業(yè)務(wù)邏輯，等等。因此，很多項目是否能夠如期完工，就需要看與其他團隊的配合情況了。

做過項目管理的同學都清楚，項目工期取決于最長關(guān)鍵路徑，但互聯(lián)網(wǎng)業(yè)務(wù)的現(xiàn)狀，往往決定了服務(wù)端在跨團隊合作中，是起到主導作用的，因此尤其要注意兩者的合作關(guān)系。

|0xFF 數(shù)據(jù)質(zhì)量與開發(fā)效率的平衡

因為績效的壓力，我們需要高效率的做開發(fā);又因為數(shù)據(jù)質(zhì)量/數(shù)據(jù)安全/業(yè)務(wù)投訴這種懸在頭上的達摩克斯之劍，我們又不能忽視繁瑣的質(zhì)量保障工作，怎么辦?

筆者的看法，我們有兩個突破口，來解決這個問題。首先，將質(zhì)量問題控制在某個層次上，也就是抓問題抓主要矛盾，其次，要有熟練的上手流程，避免重復性的說教工作。

將質(zhì)量問題控制在某個層次上。這其實要分兩個情況，一個是團隊能夠有正常的排期研發(fā)流程;另一個是野蠻成長，追求競爭的機制。

對于正常排期的研發(fā)流程，建議在流程前加入模型評審的環(huán)節(jié)，流程后加入測試的環(huán)節(jié)。對于大多數(shù)的問題，模型評審能夠解決設(shè)計混亂的問題，而測試可以有效把低級問題消滅掉。再配合自測使用的DQC，基本上95%以上的問題，都可以解決掉。這種正常研發(fā)排期的環(huán)節(jié)，對數(shù)據(jù)質(zhì)量問題往往是控制的比較好的。

對于追求競爭的機制，那么公共層的設(shè)計就很重要，默認情況下，100%的表要覆蓋DQC監(jiān)控，同時每個表也要配合三個以上的DQC規(guī)則。因為ADS開發(fā)節(jié)奏都很快，而且需求往往是變動性非常大的，今天改邏輯明天再改這種的，那么確保公共層是正確的的，阻斷大部分的問題，就很重要。

熟練的上手流程。其實數(shù)據(jù)開發(fā)不像工程，任務(wù)通常都是以表的形式存在，而且團隊會跨業(yè)務(wù)線進行開發(fā)工作，這些情況下，閱讀他人的代碼、熟悉他人的業(yè)務(wù)，就成了習以為常的事情。很多團隊總是出問題，大體上集中在兩個階段，一個是老人帶新人階段，新人不懂坑有哪些;一個是業(yè)務(wù)交接的階段，不熟悉業(yè)務(wù)，會導致一些看似邏輯正確的改動，引起了某些業(yè)務(wù)上的邏輯缺陷。

從這個角度看，作為數(shù)據(jù)開發(fā)，不厭其煩的整理文檔、Review模型、匯報業(yè)務(wù)線情況，都是一些非常有必要的事情。一方面可以幫助團隊其他同學了解業(yè)務(wù)，另一方面也為需求開發(fā)的背景和設(shè)計思路，留下比較充足的參考資料。從這個角度看，提供參考的規(guī)范與文檔定期Review，這件事情在工作中的占比，可以達到30%以上。

最后，我們還需要注意一點，就是要有與業(yè)務(wù)直接對話的通道，以培養(yǎng)業(yè)務(wù)Sense。比如，業(yè)務(wù)操作的規(guī)范性、一些常見的業(yè)務(wù)問題總結(jié)。

盡管我們是偏后臺的數(shù)據(jù)團隊，但我們要走到前臺，就要有一種宣講、同步機制。這并不是故意擴大影響力，而是確實有必要的。我們要講清楚數(shù)據(jù)背后的邏輯、數(shù)據(jù)計算的口徑、數(shù)據(jù)工具使用的方法，等等。尤其要講清楚，我們能做什么、不能做什么，有一套成熟的應(yīng)對方法，以解釋很多情況下數(shù)據(jù)與經(jīng)驗有偏差的原因，并把這些差異呈現(xiàn)出來。

雙方理解一致了，很多質(zhì)量問題，也就迎刃而解了。

祝大家工作994，生活工作兩balance。