本文为您介绍任务运行失败的报错信息及解决方法。

Seek阶段pk重复导致运行失败

  • 报错信息报错
  • 解决方法
    打开运行MaxCompute任务的Logview，并查看StdOut中的值。Loview使用方法请参考使用Logview查看作业运行信息。logstdout如果该实例的record number比其它实例大很多，请检查数据是否存在pk相同、但value不同的vector。此种情况是数据没有去重，在数据库当中有pk相同，但是向量不同的数据。在seek阶段M-R1-R2的R1到R2的过程，会将这些数据交给同样的Reducer去执行，导致数据倾斜，造成某个Reduce Job挂掉。

小类目检索准备阶段GetSmallCategoryDocNum为空

  • 报错信息报错
  • 解决方法

    该问题的主要原因是表当中某些字段的值为空，比如category列的值为空或者pk列的值为空，建议通过SQL将这些空值对应的record删除。

小类目检索阶段schema validation不匹配

  • 报错信息
    2020-07-28 16:58:15.221 [main] INFO  p.a.p.p.ProximaCEPipelineExecutor - [] - execute SmallCategorySeek worker start ..........
[400] com.aliyun.odps.OdpsException: ODPS-0420031: Invalid xml in HTTP request body - The request body is malformed or the server version doesn't match this sdk/client. XML Schema validation failed: Element 'Value': [facet 'maxLength'] The value has a length of '4952955'; this exceeds the allowed maximum length of '2097152'.
Element 'Value': '{"MaxCompute.pipeline.0.output.key.schema":"instId:BIGINT,type:BIGINT,pk:STRING,category:BIGINT","MaxCompute.pipeline.0.output.value.schema":"v
  • 解决方法

    表明doc表中的类目数量太多，需要按类目拆分成多个表。

解析表数据时出现“-nan”错误

  • 报错信息报错
  • 解决方法

    该问题一般是原始doc或query表输入的格式有问题，可能存在很大的值或者接近0的值。例如某一行vector下的值为 1.23~4.56~7.89~nan~4.21 或 1.1~2.2~127197893781729178311928739179222121.23128767846816278193456789087654~ 0.000000000000000000000000000000000000000001~5.5，会导致在数值计算时溢出或者出现除零错误。可以尝试使用MaxCompute的SQL UDF过滤出doc表和query表中的问题数据。

多类目情况下，某个类目doc数目为0，query数目不为0导致的jni调用异常

  • 报错信息报错报错
  • 解决方法

    这种情况被认为是用户输入问题，在设计时发现这样的情况时通过报错终止来提示用户，而不是忽略。这样做防止用户需要某个类目的召回结果，但是最终没有召回，如果忽略将会导致隐蔽的Bug。解决方案是剔除query或doc表中记录为0的对应类目，因为空记录的召回无论是doc还是query都是无实际意义的。

MaxCompute Tunnel Endpoint问题

  • 报错信息
    建立DownloadSession失败 ErrorCode=Local Error, ErrorMessage=Failed to create download session with tunnel endpoint
  • 解决方法
    该问题的主要是Proxima CE内部调用MaxCompute关于Tunnel的某些接口失败导致的，存在的原因有：
    • 网络问题，重试即可。
    • 跨网络访问。Tunnel Endpoint设置错误导致的读取MaxCompute table count失败。详情参考Tunnel命令常见问题 。用户可以通过添加启动参数-tunnel_endpoint指定有效的Tunnel Endpoint重新运行。

运行过程中MapReduce里的java NPE (java.lang.NullPointerException) 问题

  • 报错信息
    • error example1：setKey()导致。报错
    • error example2：VectorConvert.convert()导致。报错
    • error example3：getInputVolumeFileSystem()导致。报错
  • 解决方法
    对于error example1和error example2：一般是由于在build或seek阶段，MR任务读取输入表中的某一列时失败导致，可能的原因有：
    • 该列不存在。
    • 该列下存在某行值为null。
    • 该列下存在某行值不合法，导致解析错误。
    一般在build阶段失败需要检查doc表是否存在上述问题，在seek阶段失败需要检查query表是否存在上述问题，build/seek阶段区分如下：
    • build阶段是由Mapper-Reducer构成的MR任务，通常在日志里如上述error example2的输出。
    • seek阶段是由Mapper-Reducer1-Reducer2构成的MRR任务，通常在日志里如上述error example1的输出。
    对于error example3：一般是由于在seek阶段Mapper任务获取MaxCompute Volume时出现错误，找不到对应的Volume及对应的 Volume Partition，主要原因可能有：
    • 同一时间运行多个具有相同输入doc表的任务，最后运行日志会报如图所示错误。对于当前版本Proxima CE，对索引的分区是依赖输入的doc表名和分区名的，因此同时跑多个任务时，如果doc表相同，会出现多个任务对同一个Volume下的索引文件有覆盖甚至删除的错误，导致读取MaxCompute Volume失败，类似的也会导致索引加载失败。可以通过调整任务的输入doc表名不同，保证每个任务的正常运行。
    • 行列设置有问题。MaxCompute目前支持reducer实例最多为99999个，如果用户设置的-column_num和-row_num过大，会导致seek阶段MRR任务的实例个数（实例个数 = column_num * row_num）超过限制，这样会导致不可控的错误，使得seek阶段的reducer无法找到正确的索引Volume。可以通过使用合理的行列值来保证，详情请参考聚类分片。

