注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

データセット

データセットは、データが Foundry に登録されるときからオントロジーにマッピングされるときまでのデータの最も基本的な表現です。基本的に、データセットはバッキングファイルシステムに保存された一連のファイルのラッパーです。Foundry のデータセットを使用する利点は、パーミッション管理、スキーマ管理、バージョン管理、時間経過による更新を統合的にサポートしていることです。このドキュメントの残りの部分で、この機能の背後にある概念を詳しく説明します。

Foundry のデータ統合レイヤーでは、データセットはすべての種類のデータ - 構造化、非構造化、半構造化 - を保存し表現するために使用されます：

構造化（表形式）データは、Parquetのようなオープンソースの形式で表形式のデータを含むファイルで構成されています。このメタデータは、データセットと一緒にスキーマとして保存されます。
非構造化データセットは、画像、ビデオ、PDFなどのファイルで構成されていますが、関連するスキーマはありません。
半構造化データセットは、XMLやJSONのようなファイル形式を含んでいます。これらのファイル形式にスキーマを適用することは可能ですが、パフォーマンスと使いやすさのために、下流のデータ変換で表形式のスキーマを推測することが推奨されます。

トランザクション

データセットは時間の経過と共に変化するように設計されています。Foundry でデータセットを開いて行と列を見るとき、実際に見ているのは データセットビュー — データセットの特定の時点での内容です。

エンドユーザーとして、通常はビルドを使用してデータセットを変更します。これにより、ユーザーが指定したロジックに従ってデータセットの内容を更新できます。しかし、裏側では、データセットはトランザクションを使用して時間経過とともに更新されます。トランザクションは、データセット内のファイルへの変更を表します。トランザクションのライフサイクルは単純です：

トランザクションが開始されると、OPEN状態になります。この状態では、データセットのバッキングファイルシステムでファイルを開いて書き込むことができます。
トランザクションをコミットすることができます。これにより、トランザクションはCOMMITTED状態となり、書き込まれたファイルは最新のデータセットビューに表示されます。
トランザクションをアボートすることができます。これにより、トランザクションはABORTED状態となります。トランザクション中に書き込まれたファイルは無視されます。

もしあなたがソフトウェアエンジニアであれば、Gitに馴染みがあるかもしれません。データセットトランザクションは、Foundry のデータバージョン管理のサポートの基盤であり、"データのための Git"とも呼ばれます。トランザクションは Git のコミットに相当します：データセットの内容に対する原子的な変更です。

トランザクションの種類

トランザクションにおけるデータセットファイルの変更方法は、トランザクションの種類によります。トランザクションの種類には4つの可能性があります：SNAPSHOT、APPEND、UPDATE、そしてDELETEです。

`SNAPSHOT`

SNAPSHOTトランザクションは、データセットの現在のビューを完全に新しいファイルセットで置き換えます。

SNAPSHOTトランザクションは最も単純なトランザクションタイプであり、バッチパイプラインの基礎です。

`APPEND`

APPENDトランザクションは、新しいファイルを現在のデータセットビューに追加します。

APPENDトランザクションでは、現在のデータセットビューにある既存のファイルを変更することはできません。APPENDトランザクションが開始されて既存のファイルが上書きされた場合、トランザクションのコミットを試みると失敗します。

APPENDトランザクションは、インクリメンタルパイプラインの基礎です。新しいデータのみを Foundry に同期し、この新しいデータのみをパイプライン全体で処理することで、大規模なデータセットの変更をパフォーマントにエンドツーエンドで処理することができます。ただし、インクリメンタルパイプラインの構築と維持には追加の複雑さが伴います。インクリメンタルパイプラインについて詳しくはこちらをご覧ください。

`UPDATE`

UPDATEトランザクションは、APPENDと同様に新しいファイルをデータセットビューに追加しますが、既存のファイルの内容を上書きすることも可能です。

`DELETE`

DELETEトランザクションは、現在のデータセットビューにあるファイルを削除します。

DELETEトランザクションをコミットしても、バッキングファイルシステムから基本ファイルが削除されるわけではありません。データセットビューからファイル参照が削除されるだけです。

実際には、DELETEトランザクションは主にデータ保持ワークフローを可能にするために使用されます。保持ポリシーに基づいてデータセットのファイルを削除することで、ファイルの年齢に基づいて通常は、データを Foundry から削除することができます。これにより、ストレージのコストを最小限に抑え、データガバナンスの要件を満たすことができます。

トランザクションタイプの例

データセットのブランチに対する以下のトランザクション履歴を想像してみてください。最も古いものから始まります：

SNAPSHOT にはファイル A と B が含まれています
APPEND でファイル C を追加
UPDATE でファイル A の内容を A' に変更
DELETE でファイル B を削除

この時点で、現在のデータセットビューには A' と C が含まれています。もし5番目の SNAPSHOT トランザクションを追加してファイル D を含めた場合、現在のデータセットビューには D のみが含まれます（SNAPSHOT トランザクションは新しいビューを開始するため）そして、最初の4つのトランザクションは古いビューになります。

保持

DELETEトランザクションがバッキングファイルシステムから古いデータを実際には削除しないため、不要となったトランザクション内のデータを削除するために保持ポリシーを使用できます。

