ワークスペース計画戦略と設計モデル - DataWorks - Alibaba Cloud - DataWorks

権限モデルと組織要件に基づき、さまざまなシナリオに合わせて DataWorks のワークスペースを計画する方法を説明します。

ワークスペースの権限モデル

DataWorks の主要サービスでは、権限の分離レベルが異なります。

サービス	権限モデル
ワークスペース管理	ワークスペースは相互に [完全に分離] されています。メンバーのロールとコンピュートエンジンインスタンスの設定は、ワークスペースごとに個別に構成します。説明各ワークスペースの所有者は Alibaba Cloud アカウントです。
DataStudio	データ開発は、ワークスペース間で [完全に分離] されています。ワークフローとノードは、各ワークスペースで独立して開発され、相互に影響しません。ワークスペース内では、以下のようになります。開発者またはワークスペース管理者ロールを持つメンバーのみが、ノードの作成、編集、削除を行えます。開発者、運用保守、またはワークスペース管理者ロールを持つメンバーのみが、デプロイメントパッケージをコミットできます。運用保守、デプロイ担当者、またはワークスペース管理者ロールを持つメンバーのみが、本番環境にデプロイできます。説明ワークスペースをまたいでノードのスケジューリング依存関係を構成できます。
オペレーションセンター	運用保守は、ワークスペース間で [部分的に分離] されています。リアルタイム、周期的、手動トリガーのノード運用は、各ワークスペース内で分離されます。開発者、運用保守、またはワークスペース管理者ロールを持つメンバーのみが実行できます。 [概要] ページはワークスペース内で分離され、ノード実行に関するサマリーデータを表示します。 [アラーム] 機能はワークスペース間で共有されており、複数のワークスペースにまたがるノードを監視するベースラインを作成できます。ベースラインを作成できるのは、Alibaba Cloud アカウント、またはワークスペース管理者ロールを持つメンバーのみです。
データマップ	データマップは、[テナント内のすべてのワークスペースで共有] されます。データマップでは、現在のテナントおよびリージョン内のすべてのワークスペースのメタデータを検索して表示できます。説明共有されるのはメタデータのみです。実データに対する読み取りおよび書き込み権限は共有されません。通常、開発環境における読み取りおよび書き込み権限は開発者ロールのメンバー間で共有されますが、本番環境のデータ権限は本番アカウント専用です。
Data Quality	Data Quality は、ワークスペース間で [完全に分離] されています。ワークスペース内でデータ品質の監視ルールを構成できるのは、開発者、運用保守、またはワークスペース管理者ロールを持つメンバーのみです。
DataService Studio	DataService Studio は、ワークスペース間で [部分的に分離] されています。 API グループ定義はワークスペース間で共有されますが、ワークスペースで登録または公開された API は、そのワークスペース内でのみ表示されます。
データセキュリティガード	データセキュリティガードは [グローバル共有] です。ワークスペースは、データセキュリティルールと秘密度レベルのセットを共有します。[Access Mode] パラメーターを Safe に設定した場合、データセキュリティガードで操作を実行できるのは、セキュリティ管理者ロールを持つメンバーのみです。

ワークスペース計画の戦略

ワークスペースは、会社の部門、ビジネスプロジェクト、データウェアハウス層に基づいて計画するか、ハイブリッドアプローチを使用します。

