Data Lakehouse Solution 1.0 の外部プロジェクトから Data Lakehouse Solution 2.0 への移行 - MaxCompute

本トピックでは、Data Lakehouse Solution 1.0 の外部プロジェクトから Data Lakehouse Solution 2.0 の外部スキーマに移行する際に、さまざまなシナリオで既存のジョブを修正する方法について説明します。また、Data Lakehouse Solution 2.0 でプロジェクトレベルのメタデータと SQL 構文のスキーマモードを有効にした後の、既存のジョブの互換性についても説明します。

重要

Data Lakehouse Solution 1.0 の外部プロジェクト (External Project 1.0) の機能と使用方法は、開発が終了し、廃止される予定です。MaxCompute を使用してフェデレーションデータソースにアクセスする場合は、フェデレーションソリューションを Data Lakehouse Solution 2.0 にアップグレードする必要があります。

背景情報

Data Lakehouse Solution 1.0 は、外部プロジェクトを使用して DLF+OSS と HMS+HDFS の 2 種類のデータソースとのフェデレーションをサポートしています。Data Lakehouse Solution 1.0 では、テーブルの上のレベルはプロジェクトです。プロジェクトレベルは、DLF または Hive のデータベースにマッピングされます。

DLF と OSS とフェデレーションされたデータレイクの場合、Data Lakehouse Solution 1.0 の外部プロジェクトには接続情報が直接含まれます。MaxCompute エンジンは、外部プロジェクトのプロパティを使用して DLF メタデータと OSS データに接続します。
HMS+HDFS Hadoop インスタンスの場合、Foreign Server オブジェクトを使用してインスタンスにアクセスするための接続情報を格納します。MaxCompute エンジンは、外部データソースを使用して Hive のメタデータとデータを読み取ります。

Data Lakehouse Solution 1.0 と Data Lakehouse Solution 2.0 の比較

Data Lakehouse Solution 1.0 のフェデレーションメソッドにはいくつかの制限があります。Data Lakehouse Solution 2.0 では、これらの問題に対処するための最適化が提供されています。次の表は、2 つのソリューションを比較したものです。

項目	Data Lakehouse Solution 1.0	Data Lakehouse Solution 2.0
外部データソース	外部データソースオブジェクトは、異なるフェデレーションシナリオ間で一貫性がありません。抽象化された外部データソースがないため、テナントレベルでのリソース共有とアクセス制御が妨げられます。	統一された Foreign Server が抽象化されています。これにより、テナントレベルの権限とデータレベルの権限がより適切に分離され、共有と権限管理が簡素化されます。
プロジェクトモデル	テーブルはプロジェクトに直接格納されます。このモデルは、データソースでより一般的に使用される `Project.Schema.Table` 構造と一貫性がありません。データソース内のテーブルより上のレベルの管理オブジェクト (DLF のデータベースや Hologres のスキーマなど) にマッピングするには、多くの外部プロジェクトを作成する必要があります。	プロジェクトがアップグレードされ、スキーマモデルをサポートするようになりました。`Project.Schema.Table` 構造を使用する新しいプロジェクトを作成したり、既存の `Project.Table` 構造を置き換えたりすることができます。これにより、ビッグデータエコシステム内のより多くのデータベースやデータソースと一致させることができます。
計算メソッド	Data Lakehouse Solution 1.0 の外部プロジェクトはプロジェクトレベルのオブジェクトですが、コンピューティングジョブを実行するにはデータウェアハウスプロジェクトに依存する必要があります。これにより、プロジェクト間のデータアクセス権限付与の複雑さが増します。	Data Lakehouse Solution 2.0 では、データソース内のテーブルオブジェクトより上のレベルにマッピングするために External Schema が導入されています。外部スキーマは、それが属するデータウェアハウスプロジェクトのコンピューティングリソースを使用します。
内部と外部のマッピング

説明

外部データソースと外部プロジェクトの作成方法の詳細については、「Data Lakehouse Solution 2.0 ユーザーガイド」をご参照ください。

スキーマモードと互換性

MaxCompute では、スキーマ機能を有効にすることができます。利用可能なスイッチは、プロジェクトレベルのメタデータのスキーマモードとSQL 構文のスキーマモードの 2 つです。

プロジェクトレベルのメタデータのスキーマモード

このモードを有効にすると、無効にすることはできません。このモードを有効にすると、プロジェクト内の他のタスクやプロジェクトへのアクセスとの互換性の問題が発生する可能性があります。注意して進めてください。

プロジェクト構造の変更
- プロジェクトレベルのメタデータのスキーマモードを有効にすると、プロジェクト構造は Project.Schema.Table になります。
- スキーマモードが無効の場合、プロジェクト構造は Project.Table です。
カスタムスキーマのデータへのアクセス
カスタムスキーマのデータにアクセスするには、SQL 構文のスキーマモードを有効にする必要があります。そうしないと、DEFAULT スキーマのデータにしかアクセスできません。
組み込みスキーマ
各プロジェクトには、Default という名前の組み込みスキーマがあります。このスキーマは削除できません。
操作手順
1. MaxCompute コンソールにログインし、左上のコーナーでリージョンを選択します。
2. 左側のナビゲーションウィンドウで、構成の管理 > プロジェクト管理を選択します。
3. プロジェクト管理 ページで、対象のプロジェクトを見つけ、操作列の スキーマレベルをサポートするためのアップグレード をクリックできます。

