この記事では、Data Tank を Data Tank 2.0 に置き換える際の Integration に関する変更点について説明します。Treasure Data はセキュリティと機密データの保護への取り組みの一環として、手順を開始する前にドキュメント全体をご確認いただくことを推奨します。
このセクションでは、Data Tank と Data Tank 2.0 の機能の差異について説明します。
| 機能 | ステータス | Data Tank 1.0 | Data Tank 2.0 |
|---|---|---|---|
| エンドポイント | 差異あり | 静的 IP アドレス | ライタエンドポイント URI。関連する IP アドレスは固定できません |
| データベース名 | 差異あり | datatank | aciddb |
| アクセス制御（ロールとスキーマ） | 差異あり | Treasure Data が tank_user および tank_integration_user アカウントを提供 | ユーザーとスキーマは Management UI で作成（アカウントは Access Keys と呼ばれます）。アクセス制御は UI 内で管理 |
| DDL ステートメント | 差異あり | 追加コマンド不要 | DDL 実行前に SET ROLE _owner_aciddb_<schema_name> を実行する必要があります |
| SSL 暗号化 | 差異あり | 強制されない | すべての接続で SSL が必要 |
| メンテナンスウィンドウ | 差異あり | 定期的なウィンドウなし。必要に応じてサポートが調整 | お客様が週次メンテナンスウィンドウを定義。その時間帯にパッチが適用されます（Data Tank 2.0 のメンテナンスについてを参照） |
| IP Allowlist のサイズ | 差異あり | 制限なし | 最大 200 件の IP アドレス |
| エンジン動作の差異 | 差異あり | PostgreSQL 12 ベース | Aurora PostgreSQL 12.13 ベース。一部エンジンの差異があります |
| カスタムポート番号 | 非対応 | デフォルト 5432。サポート経由でカスタマイズ可能 | ポート 5432 に固定 |
| ポートフォワーディング | 非対応 | サポートがポート 80、443、または 5439 を追加可能 | 非対応 |
| IPv6 Allowlist | 非対応 | IPv6 をサポート | IPv6 は非対応 |
| 拡張機能 | 非対応 | plpgsql、pgcrypto、cstore_fdw、mysql_fdw、tds_fdw、foreign_table_exposer がデフォルトでインストール済み | plpgsql と pgcrypto のみ利用可能。SERVER、FOREIGN DATA WRAPPER、FOREIGN TABLE、USER MAPPING オブジェクトは移行できません |
| Management UI | 新機能 | 利用不可 | 設定、ロール、スキーマの管理およびモニタリングのための Web インターフェース |
| ログ収集 | 新機能 | 利用不可 | PostgreSQL ログを Management UI で確認可能 |
| モニタリング | 新機能 | DataDog リンク経由でダッシュボードを提供 | Management UI でダッシュボードを直接利用可能 |
Data Tank 2.0（Aurora PostgreSQL 12.13）でサポートされている拡張機能の完全なリストについては、AWS Aurora PostgreSQL 拡張機能ドキュメントを参照してください。
Management UI では、データベース設定の構成、スキーマおよびアクセスキーの作成・管理、ログやダッシュボードの確認を単一のインターフェースから行うことができます。
| レガシーモニタリング | Management UI モニタリング |
|---|---|
 |  |
