0

両方のテーブルが同じサイズの結合を含む大きな選択があるので、それを処理するために、右側のテーブルの選択を (% を使用して) チャンクに制限し、同じ選択を複数回実行します。宛先テーブルに追加します。

プロセスはチャンク 0、1、2 では正常に機能しますが、後続のチャンクでは失敗し、「提供されたスキーマがテーブルと一致しません」と主張します。

失敗するジョブの一部は次のとおりです。

job_01eb892ab77c49f2ab5a7d24fa19ea96 (chunk 3)
job_ae450380bacd42b8aae7b7b350a8bd61 (chunk 4)
job_6f40617d0e6046e7b474dffef220ade7 (chunk 5)
job_edfbf86b95364efba3a21ae855827eb4 (chunk 6)

テーブルを削除し、最初に失敗したチャンク (3) を単独で実行すると (job_bbbd3c8b56594725a3d3933c79f96286)、正常に動作し、新しいテーブルのスキーマは同じで期待どおりです。

チャンク 0、1、3、4 を選択的に処理すると、チャンク 3 は正常に動作し、4 (job_76c3addb316644f595988cbc393ffa8a) で失敗します。

これは、BQ の問題により、4 番目のチャンク (どちらであっても) を宛先テーブルに追加できず、エラーの説明が正しくないように見えます。

助言がありますか？ありがとう

4

2 に答える 2

1

これは、テーブルの結果をディスクに書き始めるときに、微妙に異なるスキーマ形式で行うバグのように見えます。修正を確認しましたが、来週のリリースまで利用できない可能性があります。

于 2012-08-21T20:01:32.350 に答える
0

これは、クエリ結果が予測できないフィールド モード (必須とオプション) を返す既知のバグだと思います。IIRC では、AS または IF() を使用してゲームをプレイし、オプションのフラグを強制的に設定できます。

于 2012-08-20T15:36:00.080 に答える