[[420500]]

|0x00 質量VS效率

我一直有一個觀點：“數據模型設計的是商業模式，是產品邏輯;數據結果反映的是業務實操，是實際現狀。”

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

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

比如，按照規定，我們要向1萬用戶發放優惠券，但因為人群選擇錯了，導致發出去了10萬張優惠券;再比如，商品綁定錯了貨品，或者是發貨發錯了，但大家的第一想法是數據算錯了。這些情況的出現，導致數據和業務出現一些對立的情緒。

但幸運的是，數據質量問題的排查，要遠比業務系統問題的排查，容易不少，因為我們有章可循。

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

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

|0x01 數據質量體系

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

從這個角度來講，我們能夠總結出一些常見的數據問題，而這些都是我們需要關注的。

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

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

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

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

所以平時就要從各個數據的關鍵環節，與業務或者服務端、客戶端一起，解決這些問題。

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

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

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

通常情況下，不論是哪個環節發現了問題，都要及時的止損，因為把錯誤數據放給了下游，導致大范圍的數據問題、數據重新刷新的成本，都是不可承受的。

當然，我們保障數據質量的方法，也都大同小異，主要包括：

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

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

DQC：為每一個關鍵任務，加上基本的數據校驗，如主鍵唯一、數據字段空值校驗，等等，這也是任務自測的關鍵環節;

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

以上，就是數據質量體系的常見內容。

|0x02 數據效率體系

數據開發講求產出，不光要有“量”的結果，也要有“質”的思考。如果一味的做基礎工作，被替代的可能性非常高。

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

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

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

在這個基礎上，SQL開發有工作臺、數據分析有在線文檔、運維有監控平臺、元數據有數據地圖、任務執行有像海豚調度這種完善的工具、數據庫有TiDB這種融合了OLAP和OLTP的工具、實時開發Flink統一天下。可以講，數據開發如何使用好工具，已經成為了提升開發效率的不二法寶。

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

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

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

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

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

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

|0xFF 數據質量與開發效率的平衡

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

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

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

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

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

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

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

最后，我們還需要注意一點，就是要有與業務直接對話的通道，以培養業務Sense。比如，業務操作的規范性、一些常見的業務問題總結。

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

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

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