AWS Glue 実践入門：Amazon RedshiftのテーブルをETLする

先日に引き続き、クローラで作成したAWS Glue Data Catalog 上のRedshiftのテーブル定義を利用して、ETL Jobを作成します。ETL Jobの作成、そして実行時の挙動についても解説します。

このブログで利用するxxxx_ssbgz_customerテーブル定義の作成方法は以下のブログを御覧ください。

AWS Glue 実践入門：Amazon Redshiftのテーブルをクロールする

ETL Job の作成

ジョブとは、抽出、変換、およびロード（ETL）作業を実行するために必要なビジネス・ロジックのことです。ジョブの実行は、イベントによってスケジュールまたは駆動されるトリガによって開始されます。

Job properties

ジョブの名前やIAM Role等の基本情報を設定します。

Redshiftに対するクエリ実行が主なので、画面下のScript libraries and job parameters(optional)を開いて、Concurrent DPUs par job runの値をデフォルトの「１０」から最小値である「２」に変更しています。

Data source

先日作成したRedshiftのデータソースとなるxxxx_ssbgz_customerテーブルを指定します。ssbgzスキーマのcustomerテーブルが入力データとなります。

Data target

新しいテーブルに対してＥＴＬした結果を出力するので、先日作成したRedshiftのredshiftdbConnectionを指定します。入力と出力のConnection指定が同じだと上書きになるのではと考えるかもしれませんが、接続ユーザー（root）のデフォルトスキーマのcustomerテーブルに対して出力されるので同じテーブルに対する追加にはなりません。

Schema

全く同じテーブルを出力しても面白くないので、c_nationカラムの削除します。

Review

入力項目の確認です。

生成されたETLスクリプト（pyspark）

生成されたETLスクリプト（pyspark）がエディタでオープンされた状態で表示されます。

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

## @params: [TempDir, JOB_NAME]
args = getResolvedOptions(sys.argv, ['TempDir','JOB_NAME'])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
## @type: DataSource
## @args: [database = "default", table_name = "xxxx_ssbgz_customer", redshift_tmp_dir = TempDir, transformation_ctx = "datasource0"]
## @return: datasource0
## @inputs: []
datasource0 = glueContext.create_dynamic_frame.from_catalog(database = "default", table_name = "xxxx_ssbgz_customer", redshift_tmp_dir = args["TempDir"], transformation_ctx = "datasource0")
## @type: ApplyMapping
## @args: [mapping = [("c_custkey", "int", "c_custkey", "int"), ("c_phone", "string", "c_phone", "string"), ("c_mktsegment", "string", "c_mktsegment", "string"), ("c_address", "string", "c_address", "string"), ("c_name", "string", "c_name", "string"), ("c_region", "string", "c_region", "string"), ("c_city", "string", "c_city", "string")], transformation_ctx = "applymapping1"]
## @return: applymapping1
## @inputs: [frame = datasource0]
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [("c_custkey", "int", "c_custkey", "int"), ("c_phone", "string", "c_phone", "string"), ("c_mktsegment", "string", "c_mktsegment", "string"), ("c_address", "string", "c_address", "string"), ("c_name", "string", "c_name", "string"), ("c_region", "string", "c_region", "string"), ("c_city", "string", "c_city", "string")], transformation_ctx = "applymapping1")
## @type: ResolveChoice
## @args: [choice = "make_cols", transformation_ctx = "resolvechoice2"]
## @return: resolvechoice2
## @inputs: [frame = applymapping1]
resolvechoice2 = ResolveChoice.apply(frame = applymapping1, choice = "make_cols", transformation_ctx = "resolvechoice2")
## @type: DropNullFields
## @args: [transformation_ctx = "dropnullfields3"]
## @return: dropnullfields3
## @inputs: [frame = resolvechoice2]
dropnullfields3 = DropNullFields.apply(frame = resolvechoice2, transformation_ctx = "dropnullfields3")
## @type: DataSink
## @args: [catalog_connection = "redshiftdb", connection_options = {"dbtable": "xxxx_ssbgz_customer", "database": "xxxx"}, redshift_tmp_dir = TempDir, transformation_ctx = "datasink4"]
## @return: datasink4
## @inputs: [frame = dropnullfields3]
datasink4 = glueContext.write_dynamic_frame.from_jdbc_conf(frame = dropnullfields3, catalog_connection = "redshiftdb", connection_options = {"dbtable": "xxxx_ssbgz_customer", "database": "xxxx"}, redshift_tmp_dir = args["TempDir"], transformation_ctx = "datasink4")
job.commit()

ETL Jobの実行

では、作成したジョブを実行します。redshiftetlジョブを選択して、Run Jobを実行します。

17分後にRun StatusがRunningからSucceededに変わり、ジョブの正常終了が確認できました。

Redshiftでは以下のテーブル作成され、データがロードされていることが確認できました。Data CatalogのString型はvarchar(65535)に変換されています。なお、ターゲットテーブルが存在しない場合は以下のようなテーブルを作成しますが、事前にテーブル作成しておくとデータロードのみであることを確認しています。

# \d xxxx_ssbgz_customer
Table "public.xxxx_ssbgz_customer"
Column | Type | Modifiers
--------------+--------------------------+-----------
c_custkey | integer |
c_phone | character varying(65535) |
c_mktsegment | character varying(65535) |
c_address | character varying(65535) |
c_name | character varying(65535) |
c_region | character varying(65535) |
c_city | character varying(65535) |

# select count(*) from xxxx_ssbgz_customer;
count
---------
3000000
(1 row)

補足

Redshiftで実行されているSQLを確認したところJDBCでデータをUNLOAD/LOADするのではなく、RedshiftのUNLOAD/COPYコマンドが実行されていることが確認できます。

• UNLOAD

UNLOAD (
'SELECT "c_custkey", "c_name", "c_address", "c_city", "c_nation", "c_region", "c_phone", "c_mktsegment" FROM ssbgz.customer '
) TO 's3://yyyy/tmp/7354d60e-c21e-4a84-9e9e-1a24e251d4b3/' WITH CREDENTIALS '' ESCAPE

• COPY

COPY xxxx_ssbgz_customer FROM
's3://yyyy/tmp/b70ea623-0bc6-4e78-97af-d2b699913b09/' CREDENTIALS '' FORMAT AS CSV DATEFORMAT 'YYYY-MM-DD HH:MI:SS' NULL AS 'null'

つまり、ソーステーブルをS3にUNLOADした後、S3ファイルを変換したファイルを作成、ターゲットテーブルにデータをCOPYするという流れでした。Job propertiesのTemporary directoryに指定したフォルダの下に中間ファイルが作成されたままになるので削除は定期的に実施したほうが良いでしょう。

最後に

Amazon Redshiftに対するETL Jobでは、Redshift にとって最適なUNLOADやCOPYコマンドが内部的に実行されていました。また、ターゲットテーブルが存在しない場合は、AWS Glue Data Catalogのテーブル定義情報を基にスキーマ変換まで自動化されていることが確認できました。今回はRedshift-Redshift間のETLでしたが、中間ファイルをS3で持つので、S3-Redshift間やRedshift-S3間、その他のDB間との組み合わせでもS3を介して、ETLができる仕組みになっていることがご理解いただけたと思います。その他に簡単なデータのロードやDBマイグレーションにも利用できるのではないかと考えられます。