數據轉換作業主要是指在數據倉庫內的結構化數據批量加工，對於非結構化數據以及在線查詢接口、數據流的開發主要是遵循代碼開發規范以及各中間件的開發規范，如使用java來開發遵守java開發規范，使用Kafka需要遵循Kafka的使用和設計規范。同時做好組件的設計，提高復用程度和開發效率。這里就不再贅述，那對於批量加工數據各平台也有相應的開發規范，對於不同的平台有不同的規范，用來提高代碼的運行效率和可維護性，以下是一些共性的設計規范。
1、常見算法及選擇
數據轉換作業從開發上可以分為兩個步驟，一是數據映射，即每個字段的來源即計算方式，比如 目標表D字段是來自於源表S字段，計算方式是SUM(S)。二是目標表加工的算法，比如delete/insert，upsert等，它是將增量數據如何和歷史數據融合轉化為全量數據的常用處理方式，以下是在數據倉庫中經常使用的一些算法：
（1）delete all/insert：先刪除目標表當前所有數據，再插入全量最新數據，此算法適用於數據量較小且不需要保留歷史數據的表。如代碼表、參數表。例如：
Delete from D ;
insert D select * from A;
(2) Append：增量追加：將當前源表數據直接追加到目標表中。此算法需要源表數據以增量提供。這種算法一般在事件表（交易流水表）和總賬表中使用較多，用來記錄所有的歷史交易記錄，記錄每天的交易以及總賬的切片數據。
delete from D where trans_date=current_date ;
insert into A select * from S wheretrans_date=current_date ;
（3）UPSERT：使用源表數據更新目標表。如果新來的源數據已經在目標表中存在，則使用新來的源數據更新目標表中的相應數據，如果新來的源數據在目標表中不存在，則直接將其加入目標表中。針對此算法，源表選擇全量或增量方式提供數據均可以。此算法適應於不保留歷史的當前表。如集市區的賬戶或客戶基本信息當前表。簡要步驟如下：
步驟1：根據映射關系生成臨時目標表T，已有目標表為D;
步驟2：update D set D.C1=T.C1 … where D.key in ( select T.key from T);
步驟3：insert D select * from T whereT.key not in (select key from D);
（4）標准歷史拉鏈：由於數據倉庫的一個特點就是保留歷史數據，因此在主數據區的數據表基本都保留歷史數據，那歷史數據保留的算法除了Append方式就是歷史拉鏈鏈方式。即在目標表中增加start_date（開始時間）和end_date（結束時間）字段，用來保存數據的歷史變化。相對於Append算法堆加方式，此方法可以減少歷史數據存儲的空間要求並方便對歷史數據的訪問。適用於部分字段發生變化的表，如客戶主表、賬戶主表等，針對此算法，源表選擇全量或增量方式提供數據均可以。標准歷史拉鏈的算法的舉例和加工流程如下圖所示:
那對於不同的情況如存在刪除數據情況下，在標准歷史拉鏈的基礎上又演變出了幾種拉鏈算法，以下是幾種變形算法：
（5）經濟型歷史拉鏈：在“標准歷史拉鏈”算法的基礎上，對PK外屬性字段為0、’’等情況下的記錄做關鏈處理。處於節約空間的考慮。允許斷鏈存在，不影響金額統計的正確性。比如將協議金額歷史表中余額為0的記錄不放到目標表。一般較少使用到。
（6）全量數據的歷史拉鏈：在“標准歷史拉鏈”算法的基礎上，對源數據中已經刪除的記錄打標記，並修改目標表中end_date來關閉該數據當前的時間鏈。此算法要求源表提供全量數據或能表示出刪除數據的增量數據。適用於源系統表存在刪除的情況；
（7）全主鍵歷史拉鏈：“標准歷史拉鏈”算法的變種，特點是表中全部字段（除了開始和結束日期外）都是拉鏈主鍵，沒有屬性。比如協議當事人關系表中，借據和擔保人是多對多的關系，需要同時做PK。
（8）自拉鏈：對保留歷史狀態的源表進行歷史拉鏈，如果源表已經保留了歷史狀態信息，但沒有使用歷史拉鏈(start_date/end_date)的方式，則通過對該源表進行自連接，將源表的數據以歷史拉鏈的形式保存到目標表中。源表數據可能是保存了一段時間的歷史數據。
2、作業設計規范
（1）作業划分及拆分
數據轉換作業名一般以目標表作為一個加工作業，可以參考以下規則來命名：
目標表名[_順序號]（例如T01_PARTY、RMRT_AGREEMENT_001）
其中T01_PARTY、T03_AGREEMENT是目標表名，不同的數據區域會有不同的命名規范，如RMRT表示是零售集市數據區，T01表示主模型的PARTY主題表；順序標識如001可省略。
順序標識主要是因為同一個目標表可能需要通過幾個獨立的作業來實現，則需要使用順序標識來區分，比如在整合模型區的T01_PARTY 表需要從核心、公貸、理財系統數據進行加工，但是核心系統數據提供比較晚，公貸和理財源系統數據提供比較早，為了提高后續作業效率，避免不必要的等待，可以按照源系統數據的到達時間進行分組，讓到達時間相近的源系統在一個加載任務中，如公貸和理財系統數據入T01_PARTY作為1組，核心數據入T01_PARTY 為第2組。
（2）支持重跑
數據加工作業也需要支持重跑，方便作業異常重新發起，而不需要先手工清洗數據，因此在作業設計事需要
1）第1步就是需要恢復數據，比如歷史拉鏈表加工T日數據第一步是將數據恢復到T-1日批后狀態（參考標准歷史拉鏈算法流程）。
2）使用臨時表，將當天數據在臨時表先加工完成，只在最后一次性更新目標表或者在最后直接以臨時表作為最終的目標表。
3）最后更新目標表時需要使用事務，避免中間異常無法回退數據；
（3）支持歷史數據處理；
作業支持重跑一般只支持當日數據重跑，對於T-N（N>1）日的歷史數據重新跑到T日的話，除了APPEND及delete all/insert算法，一般需要手動先恢復到T-N日批后數據，再逐日跑數到T日，因此作業設計時也要考慮到這種情況，特別是在作業上線時會需要追數，因此在設計時需要對於存儲歷史數據的源表使用時需要使用作業參數中的數據日期（tx_date）來獲得當日的數據，比如對於歷史拉鏈表作為源表，使用時用tx_date來獲得tx_date當日數據：
select * from T01_PARTY_H where start_dt<=tx_date and end_dt>tx_date
（3）作業監控
數據轉換作業設計時，需要確保每一步加工的信息在日志輸出，包括執行的sql語句，SQL執行的結果比如更新記錄多少條、錯誤信息等，以便錯誤時快速查找原因，在調度系統集成中也需要能快速查看轉換作業的日志。
（4）代碼轉換公共作業
在主數據區需要進行代碼標准化，即將源系統的代碼轉換為數據倉庫中定義的代碼，這和個也是數據標准在數據倉庫實施的一部分，因此會經常使用到代碼轉換，可以設計一張代碼轉換表，以源系統表名、源系統字段、源系統字段代碼值為主鍵：
在轉換作業中可以通過統一的方法即通過關聯代碼轉換表獲取對應的映射字段，不僅可以規范代碼映射方法，也可以通過維護代碼轉換表獲得數據倉庫的代碼標准和代碼轉換視圖；
（5）表所屬數據庫或SCHEMA配置化
由於生產環境和測試環境可能不同，一套物理測試環境可能分開發、SIT和UAT環境，對於各表的所屬schema或數據庫需要可配置化（參數化），以便腳本在測試環境中運行，同時也需要做好生產腳本參數和測試環境參數的代碼管理。
3、腳本開發自動化
由於算法相對固定，字段映射不同，因此可以針對不同的算法做好模板，再根據字都映射規則產生SQL填充到模板，這樣可以節省代碼開發量，同時提高數據轉換作業的可維護性，以下時轉換作業自動生成代碼的關鍵信息
（1）基本信息描述：如物理表名稱及表說明、開發人員及修改日期、表的主鍵字段
（2）任務信息描述：包括作業名稱、作業執行頻率（日、周、月、季、年）、ETL算法（第1部分提到的算法）。ETL算法如果是UPSERT算法，需要填寫比較的字段、更新的字段。如果為拉鏈算法，需要填寫比較的主鍵以及開始日期和結束日期字段。
（3）字段映射：字段映射主要包括如下字段映射、映射規則以及表關聯：
由於一個ETL作業可能有很多組映射組成，即有許多源表到目標表的映射加工，所以也需要標識組別，每一組在映射加工腳本前后還需要有自定義的SQL腳本，也可以每組映射只有自定義腳本，以方便SQL加工前處理數據或者適應無法用MAPPING描述的規則。
在填寫配置信息時，需要將需求中的字段映射關系備注也放到配置文件中，對於自定義的SQL也需要做好備注，這些備注也會自動顯示在腳本的注釋中。增加配置信息及最終生成的腳本的可讀性。
基於以上的信息以及目標表和源表的字段信息，已經具有自動化生成腳本的所有信息，可以根據這些信息自動化產生腳本，配置信息結構以及腳本生成主要步驟如下：
