/home/by-natures/dev*

データ界隈で働くエンジニアとしての技術的なメモと、たまに普通の日記。

2019/01/15 Glue における SQL 中心アーキテクチャ ETL、他

昨日居酒屋で飲んでいたら(かぶら屋 美味しいです、おすすめ)、隣の席の人が UberEATS の使いすぎで他の方から怒られていました。僕の友人でも UberEATS や LINE デリマを良く使う人はいるので、別にいいんじゃないかなと思ったら、どうやら人はタクシーやデリバリーなどの細かい出費の積み重ねで借金をしてしまった?ようです。

借金とは言わないまでも、昔はなかった通信費は今やもはや固定費になっているし、便利さと引き換えに可処分所得は減っているという記事をどこかで見たような気がしたなぁと思った週末でした。

「AWS Glue と SQLのみで、サクッとETL(Extract、Transform、Load)するJobを作成する」

dev.classmethod.jp

Glue のジョブはGlue が提供する Transform を利用しないといけないと思っていましたが、 入出力の雛形ジョブだけ Glue に用意して、SparkSQL を外部から設定できるようにすれば「SQL中心アーキテクチャ」による ETL が簡単に実現できるといった内容です。

外部(S3 上に置いておく想定)の設定ファイルは以下のようなものです:

{
    "source_database":"default", 
    "source_table":"elb_parquet_20150101", 
    "target_s3_url":"s3://<mybucket>/tmp/", 
    "target_format":"parquet", 
    "sql":"SELECT elb_name, count(*) as request_count FROM stagingtable group by elb_name order by elb_name"
}

これを S3 から読み込んで JSON パースして Glue 上で SparkSQL を実行します。これだと1テーブルしか扱えないので複数テーブル与えられるようにフォーマットを変更したいですが、これなら SQL だけ書ければ ETL 処理が実現できるので扱える人が増えそうです。

ただ、ETL ジョブの依存関係を解決しようとすると Glue だけでは難しそうです。Glue にも「トリガー」があって、他のジョブへ依存するジョブを作成できるのですが、パラメータレベルでは対応していないので、上のように SQL をパラメータ経由で渡すような運用だと「トリガー」では対応できません。

「Glueの使い方的な⑦(Step Functionsでジョブフロー)」

こちらも分かりやすい記事でした、Glue + Step Functions の組み合わせです。Glue の呼び出しには Lambda を使っています。

qiita.com

ワークフローが巨大だと GUI でも JSON でも扱いづらそうなので、ある程度意味のあるまとまりでまとめておく程度にした方がよさそうでしょうか。。CloudWatch を使えばワークフロー間の連携も実現できそうなので引き続き調べます。