[[420500]]

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

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

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

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

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

但幸運(yùn)的是，數(shù)據(jù)質(zhì)量問題的排查，要遠(yuǎn)比業(yè)務(wù)系統(tǒng)問題的排查，容易不少，因?yàn)槲覀冇姓驴裳?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

通常情況下，不論是哪個(gè)環(huán)節(jié)發(fā)現(xiàn)了問題，都要及時(shí)的止損，因?yàn)榘彦e(cuò)誤數(shù)據(jù)放給了下游，導(dǎo)致大范圍的數(shù)據(jù)問題、數(shù)據(jù)重新刷新的成本，都是不可承受的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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