FoundryがNetflix韓国ドラマ『おつかれさま』のVFX事例を公開─Nukeの2.5Dプロジェクション機能やトラッキングで歴史的な街並みを再構築

# Palantir Foundryを学ぶ 🚀 「このダッシュボードの数字、どこから来たの?」に即答できる。Data Lineageは、データの流れをまるごと可視化する探索ツールです。 📌 タイトルと機能のURL タイトル: データリネージ URL: 📝 概要 Data Lineageは、Foundryプラットフォーム上をデータがどう流れるかを包括的に示すインタラクティブな可視化ツールです。データの移動・依存関係・変換を、データエコシステム全体にわたって理解できます。ソースからパイプライン、オントロジー、アプリへと続く系譜をグラフとして辿れるため、障害対応や監査説明のコストを大きく下げられます。 🔧 機能の説明 グラフベースのビジュアライゼーションでデータの依存関係を表現します。 ・プロジェクト名・テーブル識別子・行ラベルを使ってデータセットを検索でき、Foundry Projects上から直接データを閲覧できます ・任意のデータセットについて、上流(祖先)と下流(子孫)の関係を展開・折りたたみできます ・複数のテーブル属性を同時に表示し、スキーマ詳細・ビルドのタイムスタンプ・ソースコードまで確認できます ・カスタムのカラースキームを適用して、古くなった(stale)データセットなどパイプラインの特性を強調できます ・共有可能なパイプラインのスナップショットを作成し、チーム内で共有できます 🛠 実践的な使い方 ・ダッシュボードや出力データセットから上流をたどり、数字の出所(ソース)を特定します ・上流のスキーマ変更があった際に、下流をたどって影響範囲を洗い出します ・カラースキームで古いデータセットを色分けし、放置されたパイプラインを発見します ・高レベルの全体像から、変換コードや実行履歴といった粒度の細かい技術詳細へドリルダウンします ・パイプラインのスナップショットを共有してデータワークフローを部門横断で文書化します 🎯 ユースケース ・「このダッシュボードの数字の出所」を即座に回答 ・上流スキーマ変更の影響範囲を事前に特定し、障害を未然に防止 ・監査時にデータの系譜を提示して説明コストを削減 ・古い・未使用のデータセットを発見してパイプラインを整理 ⚠️ 注意点 ・本概要ページでは、極端に大規模なパイプラインでのパフォーマンスやグラフの複雑さに関する制約は明示されていません ・リネージはFoundryプラットフォーム内のデータフローを対象とし、プラットフォーム外の処理は可視化の範囲外となります ・系譜の正確さは、変換やパイプラインがFoundry上で適切に構成されていることに依存します #PalantirFoundry# #DataLineage#

# 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#

