聊點數據開發和心態的事兒～

• 2020 年 3 月 26 日
• 筆記

hello～大家好我是SamGor～

寫在前面

最近工作上有蠻多困難的地方，每天都揪心地很，歸根到底還是心態不夠強大，心態崩了，自然事情也很難去很好的完成✅了，還好最近有老婆和家人的陪伴，也算是熬了過來，也是讓大家擔心了?，愧疚。

其實問題的根本，就是沒有調整好自己的心態，但今天我並不想在這裡講怎麼調整自己的心態，遇見前所未有的挑戰以及耽誤項目計劃的風險如何去面對，因為在這塊我只能說是勉強度過「難關」，還不能說達到給大家講「大道理」的程度。今天我更想總結的是一些數據開發上的一些開發經驗，這些內容也可以算是對自己過去3周的一些痛苦內容的總結了。

數據開發前

數據開發前，當然就是要詳細閱讀需求了，這裡面如何閱讀好標籤需求，我覺得有幾點需要明確的：

標籤定義的明確

有些標籤，需求方往往只是簡單的描述內容，業務口徑，邏輯口徑都是給的不周全的，這個時候千萬不要自己就下判斷了，不然很可能你會重新開發程式碼。

數據提供方式的確認

數據服務提供同時要考慮計算資源、傳輸效率，因為我們本次主要還是考慮ES介面的方式，按照以往的經驗來說可能不太支援本次的需求，主要就是傳輸的瓶頸問題，因此提前做好技術諮詢然後進行擴容準備。

標籤值的確認

為什麼這個要單獨拎出來說呢，因為有的時候可能需求方本身也沒有對數據有很深的了解，因此對於標籤值的定義可能都是「拍腦袋」決定的，有些比較明顯的問題可能沒能考慮到的。比如：缺失值的填充方式是否符合實際意義，是否存在矛盾衝突的情況（比如把一些「距今X天的XXX標籤的缺失填充為0，那麼容易和當天的數據衝突（因為當天就是距今0天）。還有就是枚舉值的確認，明確實際數據中，是否這個欄位的枚舉值就是需求的那幾種，在這些之外的如何處置。等等等。

更新頻率的確認

在你初步對需求進行分析的時候，可能會發現其實有些指標在計算上存在比較困難的情況，每天更新數據會比較消耗資源，這個時候可以再次和需求方確認需求情況，了解對這些欄位的更新頻率是否比較敏感，這樣子對於數據部門的資源利用也有很大的幫助。

數據開發ing

終於到了數據開發的環節，這個時候考驗一個數據開發工程師的技術來了～但我個人的小小經驗就是養成一個條理性的開發習慣真的對我們開發效率有很大的幫助！

比如說，項目文件架構的管理，創建不同的子文件夾來管理我們的項目文件：如需求文件、data、測試code、上線code等，同時我也建議要新建一個開發進度記錄excel，用來記錄在開發過程中的操作，比如：

• 開發過程中遇見的問題，記錄下來，後續追蹤是否解決；
• 開發測試的過程程式碼和測試結果，方便後續回溯；
• 記錄調度上線的操作，了解整體的開發進度。

上面的只是一些開發習慣了，不同的開發同學可能都會有適合自己的一套辦法，只要能夠有條理的記錄留存便於回溯，最合適自己的才是最好的！

此外，還有一點就是想和大家說的，就是進行數據開發前，一定要先設計好相關的開發概要文檔，內容包括資料庫表的結構設計，表欄位命名方式，更新方式等等，同時在開發前和組內同時進行評審，了解是否有缺陷或者不符合開發規範的地方，及時進行修正！正所謂「磨刀不誤砍柴工」～

那麼進行正式開發了，我們是需要對我們的底層數據進行探索的，了解數據的品質、數據分布、數據更新方式、數據分區情況、是否存在重複數據、欄位的使用方式等等，不要太相信直接的表的描述和他人的轉述，有什麼想法還是需要自己去進行驗證。

數據測試

