術語解釋
- ODS(Operational Data Store):操作型數據，即源數據，指結構與源系統基本保持一致的增量或全量數據。作爲DW數據的一個數據準備區，同時又承擔基礎數據記錄歷史變化。
- CDM(Common Data Model):通用數據模型(數據中間層)，包含DWD和DWS。
- DWD(Data Warehouse Detail):數據倉庫明細層數據。
- DWS(Data Warehouse Summary):數據倉庫彙總層數據。
- ADS(Application Data Service):面向應用的數據服務層。
- 冒煙測試：文本中指代碼運行能否正常結束，屬於功能性測試。
數據處理流程
1.離線數據處理流程
如圖所示，離線數據公共層模型層次分爲4個層次，其中DWD、DWS屬於中間層(CDM)。
2.實時數據處理流程
如圖所示，實時數據公共層模型層次分爲3個層次，其中DWD、DWS屬於中間層(CDM)，其中DWD落地供後續應用(ADS)訂閱使用，DWS爲各數據域的中間彙總層。
項目管理
1.項目命名
ODS層項目以ods爲後綴，如mtods。
中間層項目以cdm爲後綴，如mtcdm。
應用層項目分兩類：
第一類，數據報表、數據分析等應用以bi爲後綴，如mtbi。
第二類，數據產品等應用以app爲後綴，如magicapp等。
數據報表：報表就是用表格、圖表等格式來動態顯示數據，可以用公式表示爲：“報表 = 多樣的格式 + 動態的數據”。
數據分析：數據分析是指用適當的統計分析方法對收集來的大量數據進行分析，提取有用信息和形成結論而對數據加以詳細研究和概括總結的過程。
2.項目空間目錄結構
a.工作流
應初始化2層目錄(根目錄算第0層)結構，第一層目錄表示數據域（對於中間層項目）或業務線（對於應用層項目），如渠道、消費者、商品、交易、倉儲物流、服務、營銷、社交、日誌，第二層目錄表示層次，如DWD、DWS、DIM以及數據同步任務。
另外，建議增加三個一級目錄爲RESOURCE、TEMP和VIRTUAL NODE，其中RESOURCE目錄主要放置資源文件，按照節點類型再進行細分，如UDF、JAR、SHELL等，TEMP目錄按照開發人員姓名再進行細分，VIRTUAL NODE放置虛擬節點。如果虛擬節點或者UDF、JAR、SHELL 只是作用於某個表時，這些虛擬節點、資源請放在表級目錄下，如果是公用的請放在RESOURE、TEMP和VIRTUAL NODE相應的目錄下。
一般是：根目錄(工作流)—>數據域(交易)—>數據層次(DWD)—>表名稱(dwd_mt_ord_evt_di)
b.臨時查詢
臨時查詢TAB頁建議以開發人員姓名作爲文件夾進行管理，以避免臨時查詢文件列表過多。
3.工作流節點類型及命名
4.工作流起始節點
每個Project必須設立一個起始節點，命名爲vt_{project_name}_start，表示該project的任務起點。
5.資源文件
項目中公用的資源文件建議放在RESOURCE目錄中，資源名稱需有後綴表示資源類型，如.java、.py、.sh等。如果某個資源文件如java只是服務於某個表，請把這個資源文件放在表級目錄下。
表與視圖
1.表的命名
DWD表與視圖命名規範：
dwd_{業務BU縮寫/pub}_{數據域縮寫}_{業務過程縮寫}[_{自定義表命名標籤縮寫}]_{刷新週期標識}_{單分區增量全量標識}
例如：dwd_mt_ord_evt_di
DWS表與視圖命名規範：
dws_{業務BU縮寫/pub}_{數據域縮寫}_{數據粒度縮寫}[_{自定義表命名標籤縮寫}]_{統計時間週期範圍縮寫}[_刷新週期標識][_單分區增量全量標識]
關於統計實際週期範圍縮寫，缺省情況下，離線計算應該包括最近一天（_1d）,最近N天（_nd）和歷史截至當天(_td)三個表，如果出現_nd的表字段過多，需要拆分之時，只允許以一個統計週期單元作爲原子拆分，也就是說一個統計週期拆分一個表，比如最近7天(_1w)拆分一個表；不允許拆分出來的一個表存儲多個統計週期的。
例如：dws_mt_ord_shp_1d
ADS表命名不做強制要求，以下是命名建議：
{project_name}.ads_{業務BU縮寫/pub}_{應用名稱}[_數據粒度] [_{自定義表命名標籤縮寫}]_刷新週期標識
2.表的創建
創建表之前必須按照數據模型規範確定表和字段的命名，並根據需求確認表的生命週期並給表和字段加上完整的註釋。分區字段必須加上註釋。
建表樣例：
create table if not exists dwd_mt_explore_item_di(
stat_date STRING COMMENT '統計日期,星期日'
,seller_user_id BIGINT COMMENT '賣家ID'
,device_type STRING COMMENT '所屬訪問終端類型'
,item_id BIGINT COMMENT '寶貝ID'
,uv_cnt_cw_144 BIGINT COMMENT '自然周訪客UV'
,dpv_cnt_cw_058 BIGINT COMMENT '自然周被瀏覽DPV'
)
comment '寶貝瀏覽自然周表'
partitioned by (ds STRING COMMENT '賬期分區，格式yyyymmdd')
3.視圖
視圖的命名爲{表名}_v。
視圖應創建獨立的刷新任務以產生視圖，刷新任務腳本爲視圖創建腳本。
創建視圖樣例：
create or replace view dwd_mt_explore_item_di_v as
select stat_date, seller_user_id
from tbcdm.dwd_mt_explore_item_di;
編碼
1.編碼原則
- 要求代碼行清晰、整齊，具有一定的可觀賞性；
- 代碼編寫要充分考慮執行速度最優的原則；
- 代碼行整體層次分明、結構化強；
- 代碼中應有必要的註釋以增強代碼的可讀性；
- 代碼要做到整個節點可以多次重跑，結果不變；
- 規範要求非強制性約束代碼開發人員的代碼編寫行爲，在實際應用中在不違反常規要求的前提下允許存在可理解的偏差；
2.基本要求
- 代碼段中應用到的所有SQL關鍵字、保留字都使用全大寫或小寫，不能使用大小寫混合的方式，如Select或seLECT等方式；
- 代碼段中應用到的除關鍵字、保留字之外，都使用小寫；
- 四個空格爲一個縮進量，所有的縮進皆爲一個縮進量的整數倍；
- 最外層禁止使用
select *操作,所有操作必須明確指定列名； - 禁止使用insert into語句，用union all代替；
- Where條件中字段空和空字符串要進行必要的coalesce處理；
- 對應的括號通常要求在同一列的位置上。
3.數據類型
一般情況下，使用以下四種：
- Bigint
- String
- Double
- Datetime
由於潛在的兼容性問題和擴展性問題，不建議使用Boolean類型。
在對精度要求極其嚴格的場景下謹慎使用Decimal類型。
具體類型，如下圖所示：
4.編碼規範
a.代碼頭部
代碼頭部添加主題、功能描述、作者、日期等信息，並預留修改日誌及標題欄，以便後續修改同學添加修改記錄。注意每一行不超過80個字符。以下是模板：
--**************************************************************************
--所屬主題: 日誌域(項目名稱)
--功能描述: 頁面引導成交
--創建者 : XX
--創建日期: 20171017
--修改日期 修改人 修改內容
--20130826 XX init
--20150127 YY 修改訂單取數口徑，只取支付訂單
--**************************************************************************
b.字段排列要求
- SELECT語句選擇的字段按每行一個字段方式編排；
- SELECT單字後面一個縮進量後直接跟首個選擇的字段，即字段離首起二個縮進量；
- 其它字段前導二個縮進量再跟一‘，’點後放置字段名；
- 兩個字段之間的‘，’點分割符緊跟在第二個字段的前面
- ‘AS’語句應與相應的字段在同一行；多個字段的‘AS’建議儘量對齊在同一列上；
c.select子句排列要求
SELECT語句中所用到的FROM、WHERE、GROUP BY、HAVING、ORDER BY、JOIN、UNION等子句，需要遵循如下要求：
- 換行編寫；
- 與相應的SELECT語句左對齊編排；
- 子句後續的代碼離子句首字母二個縮進量起編寫；
- WHERE 子句下的邏輯判斷符 AND、OR等與WHERE左對齊編排；
- 超過兩個縮進量長度的子句加一空格後編寫後續代碼，如：ORDER BY、GROUP BY等；
d.運算符前後間隔要求
算術運算符、邏輯運算符的前後要保留一個空格
e.case語句的編寫規範
SELECT語句中對字段值進行判斷取值的操作將用到的CASE語句，正確的編排CASE語句的寫法對加強代碼行的可閱讀性也是很關鍵的一部分。
對CASE語句編排作如下約定：
- WHEN子語在CASE語句的同一行並縮進一個縮進量後開始編寫；
- 每個WHEN子句一行編寫，當然如果語句較長可換行編排；
- CASE語句必須包含ELSE子語，ELSE子句與WHEN子句對齊；
f.子查詢嵌套語句的編寫規範
子查詢嵌套在數據倉庫系統ETL開發中是經常要用到，因此代碼的分層編排就非常重要。
g.sql註釋的編寫規範
- 每條SQL語句均應添加註釋說明；
- 每條SQL語句的註釋單獨成行、放在語句前面；
- 字段註釋緊跟在字段後面；
- 應對不易理解的分支條件表達式加註釋；
- 對重要的計算應說明其功能；
- 過長的函數實現，應將其語句按實現的功能分段加以概括性說明；
- 常量及變量註釋時，應註釋被保存值的含義（必須），合法取值的範圍（可選）；
節點配置規範
1.小時任務配置
時間參數: date=[hh24]， ‘{hour}’ 可在代碼中直接作爲變量使用。Eg: insert overwrite table tmp_dwd_mt_ord_evt_hh partition (ds=’{hour}’).
時間屬性：開始時間必須選擇00:59。
2.天任務配置
時間參數: bizdate={ bizdate }'可在代碼中直接作爲變量使用。
3.調度依賴
調度任務必須選擇“自動解析”。 自動解析會把所有的from表作爲input ，所有的insert的表作爲輸出。對於程序中輔助程序開發的過程表、臨時表也會被解析出來，因此必須對這些臨時表進行過濾。
在代碼頭部加入exclude 語句即可過濾相對應的表，調度依賴中就不會顯示依賴關係。
--@exclude_output=tmp_dwd_tb_trd_ord_subpay_di_1
--@exclude_input=tmp_dwd_tb_trd_ord_subpay_di_1
測試及質量保證
1.新增業務需求測試項
2.數據遷移/重構/修改
發佈上線
無QA(質量保證)參與的項目，由開發負責自測，在開發測試環境通過後再自行發佈到生產環境。有QA參與的項目必須由開發與QA都測試通過後方可發佈。
維護及故障處理
1.數據重刷
如果任務運行失敗，請直接重跑，如果是由於代碼變更或上游數據變更導致輸出數據發送變更，請預先評估給下游帶來的影響而決定是否需要重跑。重跑之（前）後，一定要通知直接下游或重要的間接下游，讓下游採取相關的措施。
2.補數據
補數據如果只是針對歷史分區回刷，可以直接執行補數操作。如果補數據還會對現有分區數據造成影響，請預先評估給下游帶來的影響而決定是否需要進行相關操作，補數據（前）後，一定要通知直接下游或重要的間接下游，讓下游採取相關的措施。
3.口徑修改
如果表的取數口徑或者字段口徑算法發生變更，必須提前通知下游並與下游達成一致後，方可進行後續操作。
4.故障處理
遇到任務報錯、上游問題、平臺問題符合數據質量故障的走數據質量故障流程，不符合的走數據質量事件。對於他人轉過來的流程請及時處理。
5.工作交接
數據工程師在轉崗、離職前，必須將手頭任務轉給相關的接手人，如在轉崗、離職後還未交接的，該任務歸屬其主管負責。