ステップ 5: デプロイを構成する

このページでは、Cortex Framework のコアである Cortex Framework Data Foundation をデプロイする 5 番目のステップについて説明します。このステップでは、要件に合わせて Cortex Framework Data Foundation リポジトリの構成ファイルを変更します。

構成ファイル

Deployment の動作は、Cortex Framework Data Foundation の構成ファイル config.json によって制御されます。このファイルには、グローバル構成と各ワークロード固有の構成が含まれています。必要に応じて config.json ファイルを編集します。手順は次のとおりです。

  1. Cloud Shell から config.json ファイルを開きます。
  2. 次のパラメータに従って config.json ファイルを編集します。

    パラメータ 意味 デフォルト値 説明
    testData テストデータをデプロイします。 true ソース データセットが存在し、ビルドが実行されるプロジェクト。注: テストデータのデプロイは、元のデータセットが空でテーブルがない場合のみ実行されます
    deploySAP SAP をデプロイする true SAP ワークロード(ECC または S/4 HANA)のデプロイを実行します。
    deploySFDC Salesforce をデプロイする true Salesforce ワークロードのデプロイを実行します。
    deployMarketing マーケティングをデプロイする true マーケティング ソース(Google 広告、CM360、TikTok)のデプロイを実行します。
    deployOracleEBS Oracle EBS をデプロイする true Oracle EBS ワークロードのデプロイを実行します。
    deployDataMesh Data Mesh をデプロイする true Data Mesh のデプロイを実行します。詳細については、Data Mesh ユーザーガイドをご覧ください。
    turboMode ターボモードでデプロイします。 true すべてのビュービルドを同じ Cloud Build プロセスのステップとして並行して実行し、デプロイを高速化します。false に設定すると、各レポートビューが独自の連続ビルドステップで生成されます。テストデータを使用する場合や、レポート列とソースデータの不一致が解決された後にのみ、true に設定することをおすすめします。
    projectIdSource ソース プロジェクト ID - ソース データセットが存在し、ビルドが実行されるプロジェクト。
    projectIdTarget ターゲット プロジェクト ID - ユーザー向けデータセット(レポート データセットと ML データセット)のターゲット プロジェクト。
    targetBucket 生成された DAG スクリプトを保存するストレージへのターゲット バケット - DAG(および Dataflow 一時ファイル)が生成される、前に作成したバケット。実際の Airflow バケットは使用しないでください。
    location ロケーションまたはリージョン "US" BigQuery データセットと Cloud Storage バケットのロケーション。

    BigQuery データセットのロケーションに記載されている制限をご覧ください。

    testDataProject テストハーネスのソース kittycorn-public デモのデプロイ用のテストデータのソース。testDatatrue の場合に適用されます。

    独自のテストハーネスがない限り、この値は変更しないでください。

    k9.datasets.processing K9 データセット - 処理 "K9_PROCESSING" K9 構成ファイルで定義されているように、クロスワークロード テンプレート(日付ディメンションなど)を実行します。通常、これらのテンプレートはダウンストリーム ワークロードで必要になります。
    k9.datasets.reporting K9 データセット - レポート "K9_REPORTING" K9 構成ファイルで定義されているように、クロスワークロード テンプレートと外部データソース(天気情報など)を実行します。デフォルトでコメントアウトされています。
    DataMesh.deployDescriptions データメッシュ - アセットの説明 true BigQuery アセット スキーマの説明をデプロイします。
    DataMesh.deployLakes データメッシュ - レイクとゾーン false 処理レイヤでテーブルを整理する Dataplex レイクとゾーンをデプロイする場合は、有効にする前に構成が必要です。
    DataMesh.deployCatalog データメッシュ - カタログのタグとテンプレート false BigQuery のアセットまたはフィールドにカスタム メタデータを許可する Data Catalog タグをデプロイします。有効にする前に構成が必要です。
    DataMesh.deployACLs Data Mesh - アクセス制御 false BigQuery アセットにアセットレベル、行レベル、列レベルのアクセス制御をデプロイする場合は、有効にする前に構成が必要です。
  3. 必要に応じて、必要なワークロードを構成します。ワークロードのデプロイ パラメータ(deploySAPdeployMarketing など)が False に設定されている場合は、構成する必要はありません。詳細については、ステップ 3: 統合メカニズムを決定するをご覧ください。

デプロイをさらにカスタマイズするには、次のオプションの手順をご覧ください。

レポート ビューのパフォーマンスの最適化

レポート アーティファクトは、ビューとして作成することも、DAG を介して定期的に更新されるテーブルとして作成することもできます。一方、ビューはクエリの実行ごとにデータを計算し、結果を常に最新の状態に保ちます。一方、テーブルでは計算が 1 回実行され、計算コストの増加や実行時間の短縮を招くことなく、結果を複数回クエリできます。各お客様は、ニーズに応じて独自の構成を作成します。

実体化された結果はテーブルに更新されます。これらのテーブルにパーティショニングクラスタリングを追加することで、これらのテーブルをさらに微調整できます。

各ワークロードの構成ファイルは、Cortex Framework Data Foundation リポジトリ内の次のパスにあります。