以下の 2 つの機能を使用して、Data Tank からレコードをインポートしたり、Hive/Trino クエリの結果を Data Tank にエクスポートしたりすることができます。
これらの Integration を使用するには、ほとんどの場合、事前に Authentication を作成する必要があります。
以下の Authentications がデフォルトで用意されています。以下の両方の Authentications において、データベースユーザーとして tank_integration_user が使用されます。
datatankdatatank_cstore
ユーザー定義の Authentications を作成することもできます。
Authentications はデフォルトでは用意されていません。新しい Authentications を作成する必要があります。
Data Tank からインポートするには、Bulk Load ジョブを実行する必要があります。このタイプのジョブを実行するには、以下のいずれかを使用します。Data Tank を Data Tank 2.0 に置き換える場合は、インポート元を Data Tank から Data Tank 2.0 に変更する必要があります。
- Sources（Treasure コンソール）
- CLI（Toolbelt、Workflow の
td_load>オペレーター）
Data Tank 用の既存の Sources がある場合、Treasure コンソールで Authentication に接続されている Sources を以下のように確認できます。画像の赤い矢印は、databank という名前の Authentication に関連付けられている Sources の数を指しています。
既存の Source が Data Tank 2.0 からインポートする場合、各 Source の Authentication は置き換えられないため、Data Tank 2.0 用の Authentication に関連付けられた新しい Source が必要です。Data Tank 2.0 からインポートする新しい Source を作成する際は、既存の Source のスケジュール実行を停止することを推奨します。
Authentication を使用して Plazma DB にインポートするために CLI を使用する場合、以下のように YAML ファイルで td_authentication_id オプションを使用します。インポート元を変更するには、このオプションに設定されている Authentication ID を変更する必要があります。また、database オプションなど他のオプションも変更する必要があります。
in:
type: postgresql
td_authentication_id: <your_authentication_id>
...YAML ファイルで td_authentication_id オプションを使用していない場合、以下の例のように Authentication の代わりに Data Tank の認証情報が指定されています。その場合は、Data Tank 2.0 の認証情報に置き換えてください。
in:
type: postgresql
host: xx.xxx.xxx.xxx
user: tank_integration_user
password: xxxxx
...以下の機能のいずれかを使用して、Hive/Trino ジョブの結果を Data Tank にエクスポートできます。これらの機能を使用して Data Tank にエクスポートしている場合は、エクスポート先を Data Tank 2.0 に変更する必要があります。
- Treasure コンソールのクエリエディター
- Workflow の
td_run>オペレーター - Workflow の
td>オペレーター - CLI（Toolbelt）
- REST API
以下のように Export Results を選択してエクスポート設定を構成できます。次に、既存の設定を置き換えるために新しい Authentication で再設定する必要があります。既存のエクスポート設定を削除したら、Data Tank 2.0 用の Authentication を使用して新しいエクスポート設定を行ってください。
DDL が必要な場合は、以下のように Set Role オプションに _owner_<database_name>_<schema_name> を設定する必要があります。
このワークフローオペレーターは既存の保存済みクエリを呼び出します。そのため、クエリエディターの場合と同じ操作を行う必要があります。
このワークフローオペレーターでは、以下のように result_connection パラメーターに Authentication 名を指定します。このパラメーターを Data Tank 2.0 用の Authentication に置き換えるとともに、他のパラメーターも変更してください。
+export_task:
td>: queries/sample.sql
result_connection: data_tank # Authentication 名
result_settings:
database: datatank
table: ...
...また、DDL が必要な場合は、以下のように set_role オプションを指定する必要があります。
+export_task:
td>: queries/sample.sql
result_connection: <your_authentication_name>
result_settings:
database: aciddb
table: ...
schema: <schema_name>
set_role: _owner_aciddb_<schema_name>
...result_connection に Authentication を指定しない場合は、以下のように result_connection と result_settings の代わりに result_url パラメーターを使用してください。
+export_task:
td>: queries/sample.sql
result_url: postgresql://tank_integration_user:xxx@......この場合、result_url パラメーターの値を変更してください。
また、DDL ステートメントが必要な場合は、クエリパラメーターとして set_role=_owner_aciddb_<schema_name> を追加してください。
CLI では、エクスポート情報を URL 形式で指定します。
たとえば、以下のように td query コマンドを使用してクエリの結果を Data Tank にエクスポートできます。エクスポート情報を -r オプションに直接指定するため、Data Tank 2.0 の設定を指定してください。
td query -d kazzy_test -w -r "postgresql://tank_integration_user:<password>@<ip_address>/datatank/<table_name>?mode=replace" "SELECT 1 AS col1;"以下の例のように、pg> オペレーターを使用して Workflow から Data Tank で任意のクエリステートメントを実行できます。
_export:
pg:
host: ....
port: 5432
database: datatank
user: tank_integration_user
schema: public
+access_data_tank:
pg>: queries/sample.sql
...Data Tank 2.0 でクエリステートメントを実行するには、pg> オペレーターのオプションに設定されている値を変更する必要があります。DDL を使用する場合は、DDL ステートメントの前に SET ROLE ステートメントを追加する必要があります。
サードパーティツールを使用して Data Tank に接続するには、ツールに接続情報を指定します。接続情報を Data Tank 2.0 のものに置き換えてください。