この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
おはようございます、もきゅりんです。
皆さん、Glue 使ってますか？
Glue は恐ろしいやつです。
影の支配者です。
なぜなら Athena や LakeFormation は Glue の恩恵によって存在しているといっても過言じゃないからです。
(LakeFormation は Glue の拡張機能だと公言されていますし)
そんな Glue ですが、自分は何度読んでみても便利な機能っぽいんだけど、何だか分かったような分からないような気になってました。
今回はそのモヤモヤ感を払拭すべく、使い方からではなく、機能と構成要素からイメージを整理しようと考えました。
想定される読者としては、自分と同じように、 Glue が何かいい感じにETLしてくれるのは知ってる...けどよくイメージ湧いてない、という方、または Glue 全然知らないけど、 どんなものか興味がある、という方も OK です。
ちなみに、弊社ブログでも Glue の記事は多いのですが、入門的な記事としては下記が参考になります。
フルマネージド＆サーバレスなETLサービス「AWS Glue」の仕組みと構成要素を理解する
では、1つずつ進めていきます。
Glue がやること
Glue のやることはこれだけです。
元になるデータソースからデータを取得して、もちょもちょ(変換)して、ターゲットとなるデータソースに送り込みます。
(公式に似たような図あるだろ、と思ったそこのあなた！図の中に色々な概念が混ざっていると気が散るし、混乱を招きかねないので、まずはシンプルな理解していきましょうね！お願いします！)
ということで、データソースとデータターゲットをつなぐサービスなのは理解できました。
じゃそれってどうやってやるの？という疑問が当然湧きますよね？
そのイメージを補強するために、紀文さんの「練りものができるまで」を参考としましょう。
練りものの原料は魚です。
そして、ちくわやかまぼこ、はんぺんやさつま揚げのような練りものの主要な原料はすり身です。
そのすり身から、様々な加工を経て、様々な練りものになります。
ちくわとかはんぺんとか、さつま揚げとか。
このすり身から練りものの関係は、データレイクの下図のような関係と類似していますよね。
(すり身にしておけば、焼いても、揚げても、蒸しても、ゆでても好きなように好きなように調理ができるわけです。)
つまり、練りものの例の場合、データソースは魚です。
そして、データターゲットはすり身です。
この工程は、具体的にはこのようになっているようです。
このような処理を Glue が対応してくれるわけですね。
魚をすり身にする例によって、データソースからデータターゲットに対して必要な工程な処理が施されているイメージが湧いたかと思います。
では処理はどのようにして行われるのでしょう。
Glue の構成要素
魚からすり身にしていく工程を考えると、パッと思いつく限りでも下表の左列のような機能が必要になってくると思います。
そして、右列がそれに対応する Glue の構成要素です。
| 魚からすり身にする処理 | Glue の構成要素 |
|---|---|
| 原料となる魚の品質管理 | データカタログ |
| 各処理機械の運用管理 | サーバレスエンジン(ジョブ) |
| 各処理機械の工程管理 | オーケストレーション |
さらに、Glue の構成要素の機能の概要と特徴が下表になります。
(他にもできることはありますが、あくまで Glue のイメージを明瞭に掴む、が主旨なので省略します)
| Glue の構成要素 | 機能の概要 | 主な特徴 |
|---|---|---|
| データカタログ | AWS マネージドのGlue データカタログ または 自前のHiveメタストア で管理することができる(相互に移管もできる) | データカタログにメタデータを作成するクローラー。クローラは組み込み分類子、カスタム分類子の利用が可能。 |
| サーバレスエンジン(ジョブ) | サーバレス, 中規模処理のPython Shell, 大規模処理のSpark。 | コードは自動生成、自前で作成、既存コード利用が可能。 |
| オーケストレーション | スケジュール実行、ジョブイベント実行、手動実行が可能 | 一連の工程を視覚的に生成、モニタリングできるワークフロー機能がある。 |
データソースからデータターゲットへの処理イメージ、そして処理を実行している Glue の構成要素のイメージが湧いてきたでしょうか。
湧いてきたら、ここでようやく公式の図の登場です。
こちらはデータストア(データソース元となる概念) *1からクローラが組み込み分類子、カスタム分類子によってデータカタログにメタデータ(データのデータ)を記述しています。
なお、データストアとしては下記の指定が可能です。
- Amazon S3
- Amazon RDS
- Amazon Aurora
- Amazon Redshift
- Amazon DynamoDB
- Amazon VPC内のRDB on Amazon EC2(Oracle、Microsoft SQL Server、MySQL、PostgreSQL)
- JDBC接続可能なオンプレミスDB
- Amazon Kinesis Data Streams (非クローラサポート)
- Apache Kafka (非クローラサポート)
データターゲットが下記サポートされています。
- Amazon S3
- Amazon Relational Database Service (Amazon RDS)
- JDBC アクセスが可能なサードパーティのデータベース(e.g. Aurora, Redshift, etc)
そして、 Glue の全体イメージです。
最初にこの図を見ると、ふんふん、なるほど？ってなると思うのですが、あまり頭に残らないと思います。(そんなことないですか？)
でももう大丈夫、イメージが強く定着できました！(はず)
あとは、各工程において、自身のやりたいことや必要な処理を仕様に応じて適切に設定していくだけですね！
最後に
如何でしたでしょうか？
中間処理が Glue のお仕事なので、原料(今回だと魚)があっても、やりたいゴール(練りもの)が見えていないと Glue の出番はありません。
実際の業務で携わっていかないと、原料(例えばS3)はあるけど、ゴールのイメージが不明瞭だから、Glue に触れる機会も少なく、その結果、Glue ってよくわからないなあ、という印象になるだと感じました。
原料とゴールがセットになった状況の際、振り返ると Glue がいて、 その存在を頼もしく感じるのだろうと思います。
以上です。
どなたかのお役に立てば幸いです。
参考:
脚注
- データストアとデータソースの概念が、ドキュメントによって若干ズレており、混乱を招くような記述だと感じています。個人的にはデータソースとは、データカタログによって管理されているデータ(データストア)を指しているように考えています。 ↩
2
