アップグレードに関する推奨事項

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

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

コアコンポーネント

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

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

主なメリット

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

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

プロセスの更新

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

リポジトリを設定する

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

コアリポジトリをフォークする: Cortex Framework Data Foundation リポジトリのフォークを作成します。フォークにより、そのリポジトリは Google Cloud リポジトリから更新を受け取り続け、会社のメイン用の別のリポジトリが作成されます。
会社のリポジトリを作成する: 会社のリポジトリ用の新しい Git ホスト（Cloud Source など）を確立します。新しいホストに、フォークしたリポジトリと同じ名前のリポジトリを作成します。
会社のレポジトリを初期化する: フォークしたレポジトリからコードをコピーして、新しく作成した会社のレポジトリに貼り付けます。次のコマンドを使用して、元のフォークされたリポジトリをアップストリームリモートリポジトリとして追加し、リモートが追加されたことを確認します。これにより、会社のリポジトリと元のリポジトリの間に接続が確立されます。
```
git remote add google <<remote URL>>
git remote -v
git push --all google
```
リポジトリの設定を確認する: 会社のリポジトリにクローンされたコードと履歴が含まれていることを確認します。コマンドを実行すると、origin と追加したリモートの 2 つが表示されます。
```
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 のフォークで行うことも、マージではなく rebase に置き換えることもできます。また、マージブランチをマージリクエストとして送信することもできます。これらのプロセスのバリエーションは、現在の組織のポリシー、変更の深さ、利便性によって異なります。

この設定を行うと、受信した変更をローカルの変更と比較できます。変更を確認し、マージする内容を選択するには、選択したグラフィック 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 比較を使用して、変更を把握し、[current]、[incoming]、[both] のいずれかを選択します。カスタマイズに関するコメントをコード内に残しておくと、ここで役に立ちます。変更をすべて破棄する、まったくマージしたくないファイルを削除する、すでにカスタマイズしたビューやスクリプトの変更を無視する、といった選択肢があります。
変更を統合する: 適用する変更を決定したら、概要を確認し、次のコマンドでコミットします。
```
    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 ブランチをマージできます。