因為公司需要使用greenplum，而官方的datax版本在導資料到greenplum時，速度是非常慢的（嚴格說是datax導資料到postgresql，在匯入到GP時，資料走的是master，一條一條insert的，當然是慢）。

所以，這裡採用了別人開發好的支援GP 的datax版本：https://github.com/HashDataInc/DataX

首先來說一下GP，GP作為一種資料倉庫工具，是比較特殊的，因為一般的etl工具在往GP中導資料普遍是比較慢的。

GP底層就是多個postgresql資料庫組成的postgresql叢集，由一個master來管理，當然可以有一個standby的master。而一般的etl工具在向GP導資料時，會走master，再由master來分發，效率極其低下。

要用好GP，就需要順應GP。用GP最喜歡的匯入方式去導資料，比如 通過使用copy命令，通過使用gpfdist工具，當然阿里有相應的收費軟體也支援快速匯入。

本次使用的datax版本，其實是封裝了GP的copy方式。

mysql導資料到GP：

{
	"content":[
		{
			"reader":{
				"name":"mysqlreader",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":[
								"jdbc:mysql://*******:3306/*********?characterEncoding=utf8"
							],
							"table":[
								"********"
							]
						}
					],
					"password":"******",
					"username":"dev",
					"where":""
				}
			},
			"writer":{
				"name":"gpdbwriter",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":"jdbc:postgresql://*********:5432/**",
							"table":[
								"**********"
							]
						}
					],
					"password":"******",
					"postSql":[],
					"preSql":[
						"**********"
					],
					"segment_reject_limit":0,
					"username":"admin"
				}
			}
		}
	],
	"setting":{
		"speed":{
			"channel":"1"
		}
	}
}

　　通過測試，1715萬條資料355秒

而如果是mysql匯入到hdfs，通過測試，1715萬條資料211秒

可以看到，使用該版本的datax，匯入還是非常快的。

坑：

在往hdfs上導資料時，需要提前將hdfs的目錄路徑建好，如果路徑不存在，會報任務失敗。

最大的一個坑下面一個。事情是這樣的：

我需要測試一下sqlserver導資料到GP。然而，公司的測試環境中沒有sqlserver，所以我在本機中裝了一個。

當時裝的是sqlserver2005,具體的job的json檔案如下：

{
	"content":[
		{
			"reader":{
				"name":"mysqlreader",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":[
								"jdbc:mysql://*********:3306/******?characterEncoding=utf8"
							],
							"table":[
								"******"
							]
						}
					],
					"password":"****************",
					"username":"dev",
					"where":""
				}
			},
			"writer":{
				"name":"sqlserverwriter",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":"jdbc:sqlserver://**********:1433;DatabaseName=sjtb",
							"table":[
								"*********"
							]
						}
					],
					"password":"**",
					"username":"sa"
				}
			}
		}
	],
	"setting":{
		"speed":{
			"channel":"1"
		}
	}
}

　　在job執行的過程中，出現如下問題：

 當時我的磁碟空間還有200多個G，所以該問題大概的原因是SQL資料庫日誌檔案滿了導致的。結果卻讓人很意外：

 當任務有57萬條資料失敗時，整個job任然顯示success，這樣就不會觸發郵件報警。這個本身應該是sqlserverver2005的一個限制，需要更換sqlserver的版本到2008就可以了，但是，我們也需要datax做點什麼來防止這種情況下任務依舊成功

這裡需要配置的是datax的errorlimit

job.setting.errorLimit(髒資料控制)

Job支援使用者對於髒資料的自定義監控和告警，包括對髒資料最大記錄數閾值（record值）或者髒資料佔比閾值（percentage值），當Job傳輸過程出現的髒資料大於使用者指定的數量/百分比，DataX Job報錯退出。

上圖中的配置的意思是當髒資料大於10條，或者髒資料比例達到0.05%，任務就會報錯