現在、からGoogle Storageをstage_table_orders使用してデータを読み込んでいますWRITE_APPEND。このロードは新しい注文と既存の注文の両方をロードするため、同じ注文に複数のバージョンがある場合、フィールドetl_timestampはどの行が最も更新されているかを示します。
それから私WRITE_TRUNCATEは次のproduction_table_ordersようなクエリを使用します：
select ...
from (
SELECT * , ROW_NUMBER() OVER
(PARTITION BY date_purchased, orderid order by etl_timestamp DESC) as rn
FROM `warehouse.stage_table_orders` )
where rn=1
その場合、production_table_orders常に各注文の最新バージョンが含まれます。
このプロセスは、3分ごとに実行されると想定されています。
これがベストプラクティスかどうか疑問に思います。私は約2000万行あります。WRITE_TRUNCATE3分ごとに2,000万行にするのは賢明ではないようです。
提案？
私たちは同じことをしています。ただし、パフォーマンスを向上させるには、テーブルをでパーティション化しdate_purchased、クラスターを作成してみてくださいorderid。事後にパーティションを追加することはできないため、CTASステートメントを（テーブル自体に）使用します。
編集：2つのテーブルとマージを使用します
特定のユースケース、つまり古いものと新しいものの間で更新できるフィールドの数に応じて、たとえばstage_table_ordersインポートされたレコードとfinal_table_orders宛先テーブルとして2つのテーブルを使用し、次のようにすることができますMERGE。
MERGE final_table_orders F
USING stage_table_orders S
ON F.orderid = S.orderid AND
F.date_purchased = S.date_purchased
WHEN MATCHED THEN
UPDATE SET field_that_change = S.field_that_change
WHEN NOT MATCHED THEN
INSERT (field1, field2, ...) VALUES(S.field1, S.field2, ...)
プロ：数行は（テストされていませんが）、ない何百万人を「アップサート」されている場合は+プルーニングパーティションが効率的にすべき仕事。
短所：更新句と挿入句のフィールドを明示的にリストする必要があります。スキーマがほぼ修正されている場合は、1回限りの作業。
重複を排除する方法はいくつかあり、万能な方法はありません。SOで、、ARRAY_AGGまたはEXISTSwithDELETEまたはUNION ALL、...を使用して同様のリクエストを検索します。それらを試して、データセットに対してどちらが優れているかを確認してください。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加