213
阿裏雲大數據利器Maxcompute學習之--數據同步任務常見日誌報錯總結
在使用大數據開發套件時最常用的就是數據同步模塊，工單裏最常見的問題就是其中數據同步的問題，這裏總結一些常見一些從Maxcompute到其他數據源的同步任務報錯案例，主要是日誌中出現數據回滾寫入的問題。那首先看下日誌中數據回滾的原因，當數據寫入rds或者hybridDB等一些支持事務的數據庫中，數據批量寫入，一旦由於各種原因沒有寫入成功，這個批次的數據會回滾重新寫入，如果再次寫入失敗，就會報髒數據的錯誤導致任務失敗。數據寫入失敗可能是以下原因導致回滾。
1，髒數據（數據值超過數據類型最大範圍，數據類型不對應等等）
2，目標數據源字段設置，比如默認不允許為空
3，主鍵衝突
4，目標數據源本身負載太高，寫入時死鎖
5，同步的設置的速度太大，比如數據量很大，速度設為10M/s。
常見回滾日誌報錯示例：
2017-01-01 17:01:32.544 [16876048-0-0-writer] WARN CommonRdbmsWriter$Task - 回滾此次寫入, 采用每次寫入一行方式提交.
因為:java.sql.BatchUpdateException: INSERT, DELETE command denied to user 'xxx'@'xx.xx.xx.xx' for table 'report'下麵來看幾個案例
案例一： MaxCompute到hybridDB的數據同步任務報錯，錯誤提示：
INSERT INTO hybrid_schema.dim_bz_317hu_account_gold_stg (id,account_id,hospital_id,total_gold,valid_flag,withhold,type,com_date_id,com_hour_id,from_source,create_time,update_time,creator,updater) VALUES('7933'::int8,'33718'::int8,'560'::int8,'0.0'::float8,'ENABLE'::varchar,'0.0'::float8,'1'::int8,'20170322'::int8,'11031'::int8,'bz_317hu'::varchar,'2017-03-22 10:31:45.000000 +08:00:00'::timestamp,'2017-03-22 10:31:45.000000 +08:00:00'::timestamp,'liuchang'::varchar,'liuchang'::varchar) was aborted. Call getNextException to see the cause.
2017-03-23 00:51:34.154 [job-24934082] INFO LocalJobContainerCommunicator - Total 47 records, 4672 bytes | Speed 0B/s, 0 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 0.000s | All Task WaitReaderTime 0.000s | Percentage 0.00%
2017-03-23 00:51:37.976 [24934082-0-9-writer] WARN CommonRdbmsWriter$Task - 回滾此次寫入, 采用每次寫入一行方式提交. 因為:Batch entry 0 INSERT INTO hybrid_schema.dim_bz_317hu_account_gold_stg (id,account_id,hospital_id,total_gold,valid_flag,withhold,type,com_date_id,com_hour_id,from_source,create_time,update_time,creator,updater) VALUES('7931'::int8,'39316'::int8,'568'::int8,'0.0'::float8,'ENABLE'::varchar,'0.0'::float8,'1'::int8,'20170322'::int8,'11016'::int8,'bz_317hu'::varchar,'2017-03-22 10:16:04.000000 +08:00:00'::timestamp,'2017-03-22 10:16:04.000000 +08:00:00'::timestamp,'liuchang'::varchar,'liuchang'::varchar) was aborted. Call getNextException to see the cause.
2017-03-23 00:51:38.987 [24934082-0-9-writer] ERROR StdoutPluginCollector -
org.postgresql.util.PSQLException: ERROR: deadlock detected
Detail: Process 42073445 waits for ExclusiveLock on resource queue 6055; blocked by process 50785454.
Process 50785454 waits for ShareUpdateExclusiveLock on relation 853985 of database 17163; blocked by process 51099525.
Process 51099525 waits for ExclusiveLock on resource queue 6055; blocked by process 42073445.
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2198) ~[postgresql-9.3-1102-jdbc4.jar:na]
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1927) ~[postgresql-9.3-1102-jdbc4.jar:na]
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) ~[postgresql-9.3-1102-jdbc4.jar:na]
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:561) ~[postgresql-9.3-1102-jdbc4.jar:na]
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:419) ~[postgresql-9.3-1102-jdbc4.jar:na]
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:412) ~[postgresql-9.3-1102-jdbc4.jar:na]
at com.alibaba.datax.plugin.rdbms.writer.CommonRdbmsWriter$Task.doOneInsert(CommonRdbmsWriter.java:382) [plugin-rdbms-util-0.0.1-SNAPSHOT.jar:na]
at com.alibaba.datax.plugin.rdbms.writer.CommonRdbmsWriter$Task.doBatchInsert(CommonRdbmsWriter.java:362) [plugi 問題定位：
有數據回滾操作，初步定位為數據在hybridDB寫入失敗，回滾寫入失敗，出現髒數據大於用戶設置的0條。任務終止。
問題排查：
看到日誌中出現下麵報錯：
排查看到日誌中有顯眼的一句：
org.postgresql.util.PSQLException: ERROR: deadlock detected 那麼問題基本定位到：是因為hybridDB這邊表出現死鎖，數據寫不進去，報髒數據，任務失敗。
導致hybridDB死鎖的原因可能是這個表的負載很大，排查一下用戶配置：同步速率設置的10M/s，那就非常有可能是這個速度和用戶的數據量太大，寫入負載太高導致死鎖。
解決方法：根據自己數據量和需求設置同步速度，這個案例建議用戶調小一些同步速率，錯開高峰，把任務放到低穀時期執行。
案例二：目標數據庫設置字段不能為空，數據中有null值，同步報錯：
問題定位：報錯顯示目標數據庫中的有些字段設置的是cannot be null，而數據中有null值。導致失敗
解決方案：修改目標數據庫中的字段設置，如果此字段必須不能為空，核對下數據來源保證不能為空，或者對數據預處理一下null值。
案例三：數據同步到rds時，odps中有重複數據，rds中設置主鍵，導致主鍵衝突。
問題定位：日誌中有回滾寫入操作，報錯提示 Detail: Key (id)=(2022080640) already exists.可以定位是主鍵衝突了，
原因是rds中設置主鍵的這個字段在odps中存在重複，並不是唯一值。
解決方案：
1，建議重新建一張沒有主鍵的表。
2，如果要主鍵，選擇odps中有唯一約束的字段。
3，業務上允許的話，可以先對odps中的數據進行去重再同步
案例三：數據同步到rds，rds端字段數據類型設置太小。
原因定位：數據同時出現回滾，報錯：java.sql.BatchUpdateException: Data truncation: Data too long for column 'flash' at row 1
Maxcompute中的數據字段值，超出rds表中設置的數據類型的閾值，導致寫入失敗。
解決方案：去rds中調大這個字段的對應數據類型值
總結：數據同步任務涉及多種數據源，問題類型也是比較多。那從日誌中排查報錯是比較常見的方式。本文就羅列了一些Maxcompute到其他數據庫的一些常見典型的案例，有不足的地方希望讀者聯係我指出來啊
最後更新：2017-05-16 16:32:39