數據模型開發規范
數據模型的公共層設計要遵循維度建模的思想和理念。數據模型的維度設計主要以維度建模理論為基礎，基於維度數據模型總線架構，構建一致性的維度和事實。數據模型開發的基本原則如下。
1.數據要干凈、有效
要保證進入數據模型的數據是經過清洗和規范的。
2.模型可擴展
核心模型要盡可能保持穩定，經常變化的業務可以通過擴展模型進行分離。
3.禁止逆向調用
禁止逆向調用,例如不能出現ODS 層調用M DS 層數據。
4.數據可回滾
數據模型多次重跑的結果數據必須保持一致。
5.成本控制
在構建數據模型時，要充分考慮計算和存儲資源間的平衡。
數據表的命名規范
1.ODS層數據表的命名規范
表命名規則:ods_(數據源}_(原始表名)
字段默認使用源系統字段名稱
2.DWD層數據表的命名規范
表命名規則:dwd_(數據域縮寫/ust/ord/prd)_(業務過程縮寫)[_自定義標簽縮寫]_(刷新周期標識)_(單分區增量全量標識)
例：dwd_ usr_visit_rel_m_i
3.DWS層數據表的命名規范
表命名規則:dws_(數據域縮寫/usr/ord/prd)[_自定義標簽縮寫]_[刷新周期標識)[_單分區增量全量標識]
例:dws_usr_trd_d
4.維表的命名規范
表命名規則:dim_(維度定義)例:dim_usr
5.ADS層數據表的命名規范
表命名規則:ads_[_數據域縮寫/usr/ord/prd][_業務應用縮寫][_自定義標簽縮寫]_{刷新周期標識)
例:ads_usr_count_d
數據表的設計策略
1.DWD層數據表的設計策略
(1)根據業務過程來定義並建立事實表，在事實表內描述業務過程對應的原子粒度的事物信息。
(2)通過元數據系統查詢判別當前建模對應的業務過程是否已有DWD層事實表,把相同業務過程的度量指標維護在同一個基礎層模型表內。
(3)DWD層大維度表上的常用統計屬性可以冗余到事實表中，以便引用和關聯。
2.DWS層數據表的設計策略
(1)確定 DWS 層模型所對應的維度和度量信息。
(2)確定對度量進行的衍生計算方式，如求和統計、去重統計。
(3)確定數據的劇新周期。
數據開發規范
1.代碼書寫規范
1)代碼結構規范
(1)所有代碼都應該放人對應的目錄中，如 DWD 層代碼應該放入DWD 目錄中，且以 DWD 為命名首字母。
(2)不允許 tmp、test 任務出現在目錄結構中。
(3)如果需要臨時創建tmp、test 任務，那么不可以將其配置為周期調度任務，並且使用完成后需要立即刪除。
在開發環境中創建的tmp、test 任務,不可以被發布到生產環境中。
任務名稱和產出表的名稱需要保持一致，每個 SQL 語句的任務否少需要一個輸出表。
(4)在代碼最上面的部分，需要添加任務名稱、開發者、創建時間、任務描述等注釋。
(5)在代碼中間的部分，需要添加目標表的 create table if not exists 語句，以確保表存在者被順利構建。
(6)在代碼的下面部分，需要添加 insert overwrite 語句，以確保數據真正插人。
2)任務命名規范
(1)任務需要以產出表的名稱命名。
(2)如果是中間表，那么要以業務划分+mid 結尾。
(3)如果任務的業務邏輯復雜，需要用到子任務，那么要將任務和任務下的子任務放到同一個文件夾下。
3)代碼格式統一
SQL語句中的關鍵字用大寫，其余的語句用小寫(包括函數)。
4)時間格式統一
(1)統一數據插人時間:yyyy-mm-dd hh:mi:ss.
(2)統一數據統計日期:yyyymmdd.
(3)統一帶小時的時間格式:yyyy-mm-dd hh:mi:ss.
(4)統一日期格式:yyyymmdd.
5)通數使用建議
對於能封裝成函數來使用的復雜邏輯，我們要盡量使用函數。
6)代碼開發建議
(1)在表關聯中盡量合理使用子查詢完成數據的預處理，然后再進行關聯。
(2)不使用 select*語句。
(3)子查詢只查詢必需的列。
(4)如果腳本需要支持重跑，那么注意覆蓋原有數據。
(5)代碼要有縮進規范，要便於閱讀理解，要有關鍵注釋
7)周期調度配置
(1)目前支持的任務調度周期有五種:天、周、月、分鍾小時。
(2)調度規則--任務實例是否能完成需要看以下條件:
① 上游任務實例是否都運行成功。若所有上游任務實例都運行成功，則觸發任務進入等待時間狀態。
② 是否已經到了任務實例的設定時間。任務實例進入等待時間狀態后會檢查是否到了本身的設定時間，如果時間到了，那么進入等待資源狀態。
③ 當前調度資源是否充足。任務實例進入等待資源狀態后，檢查當前本項目的調度資源是否充足，若充足則可以運行。
(3)調度周期和調度時間參數配合使用。
8)參數配置說明
(1)當涉及系統的業務日期、業務實際發生的日期、數據被生產出的日期等日期變量時，使用參數${system.bizdate}，默認格式為yymmdd。
(2)當涉及系統任務實例的定時運行時間等日期變量時，使用參數${system.cyctime}，默認格式為yyyymmddhh24miss.
(3)注意:參數${system.cyctime}得到的日期默認為參數${system.bizdate}得到的日期的后一天，在正常調度時兩個參數由系統代人，在測試運行或手動執行時我們需要手動輸入參數值。
(4)測試和補數據都是手動生成的任務實例，需要選擇業務日期才能夠順利執行。
9)動態分區的使用
如果數據延遲，那么我們需要刷新以前的分區數據，可以使用動態分區。動態分區是指在插人數據時不指定具體分區，而按照查詢出來的數據判斷數據應該插人哪個分區。
2.任務發布規范
1)任務發布前提
(1)已配置好周期調度
(2)已配置好上游依賴。
(3)已配置好相應的參數。
(4)任務測試運行通過。
(5)已測試並驗證過數據產出的正確性。
2)任務發布流程
為了將開發環境和生產環境隔離，數據運維人員需要將數據開發人員提交的作業發布至生產環境，並且在生產環境里運行成功，要盡量防止出現生產故障。
3)任務發布的注意事項
(1)我們要查看需要發布的任務是否在等待發布的任務中，如果在等待發布的任務中，那么無法進行新的發布，需要將等待發布的任務中的相應任務刪除，才可以進行重新發布，要避免由於版本沖突帶來的業務邏輯出錯。
(2)我們可以把需要發布的任務打包進行一次性發布，要避免多次發布。
3.任務運維規范
1)失敗任務運維
(1)數據運維人員需要及時查看狀態為失敗的任務，由於不允許存在失敗狀態的任務實例，如果有任務失敗，那么我們需要及時處理。
(2)對於失敗任務，數據運維人員需要查看失敗任務運行的代碼，找到失敗的原因。如果代碼有問題，那么我們需要先在開發環境中修改代碼，再將修改完善后的代碼發布到生產環境中。在發布代碼之后，我們需要在運維中心找到報錯的對應任務，點擊任務讓其重新運行。
(3)如果重新運行的任務繼續報錯，那么我們要按此流程重新操作，直至實例成功。
(4)對於失敗任務可手動進行相應的補數據。
2)未運行任務運維
理論上當天業務日期下面的實例都應該成功運行(未到運行時間的任務除外)。如果出現未運行的任務,那么我們需要檢查原因(例如，可能是上游的任務報錯導致下游的任務未運行)，需要按照失敗任務的處理方式進行處理，使得上游任務成功，下游任務自動開始運行。
3)補數據任務運維
補數據任務不可存在失敗或未完成狀態。如果失敗，那么應該修改任務的相關代碼，然后點擊當前的補數據任務，使其重新運行，而不能新發起一個補數據任務。
4)周期任務的報警
(1)對於以上失敗、未完成的周期性任務實例，應當添加報警任務、報警任務可以及時通知相關人員進行處理。
(2)每個任務都需要有明確的對應責任人。
4.數據質量核查規范
(1)檢查數據的行數是否符合預期。
(2)檢查數據不可為空的列是否有空值。
(3)檢查是否有數據不符合規范的格式。
(4)檢查表的主鍵值是否唯一。
(5)將檢查規則腳本配置為周期調度的任務，對每日周期性任務的數據產出進行數據質量的檢查。
①在dqm( data quality monitor)目錄對應任務的目錄下創建周期性的工作流任務，目錄結構一定要和正式任務的目錄結構保持一致。
②在工作流任務中添加邏輯檢查節點，有幾個內部任務節點就對應幾個邏輯檢查節點。
③ 在內部節點中實現數據質量檢查邏輯的代碼運行。
④配置被檢查的任務為上游依賴，然后提交任務。