本文介紹MaxFrame的常見報錯問題。
問題1：報錯invalid type INT for function UDF definition, you need to set odps.sql.type.system.odps2=true; in order to use it
報錯原因：在未開啟MaxCompute 2.0資料類型版本的情況下，使用MaxCompute 2.0的資料類型，導致作業執行時出現錯誤。
解決方案：通過Flag開啟MaxCompute 2.0資料類型，樣本如下：
from maxframe import config # 在new_session之前添加 config.options.sql.settings = { "odps.sql.type.system.odps2": "true" }
問題2：報錯UDF : No module named 'cloudpickle'
報錯原因：缺少依賴的cloudpickle包。
解決方案：引用MaxCompute基礎鏡像，樣本如下：
from maxframe import config # 在new_session之前添加 config.options.sql.settings = { "odps.session.image": "common", }
問題3：如何在DataFrame提交（apply）的UDF中實現資源複用
在部分UDF情境中，可能涉及到某些較多的資源建立或者銷毀行為（例如初始化資料庫連接、載入模型等），希望在每個UDF被載入時只會執行一次。
可以利用Python中函數參數預設值只被初始化一次的特性，實現資源複用。
例如，在下述UDF中，模型只會被載入一次。
def predict(s, _ctx={}):
from ultralytics import YOLO
# _ctx 的初始值是一個空 dict，在 Python 執行過程中只會被初始化一次。
# 使用模型時，可以先判斷 _ctx 中是否存在該模型，不存在則執行載入，然後存入 dict 中。
if not _ctx.get("model", None):
model = YOLO(os.path.join("./", "yolo11n.pt"))
_ctx["model"] = model
model = _ctx["model"]
# 後續調用模型的相關介面
下面給出了一個需要銷毀資源的UDF樣本，該樣本中使用了一個自訂的類MyConnector負責建立和關閉資料庫連接。
class MyConnector:
def __init__(self):
# 在 __init__ 中建立資料庫連接
self.conn = create_connection()
def __del__(self):
# 在 __del__ 中關閉資料庫連接
try:
self.conn.close()
except:
pass
def process(s, connector=MyConnector()):
# 直接調用 connector 內的資料庫連接，無需在 UDF 內部再次執行串連建立和關閉
connector.conn.execute("xxxxx")
初始化的實際執行次數取決於運行UDF的Worker數量，每個Worker執行UDF時都是一個單獨的Python環境。例如，某個UDF調用需要處理10萬行資料，總共被分配給了10個UDF Worker，每個Worker處理一萬條資料，則總共會執行10次初始化，每個Worker在處理1萬條資料的過程中，初始化過程只會執行一次。
問題4：如何在DataWorks資源群組（獨享和通用）更新MaxFrame版本?
問題5：MaxFrame自訂鏡像使用實踐
問題6：查詢報錯ODPS-0130071:[0,0] Semantic analysis exception - physical plan generation failed: java.lang.RuntimeException: sequence_row_id cannot be applied because of : no CMF
解決方案：查詢時需要加上index_col，程式碼範例如下：
df2=md.read_odps_table("tablename",index_col="cloumn").to_pandas()
df2=reset_index(inplace=True)問題7：使用apply等帶自訂函數方法時報錯Cannot determine dtypes by calculating with enumerate data, please specify it as arguments
報錯原因：MaxFrame嘗試推匯出UDF可能返回的DataFrame/Series類型，這些類型用於檢查和構建後續計算的Dataframe/Series，但在下列情況下可能無法正常獲得 dtypes。
如果UDF在當前環境下無法正常執行，可能是依賴了一些自訂鏡像、第三方依賴或者傳入的參數有誤。
如果指定了
output_type，可能函數實際返回的類型與指定的output_type不符。
解決方案：修改代碼或通過指定 `dtypes` 來告知MaxFrame當前UDF返回結果的類型，例如：
返回一個包含一個 int 列的 DataFrame：
df.apply(..., dtypes=pd.Series([np.int_]), output_type="dataframe")返回一個包含 A 和 B 兩列的 DataFrame：
df.apply(..., dtypes={"A": np.int_, "B": np.str_}, output_type="dataframe")返回一個類型為 bool 名為 flag 的 Series：
df.apply(..., dtype="bool", name="flag", output_type="series")
問題8：如何按照SQL的方式添加flag？
from maxframe import config
config.options.sql.settings = {
"odps.stage.mapper.split.size": "8",
"odps.stage.joiner.num": "20"
}問題9：如何在MaxFrame開發中引用三方包？
參考引用第三方包及鏡像。
from maxframe.udf import with_resources
@with_resources("resource_name")
def process(row):
...
問題10：任務報錯TypeError: Cannot accept arguments append_partitions
檢查PyODPS版本，升級到0.12.0可以解決。
問題11：如何拆解大量JSON字串欄位
MaxFramev1.0.0及以上版本的SDK支援通過如下方式拆解大量JSON字串欄位：
問題12：ODPS-0010000: Fuxi job failed - Job failed for unknown reason, cannot get jobstatus
錯誤原因：顯示或間接使用
@with_python_requirements等方式安裝依賴時安裝失敗，導致作業無法繼續運行。錯誤資訊解釋：
ODPS-0010000: Fuxi job failed - Job failed for unknown reason, cannot get jobstatus在PythonPack的Logview的stderr中應當能見到更詳細的資訊，例如下方所見的網路連接失敗錯誤等。
解決方案：
PythonPack內部錯誤，考慮安裝Pip依賴打包的節點暫時無法正常地訪問依賴倉庫，可以首先考慮重試，如果重試仍然無法解決，請聯絡MaxFrame團隊。
如果是周期性作業，為了保證作業的穩定性，可以考慮在使用PythonPack時，直接緩衝打包成功的結果，並在之後的每天作業中直接使用緩衝的結果。對結果緩衝的使用方法如下：
from maxframe import options # 設定 pythonpack 的結果為 prod，這樣在之後的作業中，pythonpack 結果會直接使用緩衝 options.pythonpack.task.settings = {"odps.pythonpack.production": "true"}如果要忽略緩衝，需要在
@with_python_requirements中添加force_rebuild=True。也可以考慮暫時不使用PythonPack來安裝依賴，離線打包好對應的依賴，上傳為MaxFrame Resource，並在對應的作業中引用，MaxFrame會自動將依賴添加到可調用的上下文中。
PyODPS-Pack是一個簡化這個流程的工具，PyODPS-Pack會自動裝載相同環境的manylinux docker容器進行打包以避免出現相容性問題，目前可以在 X86 Linux 機器上運行（M 系列的 ARM 晶片的蘋果裝置暫時不支援）。
在MaxFrame中使用MaxCompute Resource，可以使用
@with_resources。
問題13：ODPS-0123055:User script exception
錯誤原因：這類錯誤是MaxFrame中最常見的出錯類型，發生在UDF的執行中，例如
apply、apply_chunk、flatmap、map及transform等運算元。該錯誤資訊代表提交的UDF函數運行中拋出了Python異常。目前這類異常主要由以下幾個因素導致：代碼本身存在問題，需要再次檢查代碼邏輯。
錯誤處理邏輯存在問題，拋出了沒有被正確處理的異常，需要再次檢查
try-except塊是否正確的處理了所有的異常。在 UDF 中訪問了網路，而在預設情況下MaxCompute UDF容器中網路是關閉的。
運算元中使用dtype或者dtypes聲明的輸出類型與UDF中實際返回的類型不符。
在UDF中引用了一些運行環境中缺少的依賴，導致無法正確的還原序列化客戶的代碼。
錯誤資訊解釋：
在
ODPS-0123055:User script exception報錯大部分為Python異常，可以查看失敗的執行個體的stderr。以如下測試為例，對一個非JSON字串執行JSON loads，一定會出現錯誤，這在資料處理中非常常見。
1. def simple_failure(row): 2. import json 3. 4. text = row["json_text"] 5. data = json.loads(text) 6. return data 7. 8. 9. df = md.read_pandas(pd.DataFrame({"json_text": ["123", "456", "789"]})) 10. df.apply( 11. simple_failure, axis=1, dtypes={"text": np.str_}, output_type="dataframe" 12. ).execute()對應的報錯資訊如下所示，報錯資訊中清晰地指出錯誤發生在
simple_failure函數中，對應的程式碼是line 5，也就是data = json.loads(text)這一行：ScriptError: ODPS-0123055: InstanceId: 20250622063246442gquihia95z2 ODPS-0123055:User script exception - Traceback (most recent call last): File "/home/admin/mf_udf_ref_20250622062907997gvwps9irzzc_user_udf_139907101614080.py", line 130, in wrapped return func(self, *args, **kw) ^^^^^^^^^^^^^^^^^^^^^^^ File "/home/admin/mf_udf_ref_20250622062907997gvwps9irzzc_user_udf_139907101614080.py", line 262, in process for result in self.user_func(*args): File "/home/admin/mf_udf_ref_20250622062907997gvwps9irzzc_user_udf_139907101614080.py", line 230, in user_func_caller _user_function_results = _user_function(data, *_args, **_kw_args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/folders/_8/v9wr7xm54bz0rj5pl4p9dkww0000gn/T/ipykernel_18735/2599074506.py", line 5, in simple_failure File "/usr/ali/python3.11.7/lib/python3.11/json/__init__.py", line 346, in loads return _default_decoder.decode(s) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/ali/python3.11.7/lib/python3.11/json/decoder.py", line 337, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/ali/python3.11.7/lib/python3.11/json/decoder.py", line 355, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) | fatalInstance: Odps/meta_dev_20250622063246442gquihia95z2_SQL_0_0_0_job_0/M1#0_0只要函數能正常序列化，通過對棧的分析，基本能獲得到錯誤發生的位置。
而如果引用了一些運行環境中缺少的依賴，會導致UDF無法被正常序列化，報錯資訊中會提示找不到依賴，錯誤資訊中會明顯提示出導致無法被序列化的對象或依賴，以如下為例。
# 假定本地安裝了 xxhash 並匯入 import xxhash def type_failure(row): # 在 udf 裡引用 xxhash return str(xxhash.xxh64("hello maxfrmae")) df = md.read_pandas(pd.DataFrame(np.random.randn(3, 5), columns=list("ABCDE"))) df.apply( type_failure, axis=1, dtypes={"hash_value": np.str_}, output_type="dataframe" ).execute()報錯會出現如下所示的異常棧，即MaxFrame在運行中嘗試
unpickle本地的函數失敗了，提示No module named 'xxhash'，這也是一個非常精準的報錯資訊。File "/home/admin/mf_udf_ref_20250622070426909g26q6zdfar2_user_udf_140362144866304.py", line 209, in __init__ _user_function = cloudpickle.loads(base64.b64decode(b'gAWVnwIAAAAAAACMF2Nsb3VkcGlja2xlLmNsb3VkcGlja2xllIwOX21ha2VfZnVuY3Rpb26Uk5QoaACMDV9idWlsdGluX3R5cGWUk5SMCENvZGVUeXBllIWUUpQoSwFLAEsASwFLBUsDQ1CXAHQBAAAAAAAAAAAAAHQCAAAAAAAAAAAAAKACAAAAAAAAAAAAAAAAAAAAAAAAAABkAaYBAACrAQAAAAAAAAAApgEAAKsBAAAAAAAAAABTAJROjA5oZWxsbyBtYXhmcm1hZZSGlIwDc3RylIwGeHhoYXNolIwFeHhoNjSUh5SMA3Jvd5SFlIxNL3Zhci9mb2xkZXJzL184L3Y5d3I3eG01NGJ6MHJqNXBsNHA5ZGt3dzAwMDBnbi9UL2lweWtlcm5lbF8xODczNS81NTM2OTIzNjYucHmUjAx0eXBlX2ZhaWx1cmWUaBJLBEMdgADdCw6Ndo98inzQHCzRDy3UDy3RCy7UCy7QBC6UQwCUKSl0lFKUfZQojAtfX3BhY2thZ2VfX5ROjAhfX25hbWVfX5SMCF9fbWFpbl9flHVOTk50lFKUjBxjbG91ZHBpY2tsZS5jbG91ZHBpY2tsZV9mYXN0lIwSX2Z1bmN0aW9uX3NldHN0YXRllJOUaBx9lH2UKGgZaBKMDF9fcXVhbG5hbWVfX5RoEowPX19hbm5vdGF0aW9uc19flH2UjA5fX2t3ZGVmYXVsdHNfX5ROjAxfX2RlZmF1bHRzX1+UTowKX19tb2R1bGVfX5RoGowHX19kb2NfX5ROjAtfX2Nsb3N1cmVfX5ROjBdfY2xvdWRwaWNrbGVfc3VibW9kdWxlc5RdlIwLX19nbG9iYWxzX1+UfZRoDGgAjAlzdWJpbXBvcnSUk5RoDIWUUpRzdYaUhlIwLg=='), buffers=[ ]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/ali/python3.11.7/lib/python3.11/site-packages/cloudpickle/cloudpickle.py", line 649, in subimport __import__(name) ModuleNotFoundError: No module named 'xxhash'以下是其他幾種類型錯誤的錯誤碼和錯誤資訊
錯誤的傳回型別：
def type_failure(row): text = row["A"] # 返回一個 float return text df = md.read_pandas(pd.DataFrame(np.random.randn(3, 5), columns=list("ABCDE"))) # 聲明返回一個 dataframe 包含一個名字為 A 的 str 列 df.apply(type_failure, axis=1, dtypes={"A": np.str_}, output_type="dataframe").execute()會提醒期望一個unicode，也就是str，但是得到了一個 float 類型。這些資訊通常由 dtypes 或者 dtype 指定，請確保聲明的類型與函數裡實際返回的類型一致。
ScriptError: ODPS-0123055: InstanceId: 202506220642291g87d6xot20d ODPS-0123055:User script exception - Traceback (most recent call last): File "/home/admin/mf_udf_ref_20250622062907997gvwps9irzzc_user_udf_139905326100480.py", line 130, in wrapped return func(self, *args, **kw) ^^^^^^^^^^^^^^^^^^^^^^^ File "/home/admin/mf_udf_ref_20250622062907997gvwps9irzzc_user_udf_139905326100480.py", line 263, in process self.forward(*result) TypeError: return value expected <class 'unicode'> but <class 'float'> found, value: 1.8263596267666997 | fatalInstance: Odps/meta_dev_202506220642291g87d6xot20d_SQL_0_0_0_job_0/M1#0_0未開啟網路訪問的情況下訪問
def request_aliyun_com(row): import requests url = "https://github.com/aliyun/alibabacloud-odps-maxframe-client" response = requests.get(url) return response.text df.apply( request_aliyun_com, axis=1, dtypes={"content": np.str_}, output_type="dataframe" ).execute()對應的錯誤資訊：
ScriptError: ODPS-0123055: InstanceId: 20250622070516226gzo61d9idlr ODPS-0123055:User script exception - Traceback (most recent call last): File "/usr/ali/python3.11.7/lib/python3.11/site-packages/urllib3/connection.py", line 196, in _new_conn sock = connection.create_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/ali/python3.11.7/lib/python3.11/site-packages/urllib3/util/connection.py", line 85, in create_connection raise err File "/usr/ali/python3.11.7/lib/python3.11/site-packages/urllib3/util/connection.py", line 73, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused
解決方案：
對於異常報錯，需要分析棧資訊，找到導致報錯的函數，然後嘗試修複。
修複之後可以嘗試在本地執行，只需要構造對應的資料在本地當作普通的Python函數調用即可。例如：
def udf_func(row): import json text = row["json_text"] data = json.loads(text) return data # 構造輸入傳入，在本地測試函數邏輯 udf_func(pd.Series(['{"hello": "maxfrmae"}'], index=["json_text"]))對於網路訪問的問題，需要開啟網路訪問，參考網路開通流程。
對於還原序列化失敗，請仔細檢查是否有非預期的依賴被引入，以及是否報錯提示的依賴有正確的使用pythonpack安裝或者使用resource攜帶到運行環境中。
問題14：ODPS-0123144: Fuxi job failed - kInstanceMonitorTimeout CRASH_EXIT, usually caused by bad udf performance
錯誤原因：UDF運行逾時。
錯誤資訊解釋
在UDF運行中，可能會出現
kInstanceMonitorTimeout或者CRASH_EXIT, usually caused by bad udf performance的錯誤資訊。這通常意味著UDF運行逾時了。在MaxCompute離線計算情境中，UDF通常按batch rows來監控已耗用時間，如果某個UDF在M時間裡沒有運行完 N條，就會導致逾時失敗，配置方式如下：
from maxframe import options options.sql.settings = { # batch 大小，預設 1024，最小 1 "odps.sql.executionengine.batch.rowcount": "1", # batch 逾時時間，預設 1800，最大 3600 "odps.function.timeout": "3600", }解決方案
根據實際情況，修改batch大小和batch逾時時間。
問題15：ODPS-0123144: Fuxi job failed - fuxi job failed, Job exceed live limit
錯誤原因：MaxCompute 的作業有最大逾時時間，預設為24小時，超過24小時就會導致作業運行失敗。
錯誤資訊解釋
調度系統認為作業逾時，殺掉了作業，作業本身會顯示 Failed 狀態。如果是 DataWorks 上啟動並執行作業，可能會有另外的逾時時間，需要詢問 DataWorks 團隊（會呈現 Cancel 狀態）。
解決方案
根據實際需要調整作業最大運行時間長度。
from maxframe import options # 設定 MaxFrame Session 最長存留時間 options.session.max_alive_seconds = 72 * 60 * 60 # 設定 MaxFrame Session 最長空閑逾時時間 options.session.max_idle_seconds = 72 * 60 * 60 options.sql.settings = { # 設定 SQL 作業最長已耗用時間，預設 24h，最長 72h "odps.sql.job.max.time.hours": 72, }
問題16：0130071:[0,0] Semantic analysis exception - physical plan generation failed: unable to retrive row count of file pangu://xxx
錯誤原因：使用
odps.sql.split.dop等Flag指定切分任務數量時，可能會出現該錯誤。錯誤資訊解釋
通常表示在源表寫入時未產生 meta 檔案，無法直接擷取到源表的元資訊，因此無法對源表進行精確切分。
解決方案
使用
odps.stage.mapper.split.size進行代替，單位是 MB，預設是 256，最小為 1。必要精確切分時，請考慮重建cmf，請聯絡MaxCompute團隊
此外，如果考慮寫出表時需要確保meta檔案的產生，可以考慮添加如下Flag：
from maxframe import options options.sql.settings = { "odps.task.merge.enabled": "false", "odps.sql.reshuffle.dynamicpt": "false", "odps.sql.enable.dynaparts.stats.collection": "true", "odps.optimizer.dynamic.partition.is.first.nth.value.split.enable": "false", "odps.sql.stats.collection.aggressive":"true", }我們後續會考慮更優的方式確保精確 split 功能的穩定性。
問題17：ODPS-0130071:[x,y] Semantic analysis exception
錯誤原因：ReadOdpsQuery情境中如果出現該錯誤，通常表示 SQL 本身存在語義問題。
錯誤資訊解釋
通常表示 SQL 本身存在語義問題。
解決方案
檢查SQL文法。
升級MaxFrame用戶端，
pip install --upgrade maxframe;。如果還不能解決請聯絡MaxFrame團隊。
問題18：ODPS-0020041:StringOutOfMaxLength:String length X is larger than maximum Y
錯誤原因：向表中寫入資料時，或shuffle過程中，出現了超長的字串，字串長度超過了允許的最大長度。
錯誤資訊解釋
MaxCompute中為了確保計算的穩定性，在儲存層面限制了最大的單個可讀寫的字串長度。最大為268435456。
解決方案
考慮截斷或丟棄可能出錯的資料，在ReadOdpsQuery中可以使用LENGTH過濾。
考慮壓縮資料存入，例如 gzip 等，可能會明顯縮小字串長度和大小。
def compress_string(input_string): """ Compresses a string using gzip. """ encoded_string = input_string.encode('utf-8') compressed_bytes = gzip.compress(encoded_string) return compressed_bytes聯絡MaxCompute團隊支援特定資料。
問題19：ODPS-0010000:System internal error - fuxi job failed, caused by: process exited with code 0
錯誤原因：包含 UDF/AI Function 的作業運行失敗。
錯誤資訊解釋
通常表示 UDF/AI Function 運行過程中出現了 OOM。
解決方案
聯絡MaxCompute團隊確認實際記憶體使用量。
使用更大的記憶體運行UDF或者AI Function
對於 UDF，可以使用
@with_running_options設定記憶體。@with_running_options(memory="8GB") def udf_func(row): return row對於 AI Function，可以在函數中設定
running_options={"memory": "8GB"}設定記憶體。
問題20：ODPS-0123131:User defined function exception - internal error - Fatal Error Happended
錯誤原因：讀寫外表情境。
錯誤資訊解釋：通常表示讀寫外表過程中出現了一些內部錯誤。
解決方案：聯絡MaxCompute團隊
問題21：ODPS-0010000:System internal error - com.aliyun.odps.metadata.common.MetastoreServerException: 0420111:Database not found
錯誤原因：讀寫表時無法找到指定的 schema/project/table 等資訊。
錯誤資訊解釋：計算中依賴的中繼資料無法被找到，作業無法正常運行。
解決方案：
檢查 SQL 中使用的 project.schema.table 等資訊是否正確，修改後重試。
聯絡MaxCompute團隊。
問題22：ODPS-0010000:System internal error - fuxi job failed, caused by: process killed by signal 7
錯誤原因：包含 UDF 的作業運行失敗。
錯誤資訊解釋：UDF運行時發出異常訊號。
解決方案：
檢查是否在 UDF 中使用 signal 向進程發送了 cancel，timeout 等訊號。
聯絡 MaxCompute 團隊排查。
問題23：ODPS-0010000:System internal error - fuxi job failed, caused by: StdException:vector::_M_range_insert
錯誤原因：UDF 相關作業。
錯誤資訊解釋：UDF 中運行時無法申請到足夠的記憶體，插入 vector 失敗，需要檢查業務代碼、依賴庫和記憶體設定。
解決方案：
檢查 UDF 中是否有記憶體問題，native 依賴庫是否存在記憶體問題，版本是否最新，調大 UDF 記憶體申請量。
聯絡 MaxCompute 團隊排查。
問題24：ODPS-0130071:[0,0] Semantic analysis exception - physical plan generation failed: task:M1 instance count exceeds limit 99999
錯誤原因：源表比較大的情境下，任何作業都有可能。如果錯誤地設定了 split flag，可能也會導致該問題。
錯誤資訊解釋
MaxCompute SQL 作業中，在沒有任何設定的情況下，預設按 256MB 大小對源表進行分塊分散式處理，但如果按 256MB 切分後，總共切分出的塊數量超過 99999，就會導致該錯誤。
解決方案：
使用
odps.stage.mapper.split.size代替，單位是 MB，預設是 256，最小為 1，可以設定到更大的參數確保切分總數小於 99999。使用
odps.sql.split.dop代替，最小為1，指定切分預期目標數量。在各種條件限制下，最終切出來的資料數量可能不等於預期目標數量，因此壓著上限設定切分數可能報錯。如果上述兩種方法多次調整後均不生效，請聯絡 MaxCompute 團隊。
問題25：ODPS-0110061:Failed to run ddltask - ODPS-0130131:Table not found
錯誤原因：MaxFrame 長時間啟動並執行作業（超過一天）可能出現該錯誤。
錯誤資訊解釋
MaxFrame 內部 ddltask 運行失敗，通常為單個 stage 的計算步驟已耗用時間超過 24h 的情況下，同 session 上遊節點的表到期了。
這類表通常為計算過程中產生的暫存資料表，即
df.execute()調用後產生的表。to_odps_table指定的結果表通常不會有該問題出現。解決方案：
對暫存資料表設定更大的到期時間，單位為天，預設情況下暫存資料表的到期時間是 1 天。如果計算作業的多個運算元可能跨天，通常需要設定該參數。
options.sql.settings = { "session.temp_table_lifecycle": 3, }
問題26：NoTaskServerResponseError
錯誤原因：Jupyter Notebook中，MaxFrame建立了 session並運行了部分作業後，停頓了超過 1h，再向下運行指令碼時，可能會出現該錯誤。
錯誤資訊解釋
MaxFrame Session 已經到期，找不到對應的 Session 了。
解決方案：
重新建立 Session，但 cell 前的計算狀態不會被保留下來。
如果有預期的可能會間隔一段時間，並希望可以繼續運行，需要設定
from maxframe import options # 設定為 24h 到期，預設 1h options.session.max_idle_seconds = 60 * 60 * 24
問題27：IntCastingNaNError: Cannot convert non-finite values (NA or inf) to integer: Error while type casting for column 'xx'
錯誤原因：有列類型為BIGINT或者為INT，但其中包含了NULL或者INF，且print運行結果（也包括在 jyputer notebook 中的自動列印）。
錯誤資訊解釋
MaxFrame 的資料構建在 DataFrame 之上，在本地載入資料時，資料會被轉換為 Pandas DataFrame。在 Pandas 中，BIGINT和INT類型的資料均不能為 NULL（會被作為FLOAT）。
解決方案：
MaxFrame 團隊正著手解決這個問題，但類型系統較為複雜，目前還不能給出明確的時間。暫時可考慮如下方法：
列印之前使用 fillna 填充NULL
列印之前使用 astype 轉換為FLOAT
非必要情況不要列印該列。
問題28：ODPS-0010000:System internal error - fuxi job failed, SQL job failed after failover for too many times
錯誤原因
包含 Reduce/Join 的作業
且設定了較大的 split.dop 或者較小的 split.size，產生了大量的 mapper instance
且設定了較大的 reducer.num/joiner.num，產生了大量的 reducer/joiner instance
錯誤資訊解釋
Shuffle 資料過大，導致 Job Master OOM。
解決方案：
調小 mapper 和 reducer/joiner 的數量，最大不要超過 10000
聯絡 MaxCompute 團隊。
問題29：ODPS-0010000:System internal error - task/common/task_resource_helper.cpp(747): OdpsException: ODPS-0020011:Invalid parameter - Total resource size must be <= 2048MB
錯誤原因：包含 UDF 的作業，且 UDF 依賴了較大的 Resource。
錯誤資訊解釋
UDF 允許依賴的資源的總大小為 2048MB，超過的作業將無法運行。
解決方案：
嘗試使用 external volume 加速的方式從 oss 下載對應的資源，具備更快的下載速率和更高的限制。
問題30：ODPS-0130071:[22,132] Semantic analysis exception - column values_list in source has incompatible type ARRAY/MAP/STRUCT
錯誤原因：處理的資料包含了數組、字典、結構體。
錯誤資訊解釋
可能是型別宣告問題，預期的目標列並非數組、字典、結構體。
可能是 MaxFrame 類型系統的 BUG。
解決方案：
升級 MaxFrame 用戶端
pip install -U maxframe後重試聯絡 MaxFrame 團隊進行排查
問題31：Shuffle output too large
解決方案：使用 odps.sql.sys.flag.fuxi_JobMaxInternalFolderSize flag 指定Shuffle 空間大小，單位是 MB。