このページは Cloud Translation API によって翻訳されました。

アップグレードの推奨事項

このページでは、カスタマイズされた Cortex Framework Data Foundation から新しいバージョンにアップグレードするための推奨事項について説明します。Cortex チームは、リリースごとに Cortex Framework に新機能を追加しながら、中断を最小限に抑えることに取り組んでいます。新しいアップデートでは、下位互換性が優先されます。ただし、このガイドでは、発生する可能性のある問題を最小限に抑える方法を説明します。

Cortex Framework Data Foundation には、BigQuery に複製されたデータから価値を引き出すための事前定義されたコンテンツとテンプレートのセットが用意されています。組織は、提供されているテンプレート、モジュール、SQL、Python スクリプト、パイプラインなどのコンテンツをニーズに合わせて調整します。

コアコンポーネント

Cortex Framework Data Foundation のコンテンツは、オープン性という原則を念頭に置いて設計されています。組織は、提供された BigQuery データモデルを操作する際に、最適なツールを使用できます。基盤が緊密に依存している唯一のプラットフォームは BigQuery です。他のすべてのツールは、必要に応じて交換できます。

データインテグレーション: 元のテーブルと構造を複製できる限り、BigQuery との相互接続性があるインテグレーションツールを活用できます。たとえば、元のテーブルは、SAP で作成されたものと同じスキーマ（同じ名前、フィールド、データ型）に似ている必要があります。さらに、統合ツールは、BigQuery との互換性を確保するためにターゲットデータ型を更新するなどの基本的な変換サービスや、新規レコードと変更レコードをハイライト表示するためのタイムスタンプやオペレーションフラグなどの追加フィールドを追加するなどの基本的な変換サービスを提供できる必要があります。
データ処理: 変更データキャプチャ（CDC）処理スクリプトは、Cloud Composer（または Apache Airflow）で作業を提供します（省略可）。逆に、SQL ステートメントは可能な限り Airflow 固有のファイルとは別に生成されるため、必要に応じて別のツールで個別の SQL ファイルを使用できます。
データ可視化: Looker ダッシュボードテンプレートが提供されており、可視化と最小限のロジックが含まれていますが、コアロジックは、任意のレポートツールで可視化を作成できるように、設計上 BigQuery 内のデータ基盤で引き続き使用できます。

主なメリット

Cortex Framework Data Foundation は、さまざまなビジネスニーズに適応するように設計されています。コンポーネントは柔軟に構築されているため、組織はプラットフォームを特定の要件に合わせて調整し、次のようなメリットを得ることができます。

オープン性: BigQuery 以外のさまざまなデータ統合、処理、可視化ツールとシームレスに統合できます。
カスタマイズ: 組織は、データモデルとビジネスロジックに合わせて、SQL ビューなどの事前構築済みコンポーネントを変更して拡張できます。
パフォーマンスの最適化: パーティショニング、データ品質チェック、クラスタリングなどの手法は、個々のワークロードとデータ量に基づいて調整できます。
下位互換性: Cortex は、今後のリリースで下位互換性を維持し、既存の実装の中断を最小限に抑えることを目指しています。バージョンの変更については、リリースノートをご覧ください。
コミュニティへの貢献: ユーザー間の知識共有とコラボレーションを促進します。

プロセスの更新

以降のセクションでは、デベロッパーがカスタマイズを維持しながら、Cortex Framework Data Foundation リポジトリでコードを最新の状態に保つ方法について説明します。CI/CD パイプラインで事前提供されたデプロイスクリプトを使用する。ただし、組織は、Dataform や、さまざまな Git ホストから提供される自動化ツール（GitHub Actions など）など、好みに応じて代替のツールと方法論を採用できます。

リポジトリを設定する

このセクションでは、リポジトリを設定する 1 つの方法について概説します。これらの手順を行う前に、Git を十分に理解しておくことをおすすめします。

