Documentation
ドキュメントの検索
karat

+

K

APIリファレンス ↗
データ接続と統合基本概念データセット

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

データセット

データセットは、データが Foundry に取り込まれてからオントロジーにマッピングされるまでの間、データを表現する最も基本的なリソースです。基本的に、データセットは基盤ファイルシステムに保存されたファイルをまとめるラッパーです。Foundry データセットを使用する利点は、権限管理、スキーマ管理、バージョン管理、継続的な更新を統合的にサポートすることです。このドキュメントの残りの部分では、これらの機能の基礎となる概念を詳しく説明します。

Foundry のデータ統合レイヤーでは、構造化データ、非構造化データ、半構造化データを問わず、すべての種類のデータをデータセットに保存し、表現できます。

  • 構造化（表形式）データは、Parquet ↗ などのオープンソース形式の表形式データを含むファイルと、データセットの列に関するメタデータで構成されます。このメタデータは、スキーマとしてデータセットとともに保存されます。
  • 非構造化データは、関連付けられたスキーマを持たないファイルで構成されます。たとえば、顧客サポートのメールなどの表形式ではないファイルや、画像、動画、PDF ドキュメントなどのメディアファイルが含まれます。Foundry には、非構造化データを保存する方法が2つあります。スキーマのないデータセットとして保存する方法と、メディアワークフローに最適化された別のリソースタイプであるメディアセットとして保存する方法です。Foundry で非構造化データを手動でアップロードする場合は、メディアセットとしてアップロードまたはスキーマなしでデータセットにアップロードを選択できます。
  • 半構造化データは表形式ではありませんが、ある程度の整理に役立つタグやメタデータを含むことができます。たとえば、XML や JSON などのファイル形式が該当します。半構造化データ専用のアップロードの選択肢はありません。代わりに、これらのファイルをスキーマのないデータセットにアップロードし、下流のデータ変換で表形式のスキーマを推論することで、パフォーマンスと使いやすさを向上できます。

トランザクション

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

エンドユーザーは通常、ビルドを使用してデータセットを変更します。ビルドでは、指定したロジックに従ってデータセットの内容を更新できます。ただし、その背後では、データセット内のファイルへの変更を表すトランザクションを使用して、データセットが継続的に更新されています。トランザクションのライフサイクルはシンプルです。

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

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

トランザクションの種類

トランザクションでデータセットのファイルがどのように変更されるかは、トランザクションの種類によって異なります。トランザクションには、SNAPSHOT、APPEND、UPDATE、DELETE の4種類があります。

SNAPSHOT

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

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

APPEND

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

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

APPEND トランザクションは、インクリメンタル（差分処理）パイプラインの基盤となります。新しいデータのみを Foundry に同期し、パイプライン全体でこの新しいデータのみを処理することで、大規模なデータセットへの変更をエンドツーエンドで効率よく処理できます。ただし、インクリメンタルパイプラインの構築と保守には、さらなる複雑さが伴います。インクリメンタルパイプラインについて詳しくはこちら。

UPDATE

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

既存のファイルの内容を上書きする UPDATE トランザクションは、インクリメンタルパイプラインの APPEND のみという要件に違反します。データセットにこのような UPDATE トランザクションが適用されると、下流のパイプラインはデータをインクリメンタルに処理できなくなり、SNAPSHOT（バッチ）処理に切り替える必要があります。

既存のファイルを上書きせず、新しいファイルのみを追加する UPDATE トランザクションは、インクリメンタル処理に影響しません。ほかに方法がない場合を除き、UPDATE トランザクションで既存のファイルを上書きしないでください。詳細については、インクリメンタルトランスフォームと APPEND のみの入力を参照してください。

外部システムからデータを取り込むためにファイルベースの同期を設定する際、選択したトランザクションの種類によって、パイプライン内のデータの流れ方が決まります。一般的な取り込みパターンは次の3つです。

  • **バッチミラー（SNAPSHOT）：**同期を実行するたびにすべてのファイルを取り込み、SNAPSHOT トランザクションをコミットします。これは最もシンプルなパターンであり、ファイル全体のサイズが、実行のたびにフルロードできるほど小さい場合に適しています。
  • **インクリメンタルミラー（APPEND）：**同期を実行するたびに新しいファイルのみを取り込み、APPEND トランザクションをコミットします。このパターンはエンドツーエンドのインクリメンタルパイプラインをサポートし、ファイルが変更されず追加のみが行われる場合に推奨される方法です。
  • **インクリメンタルミラー（UPDATE）：**同期を実行するたびに新しいファイルと変更されたファイルを取り込み、UPDATE トランザクションをコミットします。このパターンでは下流のインクリメンタル処理ができなくなるため、外部システムが既存のファイルを変更する場合にのみ使用します。

