サラリーマンエンジニアブログ

大企業で働くなんちゃってITエンジニアのブログです。

AWS Glue 概要 (Data Catalog・Glue Crawlers・Glue ETLについて)

glue

2018/08/01 時点での記事になります。

目次

AWS Glue 概要

AWS Glueとは

「ETL処理の支援とデータカタログの管理をしてくれるフレームワークサービス」

◾️ポイント

  1. ETLツールではなく、あくまでもETL支援サービス
  2. そのため、Glueからの操作だけでは複雑なデータ変形はできない
  3. 複雑なデータ変形をするためには、Glueの機能によって自動生成されたコードをカスタマイズ(コーディング)しなければならない

主な機能

AWS Glueには主にData Catalog・Crawlers・ETLという3つの機能が存在する

Glue ETL

Spark Jobの作成、実行と管理をするサービス

  1. Python, ScalaのSpark scriptをジョブ登録して、実行、及び実行の管理。
  2. ジョブの実行はトリガー、オンデマンド、スケジュールを指定でき、 実行されたジョブのモニタリング、アラートを飛ばすことも可能
  3. Glue上でScriptの生成、編集可能
Glue Data Catalog

カタログ情報の管理・登録するサービス

  1. AWSサービス上に保存されたデータに対してのメタデータテーブルの管理・登録
  2. 扱えるカタログ情報はAurora、RDS、Redshift、S3、Athena、EMR、Redshift Spectrum、Hive Metastore
  3. スキーマ変更のバージョン管理可能
Glue Crawlers

Glue Catalogへカタログ情報自動登録サービス

  1. スケジュール設定に従って、指定したデータストアに接続し、データのスキーマを自動判断し、Data Catalogにメタデータテーブルを作成

 

Glue Data Catalog について

Glue Data Catalogについて説明する。

Glue Data Catalogが保持しているメタデータ

テーブルのメタデータをHive メタストアで管理。

  • プロパティ
  • データ型
  • データロケーション
  • 更新情報

 等を管理している。

メタデータのバージョンも保持しているので過去のものと比較できる。

メタデータの編集も可能。f:id:yarite_parker:20181231154149p:plain

Glue Catalogの活用例

AWS上のメタデータをGlue Catalogで集中管理

RedshiftやS3, RDS, DB on EC2のカタログ情報をGlue Data Catalogで一元管理することが可能。f:id:yarite_parker:20181231145437p:plain

 

Glue Crawlers について

Glue Crawlersについて説明する。

Glue Crawlersの概要図

f:id:yarite_parker:20181231155346p:plain

Crawlers ファイルの判別

分類子タイプ

分類文字列

コメント

Apache Avro

avro

ファイルの先頭から読み取って形式を判断します。

Apache ORC

orc

ファイルのメタデータを読み取って形式を判断します。

Apache Parquet

parquet

ファイルの先頭から読み取って形式を判断します。

JSON

json

ファイルの先頭から読み取って形式を判断します。

バイナリ JSON

bson

ファイルの先頭から読み取って形式を判断します。

XML

xml

ファイルの先頭から読み取って形式を判断します。AWS Glue は、ドキュメントの XML タグに基づいてテーブルスキーマを判定します。

Ion ログ

ion

ファイルの先頭から読み取って形式を判断します。

Combined Apache ログ

combined_apache

grok パターンを通じてログ形式を判断します。

Apache ログ

apache

grok パターンを通じてログ形式を判断します。

Linux カーネルログ

linux_kernel

grok パターンを通じてログ形式を判断します。

Microsoft ログ

microsoft_log

grok パターンを通じてログ形式を判断します。

Ruby ログ

ruby_logger

ファイルの先頭から読み取って形式を判断します。

Squid 3.x ログ

squid

ファイルの先頭から読み取って形式を判断します。

Redis 監視ログ

redismonlog

ファイルの先頭から読み取って形式を判断します。

Redis ログ

redislog

ファイルの先頭から読み取って形式を判断します。

CSV

csv

次の区切り記号をチェックします。カンマ (,)、パイプ (|)、タブ (\t)、セミコロン (;)、および Ctrl-A (\u0001)