観点	部門別	ビジネスプロジェクト別	データウェアハウス層別
基準	ワークスペースの構成を、会社の組織構造と整合させます。たとえば、生産、マーケティング、人事、財務などの部門ごとにワークスペースを作成します。各ワークスペースは、当該部門のデータ開発とテーブル管理を担当します。	特定のビジネスプロジェクトに基づいてワークスペースを編成します。たとえば、四半期売上スプリント、生産安全点検、経営ダッシュボードレポートなどのプロジェクトごとにワークスペースを作成します。各ワークスペースは複数の業務システムからデータを取り込み、処理してプロジェクトを支援します。	データウェアハウスの層に応じてワークスペースを構成します。各層には 1 つ以上の専用ワークスペースを割り当てることができます。たとえば、データアクセス層、オペレーショナルデータストア (ODS) 層、データウェアハウスサマリー (DWS) 層などのデータ層ごとにワークスペースを作成できます。
シナリオ	部門の業務要件が明確で、チームメンバーが開発スキルを持ち、部門横断のデータ共有が最小限である場合に適しています。	複数部門にまたがる協業が必要な、優先度の高いビジネス主導のプロジェクトに適しています。	大規模データウェアハウス、企業共通のデータ層、データ中台アーキテクチャに適しています。
メリット	チーム構成が組織構造と整合し、安定性とデータセキュリティを確保できます。コンピュートとストレージのコスト配賦も明確です。	各ワークスペースのビジネス範囲が明確です。プロジェクト要件に応じてチームを柔軟に編成でき、データリネージも明確になります。	データアーキテクチャが明確で、データ共有が容易です。各層の特性に合わせて、開発スキルとリソース配分を最適化できます。
デメリット	データサイロを招き、コンピューティングとストレージの重複、ワークスペース間依存関係の複雑化、リソース競合の可能性につながります。	全体のデータアーキテクチャが不明確になり、プロジェクト間でビジネスロジックが一貫しない可能性があります。ワークスペース内のチーム構成が流動的になることで、データセキュリティリスクが高まる場合があります。	開発サイクルが長期化し、保守のパイプラインも延伸する可能性があります。標準モードでは、上流ノードを本番環境にデプロイする際に、下流ノードのコード変更が必要になる場合があります。
アーキテクチャの安定性	★★★★★	★☆☆☆☆	★★★★★
人員の柔軟性	★☆☆☆☆	★★★★★	★★★★☆
ビジネスの複雑性	★★☆☆☆	★★★★☆	★★★☆☆
データセキュリティ	★★★★★	★★☆☆☆	★★★☆☆
保守性	★★☆☆☆	★★☆☆☆	★★☆☆☆
データ共有	★★★☆☆	★☆☆☆☆	★★★★★

これらの戦略は、ハイブリッドモデルとして組み合わせることもできます。一般的なアプローチは、データウェアハウス層別にワークスペースを編成し、さらに各層を複数のワークスペースに分割することです。

データアクセス層 (STG)：stg_marketing_system や stg_production_management_system など、ソースアプリケーションシステム別に編成します。
- ノード：Data Integration ノードのみを含みます。
- テーブル：Time-to-Live (TTL) が短い生データのみを格納します。
- メンバー：各ソースアプリケーションシステムのデータベース管理者 (DBA) です。
- リソースの重点：Data Integration 用のリソースグループとストレージ容量です。
オペレーショナルデータストア (ODS) 層：ods_human_resources や ods_production など、部門別に編成します。データは部門内で標準化され、機密情報はクレンジングまたはマスキングされます。
- ノード：入力 1 つ、出力 1 つの SQL ノードのみを含みます。
- テーブル：ODS 層テーブルで構成されます。
- メンバー：部門ごとに割り当てられたデータクレンジング担当者です。
- リソースの重点：早い時間帯 (例：00:00 ～ 02:00) のスケジューリング用リソースグループとコンピュートエンジンリソースです。
データウェアハウスサマリー (DWS) 層：単一のワークスペースに集約するか、dws_customer_domain や dws_product_domain など、ビジネスドメイン別に編成します。
- ノード：複数入力、単一出力の SQL ノードのみを含みます。
- テーブル：DWS 層のファクトテーブルとディメンションテーブルで構成されます。
- メンバー：共通データ層の専任開発者です。
- リソースの重点：中間の時間帯 (例：02:00 ～ 05:00) のスケジューリング用リソースグループ、コンピュートエンジンリソース、およびデータ増加に対応するためのストレージです。
タグデータモデル (TDM) 層：単一のワークスペースに集約するか、ビジネスオブジェクト別に編成します。
- ノード：複数入力、単一出力の SQL ノードのみを含みます。
- テーブル：タグテーブルで構成されます。
- メンバー：共通データ層の専任開発者です。
- リソースの重点：遅い時間帯 (例：05:00 ～ 07:00) のスケジューリング用リソースグループ、コンピュートエンジンリソース、およびデータ増加に対応するためのストレージです。
アプリケーションデータストア (ADS) 層：ビジネスプロジェクト別に編成し、個別のビジネス施策ごとにワークスペースを作成します。
- ノード：SQL ノードと Data Integration ノードを含みます。
- テーブル：ビジネスアプリケーションを直接支援するテーブルに重点を置きます。
- メンバー：プロジェクトチームのメンバーです。
- リソースの重点：最も遅い時間帯 (例：07:00 ～ 09:00) のスケジューリング用リソースグループ、コンピュートエンジンリソース、および Data Integration 用のリソースグループです。