MaxCompute:よくある質問

いいえ、入力テーブルのベクトルはBINARY型にすることはできません。 Proxima CEは、docテーブルのベクトル列をインデックスに変換することによってインデックスを作成します。 デフォルトでは、docテーブルのベクトル列はSTRING型のみをサポートします。 BINARYタイプはサポートされていません。 ただし、Proxima CEは -binary_to_intコマンドラインパラメーターを提供します。 BINARY型のデータをINT型に変換するかどうかを指定します。 たとえば、入力データの区切り文字としてカンマ (,) を使用する場合、このパラメーターは次のように有効になります。

• -binary_to_intがfalseに設定されている場合、入力データは1,1、1,1、1,1、... になります。

• -binary_to_intがtrueに設定されている場合、入力データは12345,13423、13325、... になります。

データ型変換機能を使用すると、0と1で構成されるN個のバイナリ値をN個の32ビットの整数に変換できます。 このようにして、作成されるインデックスのサイズが縮小される。

ユーザーの場合:

• 列はビルドプロセスに影響します。 多数の列が作成されると、各列のインデックスサイズが小さくなり、1つの列の検索速度が速くなります。 これにより、ビルドプロセスが高速化されますが、使用されるクラスターマシンリソースの量が増加します。

• 行はシークプロセスに影響します。 多数の行が作成された場合、各行のクエリの数は少なく、1行の検索速度は速くなります。 これは、シークプロセスを加速するが、使用されるクラスタマシン資源の量を増加させる。

行と列の分割に関する次の制限に注意してください。

• クラスターリソースの使用に関するデフォルトの制限。 クラスターリソースの使用に関するデフォルトの制限については、アカウントが属するMaxComputeプロジェクトの所有者に連絡する必要があります。

• MapReduceインスタンスの制限。 MaxCompute MapReduceでは、最大数の99,999インスタンスを使用してreduceタスクを実行できます。 ビルドプロセスでは、インスタンス数はcolumn_numパラメーターで指定されます。 シークプロセスでは、インスタンスの数は次の式column_num × row_numを使用して決定されます。 上記の式を使用して計算された値が未満99999であることを確認する必要があります。

入力データが有効で、システムが期待どおりに実行されることを確認した場合、問題はdocテーブルのデータにある可能性があります。 デフォルトでは、Proxima CEはHierarchical Navigable Small World (HNSW) グラフアルゴリズムを使用してインデックスを作成します。 この場合、グラフ内のオブジェクトはリンクされなくてもよい。 その結果、取得された結果の数は指定された数より少なくなります。 解決策：

• リコール率を下げます。 この方法を使用して問題を完全に解決することはできません。 グラフリンクの問題が基礎となるアルゴリズムによって引き起こされる場合、取得される結果の数は、リコール率に関係なく、指定された数 (この例では200) と同じにすることはできません。 特別なケースでリコール率を下げると、他のベクトルの取得にも影響を与える可能性があります。 この方法を使用する前に、影響を評価する必要があります。

• インデックス作成アルゴリズムを変更します。 たとえば、階層クラスタリング (HC) を使用してグラフを作成する場合、-algo_modelコマンドラインパラメーターを設定して、インデックス作成アルゴリズムを指定できます。

• 上位Kの結果を補完します。 Proxima 2.4以降のバージョンでは、HNSWグラフアルゴリズムを使用する場合、設定 {"proxima.hnsw.searcher.force_padding_result_enable" : True} を追加して、検索結果に基づいて指定された上位K件の結果を補完できます。 この方法は、極端な場合、類似性検索に悪影響を及ぼす。 この方法を使用する前に、実際のビジネスに基づいて影響を評価する必要があります。

Proxima CEでは、同じdocテーブルを含むタスクを同時に実行することはできません。 このようなタスクを同時に実行すると、インデックスの上書きの問題が発生する可能性があります。 たとえば、タスクAのインデックスが作成された場合、タスクBのインデックスは作成されたインデックスによって上書きされます。 その結果、様々な問題が発生する。 一般的な問題:

• 基になるOSSボリュームファイルシステムに関連するエラーが報告されます。

• ビルドプロセスが失敗し、Java Native Interface (JNI) ベースのインデックス書き込みに関連するエラーが報告されます。

• シークプロセスが失敗し、JNIベースのインデックスロードに関連するエラーが報告されます。

一般的な原因は、オフラインタスクとオンラインタスクが同じクラスターで実行されることです。 一般的なケースでは、さまざまな種類のMaxComputeジョブがクラスターでハイブリッドに実行されます。 クラスターの下層は、オフラインタスクとオンラインタスクで共有されます。 したがって、オフラインタスクは大量のクラスターリソースを占有する可能性があります。 その結果、オンラインタスクは十分なリソースを取得できず、これらのタスクはゆっくりと実行され、失敗することさえあります。 解決策：

• オフラインタスクのリソース使用を制限します。 Proximaオフラインタスクの行数と列数を指定することで、オフラインタスクの同時実行を制限できます。 MaxComputeコンソールでMaxComputeプロジェクトに制限を課すこともできます。 これらの操作は、オフラインタスクの実行を遅くします。

• さまざまな期間にオンラインとオフラインのタスクを実行してみてください。 新しいリソースを申請することもできます。

次のまたは同様の情報がログに記録されます。次の理由でタスクが終了する可能性があります。

• タスクは長期間実行されます。 SQLタスクがMaxComputeで24時間以上実行されると、自動的に強制終了されます。 odps.sql.job.max.time.hoursを72に設定できます。 この方法で、最大72時間タスクを実行できます。

  set odps.sql.job.max.time.hours=72;

• クラスターが過負荷になり、リソースがタスクによって長時間プリエンプトされます。 その結果、タスクは殺されます。

• タスクは手動で強制終了されます。 プロジェクトの所有者またはプロジェクト管理者ロールが割り当てられた他のユーザーによってタスクが強制終了されたかどうかを確認できます。

ほとんどの場合、タスクが殺された場合は、再実行できます。 ただし、クラスターがオーバーロードされている場合は、次のいずれかの方法を使用することを推奨します。

• -odps_task_priorityパラメーターを設定して、タスクを優先します。 詳細については、「オプションパラメーター」をご参照ください。

  重要

  この方法は危険です。 この方法を使用すると、タスクは他の優先度の高いジョブに割り当てられているリソースを先取りする可能性があります。 プロジェクトの所有者または関係者に連絡し、プロジェクトのクラスターで優先度の高いオンラインまたはオフラインタスクが実行されていないことを確認する必要があります。

• 優先度の高いタスクのリソース使用量が減少するまで待ちます。 次に、プロキシマCEタスクを再実行します。