這一個環節是十分重要的，我們寫的程式碼跑得通並不代表就是對的，很多時候，指標的邏輯可能就沒能寫對的，所以才會引入測試的環節，而且最好就是有個「局外人」同事進行測試，從一個多維交叉的角度以及抽樣調查的方式來進行數據測試。

當然了，一個合格的數據開發工程師，這一塊的工作還是需要自己也做一遍的，而不是說完成了程式碼開發就完事了，然後就等著測試同事來給你發現問題！自己需要對結果進行多角度交叉檢驗，也需要抽幾個用例進行計算結果的核對，校對其邏輯是否正確。港真，這一塊的工作確實是枯燥乏味，但是卻很重要！！

交付

交付前，其實還有很多工作要做的，我這裡也不一一展開了，比如程式碼評審、上線評審、發布評審等等，但是記住這些都不能省，而且項目文檔記得也要做好整理和歸檔。

開發小記錄

這一塊只是針對最近一次的開發總結出來的一點點小經驗，防止後續忘記了。

1、多留意多對多情況

很多時候我們會直接對數據進行join關聯了，但是如果數據中存在主鍵重複的情況，而你又沒有合理地去重，那麼數據將會被錯誤的「膨脹」，有的時候比較明顯你會發現，有的時候你發現不了那就隱患大了。所以我建議大家在進行關聯前，都應該對數據進行一次「重複主鍵」檢驗。

2、小心數據傾斜

我們有的時候發現自己寫完hive，感覺邏輯什麼的都沒毛病，但是就是跑得很慢，那麼這個時候就要考慮一下是否有數據傾斜的情況了，這個概念我就不展開說明了，百度一下有很多的解釋以及解決辦法，這個大家也可以看看我之前的舊文《一文帶你搞清楚什麼是「數據傾斜」》

3、注意空值的處理

我們對於空值的提前預判以及處理，對於我們後續的數據品質會有很大的幫助和控制，這裡有一個函數還是很好用的，叫NVL函數。

其格式如下：NVL(expr1,expr2)

含義為：如果第一個參數為null（空值）那麼顯示第二個參數的值，如果第一個參數的值不為null（空值），則顯示第一個參數本來的值。

還有一個升級版的函數，叫Coalesce函數，大家感興趣也可以去了解一下。

4、大計算量指標的提前拆解

這一塊確實是一個比較頭疼的地方，有些指標你直接用常規的邏輯去寫hive是死活計算不出來的，我距一個例子：近2年內最近一次通話（主叫）的手機號碼。

我們假設一下我們的客戶有10個億，然後過去兩年的通話記錄明細，假設每個客戶每天至少打1個電話，每天有20%的客戶有打電話，那麼一天的數據量都會有2億行。然後我們需要計算上面那個指標，正常邏輯下，可能就是說我們把過去2年的數據都拿出來，然後根據客戶ID、手機號碼，按照通話時間進行排序，取最新的一條記錄就好了。但是一般情況下，是算不出來的～

那麼，我們可以怎麼辦呢？其實問題就在於我們需要對一個大數據進行排序操作，然後計算資源不夠導致無法排序成功，那麼我們就可以進行「時間窗口」的拆解，比如按月的數據來排序。比如：

• 取20180101-20180201的數據，根據客戶ID、手機號碼，按照通話時間進行排序，取最新的一條記錄，寫入一個臨時表，我會命名為 XXXX_loan，其分區為pt_date = 「201801」
• 接著取20180201-20180301的數據，同樣的邏輯進行計算，寫入 pt_date = 「201802」分區
• 一直寫，寫到最近的1個月，然後對 XXXX_loan表進行一次最終版的排序去重，按照客戶ID，分區欄位（pt_date）進行排序，最後保留每個客戶一條最新記錄，寫入目標表。
• 最後就是設置調度任務，每天增量地去計算每天客戶的最新一條記錄，用來更新目標表的標籤值。

這種比較折中的辦法，也是沒有辦法里的辦法了，僅供參考哈哈。

最後我還是覺得我們的心態真的很重要，千萬不要因為一些小的困難就打擊到自信，慌了陣腳～穩住，冷靜思考，這才是我們可以持續成長的關鍵！