getPartitionColumn获取分区列pt出错

  • 报错信息报错
  • 解决方法

    一般这种情况是没有检查到pt列，目前doc_table和query_table强制规定了表的schema，其中规定partition列为STRING类型的pt列，详情请参考导入输入表数据。另外pt列必须指定为分区列，如果是普通列也会出现同样的错误。

报错ShuffleServiceMode: Dump checkpoint failed

  • 报错信息
    0010000:System internal error - fuxi job failed, caused by: ShuffleServiceMode: Dump checkpoint failed
  • 解决方法

    该问题一般是单个实例output size超限导致的，即MR处理过程中，单个Mapper或Reducer实例的输出超过限制（400 GB）。原因为单个实例处理的数据过大，或者Mapper或Reducer内部逻辑导致数据膨胀过大。可以通过指定-mapper_split_size参数调低单个Mapper切分的数据大小来解决，单位为MB。

FAILED: MaxCompute-0430071: Rejected by policy - rejected by system throttling rule

  • 报错信息
    FAILED: MaxCompute-0430071: Rejected by policy - rejected by system throttling rule
  • 解决方法

    这种情况是MaxCompute系统限流，任务的执行请求被拒绝，有可能是集群在执行其他任务（例如：压测任务），也有可能是为了安全保障某段时间内禁止用户执行任务。一般过段时间重跑任务即可，具体时间可以询问Project Owner或Project集群所在负责人。

因读表失败导致的 java.lang.ArrayIndexOutOfBoundException

  • 报错信息报错
  • 解决方法
    这种情况的原因通常是内部Mapper任务GeneratePkMapper依赖读取的一个数组长度未获取到正确数据，通常情况该数组长度是前序的SQL任务通过读表获取的，一般是因为读表失败导致的。
    • 超时：由于Project所在集群网络波动导致，一般重试几次或者过段时间重跑即可。报错
    • Tunnel Exception：Proxima CE内部读表时会通过Tunnel获取表记录，因此Tunnel失败也会导致读表失败，Tunnel错误可以参考MaxCompute Tunnel Endpoint问题。

运行聚类分片时，遇到Timeout问题

  • 报错信息
    FAILED: ODPS-0010000:System internal error - Timeout when graph master wait all workers start
java.io.IOException: Job failed!
    at com.aliyun.odps.graph.GraphJob.run(GraphJob.java:429)
    at com.alibaba.proxima2.ce.pipeline.odps.worker.KmeansGraphJobWorker.apply(KmeansGraphJobWorker.java:131)
    at com.alibaba.proxima2.ce.pipeline.odps.runner.OdpsPipelineRunner.run(OdpsPipelineRunner.java:31)
    at com.alibaba.proxima2.ce.pipeline.PipelineExecutor.execute(PipelineExecutor.java:27)
    at com.alibaba.proxima2.ce.ProximaCERunner.runWithNormal(ProximaCERunner.java:28)
    at com.alibaba.proxima2.ce.ProximaCERunner.main(ProximaCERunner.java:149)
  • 解决方法
    聚类分片在构建索引时，首先会基于Graph引擎做数据聚类，具体是执行对应的GraphJob来完成，GraphJob会默认申请一个Worker数量，当集群资源不足时会出现上述问题。可以在执行命令里限定执行GraphJob的Worker数量来限制资源申请。在Proxima CE的启动命令前设置参数：
    set odps.graph.worker.num=400; -- 400 是实例说明，具体数量根据集群资源设置
    完整命令如下：
    set odps.graph.worker.num=400;
jar -resources kmeans_center_resource_cl,proxima-ce-aliyun-1.0.0.jar
-classpath http://schedule@{env}inside.cheetah.alibaba-inc.com/scheduler/res?id=251678818 com.alibaba.proxima2.ce com.alibaba.proxima2.ce.ProximaCERunner
-doc_table doc_table_pailitao
-doc_table_partition 20210707
-query_table query_table_pailitao
-query_table_partition 20210707
-output_table output_table_pailitao_cluster_2000w
-output_table_partition 20210707
-data_type float
-dimension 512
-oss_access_id xxx
-oss_access_key xxx
-oss_endpoint xxx
-oss_bucket xxx
-owner_id 123456
-vector_separator blank
-pk_type int64
-row_num 10
-column_num 10
-job_mode build:seek:recall
-topk 1,50,100,200
-sharding_mode cluster
-kmeans_resource_name kmeans_center_resource_cl
-kmeans_cluster_num 1000;