本トピックでは、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 では、これらの課題を解決するための最適化が提供されています。以下の表に、両ソリューションの比較を示します。
項目 | Data Lakehouse Solution 1.0 | Data Lakehouse Solution 2.0 |
外部データソース | 異なるフェデレーションシナリオ間で、外部データソースオブジェクトの定義が一貫していません。抽象化された外部データソースが存在しないため、テナントレベルでのリソース共有およびアクセスの制御が困難です。 | 統一された Foreign Server が抽象化されています。これにより、テナントレベルの権限とデータレベルの権限がより明確に分離され、共有および権限管理が簡素化されます。 |
プロジェクトモデル | テーブルはプロジェクトに直接格納されます。このモデルは、データソースで一般的に採用されている DLF のデータベースや Hologres のスキーマなど、データソースにおけるテーブルの上位管理オブジェクトに対応させるには、多数の外部プロジェクトを作成する必要があります。 | プロジェクトはスキーマモデルをサポートするようにアップグレードされています。新しいプロジェクトでは |
計算方法 | Data Lakehouse Solution 1.0 の外部プロジェクトはプロジェクトレベルのオブジェクトですが、計算ジョブを実行するにはデータウェアハウスプロジェクトに依存する必要があります。これにより、クロスプロジェクト間のデータアクセス権限付与が複雑化します。 | Data Lakehouse Solution 2.0 では、データソースにおけるテーブルオブジェクトの上位レベルに対応する 外部スキーマ が導入されています。外部スキーマは、所属するデータウェアハウスプロジェクトの計算リソースを使用します。 |
内部／外部マッピング |
|
|
外部データソースおよび外部プロジェクトの作成方法については、「Data Lakehouse Solution 2.0 ユーザーガイド」をご参照ください。
スキーマモードと互換性
MaxCompute では、スキーマ機能を有効化できます。利用可能なスイッチは 2 つあり、プロジェクトレベルのメタデータ向けスキーマモード および SQL 構文向けスキーマモード です。
プロジェクトレベルのメタデータ向けスキーマモード
このモードを有効化すると、無効化することはできません。有効化すると、プロジェクト内の他のタスクおよびプロジェクトへのアクセスにおいて互換性の問題が生じる可能性があるため、十分にご注意ください。
プロジェクト構造の変更
プロジェクトレベルのメタデータ向けスキーマモードを有効化すると、プロジェクト構造は
Project.Schema.Tableとなります。スキーマモードが無効化されている場合、プロジェクト構造は
Project.Tableとなります。
カスタムスキーマ内データへのアクセス
カスタムスキーマ内のデータにアクセスするには、SQL 構文向けスキーマモードを有効化する必要があります。それ以外の場合、DEFAULT スキーマ内のデータにのみアクセスできます。
組み込みスキーマ
各プロジェクトには、Default という名前の組み込みスキーマが存在します。このスキーマは削除できません。
操作手順
MaxCompute コンソール にログインし、左上隅からリージョンを選択します。
左側のナビゲーションウィンドウで、 を選択します。
プロジェクト管理 ページで、対象のプロジェクトを見つけ、スキーマレベルをサポートするためのアップグレード を 操作 列からクリックします。
SQL 構文向けスキーマモード
SQL 構文向けスキーマモードは、セッションレベル および テナントレベル の 2 つのレベルで設定できます。それぞれの適用スコープは異なります。
セッションレベルの設定
これらの設定は、現在のセッションのセマンティクスにのみ影響し、テナントレベルの設定よりも優先されます。SET odps.namespace.schema= true | false; コマンドを実行することで、SQL 構文向けスキーマモードを有効化または無効化できます。
テナントレベルの設定
SQL 構文向けスキーマモードをテナントレベルで有効化した場合、以下の点にご注意ください。
すべてのジョブ：セッションレベルの構文スイッチを追加する必要がなくなります。新規プロジェクトでは、メタデータ向けスキーマモードがデフォルトで有効化 されます。
すべてのプロジェクト：すべてのプロジェクトで SQL 構文向けスキーマモードがサポートされます。一度有効化すると、無効化することはできません。
プロジェクト内の既存ジョブが SQL 構文向けスキーマモードと互換性がない場合、このスイッチを有効化すると既存ジョブが失敗します。そのため、まずセッションレベルで SQL 構文向けスキーマモードを有効化し、ジョブが正常に実行されることを確認したうえで、テナントレベルでの有効化を行ってください。
操作手順
MaxCompute コンソール にログインし、左上隅からリージョンを選択します。
左側のナビゲーションウィンドウで、 を選択します。
テナント管理 ページで、テナントプロパティ タブをクリックします。
現在のテナントにプロジェクトが存在しない場合
テナントプロパティ タブで、テナントレベルの情報スキーマ構文 をオンにします。
現在のテナントにプロジェクトが存在する場合
設定を変更しないでください。
詳細については、「テナントプロパティ」をご参照ください。
互換性への影響
Data Lakehouse Solution 2.0 において、プロジェクトレベルのメタデータ向けスキーマモード と SQL 構文向けスキーマモードの状態が一致していない場合（片方のみ有効化されている場合）、互換性エラーが発生します。
両方のスキーマモードが 無効化 されているデータウェアハウスプロジェクトを例に挙げます。このプロジェクトの構造は project(p).table(t) であり、既存のジョブは正常に実行されます。
データウェアハウスプロジェクトに対して メタデータ向けスキーマモードを有効化 した場合
または、データウェアハウスプロジェクト内でクエリジョブに対して SQL 構文向けスキーマモードを有効化 した場合
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) で実行する場合、変更は不要です。
外部スキーマとデータウェアハウスプロジェクト間のクロスプロジェクト結合クエリ を実行する場合、プロジェクト (p1) で
SELECT * FROM e.t1 JOIN p1.t2;を実行すると、p1.t2に対してプロジェクト (p1) 内のスキーマ (p1) を照会します。これは、プロジェクト (p1) ではメタデータ向けスキーマモードが有効化されていないにもかかわらず、SQL 構文向けスキーマモードが有効化されているためです。したがって、SQL ステートメントをSELECT * FROM p2.e.t1 JOIN p1.default.t2;に変更する必要があります。