AWS Glue 実践入門:Amazon RedshiftのテーブルをETLする
先日に引き続き、クローラで作成したAWS Glue Data Catalog 上のRedshiftのテーブル定義を利用して、ETL Jobを作成します。ETL Jobの作成、そして実行時の挙動についても解説します。
このブログで利用するxxxx_ssbgz_customerテーブル定義の作成方法は以下のブログを御覧ください。
ETL Job の作成
ジョブとは、抽出、変換、およびロード(ETL)作業を実行するために必要なビジネス・ロジックのことです。ジョブの実行は、イベントによってスケジュールまたは駆動されるトリガによって開始されます。
Job properties
ジョブの名前やIAM Role等の基本情報を設定します。
Redshiftに対するクエリ実行が主なので、画面下のScript libraries and job parameters(optional)
を開いて、Concurrent DPUs par job run
の値をデフォルトの「10」から最小値である「2」に変更しています。
Data source
先日作成したRedshiftのデータソースとなるxxxx_ssbgz_customerテーブルを指定します。ssbgzスキーマのcustomerテーブルが入力データとなります。
Data target
新しいテーブルに対してETLした結果を出力するので、先日作成したRedshiftのredshiftdb
Connectionを指定します。入力と出力の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マイグレーションにも利用できるのではないかと考えられます。