もしあなたが Amazon QuickSight のレガシートピックをデータセットと一緒に管理してきたなら、その課題をご存知でしょう。2 つのアセットは完全に同期を保つ必要があり、それぞれに独自の権限、系列、バージョン管理があります。列の同義語はずれ、計算フィールドは分岐し、データセットの名前変更はレガシートピックを静かに破壊します。現在、新しいデータ準備エクスペリエンスの「データセットエンリッチメント」を使用して、ビジネスコンテキストをデータセット自体に直接埋め込むことができます。列の説明、同義語、計算フィールド、カスタム命令、ビジネスルールがすべてデータと共存します。データセットエンリッチメントはビジネスコンテキストをデータセットに直接焼き付けます。すべて（権限、セマンティクス、AI コンテキスト）はデータとともに移動し、その上に構築されたものすべてに自動的に継承されます。1 つのアセット、1 つの真実のソース、1 つのガバナンスポイント。この記事では、データセットエンリッチメントとは何か、レガシートピックとどう違うかを説明し、3 つの移行シナリオとステップバイステップのガイダンスを提供し、ビジネスコンテキストをデータセット層に自信を持って移行できるようにします。
トピックは現在、マルチデータセットのセマンティックおよび推論層であり、複数のデータセットを構成し、関係を定義し、ビジネスメトリクスを作成し、ビジネス用語をマッピングする構造です。新しい構造を導入するのではなく、トピックの役割をより完全に果たすために再利用しています。データセット固有のセマンティクスを本来あるべき場所に移動し、トピックを昇格させて、本来担うべきクロスデータセットの関係、メトリクス、ビジネス用語を所有させます。これは表面的な変更ではありません。確定的な BI ワークフローと柔軟な AI 駆動分析の両方を共有セマンティック基盤からサポートする、クリーンで将来性のあるアーキテクチャを確立します。また、カタログ統合のフレームワークを設定します。
レガシートピックとは レガシートピックは、Amazon QuickSight のデータセットにビジネスコンテキストを追加する最初のアプローチを提供しました。これは、列の同義語、計算フィールド、名前付きエンティティ、フィルター、カスタム命令を、データセットの上に配置された別個のオブジェクトに保存し、リンクされているが独立して管理されていました。今後、既存のトピックをレガシーとして分類します。新しいバージョンのトピックは、マルチデータセットセマンティック層に昇格されます。これは、ビジネスユーザーと AI ワークフローが1 つの会話で複数のエンリッチされたデータセットをクエリできるようにする、クロスデータセット Q&A の単一エントリポイントです。データセットエンリッチメントはこれを可能にする基盤です。各データセットは、トピックがより高いレベルでそれらを統合する前に、独自のセマンティックコンテキストを保持する必要があります。
主な違い：レガシートピック vs. データセットエンリッチメント（新しいデータ準備）
| 側面 | レガシートピック | データセットエンリッチメント | |------|------------------|------------------------------| | メタデータの場所 | データセットにリンクされた別個のレガシートピックオブジェクト | データセットメタデータ自体の内部 | | 列の同義語 | レガシートピックの「列同義語」で定義 | 列の「追加ノート」で定義 | | ビジネスルールとフィルター | 構造化条件を持つ名前付きフィルター | カスタム命令のテキストベースのルール | | 計算フィールド | レガシートピックレベルの計算（名前付き式） | 計算列（行レベルの変換） | | 名前付きエンティティ | 同義語を持つ構造化エンティティオブジェクト | カスタム命令のテキストエントリ（データセット出力タブ） | | カスタム命令 | レガシートピックのカスタム命令文字列 | カスタム命令のテキストエントリ（データセット出力タブ） | | ガバナンス | 権限と監査が必要な 2 つのアセット | 権限と監査が必要な 1 つのアセット | | セマンティックタイプ | フィールドのプロパティ | 列のプロパティ | | 集計レベル | フィールドのプロパティ | 実行時にエージェントが質問に基づいて処理 |
移行中に変わらないもの すべてが変わるわけではありません。これらの QuickSight 環境の側面は移行中も変わりません：ルールデータセットは移行を必要としません。ルールベースのロジックは以前と同様に機能し続けます。SPICE ストレージと直接クエリモードは影響を受けません。トピックとデータセットエンリッチメントのどちらを使用しても、データアクセスパターンは同じです。ダッシュボードと分析は再構築されません。エンリッチされたデータセットを使用します。ユーザー向け Q&A 対話モデルは変わりません。ユーザーは引き続き Amazon Quick Chat を通じて自然言語で質問します。違いはユーザーには見えません。
なぜビジネスコンテキストをデータセットに移行するのか？ ビジネスメタデータが別個のレガシートピックオブジェクトに存在する場合、同期を保つ必要がある 2 つのアセットを管理します。権限、系列、発見可能性はすべて境界を越えて分割されます。データセットエンリッチメントはこれを解消します：単一の真実のソース。ビジネスコンテキストはデータとともに移動します。同期がずれる別個のアセットはありません。自動継承。エンリッチされたデータセット上に構築されたダッシュボード、分析、レガシートピック、AI 駆動チャット機能は、追加設定なしでセマンティックコンテキストを継承します。よりシンプルなガバナンス。権限、監査、バージョン管理を管理するための 1 つのアセット。AI 対応性。データセットは自然言語クエリに対して自己記述的になります。Amazon Quick のチャットエクスペリエンスは、別個のトピックを必要とせずに、データセットメタデータから曖昧なビジネス言語を直接解決できます。
データセットエンリッチメントの一部としてのデータセット定義の変更 新しいデータ準備エクスペリエンスは、データセットに semantic_model_configuration を導入します。これには 2 つの層があります：
列レベルメタデータ（TableMap 内）：
- 説明：フィールドの意味。
- 追加ノート：ユーザーが言うかもしれない同義語と代替名。
データセットレベルメタデータ（SemanticMetadata 内）：
- 説明：データセットの全体的な要約。
- カスタム命令：ビジネスロジック、式、名前付きエンティティ、ルール。
レガシートピックフィールドからデータセットエンリッチメントへのマッピング：
| レガシートピックフィールド | データセット SemanticModel ターゲット | |---------------------------|--------------------------------------| | ColumnDescription | ColumnProperties.Description.Text | | ColumnSynonyms[] | ColumnProperties.AdditionalNotes.Text（カンマ区切り） | | CalculatedFields.Expression | DataPrepConfiguration → CreateColumnsStep | | NamedEntities.EntityName + EntityDescription + Definition | CustomInstructions.InlineCustomInstruction.InstructionText（形式：「エンティティ名：定義（フィールド：…）（同義語：…）」） | | Filters | CustomInstructions.InlineCustomInstruction.InstructionText（形式：「ビジネスルール – 名前：出力列名 IN [値]」） | | CustomInstructionsString | CustomInstructions.InlineCustomInstruction.InstructionText |
ソリューション概要 移行は 4 段階のプロセスです。ターゲットデータセットを特定し、ソースレガシートピックを見つけ、Python スクリプトを実行してレガシートピックのメタデータを抽出し、QuickSight API を介してデータセットの SemanticModelConfiguration に書き込みます。スクリプトは、列の説明、同義語、計算フィールド、名前付きエンティティ、フィルター、カスタム命令を 1 回のパスで処理します。手動の UI 作業は必要ありません。
前提条件 始める前に、以下が整っていることを確認してください：AWS CLI v2（バージョン 2.34.50 以降）がインストールされ、有効な認証情報で設定されていること。Python 3.6 以降。Amazon QuickSight エンタープライズエディションで Q が有効になっていること。ターゲットデータセットが新しいデータ準備エクスペリエンス（DataPrepConfiguration）を使用し、すべての InputColumns に列 ID があること。移行する列、説明、同義語、およびオプションで計算フィールド、エンティティ、フィルターを含む既存のレガシートピック（ソース）があること。IAM 権限：quicksight:DescribeDataSet、quicksight:UpdateDataSet、quicksight:DescribeTopic。
移行シナリオ 正しいアプローチは現在の設定によって異なります。最も単純なものから最も複雑なものまで、3 つのシナリオをカバーします。
シナリオ 1：レガシートピックのないレガシーデータセット データセットはクラシック QuickSight エクスペリエンスを使用して構築され、セマンティック層がありません。ユーザーはダッシュボードで生の列名を表示します。誰かが Amazon Quick Chat で自然言語の質問を入力すると、システムにはコンテキストがまったくありません。レガシーデータセット（LogicalTableMap を使用）はデータセットエンリッチメントをサポートしていません。現在、インプレースアップグレードパスはありません。データセット Q&A 機能を使用してデータセットを直接クエリすることを選択できます。
シナリオ 2：レガシーデータセット上のレガシートピック トピックがレガシーデータセットの上に配置され、ユーザーが依存するセマンティック層を提供しています。しかし、基礎となるデータセット自体にはエンリッチメントがなく、LogicalTableMap を使用しています。シナリオ 1 と同様に、基盤となるレガシーデータセットは SemanticModelConfiguration をサポートしていません。新しいデータ準備エクスペリエンスを使用して新しいデータセットを作成し、レガシートピックのメタデータをデータセットエンリッチメントとして移行し、結果を検証してから切り替えることが、前進するための道です。または、レガシーデータセットでデータセット Q&A 機能を使用することもできます。
シナリオ 3：新しいデータ準備データセット上のレガシートピック 現在の状態：データセットに新しいデータ準備エクスペリエンスを既に使用しています。DataPrepConfiguration がありますが、レガシートピックが依然として上層にあり、ユーザーが依存するセマンティックコンテキストを提供しています。データセット構造はエンリッチメントをネイティブにサポートしていますが、まだ適用されていません。これは直接のインプレース移行が可能な唯一のシナリオです。データセットが DataPrepConfiguration を使用しているため、SemanticModelConfiguration を update-data-set API に直接渡すことができます。これにより、列の説明と同義語、計算フィールド、名前付きエンティティ、フィルター、カスタム命令を移行できます。移行中はレガシートピックをアクティブに保ち、両方を一時的に共存させることができます。エンリッチされたデータセットの Q&A 動作をレガシートピックと比較して検証し、準備ができた後にレガシートピックを削除します。