Amazon Redshift

redshift

JDBC 接続を使用してメタデータをインポートします。

MySQL

mysql

JDBC 接続を使用してメタデータをインポートします。

PostgreSQL

postgresql

JDBC 接続を使用してメタデータをインポートします。

Oracle データベース

oracle

JDBC 接続を使用してメタデータをインポートします。

Microsoft SQL Server

sqlserver

JDBC 接続を使用してメタデータをインポートします。

Amazon DynamoDB

dynamodb

DynamoDB テーブルからデータを読み取ります。

※Zip, BZIP, GZIP, LZ4, Snappyといった圧縮形式でも分類可能

Crawlersによるカタログ情報自動更新

  • クローラーが自動的にスキーマを推測しカタログへ登録する

(クローラーがファイルタイプを識別し、どのような内容が含まれるのかを分類し、スキーマ、ファイルタイプ、パーティションを自動抽出しカタログへ登録する)

  • クローラーをスケジュール実行することで新しいデータやスキーマの変更を発見
  • クローラーを使わず手動で登録も可能
  • ログはCloudWatch Logsに出力される

Crawkersのスケジューリングについて

  • 毎日
  • 毎時
  • 曜日設定
  • 毎週
  • 月別
  • カスタム (Cronで設定)

ができる

f:id:yarite_parker:20181231154924p:plain

 

Glue ETL について

Glue ETLについて説明する。

Glue ETL ジョブ開発プロセス

下記のようなプロセスでジョブを開発する

  1. データソース選択 (ETL したいテーブルの選択)
  2. データターゲット選択 (データストア・形式・圧縮タイプ・ターゲットパス)
  3. マッピング  (列をどうするかを編集)
  4. コーディング (1 ~ 3によって自動生成されたコードの編集)
  • 1 ~ 3 でGUIでデータソース、ターゲット、列のマッピングを設定することでひな形が生成される。
  • csv ⇒ Parquetのフォーマット変換だけといった処理であればPythonコードの編集なしで実現可能。
  • サポートされている言語はPython2.7 or Scala

  • 自動生成されたコードはGlueの独自ライブラリを使用して書かれている。

Glue ETL ジョブスクリプトの基本 

f:id:yarite_parker:20181231160746p:plain

f:id:yarite_parker:20181231160909p:plain

DynamicFrameとDataFrameの違い

DynamicFrameとは

 DynamicFrameはAWS Glueで独自に定義されたデータ構造

特徴
  • Sparkで使われているDataFrameのようなテーブル形式でデータ
  • DataFrameと異なり、同一列内に複数のデータ型の混在が可能

※不正なデータが含まれてしまっているのを検知できるので非常に役立つ時がある。

DataFrameとの互換性
  • fromDF・toDFメソッドでDynamicFrame ⇔ dataFrameの変換が容易に可能
  • 同一列に複数の型が共存している場合は、toDFを使ってSparkのDataFrameには変換できない。修正してから変換する必要あり。
DataFrameとの使い分け

私は基本的にSparkDataFrameの方が慣れているので、最初にDynamicFrameからSparkDataFrameに変換して、その後の処理を書いている。

DynamicFrameの変換クラス・メソッド

DynamicFrameには変換のためのメソッドが用意されている。

AWS Glue PySpark 変換リファレンス - AWS Glue

Glue ETLにおけるライブラリの利用制約

ジョブ作成・編集時にs3からライブラリをインポート可能

  • Python 2.7 ライブラリ (v3はサポートされていない)

S3にライブラリファイルを置いてジョブ作成時に指定

S3のURLはカンマ区切りで複数設定可能

Pure Pythonのコードであるということ(Pandasの様なC言語拡張に依存するライブラリは利用不可)

  • Java ライブラリ
  • S3にJarファイルを置いてジョブ作成時に指定
  • Pure Javaもしくは Scala 2.11ベースのコードのみ

Glue ETL Jobのトリガー・実行状況

◾️ジョブ開始のタイミング

        – 先行ジョブ完了時

        – スケジュール

        – オンデマンド

ETL ジョブの実行状況

  • ETLジョブの状況は管理コンソールに表示される
  • ログはCloudWatch Logsに出力される

 

