如何理解maxcompute常見報錯信息？
貌似大部分人在遇到報錯的時候，都懶得用翻譯軟件翻譯報錯信息，一般直接拋出來問，甚至連報錯信息都懶得復制，直接截圖出來。所以這裏特地總結了一下，最近一段時間有人經常在群裏問到的報錯信息。
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和官方文檔上也一模一樣，之前運行過都沒問題的，現在出問題了，到底是怎麽回事兒呢？ ”
這就不是一個想解決問題的態度。有人會在去醫院看病的時候，坐在醫生對面說，“我什麽事兒都沒有，好得很”麽？
閱讀原文?請添加鏈接描述
本文為雲棲社區原創內容，未經允許不得轉載。
如何理解maxcompute常見報錯信息？