コアリポジトリをフォークする: Cortex Framework Data Foundation リポジトリのフォークを作成します。フォークにより、そのリポジトリは Google Cloud リポジトリから更新を受け取り、会社のメイン用に別のリポジトリを保持します。
会社のリポジトリを作成する: 会社のリポジトリ用に新しい Git ホスト（Cloud Source など）を設定します。新しいホストに、フォークしたリポジトリと同じ名前のリポジトリを作成します。
会社リポジトリを初期化する: フォークしたリポジトリから、新しく作成した会社リポジトリにコードをコピーします。次のコマンドを使用して、元のフォークされたリポジトリをアップストリームリモートリポジトリとして追加し、リモートリポジトリが追加されたことを確認します。これにより、会社のリポジトリと元のリポジトリ間の接続が確立されます。
```
git remote add google <<remote URL>>
git remote -v
git push --all google
```
リポジトリの設定を確認する: クローンを作成したコードと履歴が会社のリポジトリに含まれていることを確認します。このコマンドを使用すると、2 つのリモート（origin と追加したリモート）が表示されます。
```
git remote -v:
```
これで、デベロッパーが変更を送信できるリポジトリ（会社のリポジトリ）が作成されました。デベロッパーは、新しいリポジトリのブランチをクローン化して作業できるようになりました。

変更を新しい Cortex リリースと統合する

このセクションでは、会社のリポジトリからの変更と Google Cloud リポジトリからの変更を統合するプロセスについて説明します。

フォークを更新する: [フォークを同期] をクリックして、リポジトリのフォークをリポジトリの変更で更新します。 Google Cloud たとえば、会社のリポジトリに対して次の変更が行われます。また、新しいリリースでは、 Google Cloud による Data Foundation リポジトリにもいくつかの変更が加えられています。
- SQL で新しいビューの使用を作成して組み込んだ
- 既存のビューを変更した
- スクリプトを独自のロジックで完全に置き換えました
次のコマンドシーケンスは、フォークリポジトリをアップストリームリモートリポジトリとして追加して、更新されたリリースを GitHub から pull し、そのメインブランチを GitHub-main としてチェックアウトします。この例では、 Google Cloud Source の会社のリポジトリからメインブランチをチェックアウトし、merging_br という結合用のブランチを作成します。
```
git remote add github <<github fork>>
git fetch github main
git checkout -b github-main github/main
git checkout  main
git checkout -b merging_br
```
このフローを構築する方法は複数あります。マージプロセスは GitHub のフォークで行うことも、マージではなくリベースに置き換えることもできます。また、マージブランチをマージリクエストとして送信することもできます。プロセスのこれらのバリエーションは、現在の組織のポリシー、変更の深さ、利便性によって異なります。

この設定により、受信した変更をローカルの変更と比較できます。任意のグラフィック IDE のツールを使用して変更を確認し、マージする内容を選択することをおすすめします。（例: Visual Studio）。

差分プロセスを容易にするために、視覚的に目立つコメントを使用してカスタマイズにフラグを立てることをおすすめします。
マージプロセスを開始する: 作成したブランチ（この例では merging_br というブランチ）を使用して、すべての変更を統合し、ファイルを破棄します。準備ができたら、このブランチを会社のリポジトリのメインブランチまたは別のブランチに統合して、マージリクエストを作成できます。会社のリポジトリのメイン（git checkout merging_br）からチェックアウトしたマージブランチから、リモートフォークからの変更をマージします。
```
    ## git branch -a
    ## The command shows github-main which was created from the GitHub fork
    ## You are in merging_br

    git merge github-main

    ## If you don't want a list of the commits coming from GitHub in your history, use `--squash`
```
このコマンドは、競合のリストを生成します。グラフィカルな IDE 比較を使用して変更を把握し、[現在の]、[受信]、[両方] のいずれかを選択します。カスタマイズに関するコメントをコードに記述しておくと便利です。変更をすべて破棄する、統合しないファイルをすべて削除する、すでにカスタマイズしたビューやスクリプトに対する変更を無視するなどの選択ができます。
変更を統合する: 適用する変更を決定したら、概要を確認し、次のコマンドで commit します。
```
    git status
    ## If something doesn't look right, you can use git rm or git restore accordingly
    git add --all #Or . or individual files
    git commit -m "Your commit message"
```
どの手順でも不安がある場合は、Git の基本的な取り消しをご覧ください。
テストとデプロイ: これまでは、「一時的な」ブランチにのみマージしていました。この時点で cloudbuild\*.yaml スクリプトからテストデプロイを実行して、すべてが想定どおりに実行されていることを確認することをおすすめします。自動テストを使用すると、このプロセスを効率化できます。このマージブランチが問題ないと判断したら、メインのターゲットブランチをチェックアウトし、merging_br ブランチをそのブランチにマージします。