DataWorks は、さまざまなデータ本番、セキュリティ、ガバナンスのニーズを満たすために、基本モードと標準モードの 2 つのワークスペースモードを提供します。このトピックでは、基本モードと標準モードのアーキテクチャと開発ワークフローを比較します。
背景
このトピックでは、次のセクションについて説明します。
セクション | 説明 |
各ワークスペースモードのアーキテクチャについて説明します。 | |
各モードのアーキテクチャプロパティに基づいた DataWorks の開発および O&M メカニズムについて説明します。 | |
各ワークスペースモードの長所と短所を比較します。 | |
標準モードのワークスペースにおけるロールベースのワークフローとガバナンスについて説明します。 | |
各モードで利用可能なさまざまな環境で DataWorks モジュールがデータソースに接続する方法について説明します。 | |
開発と本番の分離を実装したい基本モードのワークスペースのユーザー向けにガイダンスを提供します。 |
注意
各ワークスペースモードには、データソースを作成するための特定の要件があります。標準モードのワークスペースで環境の隔離を実現するには、開発環境と本番環境用に物理的に分離されたデータソースを作成します。ワークスペースでのデータソースの作成に関する詳細については、「データソース管理」をご参照ください。
異なるプロジェクトやデータベース間でリソースやデータにアクセスできるかどうかは、データソース自体の機能に依存します。開発環境と本番環境に異なるデータソースを設定した場合、開発環境から本番テーブル、リソース、または関数にアクセスできるかどうかは、データソースの機能によって決まります。
デフォルトでは、標準モードの開発環境のノードは定期的な実行がスケジュールされません。本番環境にデプロイされたノードのみが定期的にスケジュールできます。
基本モードと標準モードの概要
DataWorks を試すために、どちらかのモードでワークスペースを作成できます。ただし、実際の開発作業では、標準モードのワークスペースを使用することを強く推奨します。これにより、開発環境と本番環境の間でコードの隔離を実装し、個別の計算リソースを使用し、権限制御を適用し、管理されたノードのデプロイメントプロセスを確立できます。
基本モードのワークスペースを使用していて、そのコードを保持したい場合は、標準モードにアップグレードできます。詳細については、「ワークスペースモードのアップグレード」をご参照ください。
次の表は、基本モードと標準モードのワークスペースを比較したものです。
側面 | 基本モード | 標準モード（推奨） |
データソースの数 | 基本モードのワークスペースは、単一のデータソースに接続します。 | 1 つの DataWorks ワークスペースは 2 つのデータソースに関連付けられており、開発環境と本番環境のデータソースを隔離できます。 説明 環境の隔離を実現するには、開発環境と本番環境用に物理的に分離されたデータソースを作成します。
|
対応する DataWorks 環境 | 単一のデータソースは、DataWorks の本番環境として機能します。 | 1 つのデータソースは DataWorks の開発環境として機能し、もう 1 つは本番環境として機能します。 説明 各環境に異なるタイプのデータソースを設定できます。例:
|
本番ノードの開発と O&M に対するさまざまなモードの影響
比較 | 基本モード | 標準モード（推奨） |
本番ノード開発ワークフローの制御 | ノードがコミットされると、スケジューリングシステムはすぐにそれを定期的に実行して出力データを生成できます。デプロイメントステップは必要ありません。 (コミット -> 本番)
| ノードはまず開発環境にコミットする必要があります。その後、自動的にスケジュールされて実行される前に、本番環境にデプロイする必要があります。 (コミット -> デプロイ -> 本番) 説明 標準モードでは、本番環境のノードのみが自動的にスケジュールされます。
|
本番ノードの O&M 権限の制御 | 開発者は本番ノードのコードを直接編集できます。 | 開発者は Data Studio でコードを編集およびコミットすることしかできません。本番環境にコードを直接デプロイすることはできません。本番環境へのデプロイには、ワークスペースオーナー、管理者、O&M などのロールが持つ O&M 権限が必要です。
|
本番データ権限の制御 | 開発者はテストに本番データを直接使用できるため、データセキュリティにリスクをもたらします。 | 開発環境では、開発者はテストデータを使用してテストできます。また、検証のために本番テーブルデータを使用する権限を付与されたり、申請したりすることもできます。 説明
|
データアクセス ID の違い | 単一の ID を使用して本番環境を直接操作します。 MaxCompute、Hologres、EMR、および CDH の場合、アクセス ID は Alibaba Cloud アカウント、RAM ユーザー、RAM ロール (MaxCompute のみ)、またはノードのオーナーにすることができます。 説明 AnalyticDB for MySQL や AnalyticDB for PostgreSQL などの他のコンピュートエンジンの場合、アクセス ID はデータソースの作成時にバインドするアカウントに依存します。権限は、データベース内のアカウントの権限と一致します。 |
説明 MaxCompute、Hologres、EMR、および CDH の場合:
AnalyticDB for MySQL や AnalyticDB for PostgreSQL などの他のコンピュートエンジンの場合、アクセス ID はデータソースの作成時に各環境にバインドするアカウントに依存します。権限は、データベース内のアカウントの権限と一致します。 |
各モードの長所と短所の比較
側面 | 基本モード | 標準モード |
長所 | シンプルで使いやすい。 開発者に開発者ロールを付与するだけで、すべてのデータウェアハウス開発タスクを実行できます。 | 安全で適切に管理されています。
|
短所 | 不安定性と非安全性のリスクを伴います。
| ワークフローはより複雑です。通常、一人の人間が開発から本番までのライフサイクル全体を管理することはできません。 |
ユースケース: 標準モードがワークフローに与える影響
次の図に示すように、標準モードでの環境の隔離は、データモデルの設計、データ処理ロジック、コードのデプロイメントなどのワークフローに影響を与えます。
各モードにおける DataWorks モジュールのデータソースマッピング
[計算リソース] ページに移動すると、Data Studio でバインドされた計算リソースを表示できます。バインド後、DataWorks モジュールは各ワークスペースモードで次のデータソースを操作します:
DataWorks モジュール | 標準モード | 基本モード |
Data Studio | 開発環境のデータソース (インスタンス、プロジェクト、またはデータベース) を操作します。 | 本番環境のデータソース (インスタンス、プロジェクト、またはデータベース) を操作します。 |
オペレーションセンター |
|
基本モードで環境の隔離を実現する
目標: 基本モードのワークスペースを使用しながら、開発環境と本番環境を隔離すること。
実装: 2 つの個別の基本モードのワークスペースを使用できます。1 つを開発環境として、もう 1 つを本番環境として使用します。その後、ワークスペース間のデプロイメント機能を使用して、開発ワークスペースから本番ワークスペースにノードをデプロイできます。このアプローチにより、環境が隔離されます。
短所: このアプローチでは、本番ワークスペースの Data Studio モジュールで本番コードを直接編集できます。これは、本番環境にコード更新のための単一の制御されたエントリポイントがなく、管理されたワークフローの制御をバイパスすることを意味します。
推奨事項: 基本モードのワークスペースを標準モードのワークスペースにアップグレードして、より堅牢で管理された開発ワークフローを確立することを強く推奨します。詳細については、「ワークスペースモードのアップグレード」をご参照ください。