本文为您整合了使用Proxima CE过程中的常见问题。

Proxima CE用的是哪里的资源？

用户所在MaxCompute Project下的资源。

输入表中的vector可以直接使用MaxCompute的Binary类型吗？

目前不支持，Proxima CE当前版本构建索引的处理方法是将doc表中的vector列转换成索引，doc表中的vector列默认只支持STRING类型，暂不支持BINARY类型。但是Proxima CE对BINARY类型的输入也做了一些优化，提供了-binary_to_int命令行参数，即假设分割符为半角逗号,：
  • 如果-binary_to_int值为false，用户的输入类似于1,1,1,1,1,1,….。
  • 如果-binary_to_int值为true，用户的输入类似于12345,13423,13325,….。
从N个0/1值转换为了N/32个整数，能对生成的索引起到压缩空间的作用。

如何设置行列值（-column_num和-row_num）？

Proxima CE属于分布式离线向量处理引擎，当前主要依托MaxCompute平台的MapReduce（简称MR）来处理超大规模数据。在build过程，需要分列（column），将doc划分到每个列上构建索引；在seek过程中，需要分行（row），将query划分到每个行上检索。通过分行分列来处理超大规模的数据。

对于使用者而言：
  • 列（column）影响build阶段，列越多，每列索引大小降低，单列构建检索速度提高，加速build阶段，但使用的集群机器资源变多。
  • 行（row）影响seek阶段，行越多，每行检索的query变少，单行检索速度提升，加速seek阶段，同样使用的集群机器资源变多。
因此对于行列的划分需要考虑以下限制：
  • 默认集群的资源限制。需要联系用户所在MaxCompute Project对应的Project Owner了解。
  • MapReduce的实例限制。目前MaxCompute MR的reduce任务限制99999个实例，实例个数在build阶段个数为column_num ，在seek阶段个数为column_num * row_num。因此需要保证column_num * row_num<99999。

考虑到上述架构以及相关限制，我们通常推荐用户使用默认的行列数配置。即不需要指定，Proxima CE会根据用户输入的相关参数计算出默认的行列数，具体的计算方式请参考多类目检索。

当然系统计算出的行列是保障正常运行的资源要求，即当用户需要加速时，可以增加行列，或者当集群资源不够时，可以减少行列，这些都需要根据自己所在MaxCompute Project的情况具体分析，包括下述如何加速任务的运行速度?均是提供一个通用的原则与思路。

如何加速任务的运行速度?

  • 多类目情况下，任务整体分成两部分，一部分是单类目doc个数小于100万（默认阈值，可配置）的类目，另一部分是单类目doc个数大于100万的类目，所有小于100万的类目会一起用线性的方法进行检索，要加快这部分的速度，可以设置如下两个命令行参数 -category_row_num和-category_col_num。对于大类目部分的加速，可以通过设置这两个参数-row_num和-column_num。大体上的原则是增大列数和增加行数，这是由于增大列数，每列索引大小降低，单列检索速度提高；增大行数，每行 query 数量减少，同一批的检索速度提升，但是相应的资源的消耗就增加，具体需要结合业务与资源情况进行分析。详情请参考多类目检索。
  • 非多类目情况下，可以通过设置-row_num和-column_num参数，提高任务整体的并发度。

为什么有query没有达到指定的topn？

在确认输入数据和系统运行没有问题之外，那么可能就是原始输入doc表的数据问题，Proxima CE默认采用的是hnsw算法构建索引，可能出现了构图不连通的极端情况，导致检索召回结果数量不够。解决方法：
  • 可以通过降低recall 。该方法解决不彻底，如果是底层算法构图不连通，那么无论减少多少也可能不会得到200个，另外如果有，为特例case降低召回率对其他向量召回的效果也有影响，需要自行评估。
  • 改变构造索引算法。例如采用HC方式构图，可通过-algo_model命令行参数指定。
  • 补全topk。对于proxima2.4以上的版本，如果指定为HnswSearcher的hnsw的图算法，通过添加参数{"proxima.hnsw.searcher.force_padding_result_enable" : True}补全search结果到指定的topk，对极端case的相似性的效果有一定影响，需要根据具体业务自行评估影响是否可接受。