SQL 構文のスキーマモード

SQL 構文のスキーマモードは、セッションレベルとテナントレベルの 2 つの異なるレベルで設定できます。適用範囲は各レベルで異なります。

セッションレベルの設定

これらの設定は現在のセッションのセマンティクスにのみ影響し、テナントレベルの設定よりも優先されます。SET odps.namespace.schema= true | false; コマンドを実行して、SQL 構文のスキーマモードを有効または無効にできます。

テナントレベルの設定

テナントレベルで SQL 構文のスキーマモードを有効にした後、次の点に注意してください：

すべてのジョブ：セッションレベルの構文スイッチを追加する必要はもうありません。新しいプロジェクトはデフォルトでメタデータのスキーマモードをサポートします。
すべてのプロジェクト：すべてのプロジェクトが SQL 構文のスキーマモードをサポートします。このモードを有効にすると、無効にすることはできません。
プロジェクト内の既存のジョブが SQL 構文のスキーマモードと互換性がない場合、このスイッチを有効にすると既存のジョブが失敗します。したがって、まずセッションレベルで SQL 構文のスキーマモードを有効にする必要があります。ジョブが期待どおりに実行されることを確認した後、テナントレベルで SQL 構文のスキーマモードを有効にできます。
操作手順
1. MaxCompute コンソールにログインし、左上のコーナーでリージョンを選択します。
2. 左側のナビゲーションウィンドウで、構成の管理 > テナント管理を選択します。
3. テナント管理 ページで、テナントプロパティ タブをクリックします。
  - 現在のテナント配下にプロジェクトが存在しない場合
    テナントプロパティ タブで、テナントレベルの情報スキーマ構文をオンにします。
  - 現在のテナント配下にプロジェクトが存在する場合
    設定を変更しないでください。

詳細については、「テナントプロパティ」をご参照ください。

互換性の影響

Data Lakehouse Solution 2.0 のプロジェクトレベルのメタデータのスキーマモードと SQL 構文のスキーマモードが同じ状態でない場合 (一方が有効で他方が無効)、互換性エラーが発生します。

プロジェクトレベルのメタデータのスキーマモードと SQL 構文のスキーマモードの両方が無効になっているデータウェアハウスプロジェクトを考えます。プロジェクト構造は project(p).table(t) で、既存のジョブは正常に実行されます。

データウェアハウスプロジェクトのメタデータのスキーマモードを有効にする場合
または、データウェアハウスプロジェクトのクエリジョブに対して SQL 構文のスキーマモードを有効にする場合

SQL 式を変更せずに元のクエリジョブを実行すると、互換性エラーが発生する可能性があります。詳細は次の表のとおりです。

スキーマモードのステータス	ジョブタイプ	互換性	提案
メタデータサポートなしのスキーマパターン SQL 構文のスキーマモードが有効になっている。	既存のジョブ	既存のジョブが `...FROM t` 構文を使用している場合、システムは `t` の構造を `current_project(p).table(t)` として解析します。これにより、構文の互換性が確保されます。ジョブが `...FROM p.t` 構文を使用している場合、システムは `p.t` の構造を `current_project.schema(p).table(t)` として解析します。しかし、データは `project(p).table(t)` にあり、Schema (p) レイヤーが存在しないため、エラーが発生します。	修正は不要です。文を `...FROM p.default.t` に変更します。
メタデータサポートなしのスキーマパターン SQL 構文のスキーマモードが有効になっている。	新しいタスク	新しいジョブを `p.default.t` として記述すると、`project(p).schema(default).table(t)` として解析されます。新しいジョブを `default.t` として記述すると、`current_project.schema(default).table(t)` として解析されます。新しいジョブを `t` として記述すると、`current_project.current_schema.table(t)` として解析されます。新しいジョブを `p.s.t` として記述すると、`project(p).schema(s).table(t)` として解析されます。プロジェクト (p) にスキーマ (s) レイヤーが存在しない場合、エラーが報告されます。	修正は不要です。
スキーマパターンのメタデータサポートを有効にする SQL 構文のスキーマモードが無効になっている。	既存のジョブ	既存のジョブが `...FROM t` 構文を使用している場合、システムは `t` の構造を `current_project(p).schema(default).table(t)` として解析することで、構文の互換性を維持します。既存のジョブが `...FROM p.t` 構文を使用している場合、システムは `p.t` の構造を `project(p).schema(default).table(t)` として解析し、構文の互換性を確保するために Default Schema レベルを自動的に追加します。	修正は不要です。
スキーマパターンのメタデータサポートを有効にする SQL 構文のスキーマモードが無効になっている。	新しいジョブ	新しいジョブを `p.t` として記述すると、`project(p).schema(default).table(t)` として解析されます。システムは自動的に Default スキーマレベルを追加します。新しいジョブを `t` として記述すると、`project.schema(default).table(t)` として解析されます。システムは自動的に Default スキーマレベルを追加します。説明現在の状態では、カスタムスキーマにアクセスしたり、`USE SCHEMA <schema_name>` を使用したりすることはできません。	修正は不要です。
スキーマモードでメタデータサポートを有効にする SQL 構文のスキーマモードが有効になっている。	既存のジョブ	ジョブが `...FROM t` 構文を使用している場合、システムは `t` の構造を `current_project(p).schema(default).table(t)` として解析します。この構文は互換性があります。既存のジョブが `...FROM p.t` 構文を使用している場合、システムは `p.t` の構造を `current_project.schema(p).table(t)` として解析します。データは `project(p).table(t)` にあり、Schema (p) レイヤーが存在しないため、エラーが発生します。	シナリオ 1：修正は不要です。シナリオ 2：文を `...FROM p.default.t` に変更します。
スキーマモードでメタデータサポートを有効にする SQL 構文のスキーマモードが有効になっている。	新しいタスク	サポートされているスキーマモードと構文ルールを使用できます。	修正は不要です。

