數據開發流程

一、背景

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

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

二、數據開發流程

鑑於對日常數據倉庫研發工作的總結與歸納,將數據倉庫研發流程抽象爲如下幾點:

  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內說明無法在規定時間內解決的合理的解釋,並告知該問題具體的解決時間點同時郵件說明。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章