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

データセット

データセットは、Foundry に取り込まれてから オントロジー にマッピングされるまでのデータの最も基本的な表現です。基本的に、データセットは バックファイルシステム に格納されているファイルのコレクションをラップするものです。Foundry データセットを使用する利点は、権限管理、スキーマ管理、バージョン管理、および時間経過に伴う更新の統合サポートを提供することです。この機能の基本概念については、このドキュメントの残りの部分で説明します。

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

  • 構造化(表形式)データは、Parquet ↗ などのオープンソース形式で表形式データを含むファイルと、データセット内の列に関するメタデータで構成されます。このメタデータはデータセットと共に スキーマ として保存されます。
  • 非構造化データセットは、画像、ビデオ、または PDF などのファイルで構成されており、関連付けられたスキーマはありません。
  • 半構造化データセットは、XML や JSON などのファイル形式を含みます。これらのファイル形式にスキーマを適用することは可能ですが、パフォーマンスと使いやすさのために、下流のデータトランスフォーメーションで 表形式スキーマを推論 することが望ましいです。

トランザクション

データセットは時間と共に変化するように設計されています。Foundry でデータセットを開いて行と列を表示するとき、それは実際には最新の データセットビュー です。

エンドユーザーとしては、通常 ビルド を使用してデータセットを変更し、指定したロジックに従ってデータセットの内容を更新します。しかし、実際にはデータセットは トランザクション を使用して時間と共に更新され、これによりデータセット内のファイルが変更されます。トランザクションにはシンプルなライフサイクルがあります。

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

ソフトウェアエンジニアであれば、Git に精通しているかもしれません。データセットトランザクションは、データバージョン管理のサポートの基盤であり、時には「データの Git」とも呼ばれます。トランザクションは Git の コミット に類似しており、データセットの内容に対するアトミックな変更です。

トランザクションタイプ

トランザクションでデータセットファイルが変更される方法は、トランザクションタイプに依存します。トランザクションタイプには、SNAPSHOTAPPENDUPDATEDELETE の 4 種類があります。

SNAPSHOT

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

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

APPEND

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

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

APPEND トランザクションは インクリメンタルパイプライン の基盤です。新しいデータのみを Foundry に同期し、この新しいデータのみをパイプライン全体で処理することで、大規模なデータセットの変更を効率的に処理できます。しかし、インクリメンタルパイプラインの構築と維持には追加の複雑性が伴います。インクリメンタルパイプラインの詳細はこちら。

UPDATE

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

DELETE

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

DELETE トランザクションをコミットしても、バックファイルシステムから基礎となるファイルが削除されることはありません。単にデータセットビューからファイルのリファレンスが削除されるだけです。

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

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

次のようなデータセットのブランチのトランザクション履歴を想像してください(最も古いものから始めます):

  1. SNAPSHOT はファイル AB を含む
  2. APPEND はファイル C を追加する
  3. UPDATE はファイル AA' に変更する
  4. DELETE はファイル B を削除する

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

保持

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

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

ベータ機能

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

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

Retention policies section screenshot

ブランチ

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

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

データセットビュー

データセットビューは、ある時点でのブランチのデータセットの有効なファイル内容を表します。履歴ビューはデータセットの履歴バージョンに類似しています。ビューに含まれるファイルを計算するには:

  1. 空のファイルセットから始めます。
  2. ある時点でのビューは、その時点の前の最新の SNAPSHOT トランザクションから始まります。SNAPSHOT トランザクションが存在しない場合は、データセットの最も早いトランザクションを代わりに取ります。
  3. ビュー内の最初のトランザクション、およびその後の各トランザクションについて以下を行います:
    • SNAPSHOT(最初のトランザクションのみ)または APPEND トランザクションの場合、トランザクションのすべてのファイルをセットに追加します。
    • UPDATE トランザクションの場合、トランザクションのすべてのファイルをセットに追加し、既存のファイルを置き換えます。
    • DELETE トランザクションの場合、トランザクション内のすべてのファイルをセットから削除します。

結果として得られるファイルセットがデータセットビューを構成します。

データセットが SNAPSHOT トランザクションのみを含む場合、ビューの数はトランザクションの数に等しくなります。インクリメンタルデータセットの場合、ビューの数は SNAPSHOT トランザクションの数に等しくなります。

ビューは複数のブランチからのトランザクションを含むことがあります。たとえば、master ブランチの SNAPSHOT といくつかの APPEND トランザクションを含むインクリメンタルデータセットの場合、これらのトランザクションはブランチ上のデータセットビューの開始を形成し、ブランチ上の後続のトランザクションも APPEND(または厳密には SNAPSHOT 以外の)トランザクションである場合に適用されます。

スキーマ

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

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

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

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

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

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

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

一部のフィールドタイプには追加のパラメーターが必要です:

  • DECIMAL には precisionscale が必要です。これらのパラメーターを設定する際に不明な場合は、precision: 38scale: 18 をデフォルトとして設定することをお勧めします。38 は最大の精度値です。
  • MAP には mapKeyTypemapValueType が必要であり、これらは両方ともフィールドタイプです。
  • ARRAY には arraySubType が必要であり、フィールドタイプです。
  • STRUCT には subSchemas が必要であり、フィールドタイプのリストです。

上記のフィールドタイプに関する詳細な情報、説明、および例については、Spark データタイプドキュメント ↗ を参照してください。

スキーマオプション

Dataset Preview の 詳細 タブの スキーマ セクションでは、スキーマメタデータの options ブロックに CSV ファイルのオプションの解析設定を追加できます。詳細については、CSV 解析 のドキュメントを参照してください。

ファイル形式

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

  • Parquet
  • Avro
  • Text

Text ファイル形式は、さまざまな CSV 形式や JSON ファイルなど、さまざまなファイルタイプを表現するために使用できます。Text の解析方法に関する追加情報は customMetadata というスキーマフィールドに保存されます。

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

バックファイルシステム

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