# Palantir Foundryを学ぶ 🚀 ノーコードでは届かない複雑なロジックを、ソフトウェア工学の品質管理ごとデータ基盤に持ち込む。それがCode Repositoriesです。 📌 タイトルと機能のURL タイトル: Code Repositories(Pythonトランスフォーム) URL: 📝 概要 Code Repositoriesは、Foundry内で本番品質のコードを作成・協働するためのWebベースの統合開発環境(IDE)です。基盤にあるGitリポジトリをブラウザのUIから操作でき、コマンドライン無しでチーム開発を進められます。プラットフォーム固有の機能を備え、データエンジニアリングにソフトウェア開発の作法をそのまま適用できます。 🔧 機能の説明 バージョン管理とコラボレーションが中核です。 ・ブランチ作成・コミット・リリースタグ付けといったGit操作をWeb UIから実行できます ・プルリクエスト(PR)でコードレビューを行い、権限は「高度に設定可能」でレビュー必須化などの品質保証を支えます ・IntelliSense、リンティング、エラーチェック、文脈に応じたヘルプダイアログがすべてのリポジトリ種別で利用できます ・Transformsリポジトリでは、Python・Java・SQLでのデータ変換ロジックを記述し、プレビューとデバッグが可能です ・FunctionsリポジトリはオントロジーをネイティブにサポートしTypeScript/Pythonで低レイテンシのビジネスロジックを実装できます 🛠 実践的な使い方 ・PySparkを用いて、数十億行規模の名寄せや複雑な業務ルールをコードで実装します ・PRレビューを必須に設定し、マージ前に第三者の確認とCIチェックを通すことを強制します ・ユニットテストを組み込み、変換ロジックの回帰を防ぎます ・Functionsリポジトリでは、オントロジーのデータ型に基づくオートコンプリートを活かして安全にロジックを記述します ・モデル開発リポジトリで機械学習ワークフローもプラットフォーム内に取り込みます 🎯 ユースケース ・Pipeline Builderでは表現しきれない複雑な名寄せ・業務ルールをPySparkで実装 ・「本番直編集によるデグレ」を、レビュー必須化とブランチ運用で構造的に排除 ・派生KPIや検証ロジックをFunctionsとして実装し、各アプリから再利用 ・MLモデルの学習・推論コードをガバナンス下で管理 ⚠️ 注意点 ・ドキュメントの日本語訳は機械生成で未検証である旨が記載されており、ローカライズ内容には精度上の限界がある可能性があります ・リポジトリ種別(Transforms/Functions/Model)ごとに対応言語や用途が異なるため、目的に合った種別を選ぶ必要があります ・プロコード環境ゆえ、レビュー・CI・テストの運用ルールを組織として整備しないと品質管理の効果が出ません #PalantirFoundry# #DataEngineering#

# Palantir Foundryを学ぶ 🚀 「閉域網のオンプレOracleやSAPに、ファイアウォールに穴を開けずどう繋ぐ？」エンタープライズ導入の最初の関門を突破するのがData Connectionです。 📌 タイトルと機能のURL タイトル: Data Connection URL: 📝 概要 Data Connectionは、外部システムのデータをFoundryに同期し、データ統合・モデリング・オントロジーの各レイヤーで利用できるようにするアプリケーションです。Webhookやデータエクスポートによる外部システムへの書き戻し（アウトバウンド）にも対応します。多数のソースタイプに対応し、認証・スケジュール・監視といった煩雑な部分を抽象化して、シンプルな画面からパイプラインを構成できます。 🔧 機能の説明 Foundryのデータ接続は、3つの原則に沿って標準化されています。 ・堅牢性: 自動リトライ、小さなバッチ単位での処理、ヘルス監視による障害警告を備えます。データは「最も原始的なソースからそのまま（as-is）」取り込み、Foundryのバージョン管理されたパイプラインを唯一の正（single source of truth）とすることで、外部前処理に依存しません ・拡張性: データベース、FTPS、HDFS、S3、SFTPなどの標準連携に加え、新しいソースタイプにも対応できます。スケジューリングやオーケストレーションといった中核機能は標準化されているため、接続固有の調整だけで済みます ・使いやすさ: 複雑さを抽象化し、認証・スケジュール・監視を手作業で管理する代わりに、シンプルなインターフェースで構成できます ・主要な構成要素として、エージェントのセットアップ、ソース構成、バッチ／ストリーミングの同期、Webhook、エクスポートを備えます 🛠 実践的な使い方 ・ワークスペースのナビゲーションまたはアプリケーションポータルからData Connectionにアクセスします ・接続先（ソース）を構成し、バッチまたはストリーミングの同期（sync）を設定して、データを「そのまま」取り込みます ・取り込み後の変換はFoundry側のパイプラインに集約し、ソース側では前処理を行わないようにします ・書き戻しが必要な場合は、Webhookやエクスポートでアウトバウンド連携を構成します 🎯 ユースケース ・閉域網のオンプレOracle/SAPを、エージェント方式（アウトバウンドのみで成立）でFW穴あけなしに接続 ・データベース・SFTP・S3など多様なソースからの定期バッチ取り込み ・処理結果を外部システムへ書き戻すアウトバウンド連携 ⚠️ 注意点 ・データはソースから「as-is」で取り込み、変換はFoundryのパイプラインに寄せる設計が前提です。ソース側で加工すると追跡性が損なわれます ・エージェントやソースの構成には、ネットワーク・認証の適切な準備が必要です ・X APIなど外部サービスの上限や規約は仮定せず、接続先ごとの制約を事前に確認してください #PalantirFoundry# #DataIntegration#