データソース 設定ファイル
運用 - SAP src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml
運用 - Salesforce Sales Cloud src/SFDC/config/reporting_settings.yaml
運用 - Oracle EBS src/oracleEBS/config/reporting_settings.yaml
マーケティング - Google 広告 src/marketing/src/GoogleAds/config/reporting_settings.yaml
マーケティング - CM360 src/marketing/src/CM360/config/reporting_settings.yaml
マーケティング - Meta src/marketing/src/Meta/config/reporting_settings.yaml
マーケティング - Salesforce Marketing Cloud src/marketing/src/SFMC/config/reporting_settings.yaml
マーケティング - TikTok src/marketing/src/TikTok/config/reporting_settings.yaml
マーケティング - YouTube(ディスプレイ&ビデオ 360 を使用) src/marketing/src/DV360/config/reporting_settings.yaml
マーケティング - Google アナリティクス 4 src/marketing/src/GA4/config/reporting_settings.yaml
マーケティング - クロスメディアとプロダクトの連携インサイト src/marketing/src/CrossMedia/config/reporting_settings.yaml

レポート設定ファイルのカスタマイズ

reporting_settings ファイルは、レポート データセット用に BigQuery オブジェクト(テーブルまたはビュー)を作成する方法を決定します。次のパラメータの説明に沿ってファイルをカスタマイズします。このファイルに次の 2 つのセクションがあるとします。

  1. bq_independent_objects: 他の依存関係なしで個別に作成できるすべての BigQuery オブジェクト。Turbo mode が有効になっている場合、これらの BigQuery オブジェクトはデプロイ時に並列で作成されるため、デプロイ プロセスが高速化されます。
  2. bq_dependent_objects: 他の BigQuery オブジェクトへの依存関係により、特定の順序で作成する必要があるすべての BigQuery オブジェクト。Turbo mode は、このセクションには適用されません。

デプロイヤーは、まず bq_independent_objects にリストされているすべての BigQuery オブジェクトを作成し、次に bq_dependent_objects にリストされているすべてのオブジェクトを作成します。各オブジェクトに次のプロパティを定義します。

  1. sql_file: 特定のオブジェクトを作成する SQL ファイルの名前。
  2. type: BigQuery オブジェクトのタイプ。値は次のいずれかです。
    • view : オブジェクトを BigQuery ビューにするかどうか。
    • table: オブジェクトを BigQuery テーブルにするかどうか。
    • script: 他のタイプのオブジェクト(BigQuery 関数やストアド プロセスなど)を作成します。
  3. typetable に設定されている場合、次のオプション プロパティを定義できます。
    • load_frequency: このテーブルを更新するために Composer DAG が実行される頻度。有効な値の詳細については、Airflow のドキュメントをご覧ください。
    • partition_details: テーブルのパーティショニング方法。この値は省略可です。詳細については、テーブル パーティションのセクションをご覧ください。
    • cluster_details: テーブルのクラスタ化方法。この値は省略可です。詳細については、クラスタ設定のセクションをご覧ください。

テーブル パーティション

特定の設定ファイルを使用すると、カスタムのクラスタリング オプションとパーティショニング オプションを使用してマテリアライズド テーブルを構成できます。これにより、大規模なデータセットのクエリ パフォーマンスが大幅に向上します。このオプションは、SAP cdc_settings.yaml ファイルとすべての reporting_settings.yaml ファイルにのみ適用されます。

テーブル パーティショニングは、次の partition_details を指定して有効にできます。

- base_table: vbap
  load_frequency: "@daily"
  partition_details: {
    column: "erdat", partition_type: "time", time_grain: "day" }

次のパラメータを使用して、特定のテーブルのパーティショニングの詳細を制御します。

プロパティ 説明
column CDC テーブルをパーティショニングする列。 列名。
partition_type パーティションのタイプ。 時間ベースのパーティションの場合は "time"。詳細については、タイムスタンプ パーティション分割テーブルをご覧ください。整数ベースのパーティションの場合は "integer_range"。詳細については、整数範囲のドキュメントをご覧ください。
time_grain パーティションに使用する時刻部分。partition_type = "time" の場合に必須です。 "hour""day""month""year"
integer_range_bucket バケット範囲partition_type = "integer_range" の場合は必須です "start" = 開始値、"end" = 終了値、"interval = 範囲の間隔。

オプションと関連する制限事項の詳細については、BigQuery テーブル パーティションをご覧ください。

クラスタの設定

テーブルのクラスタリングは、cluster_details を指定することで有効にできます。

  - base_table: vbak
    load_frequency: "@daily"
    cluster_details: {columns: ["vkorg"]}

次のパラメータを使用して、特定のテーブルのクラスタの詳細を制御します。

プロパティ 説明
columns テーブルがクラスタ化される列。 列名のリスト。たとえば、"mjahr""matnr" です。

オプションと関連する制限事項の詳細については、テーブル クラスタのドキュメントをご覧ください。

次のステップ

このステップが完了したら、次のデプロイ ステップに進みます。

  1. ワークロードを確立する
  2. リポジトリのクローンを作成する
  3. 統合メカニズムを決定する
  4. コンポーネントを設定する
  5. デプロイを構成する(このページ)。
  6. デプロイを実行する