資料開發流程及規範

在大資料時代，規範地進行資料資產管理已成為推動網際網路、大資料、人工智慧和實體經濟深度融合的必要條件。貼近業務屬性、兼顧研發各階段要點的研發規範，可以切實提高研發效率，保障資料研發工作有條不紊地運作。而不完善的研發流程，會降低研發效率，增加成本與風險。

資料研發規範旨在為廣大資料研發者、管理者提供規範化的研發流程指導方法，目的是簡化、規範日常工作流程，提高工作效率，減少無效與冗餘工作，賦能企業、政府更強大的資料掌控力來應對海量增長的業務資料，從而釋放更多人力與財力專注於業務創新。

二、資料開發流程

鑑於對日常資料倉儲研發工作的總結與歸納，將資料倉儲研發流程抽象為如下幾點：

1. 需求階段：資料產品經理應如何應對不斷變化的業務需求。

2. 設計階段：資料產品經理、資料開發者應如何綜合效能、成本、效率、質量等因素，更好地組織與儲存資料。

3. 開發階段：資料研發者如何高效、規範地進行編碼工作。

4. 測試階段：測試人員應如何準確地暴露程式碼問題與專案風險，提升產出質量。

5. 釋出階段：如何將具備釋出條件的程式平穩地釋出到線上穩定產出。

6. 運維階段：運維人員應如何保障資料產出的時效性和穩定性。

具體開發流程

1. 需求：與運營產品討論需求。業務方把需求提交到JIRA，並且和產品溝透過。

2. PRD評審：產品評審PRD文件。

3. 技術方案討論：最好是負責人先溝通一個初級的方案，然後找大家一起討論（可能比直接頭腦風暴效率搞，根據負責人的經驗來討論）；然後找大家一起討論。

4. 技術設計評審：設計評審叫上測試。

5. 設計評審的原則：評審會議應該是設計方案大家基本認同的前提下，做方案的文件。

6. 設計介面：重點準確描述輸入和輸出。

7. 設計欄位：根據需求定義欄位，並確定欄位指標和獲取來源，建立資料字典。

8. 開發：開分支，寫程式碼。做好測試case的建立，然後自測。

9. 程式碼review：叫上測試和一個其他開發同學，給出review的結果。目的是讓其他同學幫忙review其中的邏輯。

10. 提測：給出提測報告，包括羅列測試點。

11. 上線：提前告知運維，提前申請機器資源，根據業務預估好CPU、儲存、頻寬等資源。

12. 文件：開發完成後，文件記錄一下流程以及提供資料表欄位說明，方便重構。

資料需求流程

各個角色職責

這個流程針對的是專案是開發，在專案立項的開始，就需要明確各個角色的職責，而且需要和多個角色進行配合。作為資料開發人員，需要協調和各個角色之間的互動：

• 需要和產品評估該需求的合理性，現有技術棧能否支援該需求，例如：公司想要做個實時資料大盤，如果沒有實時數倉的架構，是沒法完成這塊需求。一旦確定開發，需要協調資源，包含開發資源、裝置資源等等。
• 需要和業務方、產品方評估資料可行性，資料開發的資料來源並不是憑空出現的，需要和業務方明確已有資料能否支撐需求開發，如果缺少資料，則需要另行規劃缺失資料的抽取方案。
• 需要自己評估技術可行性，資料開發可能涉及到資料傳輸、資料同步、ETL、實時開發、離線開發等等，要評估從資料來源獲取到資料展現一套流程的可行性，例如：資料來源如果為多個地方產出，可能需要從binlong獲取、Kafka讀取、業務庫同步、HDFS讀取等等，資料輸出也可能到各個地方，例如：mysql、hive、ES、Kafka、redis等等多個儲存，需要在開發之前確定整套資料的流程。
• 需要確定是否滿足安全與合規要求，對於一些敏感資料如何處理，是一個很重要的組成部分，作為資料開發人員，可能接觸的資料比較多，但是哪些資料可以展現、哪些資料脫敏後可以展現、哪些資料不能落地等等，而且在資料流轉過程中，也要關注資料的安全性，能否落地、能否轉存等等。
• 需要和測試同學同步資料處理邏輯，並將一些邏輯的SQL進行文件化，方便測試同學進行單元測試，在交付測試之前，需要對程式碼進行自測，以便保障流入到測試執行環節的程式碼達到一定的質量標準。同時最好能讓程式碼透過配置在不同環境進行切換，方便測試同學在測試環境、預發環境進行測試，測試透過後同一套程式碼能夠直接上線。

