摘要：?貌似大部分人在遇到報錯的時候，都懶得用翻譯軟件翻譯報錯信息，一般直接拋出來問，甚至連報錯信息都懶得復制，直接截圖出來。所以這里特地總結了一下，最近一段時間有人經常在群里問到的報錯信息。 ODPS-0130252:Cartesian product is not allowed “不允許笛卡爾積”主要是為了防止用戶誤操作，不小心漏了關聯條件，造成大量的資源的耗費。

貌似大部分人在遇到報錯的時候，都懶得用翻譯軟件翻譯報錯信息，一般直接拋出來問，甚至連報錯信息都懶得復制，直接截圖出來。所以這里特地總結了一下，最近一段時間有人經常在群里問到的報錯信息。

ODPS-0130252:Cartesian product is not allowed

“不允許笛卡爾積”
主要是為了防止用戶誤操作，不小心漏了關聯條件，造成大量的資源的耗費。特別，如果是后付費用戶，做大表的笛卡爾積會占用大量的計算資源，會影響整個資源池的其他用戶的正常使用。
大部分場景下，笛卡爾積都不是用戶的本意。對于真的想做笛卡爾積的用戶，也有解決辦法：
（1）有小表的時候，使用mapjoin；
（2）沒有小表的時候，左右兩張都單獨新增一個字段，例如?1 as join_column?，關聯時候用t1.join_column = t2.join_column；

ODPS-0130241:Illegal union operation - type mismatch for column 12 of UNION, left is BIGINT while right is STRING

“union左右兩邊字段類型不一致”
union左右兩邊的字段個數、字段名、字段類型需要完全一致。特別注意有種情況union中的某個表的某個字段值為顯示的NULL，比如NULL as col1，但其他表的該字段為bigint，那么需要cast(NULL AS bigint) as col1

ODPS-0130111:Subquery partition pruning exception - records returned from subquery exceeded limit of 1000.

“子查詢結果數大于1000行”
這是maxcompute的限制。子查詢一般是習慣于使用傳統數據庫的開發，經常用的查詢方式。而實際上，無論是MYSQL還是maxcompute，都不建議使用子查詢。在maxcompute中一般會用多表關聯來解決問題。

ODPS-0130071:Semantic analysis exception - physical plan generation failed: java.lang.RuntimeException: Table(xxxx) is full scan with all partitions, please specify partition predicates.

“分區表不允許全表掃描，必須指定分區值”
這條限制主要用來防止用戶誤操作，造成大量的金錢和時間上的浪費。很可能用戶的本意只是隨便挑兩條數據看看，卻習慣性的隨手寫了一個select * from table1;其實無論是mysql還是maxcompute，都不建議寫select *?掃描全表。
對于隨便挑兩條數據看看的需求，推薦使用read關鍵字，read table1 partition (pt = xxx) 10;即在表table1的pt=xxx分區中隨便挑10條數據出來看看。read關鍵字不會講任務轉化成MR任務，可以直接返回。
而如果真的需要掃描全表，則可以添加分區字段的范圍查詢，例如pt >= '2000' and pt <= '2099'。養成添加分區字段篩選條件的好習慣。

ODPS-0130071:[1,10] Semantic analysis exception - encounter runtime exception while evaluating function /, detailed message: DIVIDE func result NaN, two params are 0.000000 and 0.000000

“除數為0”
這個錯誤信息雖然寫的比較繞彎，但是還是可以理解的。所有涉及到除法的地方，都必須增加分母不為0的判斷，if(bb IS NOT NULL AND bb <> 0, aa / bb ,NULL)

ODPS-0123111:Format string does not match datetime string

“字符串格式不符合datetime類型”
maxcompute中的datetime類型其實很好理解，和yyyy-MM-dd HH:mm:ss格式的字符串幾乎是完全等價的。比如unix_timestamp('2018-01-01 00:00:00')就是正常結果，如果寫成unix_timestamp('2018-01-01')結果就是NULL。

ODPS-0123031:ODPS partition exception - maximum 60000 partitions allowed

“單表最多6萬個分區”
一個表不允許超過6萬的分區，如果分區過多，就要考慮重新設計分區了。

ODPS-0130071:Semantic analysis exception - Top level UNION is not supported

“不允許最外層使用union”
外邊再套一層select就行了。select * from (select a from table1 union all select a from table2) t;

ODPS-0130161:Parse exception - invalid token ')'

“不合法字符”
這種情況一般就是HQL寫錯了。原因可能多種多樣，一般可以肉眼檢查出來。
目前dataworks已經支持了編譯時錯誤的自動檢測。

ODPS-0420061: Invalid parameter in HTTP request - Fetched data is larger than the rendering limitation. Please try to reduce your limit size or column number.

“獲取數據量過大”
一般這種情況比較容易發生在“大寬表”的情況下，也可能是某個字符串類型的字段值過長。解決辦法就是指定select 出來的字段、或者限制條數。

ODPS-0130071:Semantic analysis exception - only a single expression in the SELECT clause is supported with UDTF's

“select后邊只能有一個單獨的UDTF”
如果想把UDTF放在select后邊，那么這個select里就只能有這一個UDTF，不能有其他任何字段。
如果不是只想要這一個UDTF，那就要結合著lateral view一起用了。

最后補充一句

拋出問題給別人，是想讓別人幫忙解決的。我發現很多人提問，習慣把問題描述到一個“絕不可能出問題”的情景下，但是還“偏偏出問題”了。

“我XXX也檢查過了，XXX也檢查過了，XXX也找人看過了，也在別人電腦上試過了，XXX和官方文檔上也一模一樣，之前運行過都沒問題的，現在出問題了，到底是怎么回事兒呢？ ”

這就不是一個想解決問題的態度。有人會在去醫院看病的時候，坐在醫生對面說，“我什么事兒都沒有，好得很”么？

閱讀原文

本文為云棲社區原創內容，未經允許不得轉載。