所感

  • Glue ETL,DataCatalog, Crawlersは全体的に使いやすいサービス
  • Glue DataCatalogはAthenaやEMRなど他サービスでも共有して使えるので非常に便利
  • DataCatalogは使うべきサービス
  • Crawlersはどこまで正確にテーブル定義してくれているかが未知数
  • Crawlersは探索にどのくらい時間がかかるのかも未知数で費用感が読めない
  • Glue ETLはコンセプトとしてはいいがPython3がサポートされていないのが難点
  • ETL ジョブは起動が遅く、ジョブが走るまでに5~10分くらいかかる。
  • DynamicFrameは気持ち悪いと思ったが、Spark DataFrameに容易に変換できるのであまり気にせずにコーディングできる。

結局...

  • Glue ETLはPython3がサポートされていないっていう時点で使用対象外 (コンセプトとしてはいい)
  • Data CatalogはDataLakeを管理する上で使用すべきサービス
  • Crawlersは未知数な部分が多いが、パーティションを自動的に切ってくれたり、試してみたいサービス。テーブル定義が間違ってたとしても手動で直せばいいので。

 

その他

EMRAWS Glue ETLの違い/使い分け

 

EMR

Glue

用途

汎用Hadoop/Spark環境

ETL処理に特化 Spark ベース

(Spark2.2.1をサポート)

スケールアウト

可能(ユーザ設計)

可能(パラメータ指定)

サーバ管理

数クリックで指定した環境が準備される

不要 (サーバレス)

S3へのアクセス

可能

可能

プログラミング環境

Hadoopエコシステム上の多様なアプリケーション

PySparkでETL処理を作成

コスト

Glueと比べて高い

EMRより安い

Python version

基本はv2.7

オプション設定でv3も可能

v2.7のみ

ライブラリ

インストールすればなんでも使用可能

Pure Python コードのライブラリのみ使用可能

EMRとの使い分け 

  • ビッグデータのETLはすべてGlueに集約してもいいかもしれない (Jobやメタデータの管理がEMRよりしやすい)
  • Spark以外のアプリケーションを使いた場合やアドホックな分析をしたい場合はEMR

使用可能リージョン

  • パリ
  • サンパウロ

以外全てのリージョンで使用可能

デフォルトのアカウント制限事項

デフォルトの制限はAWSサポートに連絡すれば、上限を引き上げてもらえる

リソース デフォルトの制限
アカウントあたりのデータベース数 10,000
データベースあたりのテーブル数 100,000
テーブルあたりのパーティションの数 100 万回
テーブルあたりのテーブルバージョンの数 100,000
アカウントあたりのテーブル数 100 万回
アカウントあたりのパーティションの数 10,000,000
アカウントあたりのテーブルバージョンの数 100 万回
アカウントあたりの接続数 1,000
アカウントあたりのクローラ数 25
アカウントあたりのジョブ数 25
アカウントあたりのトリガー数 25
アカウントあたりの同時ジョブの実行数 30
ジョブあたりの同時ジョブの実行数 3
トリガーあたりのジョブ数 10
アカウントごとの開発エンドポイントの数 5
アカウントあたりのセキュリティ設定の数 10
一度に開発エンドポイントによって使用される最大 DPU 数 5
一度にロールによって使用される最大 DPU 数 100

コスト

 1DPU : 4 vCPU,16GB of memory

ETL ジョブの料金体系

  • DPU 時間あたり 0.44 ドルが 1 秒単位で課金
  • デフォルト10 DPU (最低 2 DPU)

開発エンドポイントの料金体系

  • DPU 時間あたり 0.44 ドルが 1 秒単位で課金
  • デフォルト5 DPU (最低 2 DPU)

データカタログの料金体系

  • 最初の 100 万個のオブジェクトの保存は無料
  • 100 万個を超えて保存された場合、100,000 個のオブジェクトごとに毎月 1 ドル

クローラの料金体系

  • DPU 時間 あたり 0.44 ドルが 1 秒単位で課金され、クローラの実行ごとに最低 10 分

参考

dev.classmethod.jp