注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
推奨されるプロジェクトとチームの構成
このページでは、Foundry でプロジェクトを使用してデータパイプラインを構成し、次のことを実現するための推奨方法を説明します。
- パイプライン全体にわたる適切に構成された権限
- ロール間の効果的なコラボレーション
- 理解しやすく、保守しやすいパイプライン構成
また、本番環境でパイプラインを適切に管理するために必要なロールと責任についても説明します。
ここでは、パイプラインのさまざまな段階と、それぞれの目的について概念的な概要を説明します。Foundry でこの構成を設定する方法を順を追って説明したガイドについては、プラットフォームセキュリティのドキュメントのデータ基盤を保護するを参照してください。
プロジェクトの境界
プロジェクトは、Foundry 内のデータとコードを整理する手段です。特定の作業範囲で共同作業を行う個人やチームのアクセスと権限を管理する主要な単位となります。また、プロジェクトには、プロジェクトのアクティビティのイベントログ、プロジェクトのドキュメントを記載するスペース、プロジェクトのリソース消費量や計算処理のメトリクスなどのメタデータを記録し、共有するための機能があります。
優れたプロジェクトの条件を考える際には、優れたマイクロサービスの条件を参考にしてください。目的が明確に定義されていること、下流の依存関係で使用される出力データセットや API が明確であること、そして、互いに効果的に連携し、プロジェクト管理の独自の基準を定められる程度の少人数で所有することが重要です。
新しいプロジェクトを作成するか、既存のプロジェクト内で開発するかを判断する際には、次の点を考慮してください。
- プロジェクトと Code Repositories は1対1にするべきです。範囲が広いほど、より深いコラボレーションが可能になりますが、円滑なバージョン管理を確保するための運用要件がより厳しくなります。
- プロジェクトは、関連するすべてのリソースにファイル構成と権限を適用する単位です。概念上は単一の「プロジェクト」であっても、そのサブコンポーネントに個別の権限が必要になる場合は、Foundry で複数のプロジェクトを作成することを検討してください。
パイプラインの段階
以下の段階は、適切に整理されたパイプラインを構成するプロジェクトの論理的な区分を定義します。それぞれについて、後で詳しく説明します。
- Data Connection：同期によって、ソースシステムから生データがデータソースプロジェクトに取り込まれます。
- データソースプロジェクト：論理的なデータソースごとに1個のデータソースプロジェクトを用意し、生データセットごとに基本的なクリーンアップ手順を定義して、一貫したスキーマを適用します。
- トランスフォームプロジェクト：1個以上のデータソースプロジェクトからデータセットをインポートし、加工して、標準化された再利用可能なデータセットを生成します。
- オントロジープロジェクト：1個以上のトランスフォームプロジェクトからデータセットをインポートし、加工して、個々の業務オブジェクトを表す標準化されたテーブルを生成します。管理を容易にするために、特定の業務領域に関連するオブジェクト群を1個のオントロジープロジェクトにまとめることがよくあります。
- ワークフロープロジェクト：ワークフロープロジェクトでは、特定の成果を得るためにオントロジープロジェクトからデータをインポートします。多くの場合、これは業務ワークフロー、データサイエンスの調査、ビジネスインテリジェンスの分析とレポート、またはアプリケーション開発のプロジェクトです。
パイプラインの各段階は独立した単位であり、その出力は、下流のプロジェクトがインポートしてほかのユースケース、パイプライン開発、分析などに使用できるデータセットです。各プロジェクトでは、担当チームは変換手順を実装するだけでなく、出力の安定性と整合性を管理する必要があります。これには、ビルドスケジュールの管理、Data Health チェックの設定と監視、および必要に応じたユニットテストの作成や追加のデータ整合性テストが含まれます。
以下のセクションでは、パイプラインを通るデータの流れに沿って、下流にある各種類のプロジェクトを詳しく説明します。一方、パイプラインを設計する際には、オントロジー層から逆にたどって、接続する必要のあるソースシステムと、実装するパイプラインの変換処理を特定します。
1. Data Connection
Foundry のパイプラインを流れるデータは、通常、外部のソースシステムから取得されます。Data Connection サービスは、ソースシステムを登録する管理インターフェースを提供します。ソースシステムごとに1個以上の同期を設定し、データソースプロジェクト内の生データセットにデータを取り込みます。
ソースシステムや同期を設定する前に、通常はAgent 管理者が Data Connection の Agent を設定する必要があります。各 Agent は、Agent 管理者のみがアクセスできる専用プロジェクトに保存するべきです。
新しいデータソースへの新しい接続を管理するには、データソース所有者、Agent 管理者、データソース開発者の連携による、専門分野をまたいだ取り組みが必要です。ただし、ソースシステムから新しい環境へのデータの移動については、コンプライアンス／法務担当者の承認が必要になることがよくあります。
ただし、ソースシステムを一度設定すると、データソース開発者は独立して個々の同期を設定できます。これにより、チーム間のやり取りが大幅に減り、新しいシステムの接続に必要な作業を、少ない負担で1回限りのものにできます。
各接続で重要な検討事項は、同期のたびに現在のデータを置き換える SNAPSHOT と、同期のたびに既存のデータに累積的に追加する APPEND のどちらを選ぶかです。これらの概念と、効率的で性能の高いパイプラインを作成するうえでの影響をより詳しく理解するには、インクリメンタル（差分処理）パイプラインのセクションを参照してください。
関連資料
データソースと同期の原則、アーキテクチャ、設定について詳しくは、Data Connection のドキュメントを参照してください。
接続の監視や、パイプラインに流れ込むデータが正確で想定の範囲内にあることを確認する方法について詳しくは、パイプラインを保守するのセクションを参照してください。
2. データソースプロジェクト
各ソースシステムのデータは、プラットフォーム内の対応するプロジェクトに取り込む必要があります。通常のパターンでは、各同期からのデータを可能な限り「生」の形式で取り込みます。「クリーン」なデータセットへの変換ステップは、プロジェクトの コードリポジトリ で定義します。
このようなデータソースごとにプロジェクトを設けるモデルには、次のような利点があります。
- 決まった場所で新しいデータソースを探索しやすくなります。
- データソースへのアクセス制御を指定する場所を1か所にまとめられます。
- 異なるチームが同じデータを同期する作業の重複を最小限に抑えられます。
- コードリポジトリが小規模になり、ソースシステムのデータの種類や形式を処理する目的に特化できます。
- パイプライン層がデータにアクセスする前に、データの匿名化、クレンジング、標準化を行えます。
データソースプロジェクトの目標
各データソースプロジェクトの目標は、同期されたデータを、組織全体のさまざまなユーザー、ユースケース、パイプラインで利用できるように準備することです。
出力データセットとそのスキーマは API として捉える必要があります。つまり、データソースプロジェクトの出力データセットは、すべての下流の作業の基盤となるため、論理的に整理され、長期にわたって安定していることが目標です。出力はソースのテーブルまたはファイルと1対1で対応している必要があります。データセットの各行には、ソースシステム内に直接対応する行が存在している必要があります。
この目的を達成するため、生データからクリーンデータへの変換では、一般的に次のことを目指します。
- 一貫した列の命名規則を適用します。
- 列に適切なデータ型が適用されていることを確認します。
- 欠損値、不正な値、データ型が誤っている値を処理します。
- 主要なヘルスチェックを設定します。
- 一般的な利用に適さない PII（個人を特定できる情報）やその他の機密データを削除します。
プライバシー保護のベストプラクティスとして、この早い段階で機密性の高いフィールドを特定します。利用が広がってからアクセスを修正するよりも、不要なデータが共有出力に含まれないようにする方が安全なためです。Sensitive Data Scanner はその検出を支援できます。また、プライバシーと市民的自由の実践では、データの最小化と難読化をパイプライン設計に適用する方法を説明しています。
ソースシステムが列のデータ型情報を提供している場合でも、値を STRING 型として取り込む必要があることがあります。ソースシステムで非標準の形式で表現されることが多い DATE、DATETIME、TIMESTAMP 型や、ときどき問題が生じる数値型には、特に注意してください。ソースシステムから取得するこれらのデータ型の形式が信頼できない場合は、STRING 型としてインポートすることで、より堅牢なパース処理を実装し、不正な値を処理したり、使用できない行や重複した行を削除したりするロジックを定義できます。
これらのプログラムによる処理に加えて、クリーンなデータセットについては、ドキュメントを厳密に整備する必要があります。データセットの定性的な説明、ソースシステムの来歴、適切な連絡先と管理手順、および必要に応じてデータの特徴を説明する列ごとのメタデータを記載することで、将来の開発者がデータを適切に利用できるようになります。
データソースプロジェクトを実装する
- システム管理者が対象のデータソース用に新しいプロジェクトを作成し、プロジェクトを管理する新しいユーザーグループに適切なデータソース開発者を追加します。
- プロジェクト内のデータセットをビルドする権限は、そのデータソースのデータソース開発者グループのメンバーだけに付与する必要があります。
- データソース所有者と Agent 管理者が協力して、ソースシステムに Data Connection Agent をデプロイし、UI でデータソース接続を設定します。
- データソース開発者がソースシステム内のテーブルやファイルをプレビューできるように、適切な権限が設定されていることを確認してください。
- データソース開発者が、適切な同期頻度と同期の種類を考慮して、プロジェクト内の1個以上の生データセットの同期を設定し、各生データセットに適切な Data Health チェックを追加します。
- データソース開発者がクレンジングのトランスフォームを実装し、ほかのプロジェクトで利用できる「クリーン」なデータセットを作成します。
- 下流の開発者は、プロジェクトまたは特定のクリーンなデータセットに対して Issue を起票し、ソースシステムからの新しいデータセットやクリーンなデータセットの改善を依頼したり、データ品質の問題を報告したりします。
データソースにはそれぞれ固有の特徴がありますが、ソースシステムのクレンジングや準備には、生の文字列値を指定のデータ型にパースする処理やエラー処理など、共通するステップがあることがよくあります。データソースに類似したクレンジングのトランスフォームがいくつもある場合は、Python でライブラリを定義し、一貫したツールを提供してコードの重複を減らすことがベストプラクティスです。
推奨フォルダー構成
/raw：データ接続の同期から取得したデータセット用です。/processed（任意）：テーブル形式ではないファイルからテーブル形式のデータを作成する、ファイル単位の変換用です。/clean：/raw内のデータセットと1対1で対応し、クレンジングのステップを適用したデータセット用です。/analysis：クレンジングのトランスフォームをテストまたは文書化し、データの形式を示すために作成したリソース用です。/scratchpad：クレンジングのトランスフォームを構築またはテストする過程で作成した一時的なリソース用です。/documentation：クレンジングのパイプラインステップを示す Data Lineage のグラフと、Foundry Notepad で作成した追加のドキュメント（プロジェクトの最上位の README 以外）用です。
3. トランスフォームプロジェクト
トランスフォームプロジェクトの目標は、意味的にまとまりのある共有データをグループ化してカプセル化し、オントロジー層に渡す標準的なビューを作成することです。
これらのプロジェクトでは、1個以上のデータソースプロジェクトからクレンジング済みのデータセットをインポートし、参照用データセットと結合して値を拡充したり、関係を正規化または非正規化してオブジェクト中心または時間中心のデータセットを作成したり、データを集計して標準的な共有メトリクスを作成したりします。
推奨フォルダー構成
/data/transformed（任意）：トランスフォームプロジェクトの中間ステップから出力されるデータセットです。/output：トランスフォームプロジェクトの「出力」となるデータセットです。下流のオントロジープロジェクトでは、このデータセットだけを利用対象とする必要があります。
/analysis：クレンジングのトランスフォームをテストまたは文書化し、データの形式を示すために作成したリソース用です。/scratchpad：クレンジングのトランスフォームを構築またはテストする過程で作成した一時的なリソース用です。/documentation：クレンジングのパイプラインステップを示す Data Lineage のグラフと、Notepad で作成した追加のドキュメント（プロジェクトの最上位の README 以外）用です。
4. オントロジープロジェクト
オントロジーは Foundry 全体で共通のコミュニケーションレイヤーを確立します。整理され、体系的で、安定したオントロジーを維持することは、共通状況図を充実させながら、価値のある幅広いプロジェクトを同時に進められるようにするための最重要目標です。オントロジーの設計と管理に関する概念や実務について詳しくは、オントロジーの概念に関するドキュメントを参照してください。
オントロジープロジェクトは、あらゆるパイプラインの中心であり、オントロジーで定義された単一のオブジェクトまたは関連するオブジェクトグループの定義に準拠するデータセットを生成するために必要な、最終的な変換を担います。また、これらのプロジェクトは、それとは別に、Object Explorer のビューの元データとなるよう同期されるデータセットも生成します。
オントロジーのデータセットは、それが表す業務上のオブジェクトについての正規の信頼できる情報を表すため、すべての「利用側」プロジェクトの出発点となります。上流のクレンジングやパイプラインのステップの来歴と変換ロジックは閲覧できますが、オントロジープロジェクトのデータのみを利用するプロジェクト開発者、AIP Analyst、データサイエンティスト、業務ユーザーにとって、これらのステップや中間データセットは、概念上はブラックボックスとして扱うこともできます。この意味で、オントロジーレイヤーは業務上のオブジェクトの API として機能します。
オントロジープロジェクトを実装する
データソースプロジェクトと同様に、オントロジープロジェクトを維持するうえで不可欠な要素は次のとおりです。
- 充実したドキュメント
- 意味のあるヘルスチェック
- 定期的なスケジュール
- データカタログでの整理と適切なタグ
これらについては、パイプラインの維持セクションと、以下のプロジェクトのドキュメント化に関するコールアウトで詳しく説明しています。
さらに、オントロジーがより堅牢になり、より多くのチームがオントロジーレイヤーに貢献するようになるにつれて、データセットの「API」の整合性を維持することがいっそう重要になります。このため、提案された変更によって出力データセットのスキーマの整合性が保たれることを確認する、追加のチェックの実装を検討してください。これについては、近日公開予定の追加ドキュメントでさらに詳しく説明します。
推奨フォルダー構造
/data/transformed（任意）：これらのデータセットは、オントロジープロジェクトの中間ステップから出力されます。/ontology：これらのデータセットは、オントロジープロジェクトの「出力」であり、下流のユースケースプロジェクトやワークフロープロジェクトで依存先として使用すべき唯一のデータセットです。
/analysis：クレンジングのトランスフォームをテストまたはドキュメント化し、データの形式を示すために作成されたリソースです。/scratchpad：クレンジングのトランスフォームを作成またはテストする過程で作成された一時的なリソースです。/documentation：クレンジングのパイプラインステップを示す Data Lineage グラフと、レポートに記述された追加ドキュメント（プロジェクトの最上位の README 以外）です。
5. ワークフロープロジェクト
ワークフロープロジェクトは、ユースケースプロジェクトとも呼ばれ、その場の状況に合わせて柔軟に設計する必要があります。ただし、通常は単一のプロジェクトまたはチームを中心に構成し、効果的な共同作業の単位を形成するとともに、責任とアクセスの範囲を明確にします。
一般に、ワークフロープロジェクトではオントロジープロジェクトのデータを参照し、業務ワークフロー、ビジネスインテリジェンス分析、アプリケーションプロジェクトがすべて、現実世界に対する共通の認識を共有できるようにする必要があります。ワークフロープロジェクトの開発中に、オントロジーレイヤーで利用可能なデータソースだけではソースとして不十分である場合は、オントロジーを充実させ、拡張する必要があることを示しています。パイプラインのそれより前（または後）の段階のデータを参照することは避けてください。特定の種類のデータについて、信頼できる情報源が分散する可能性があります。
各プロジェクトは、開発プロセス全体を通じて十分にドキュメント化する必要があります。一般的なパターンとベストプラクティスをいくつか紹介します。
- 各プロジェクトのルートに1個以上の Data Lineage グラフリソースを保存し、最も重要なデータセットとパイプラインの関係を記録します。グラフごとに異なる配色を使用して、データ更新の規則性、関連するデータセットのグループ化、サイズなどのデータセットの特性といった、関連する特徴を強調表示できます。
- プロジェクトに短い説明を追加します。説明は、プロジェクトタイトルのすぐ下で設定できます。この説明は、すべてのプロジェクトのリスト表示で使用されます。プロジェクトに詳しくないユーザーが、その背景や位置づけを理解できる内容を重視します。
- プロジェクトの最上位フォルダーの右サイドバーにあるドキュメントを追加ボタンを使用して、Markdown ↗構文で記述します。ここは、プロジェクトの目的、主要な出力、プロジェクトの利用者に関連するその他の情報を説明するのに最適な場所です。
- プロジェクト全体に関する追加ドキュメントは、ローカルで作成してドキュメントフォルダーにアップロードした Markdown (.md) ファイル、または Notepad に配置し、最上位のドキュメントからリンクします。
- プロジェクトのコードリポジトリに README.md ファイルを追加し、各トランスフォームファイルに説明と追加のインラインコードコメントがあることを確認してください。
推奨フォルダー構造
ワークフロープロジェクトの構造は、ほかの種類のプロジェクトよりも多様になります。主要なリソースにすぐにアクセスでき、そのドキュメントが十分に整備されていることを重視する必要があります。
/data/transformed（任意）：これらのデータセットは、ワークフロープロジェクトの中間ステップから出力されます。/analysis（任意）：これらのデータセットは、分析ワークフローから出力されます。/model_output（任意）：これらのデータセットは、モデルワークフローからの出力であり、その後、モデルの適合度を判断するために分析できます。/user_data（任意）：ワークフローでユーザーが独自のデータの「スライス」を作成できる場合は、ここにあるユーザー別のフォルダーに保存します。
/analysis：意思決定とフィードバックループを促進するために作成されたリソースとレポートです。/models：作成したモデルはここに保存する必要があります。/templates：プロジェクト固有の用途向けに共有される Code Workbook テンプレートはここに保存する必要があります。
/applications：追加のワークフローアプリケーションまたはサブアプリケーションはここに保存します。主要なアプリケーションは、目につきやすくアクセスしやすいよう、プロジェクトのルートに保存する必要があります。/develop：開発中のアプリケーション、新しい機能、テンプレートはここに保存します。
/scratchpad：クレンジングのトランスフォームを作成またはテストする過程で作成された一時的なリソースです。/documentation：クレンジングのパイプラインステップを示す Data Lineage グラフと、レポートに記述された追加ドキュメント（プロジェクトの最上位の README 以外）です。
パイプライン管理のロール
以下のロールは、Foundry のパイプラインのスコープ策定、設計、実装、管理に一般的に関わる担当者の例です。特にプラットフォーム開発の初期段階では、状況によってはすべてのロールが必要とは限らず、1人が同時に複数のロールを担う場合もあります。ただし、これらのロールの説明と相互の連携を全般的に検討することで、適切に組織された効果的なチームを作ることができます。
以下の図は、主要なロールと、そのロールが最もよく活動するパイプラインの区間との関係を示しています。
主要なロール
- Agent 管理者： Agent 管理者は、Data Connection の Agent の作成と設定、および関連するデータソース所有者との共有を担当します。これにより、Agent のインストールと設定の管理を一元化し、セキュリティと管理を強化します。
- データソース開発者： データソース開発者は、データレイクに関連する各データソースの取り込みプロセスを担当するエンジニアです。これは1つのチームで担当することも、ソースシステムごとに分担することもできます。
- 各データソース開発者は、（1）データソースへの技術的な接続を持つ Data Connection のデータソースと、（2）同期したデータの取り込み先となる Foundry プロジェクトを担当します。
- データソースプロジェクトの出力は、クレンジングと準備が完了し、1つ以上の下流のユースケースプロジェクトで利用できるデータセットです。データソース開発者は、担当する各データソースの更新頻度も定義し、リリースマネージャーまたは運用マネージャーと協力して、_パイプラインのビルドポリシー_のスケジュールを設定します。
- データパイプライン開発者： データパイプライン開発者は、すべてのユースケースで利用するデータ資産を提供する共通のオントロジーレイヤーの構築を担当するデータエンジニアです。データパイプライン開発者は、このオントロジーレイヤーを定義し、ソース構造からオントロジー構造への変換に必要なトランスフォームを構築します。
- リリースマネージャー： リリースマネージャーは、本番パイプラインを担当し、リリースプロセスを管理することで、本番パイプラインが組織の標準に準拠し、確実に実行されるようにします。
- パイプラインのコード変更については、通常、master へのプルリクエストの承認プロセスと、master でのパイプラインビルドの実行承認を通じてこれを行います。継続的な信頼性を確保するため、リリースマネージャーは、パイプライン開発者およびデータソース開発者と共同で主要なデータセットに定義した_ヘルスチェック_を監視します。
- コンプライアンス担当者 / 法務担当者： コンプライアンス担当者は、ユースケースの開発前の承認を担当します。この承認では、管轄地域のデータ保護制度と組織独自のポリシーに照らして、（1）使用する必要のあるデータ、（2）プロジェクトの目的、（3）データにアクセスできるユーザーを考慮する必要があります。
- ユースケース開発者： ユースケース開発者は、ユースケースの開発を担当するエンジニア（ソフトウェア開発者やデータサイエンティスト）です。オントロジーレイヤーから取り込まれ、コンプライアンス担当者によって利用が承認されたデータを使用します。
その他のロール
- 運用マネージャー： このロールは、本番パイプラインが正常に実行されることの監視を担当します。さまざまなソースのデータ更新や、さまざまなパイプラインのビルドの実行を監視し、サポート依頼のトリアージを支援します。このロールは、リリースマネージャーを支援します。
- 権限所有者 / 属性管理者： ほとんどの場合、ユーザーのグループへの割り当ては顧客の属性管理システムで管理され、その情報は SAML 統合を通じて Foundry に渡されます。このような場合、権限管理者がそのプロセスを担当します。
- データ担当者： オントロジーレイヤーをユーザー中心の世界観に基づいてモデル化し、データ品質を管理するとともに、オントロジーレイヤーを拡張するために統合すべき新しいデータソースを探すことを担当します。データ担当者は、ユースケースで行われたデータの拡充を監視し、再利用性を高めるためにそれらを汎用化してオントロジーレイヤーに取り込むことも担当します。
- プロジェクトマネージャー： プロジェクトマネージャーは、プロジェクトに貢献するエンジニアと協力し、技術面とビジネス面の目標を揃えること、プラットフォーム上での開発に関するベストプラクティスの標準を遵守すること、およびほかのプロジェクトチームとの調整を確実に行います。プロジェクトマネージャーは、プロジェクトの文書化も担当します。
- データソース所有者： 特定のソースシステムの主要な連絡窓口です。新しいデータ接続の設定時には、Agent 管理者と緊密に連携する必要があります。その後は、自身のサーバーやファイルシステム上で実行される Agent サービス、またはデータ自体の完全性に関する「上流」の問題について、一定の責任を担います。