移行ガイド

シナリオに基づいて、既存のプロジェクトを選択するか、新しいプロジェクトを作成し、プロジェクトレベルのメタデータのスキーマモードを有効にします。このモードを有効にすると、Default スキーマが自動的に生成されます。プロジェクト内のすべての内部テーブルは Default スキーマに属します。スキーマの詳細については、「スキーマ」および「スキーマ操作」をご参照ください。
プロジェクトレベルのメタデータのスキーマモードを有効にした後、無効にすることはできません。このモードを有効にすると、プロジェクト内の他のタスクやプロジェクトへのアクセスとの互換性の問題が発生する可能性があります。注意して進めてください。スキーマの互換性の詳細については、「スキーマモードと互換性」をご参照ください。
メタデータのスキーマモードが有効になっているプロジェクトに外部スキーマを作成できます。作成の詳細は、データソースの種類によって異なります。詳細については、「Data Lakehouse Solution 2.0 ユーザーガイド」をご参照ください。
外部スキーマの名前は、外部プロジェクトの名前と同じに設定してください。

シナリオ 1：既存のジョブを実行するプロジェクトに外部スキーマを作成し、外部スキーマのデータにアクセスする

シナリオ例：既存のジョブを実行するプロジェクトはプロジェクト (p1) です。クエリのターゲットは、external_project(e).table(t) として指定された外部プロジェクトです。移行後、フェデレーションデータソースは project (p1).external_schema(e).table(t) 構造に再マッピングされます。
既存のジョブが SELECT * FROM e.t; の場合
- SQL 構文のスキーマモードを有効にすると、e.t の構造は external_schema(e).table(t) として解析されます。ジョブはプロジェクト (p1) で修正なしで正常に実行できます。
- SQL 構文のスキーマモードを有効にしない場合、既存のジョブ SELECT * FROM e.t; の e.t の構造は project (e).table(t) として解析されます。システムは e という名前の内部または外部プロジェクトをクエリします。これは再マッピングされた構造と一致せず、既存のアクセスジョブは失敗します。
プロジェクト (p1) がデータクエリのために外部プロジェクトに関連付けられている場合、たとえば SELECT * FROM e.t1 JOIN p1.t2; の場合。
SQL 構文のスキーマモードを有効にすると、p1.t2 の p1 はスキーマとして解析されます。したがって、SQL 文を SELECT * FROM e.t1 JOIN p1.default.t2; に変更する必要があります。

シナリオ 2：別のプロジェクトに外部スキーマを作成し、外部スキーマのデータにアクセスする

シナリオ例：既存のジョブを実行するプロジェクトはプロジェクト (p1) です。外部プロジェクトの構造は external_project(e).table(t) です。プロジェクト (p1) のメタデータのスキーマモードを有効にすることが適していない場合、移行のために別のプロジェクト (p2) を選択または作成できます。移行後、フェデレーションデータソースは project (p2).external_schema(e).table(t) 構造に再マッピングされます。
プロジェクト p1 の既存のジョブに SELECT * FROM e.t; という文が含まれている場合、SQL 構文のスキーマモードを有効にした後、文を SELECT * FROM p2.e.t; に変更する必要があります。
プロジェクト (p2) で前述のジョブを実行する場合、修正は不要です。
外部スキーマとデータウェアハウスプロジェクトの間でプロジェクト間の JOIN クエリを実行する場合、プロジェクト (p1) で SELECT * FROM e.t1 JOIN p1.t2; を実行すると、プロジェクト (p1) のメタデータのスキーマモードが有効になっていなくても、SQL 構文のスキーマモードが有効になっているため、システムは p1.t2 のためにプロジェクト (p1) 内のスキーマ (p1) をクエリします。したがって、SQL 文を SELECT * FROM p2.e.t1 JOIN p1.default.t2; に変更する必要があります。