# Palantir Foundryを学ぶ 🚀 数十億行のテーブルを毎日まるごと再計算していませんか。差分だけを処理すれば、コンピュート費は劇的に下がります。 📌 タイトルと機能のURL タイトル: インクリメンタル変換 URL: 📝 概要 インクリメンタル変換は、前回の実行以降に追加・変更されたデータだけを処理することで、効率的なデータ処理を実現する仕組みです。データセット全体を再処理する代わりに、差分のみを扱います。`@incremental()`デコレータを付けることで有効になり、入力の変化パターンに応じてインクリメンタル実行とスナップショット実行を自動的に切り替えます。 🔧 機能の説明 `@incremental()`デコレータは、トランスフォーム関数をラップして差分処理の能力を付与します。 ・標準の入出力オブジェクトを、`IncrementalTransformInput` / `IncrementalTransformOutput` / `IncrementalTransformContext` といったインクリメンタル版に変換します ・入力の読み取りモードは、`added`(前回以降の新規行・既定)/ `previous`(前回実行時の状態)/ `current`(現在のデータセット全体)を選べます ・出力の書き込みモードは、`modify`(既存出力に追記)/ `replace`(出力全体を上書き)があり、インクリメンタル時の既定は`modify`、スナップショット時は`replace`です ・主なパラメータには、`require_incremental`(差分実行不能なら失敗させる)、`semantic_version`(値を上げるとスナップショット再構築を誘発)、`snapshot_inputs`(特定入力を差分制約から除外)、`strict_append`(追記専用の安全性を強制)などがあります 🛠 実践的な使い方 ・追記中心の大規模ログ・トランザクションテーブルに`@incremental()`を付け、毎日のフル再計算を差分処理に置き換えます ・ロジックを変更したら`semantic_version`を上げ、安全にスナップショット再構築を走らせます ・全件再処理を許したくない場合は`require_incremental`で差分実行を強制します ・厳密な追記保証が必要な場面では`strict_append`を使います 🎯 ユースケース ・数十億行テーブルの毎日フル再計算によるコンピュート費高騰を、差分処理で大幅削減 ・大規模案件の採算性を左右するコスト最適化の中核技術として活用 ・追記専用の取引履歴・イベントログの日次取り込み ・上流が追加のみ(APPEND/UPDATE)で増えるパイプラインの効率化 ⚠️ 注意点 ・プレビュー機能は常に非インクリメンタルで実行されます ・すべての非スナップショット入力が「追加のみ(APPEND/UPDATEトランザクション)」である、入力リストが安定している、`semantic_version`が変わっていない、などの要件を満たさない限り、自動的にスナップショットモードで実行され出力が全置換されます ・更新・削除された入力ファイルはスナップショット入力としてマークする必要があります ・`previous`モードは前回出力の構造に一致するスキーマ検証を要します ・トランスフォームのロジックはインクリメンタルとスナップショットの両方の実行経路に対応している必要があります #PalantirFoundry# #DataEngineering#