データセットの保持ポリシーを表示 [ベータ]

ベータ機能

これはベータ機能であり、お使いの Foundry インスタンスでは使用できない場合があります。詳細については、Palantir の担当者にお問い合わせください。

特定のデータセットに現在適用されている保持ポリシーを表示するには、データセット詳細ページに移動します。

保持ポリシー部分のスクリーンショット

ブランチ

データセットのトランザクションはデータセットの内容が時間の経過と共に変化することを可能にするように設計されていますが、共同作業 — 複数のユーザーが同時にデータセットへの変更を試行できるようにするためには、追加の機能が必要です。データセットのブランチは、これらのワークフローを可能にするように設計されています。

Foundry でのブランチングについては、個々のデータセットだけでなく、パイプライン全体にわたるブランチングについても、ブランチング概念ページを参照してください。

スキーマ

スキーマはデータセットビューに対するメタデータであり、ビュー内のファイルがどのように解釈されるべきかを定義します。これには、ビュー内のファイルがどのように解析されるべきか、また、ファイル内の列やフィールドがどのように命名されるべきか、または型付けされるべきかが含まれます。Foundry で最も一般的なスキーマは表形式であり、データセット内の列、その名前およびフィールドタイプを説明します。

データセット内のファイルが指定されたスキーマに実際に準拠していることは保証されません。たとえば、CSVファイルを含むデータセットにParquetスキーマを適用することが可能です。この場合、データセットの内容を読み取ろうとするクライアントアプリケーションは、一部のファイルがスキーマに準拠していないという事実によってエラーが発生します。

スキーマはデータセットビューに保存されるため、スキーマは時間の経過とともに変化することができます。これは便利な機能です。なぜなら、データセットの内容は構造的に時間の経過とともに変化する可能性があるからです。たとえば、新しいトランザクションが表形式のデータセットに新しい列を導入したり、フィールドのタイプを変更したりする場合があります。

Foundry では、データセットプレビューアプリケーションの任意のデータセットでスキーマを表示できます。詳細タブに移動してスキーマを選択します。

サポートされているフィールドタイプ

以下はデータセットで利用可能なフィールドタイプのリストです：

BOOLEAN
BYTE
SHORT
INTEGER
LONG
FLOAT
DOUBLE
DECIMAL
STRING
MAP
ARRAY
STRUCT
BINARY
DATE
TIMESTAMP

いくつかのフィールドタイプは追加のパラメーターが必要です：

DECIMAL はprecision と scale が必要です。これらのパラメーターの設定がわからない場合、デフォルトで precision: 38 と scale: 18 が良いでしょう。 38 は可能な精度値の最大値です。
MAP はmapKeyType と mapValueType が必要で、これらは両方ともフィールドタイプです。
ARRAY はarraySubType が必要で、これはフィールドタイプです。
STRUCT はsubSchemas が必要で、これはフィールドタイプのリストです。

上記に示したフィールドタイプについての詳細情報、説明や例については、Spark data types documentation（外部）をご覧ください。

スキーマのオプション

Dataset Preview の詳細タブの スキーマ セクションでは、スキーマメタデータの下部にある options ブロックで、CSVファイルのオプションの解析設定を追加することができます。サポートされているオプションのリストについては、Spark CSV DataFrameReader documentationを参照してください。設定は次のようにキーと値のペアとして追加できます：

Copied!1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
"dataFrameReaderClass": "com.palantir.foundry.spark.input.TextDataFrameReader",
  // データフレームリーダークラスの設定
  "customMetadata": {
    "textParserParams": {
      "parser": "CSV_PARSER",
      // CSVパーサーを指定
      ...
    },
    "options": {
      "unescapedQuoteHandling": "STOP_AT_DELIMITER",
      // エスケープされていないクォート処理:デリミタで停止
      "multiline": true,
      // 複数行の設定
      ...
    }
  }

上記のスキーマオプションは、CSV ファイルから構築されたデータセットにのみ適用可能であることに注意してください。

ファイル形式

スキーマには、データセット内のファイルの基礎となるストレージ形式に関する情報が含まれています。最も広く使用されている形式は次の 3 つです：

Parquet
Avro
Text

Text ファイル形式は、多種多様な CSV 形式や JSON ファイルを含む、広範なファイルタイプを表現するために使用できます。Text がどのようにパースされるべきかについての追加情報は、customMetadata というスキーマフィールドに格納されます。

実際には、JSON や XML などの非表形式については、ファイルを構造化されていない（スキーマレスの）データセットに保存し、スキーマ推論ドキュメンテーションで説明されているように、下流のデータ変換でスキーマを適用することを推奨します。

バッキングファイルシステム

データセット内で追跡されるファイルは、Foundry 自体には保存されません。代わりに、ファイルの 論理パス と Foundry 内と、その 物理パス との間のバッキングファイルシステムのマッピングが維持されます。Foundry のバッキングファイルシステムは、Hadoop ファイルシステムのベースディレクトリで指定されます。これは自己ホスト型の HDFS クラスターであることもありますが、一般的には Amazon S3 などのクラウドストレージプロバイダーを使用して設定されます。すべてのデータセットファイルは、バッキングファイルシステムのベースディレクトリの下のフォルダー階層に保存されます。