# Palantir Foundryを学ぶ 🚀 「営業は自分の担当顧客の行だけ見える」を、データセットを部門ごとにコピーすることなく実現する仕組み。それが制限付きビュー（行レベルセキュリティ）です。 📌 タイトルと機能のURL タイトル: 制限付きビュー(行レベルセキュリティ) URL: 📝 概要 制限付きビュー（Restricted Views）は、1つの基盤データセットの上に構築される、行レベルのアクセス制御の仕組みです。同じ元データに対して、閲覧するユーザーごとに見える行のサブセットを変えられます。これにより「部門別にデータをコピーして配る」運用をやめ、単一データセットを正として全社で共有しながら、権限だけを行単位で分けられます。 🔧 機能の説明 制限付きビューは、行の可視性を決めるルールを持つ「ポリシー」によって動作します。 ・ポリシーは、閲覧ユーザーの属性、基盤データセットの列名、特定の値（文字列・真偽値・数値・配列）を評価して、どの行を見せるかを判定します ・ユーザー・グループ・組織を参照する場合は、名前ではなく一意の識別子（UUID）をポリシー列とポリシー定義の両方で指定する必要があります ・マーキング連携型では、上流データセットにマーキングIDの文字列配列の列を持たせ、各行は必要なマーキングを持つユーザーにのみ表示されます ・制限付きビューは基盤データセットの上に構築され、トランスフォーム（変換）の入力としては使用できません ・ポリシー変更の追加・マージを扱う実験的なブランチ対応も提供されています 🛠 実践的な使い方 ・基盤データセットに、各行のアクセス可否を判定するための列（担当拠点、組織IDなど）を用意します ・その列とユーザー属性を突き合わせるポリシーを定義し、行レベルのフィルタを構成します ・権限管理を明確にするため、制限付きビューは元データセットとは別のプロジェクトに保存するのが一般的です ・マーキングを使う場合は、行ごとに必要なマーキングIDの配列を持たせて可視性を制御します 🎯 ユースケース ・営業担当が、自分の担当拠点の顧客行のみを閲覧できるようにする ・部門・組織単位で、同一テーブル上のレコードを分離して見せる ・機密度の異なるレコードを、マーキング保有者だけに開示する ⚠️ 注意点 ・制限付きビューはトランスフォームの入力に使えないため、下流のパイプライン処理に直接組み込めません ・ユーザー・グループ・組織はUUIDで指定する必要があり、名前指定では機能しません ・ブランチによるポリシー変更のマージは実験的機能であり、環境によっては利用できない場合があります #PalantirFoundry# #DataGovernance#