フィルター設定や矛盾するオプションなど、これらのパターンの詳細な設定方法については、ファイルベースの同期を参照してください。

DELETE

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

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

実際には、DELETE トランザクションは主にデータ保持ワークフローを実現するために使用されます。保持ポリシー（通常はファイルの経過期間に基づくもの）に従ってデータセットのファイルを削除することで、Foundry からデータを削除し、ストレージコストを最小限に抑えるとともに、データガバナンスの要件に準拠できます。

トランザクションの種類の例

データセットのブランチに、古い順に次のトランザクション履歴があるとします。

  1. SNAPSHOT にファイル A と B が含まれています
  2. APPEND がファイル C を追加します
  3. UPDATE がファイル A を変更し、内容の異なる A' にします
  4. DELETE がファイル B を削除します

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

保持

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

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

ベータ版

データセットの保持ポリシーを表示する機能は、開発ライフサイクルのベータ版段階にあり、お使いのエンロールメントでは利用できない場合があります。開発が進むにつれて機能が変更される可能性があります。データセットの保持ポリシーの利用をご希望の場合は、Palantir サポートにお問い合わせください。

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

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

ブランチ

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

個々のデータセットとパイプライン全体の両方における Foundry のブランチ機能については、ブランチの概念ページを参照してください。

データセットビュー

データセットビューは、ある時点のブランチにおけるデータセットの実効的なファイル内容を表します。過去のビューは、データセットの過去のバージョンに相当します。ビューに含まれるファイルを特定するには、次の手順に従います。

  1. 空のファイル集合から始めます。
  2. ある時点のビューは、その時点より前の最新の SNAPSHOT トランザクションから始まります。SNAPSHOT トランザクションが存在しない場合は、代わりにデータセットの最初のトランザクションを使用します。
  3. ビュー内の最初のトランザクションと、それ以降の各トランザクションについて、次の操作を行います。
    • SNAPSHOT（最初のトランザクションのみ）または APPEND トランザクションの場合は、そのトランザクションのすべてのファイルを集合に追加します。
    • UPDATE トランザクションの場合は、そのトランザクションのすべてのファイルを集合に追加し、既存のファイルを置き換えます。
    • DELETE トランザクションの場合は、そのトランザクションに含まれるすべてのファイルを集合から削除します。

この結果のファイル集合がデータセットビューを構成します。

新しいビューは SNAPSHOT トランザクションでのみ始まるため、データセットの履歴内のビュー数は、その履歴に含まれる SNAPSHOT トランザクション数と等しくなります。データセットに SNAPSHOT トランザクションのみが含まれている場合、ビュー数はトランザクション数と等しくなります。インクリメンタル（差分処理）データセットの場合、APPEND、UPDATE、DELETE トランザクションは新しいビューを開始するのではなく、現在のビューを拡張するため、ビュー数は SNAPSHOT トランザクション数と等しいままです。

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

スキーマ

スキーマは、データセットビューのメタデータであり、ビュー内のファイルをどのように解釈するかを定義します。これには、ビュー内のファイルのパース方法や、ファイル内の列またはフィールドの名前とデータ型が含まれます。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 のデータ型のドキュメント ↗を参照してください。

スキーマのオプション

データセットプレビューの詳細タブにあるスキーマセクションでは、スキーマメタデータの下部にある options ブロックに、CSV ファイル用の任意のパース設定を追加できます。詳しくは、CSV のパースに関するドキュメントを参照してください。

ファイル形式

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

  • Parquet
  • Avro
  • Text

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

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

基盤ファイルシステム

データセット内で追跡されるファイルは、Foundry 自体には保存されません。代わりに、Foundry 内のファイルの論理パスと、基盤ファイルシステム内の物理パスの間の対応付けが維持されます。Foundry の基盤ファイルシステムは、Hadoop FileSystem ↗ 内のベースディレクトリによって指定されます。これはセルフホスト型の HDFS クラスターにすることもできますが、通常は Amazon S3 などのクラウドストレージプロバイダーを使用して設定されます。すべてのデータセットファイルは、基盤ファイルシステムのベースディレクトリ配下のフォルダー階層に保存されます。