Proxima CE可以设置cosine（余弦）距离吗？

Proxima CE支持cosine距离，且对内积的支持有优化，详情参考内积和余弦距离。

为什么提交的Proxima CE任务执行缓慢？

Proxima CE的主体是运行在MaxCompute MapReduce job，在任务正常编译运行的情况下，可能是MaxCompute调度和资源的问题，您可以通过申请链接或搜索（钉钉群号：11782920）加入MaxCompute开发者社区钉群联系MaxCompute技术支持团队获取支持。

创建临时表异常是什么问题？

该情况通常伴随invalid table name: xxx.yyy报错，主要原因是输出表命名出现问题。

对于Proxima CE的输入输出表，其命名需要符合MaxCompute的命名规定，注意名称中不能带点号.，该符号为MaxCompute的特殊字符，会导致后续流程错误。通常发生在创建output表为xxx.output_table_name的情况。

多个任务同时执行会有问题吗？

目前Proxima CE不支持相同输入doc的多个任务同时执行，因为多个任务同时执行会导致索引的坏写，比如A任务写了某份索引，B任务会覆盖，这样会导致各种问题，常见问题如下：
  • 底层OSS Volume Filesystem相关的错误。
  • build过程失败，提示jni write index失败相关的错误。
  • seek过程失败，提示jni load index失败相关的错误。

为什么我运行的离线任务影响在线任务？

一般原因是离线任务和在线任务运行于同一个集群所导致。一般MaxCompute任务是混部集群上执行的，混部集群底层对离线、在线任务是共用的，因此可能出现离线任务占用了较多的集群资源，导致在线任务获取不到相应的资源，出现运行缓慢甚至失败等情况。一般建议：
  • 限制离线任务的资源使用。可以限制任务的并发，通过指定Proxima离线任务的行列，也可以在自己的MaxCompute Project控制台加限制，这些都会导致离线任务运行变慢。
  • 尽量分离两个任务。可以尝试分时使用集群，或者尝试申请新的资源。

RunLog与Logview是什么含义？有什么区别？

  • RunLog
    技术支持接口人经常使用的运行日志、runLog通常是指在DataWorks节点运行后生成的运行日志下的全部内容。用户可以复制runlog信息发送给接口人定位问题。runlog如果使用odpscmd运行脚本，通常也会在客户端生成运行日志，可以复制客户端上的全部日志发送给接口人，也可以将日志重定向到一个日志文件，将文件发送给接口人。cmd
  • logview

    Logview是一个在MaxCompute Job提交后查看任务和Debug任务的工具，对于Proxima CE来讲，通常指的是在整体任务运行过程中，中间的SQLTask、MapReduce Task等运行时生成的Web日志状态信息，可以帮助用户查看基于MaxCompute运行的SQL、MR、Graph等任务的状态或调试运行出现的问题。详情请参考使用Logview查看作业运行信息。

任务被killed（ERROR: KILLED）怎么办？

这种情况一般出现的日志如下：日志任务被kill有以下几种可能：
  • 任务运行时间过久，MaxCompute上单个SQL任务默认运行超过24小时会被kill，您可以通过设置以下参数使SQL作业延长至72小时：
    set odps.sql.job.max.time.hours=72;
  • 集群负载过大，资源被某个高优任务长期抢占，系统调度kill。
  • 人为kill，可以询问Project Owner是否处理过，或者其他具有Project管理员权限的人是否处理过。
一般任务被kill了可以采用重跑方式，但是在集群负载比较大的时候建议采用以下两种方式。
  • 提高任务优先级，通过设置-odps_task_priority参数改变任务优先级。详情请参考可选参数。
    重要 该操作风险较大，因为这样会抢占其他高优任务的资源，需要联系Project Owner 或者相关负责人，确定当前Project所在集群没有高优的在线或离线任务。
  • 等待高优任务资源洪峰过后再执行Proxima CE任务。

为什么-odps_task_priority设置的任务优先级不起作用？

如果您的Project设置了基线优先级，当您设置的优先级高于基线优先级时，所设置的优先级将会失效。基线详情请参考基线管理。