#目的

Attributesページは、ユニークな属性名ごとにLakehouse Managerのすべての属性をグループ化します。これらの属性はそれぞれ、物理的または仮想的というリアルムの一部です。

#物理的な属性

物理的な属性は、Lakehouse Managerテーブルに物理的に保存されている属性です。テーブルレベルでそのカテゴリ、タイプ、その他の情報を編集できます。

これらはAttributesページで名前ごとにグループ化されており、データウェアハウス/データレイク全体で各属性が取る異なるカテゴリとタイプを一目で確認できます。

各属性を展開すると、この属性を使用するプロジェクト内のオブジェクトの完全な系譜を取得できます:

• Lakehouse Manager テーブル
• Data Processing Engine アクション
• Analytics Manager クエリ

一部の属性は、辞書のキーになり得ます。その場合、別の属性がこの属性のラベルとして使用され、アプリケーションでキーの代わりに自動的に表示されます。

ラベルは、テーブル画面で、辞書キーを主キーとして含むテーブルレベルで設定できます。

#サポートされている属性タイプ

属性は、次のプリミティブタイプをサポートしています:

integer, bigint, float, real, double, decimal, varchar, boolean, timestamp, date。

ネイティブのGEOMETRYタイプはありません。複雑または入れ子になった構造はネイティブで保存されません。以下のパターンは、その間の最も一般的なニーズをカバーしています。

#非構造化または複雑なデータの操作

ドキュメント（PDF、Word、...）

1. 生のファイルをバケットに保存します。
2. カスタムアクションでその内容を抽出します（Python、ライブラリpypdfまたはpython-docxをPython Requirementsを通じてインストール）。
3. メタデータと抽出されたテキストをテーブルに書き込み、クエリ可能にします。

地理的オブジェクト

現在、ネイティブなパスはありません。2つのオプションがあります:

• WKTテキストをvarchar属性として、またはWKBをVARBINARY属性として保存します。
• Apache Sedona（PySparkカスタムアクションのGit依存関係として追加）またはNotebook内のgeopandas / shapelyでスキーマ外で空間計算を実行します。

半構造化JSON

• スキーマが安定している場合は、IcebergでROW / MAPフィールドを使用します。
• スキーマが変化する場合は、varchar属性とTrinoのjson_*関数（json_extract、json_parse）を使用します。

フルテキスト/ベクトル検索

ネイティブなパスはありません。推奨されるパターンは、出力側のカスタムアクションを通じて外部サービス（管理型Elasticsearch、ベクトルデータベース）にエクスポートすることです。

#制約

物理属性は、テーブルが構築される際に適用される制約を持つことができます:

• 必須: フィールドはNULLを含むことはありません。
• 必須 + 識別子: フィールドはアップサート操作で行の一意性を定義するために必須です。識別子フィールドはdoubleまたはdecimalにはできません。

これらは、テーブルで属性を追加または編集する際に設定します。

#名前付け規則

属性名はテーブルごとにユニークですが、プラットフォームはAttributesページでプロジェクトレベルで名前ごとにそれらを集約します。これにより、例えば同じcode属性が1つのテーブルではintegerとしてタイプ指定され、別のテーブルではbigintとしてタイプ指定されているといった不整合を検出できますが、それらを防ぐことはできません。

属性に対する一般的な命名ガイドラインと予約語のリストは、テーブルと同様に適用されます。詳細は、TablesページのNaming ConventionsとReserved Wordsを参照してください。

#同音異義属性の処理

code、libelleまたはvalueのような属性が、異なるタイプの異なるソースから来る場合、次の慣行を使用します:

1. ドメインまたはソースでプレフィックスを付けます。 顧客の場合はclt_code、clt_libelle、clt_valueを使用し、製品の場合はprd_code、prd_libelleを使用し、注文の場合はcmd_codeを使用します。プレフィックスはcodeをentity_codeに変換し、読み取り時と自動検出された式の両方で曖昧さを取り除きます。
2. 名前の変更が不可能な場合は、テーブル全体でタイプを統一します。 最も広いタイプ（decimalまたはbigint）を選択し、ソーステーブルでCASTをINSERT時に実行します。これにより、少なくともAttributesページのタイプの不整合が解消されます。
3. タグと説明で文書化し、名前が曖昧な場合の使用を区別します。
4. 短い汎用的な名前（code、libelle、value、id、name、status）をクロスカット使用に予約するか、全く避ける。

#共有属性の文書化: データ辞書

Data Platformは完全な外部データカタログを提供しませんが、いくつかの組み込みメカニズムはすでに機能的なデータ辞書として機能しています:

• Attributesページ。 プロジェクト全体の各属性名に1つのエントリがあり、テーブル全体でそのタイプとカテゴリの内訳（codeとしてinteger対bigint対decimalを検出するのに最適）と、それを消費するオブジェクトの完全な系譜が記載されています。詳細は上記を参照してください。
• ポリシータグ。 ポリシータグはアクセス制御のために設計されていますが、データの分類にも再利用できます: domain: finance、sensitivity: high、pii: true、glossary_term: client_id。ポリシータグはデータセットからテーブル、テーブルから属性に継承されます。データセットに設定されたタグは、その下の未タグの属性全てに適用されます。これにより、ベースラインを設定し、必要に応じて上書きできます。
• 辞書。 上記で説明した辞書メカニズム（キー→ラベル）は、コード→ラベル参照テーブルを処理します。

属性ごとの豊富な説明、ビジネス用語集、所有権、外部カタログ（Collibra、DataHub）との統合は利用できません。これらのニーズには、補完的な外部ツールがまだ必要です。

#バーチャル属性

バーチャル属性は、データに対して新しい式を計算するために使用されます。これらはデータベースに保存されませんが、クエリまたはダッシュボード/レンダリングチャートの実行時に動的に計算されます。

#バーチャル属性の式

バーチャル属性の最も重要な要素は、そのSQL定義です。

SQLキーワードと物理属性の組み合わせを含む式を記述します。

#バーチャル属性の式の例

SUM(rides)/COUNT(DISTINCT CONCAT(CAST(date AS VARCHAR), CAST(station_id AS VARCHAR)))

ここで、rides、date、およびstation_idは、Lakehouse Managerテーブルから取得した物理属性です。プラットフォームは、これらを自動的に検出し、クエリ対象の最も関連性の高いテーブル（式に明示的に定義されていない場合）を特定します。

#バーチャル属性のオプション

#必須属性

プラットフォームは、バーチャル属性の式を実行するために必要な物理属性を自動的に検出します。

バーチャル属性の詳細設定で編集できます。編集する理由は（以下に限定されません）：式内の物理属性がSQLキーワードとして検出される代わりに必要な属性として検出される、またはその逆です。

#型

バーチャル属性の型は、作成時に自動的に推論されます。この型により、プラットフォームはバーチャル属性を使用するクエリの計画を自動化できます。

バーチャル属性の詳細設定で編集できます。編集する理由は（以下に限定されません）：バーチャル属性に基づいてフィルタ値を変換すると、別の型に自動的に変換され、Analytics Managerでクエリが失敗することがあります。

#さらに詳しく

当社のソリューションのトレーニングや技術的なサポートが必要な場合は、営業担当者にお問い合わせください、または当社のプロフェッショナルサービスページをご覧ください。見積もりをリクエストし、当社の専門家がプロジェクトを分析してください。

専用Discordチャネルで質問を投稿し、フィードバックを送信したり、Data Platformを構築するチームと直接交流したりできます。

OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。

ユーザーコミュニティに参加してください。