三、日常資料支撐

除了專案式的開發外，資料開發人員大部分情況下都會面對產品提出來的一些臨時性的資料需求，例如拉去一下近半年的銷售情況、使用者訪問情況等等，這部分資料支撐不需要後端配合、可能也不需要進行測試，而是在已明確的資料指標的基礎上，定期或者不定期的提供一個資料包表。這部分的資料開發模式相對來說比較簡單和快速，但是也需要明確：

• 明確資料需求模板、常規需求申請單等等，提供需求單的目的是避免長時間的溝通，特別是已經有的資料指標，只需要讓產品提供一份詳細的資料需求單，按照需求單的模版進行提供資料即可。模版如下：

指標需求中通常會涉及到下表中的約定項，如果需要自定義約定項，可以在自定義格式列進行填寫。

• 明確需求的指標含義，和所需求的欄位明細、統計週期、開發週期等。

四、注意

• 需求評審完成後，如果發生需求變更或者迭代，一定需要提供迭代/變更的需求申請單，或者提供JIRA，避免需求不可追溯。

• 對於一些重要指標的定義，就算文件中寫了，也要和產品進行確定，例如產品需要近半年的所有銷量，那麼要明確這個銷量是否包含退款、是按照成交時間還是付款時間來計算等等。避免資料指標不匹配，導致二次開發。

• 開發過程中，文件要規範，先設計在開發，而且在做系統建設的時候，要有全域性視野，不侷限某一個點，並不是釋出完成了，就算結束，程式碼開發完成只是第一步，後續的文件建設、程式碼覆盤、資料監控、資料告警、穩定性等等，都需要在開始規劃好。

• 及時反饋，在開發過程，不論進行到哪個階段，專案期間每天都需要和前後端同步一下進度，避免延期的風險。

• 故障處理，在程式上下後，可能會因為客觀或者程式碼的原因出現一些BUG，不同的故障處理方案不同，但是注意覆盤和故障記錄，避免下次出現相同的BUG。

故障等級定義：

P0 ：
1.全域性問題，影響所有使用者，例如系統必現崩潰，主要功能不可用，嚴重影響使用者正常交易。
2.涉及到使用者資金損失的問題。
解決時間：2小時內。
反饋時間：0.5小時。
反饋方式：comments自動郵件方式+即時通訊：例如QQ\微信\釘釘\電話

P1：
1.全域性問題，影響所有使用者，例如系統次要功能不可用，系統偶現崩潰且崩潰率超過50%。
2.區域性問題，影響超過20%的使用者，例如系統主要功能不可用，系統必現崩潰。解決時間：待定不過夜。
反饋時間：1小時。
反饋方式：comments自動郵件方式+即時通訊：例如QQ\微信\釘釘\電話

P2：
1.區域性問題，影響使用者10%-20%，例如系統次要功能不可用，或者系統某一個邏輯不可用，系統崩潰率20-50%。
解決時間：待定48小時。
反饋方式：comments自動郵件方式。

P3：
1.區域性問題，影響使用者10%以下，例如系統次要功能不可用，系統部分邏輯不正常，僅在某一單一機型或單一使用者出現的問題。
解決時間：待定下個版本釋出。
反饋方式：下個版本的需求計劃中體現。

P4：
1.系統文字錯誤，系統樣式錯誤，系統互動友好性等不影響使用者正常使用的功能。（包含全域性性質）
解決時間：下個版本上線時。
反饋方式：下個版本的需求計劃中體現。

P0\P1級別問題在規定時間內無法解決的，需要該問題的研發同學在問題comments內說明無法在規定時間內解決的合理的解釋，並告知該問題具體的解決時間點同時郵件說明。