# Palantir Foundryを学ぶ 🚀 「この顧客の情報、結局どの画面を何枚開けば全部わかるの？」という現場の悩みを一発で解消するのがオブジェクトビューです。1つのオブジェクトに関わる情報と操作を、1画面に束ねます。 📌 タイトルと機能のURL タイトル: オブジェクトビュー URL: 📝 概要 オブジェクトビューは、特定のオブジェクトに関するあらゆる情報とワークフローを集約する中心的なハブです。プロパティ、関連リンク先のオブジェクト、メトリクスや分析、ダッシュボード、そして業務アプリケーションを1つの統合インターフェースにまとめます。たとえば「空港」オブジェクトのビューであれば、フライトのタイムライン、遅延対応のワークフロー、位置情報を1画面で扱えるようになります。現場ユーザーが日々最初に開く「業務のホーム画面」として機能します。 🔧 機能の説明 オブジェクトビューは、ビルダーが柔軟に設計・カスタマイズできる構成になっています。 ・複数のフォーマットやサイズに対応し、用途に応じて見た目や操作パターンを設計できます ・プロパティ（属性）、関連リンク先のオブジェクト、メトリクス、分析、ダッシュボードを統合して表示できます ・プラットフォーム全体の各所に埋め込んで配置できます ・設定はOntology Managerの「オブジェクトビュー」タブから行い、ビュー上部のタブでフォーマットのバージョンを切り替えられます ・「ビューを編集」を選ぶと、構成エディタや背後のWorkshopモジュールにアクセスできます ・バージョン管理、パネルのバリエーション、コメント機能、Marketplace製品との連携にも対応しています 🛠 実践的な使い方 ・Ontology Managerで対象のオブジェクトタイプを選び、「オブジェクトビュー」タブからプレビューと設定を行います ・基本情報、関連オブジェクト、操作履歴、埋め込みダッシュボードをレイアウトして、現場が必要とする情報を1画面にまとめます ・閲覧だけでなく、アクションタイプを組み込むことで、ビューから直接ステータス変更や割当などの操作を実行できる導線を作れます ・複数フォーマットを用意し、役割（例: 営業向け／保全担当向け）に応じた見せ方を切り替えます 🎯 ユースケース ・顧客360: 取引履歴・問い合わせ・関連注文・担当者を1画面に集約した営業の起点画面 ・設備カルテ: センサー値・保全履歴・関連部品・対応中チケットをまとめた保全担当のホーム画面 ・案件管理: 案件オブジェクトに対し、関係者・期日・承認状況・次アクションを一望 ⚠️ 注意点 ・ビューはオントロジーのモデリング（オブジェクトタイプ・リンクタイプ）の品質に依存します。土台が弱いと良いビューは作れません ・情報を詰め込みすぎると現場が迷うため、役割ごとに見せる項目を絞る設計が重要です ・編集にはOntology Managerおよび背後のWorkshopモジュールへの適切な権限が必要です #PalantirFoundry# #DataPlatform#

# Palantir Foundryを学ぶ 🚀 ビジネスロジックをオントロジーに常駐させる。ファンクションは「部門間で数字が合わない」問題を、ロジックの一元化で根治します。 📌 タイトルと機能のURL タイトル: ファンクション URL: 📝 概要 ファンクションは、隔離された環境でサーバーサイドのロジックを実行する仕組みです。ダッシュボードや意思決定支援といったオペレーショナルアプリを支えます。Foundryのオントロジーと連携して動くよう設計されており、オブジェクトのプロパティ読み取り、リンクの走査、柔軟なオントロジー編集が行えます。 🔧 機能の説明 ・対応言語: TypeScript(フル機能対応)と Python(ベータ、特にサーバーレス/デプロイ実行で対応が拡大中)をサポートします。 ・サーバーレス実行: 呼び出し時にオンデマンドで起動し、実行時のみ課金されます。合計60秒のウォールクロックタイムアウト(CPU30秒+ネットワーク30秒)があります。複数バージョンを同時稼働でき、アップグレードを安全にします。 ・デプロイ実行: 専有リソースを確保する方式で、サーバーレスで要件を満たせない場合に有効です。単一バージョンを稼働させ、デプロイ中は継続課金されます。 ・機能差: オントロジーの読み書きやWorkshop連携・外部API呼び出しは両言語で可能。Pipeline BuilderはPython、モデル埋め込みやセマンティック検索はTypeScriptが対応します。 🛠 実践的な使い方 ・派生プロパティ: 計算列としてファンクションで算出した値を表示します。 ・ファンクション付きアクション: 複数オブジェクトにまたがる複雑な編集を実装します。 ・Workshop連携: 変数の計算や表示のためにファンクションを実行します。 ・APIゲートウェイ: クエリ系ファンクションをプログラムから呼び出し、同一ロジックを再利用します。 🎯 ユースケース ・派生KPIの算出ロジックを一元実装し、Workshop/OSDK/APIから同じ結果を返す。 ・外部システムを照会してオントロジーのオブジェクトをエンリッチする。 ・複雑な検証や一括更新を、ファンクション付きアクションとして実装する。 ⚠️ 注意点 ・60秒のタイムアウトが全実行モードに一律適用されるため、効率的な実装が求められます。 ・呼び出しコンテキストにより利用可能な機能が変わります(例: モデル埋め込みやセマンティック検索はTypeScriptのみ)。言語選定は早めに見極めてください。 #PalantirFoundry# #DataEngineering#