AWSのフルマネージド型 ETL サービス『AWS Glue』の紹介動画を観て来たるべきリリースに向けて情報収集してみる
昨年2016年12月の『AWS re:Invent 2016』で発表された、AWSによるフルマネージド型ETLサービス『AWS Glue』。イベント当日での発表では『今後リリース予定です』との内容に留まり、詳細なリリース時期等は明らかになっていませんが、イベントにてAWS Glueの内容について言及されたセッションが展開されており、関連するYouTube動画もアップされていました(特にこの動画について触れている人が居なかった)ので、今後来るであろう正式リリースに向けて事前に情報を把握、予習しておこうと思います。
ちなみに以下が2016年12月のre:Invent 2016 キーノートでAWS Glueが発表された際のYouTube動画シーンです。
目次
なぜAWSはETLサービスを作るのか？
なぜ、AWSはETLの領域に足を踏み入れたのか？
- AWSは多数のETL(サービス)パートナーが存在
- ETLを行う上で課題となっている事は、ETLジョブの70%が"手書き"のジョブ、即ち『ETLツールを使っていない』という事。実際のところ、クラウド上においてはその割合は90%以上になるだろう。
- 誰が手作業でコーディングするのか？手作業で書かれたコードは脆く、エラーを起こしやすい。 そして何よりメンテナンスが大変だ。
- また、これらのコードをメンテナンスしていく必要がある。
- データフォーマットが変更された時
- ソースを追加した時
- 対象スキーマの情報が変わった時
- データソースのデータ量が増大した時
- コードは柔軟であり、かつパワフルなもの。これらを扱っていくには以下のようなものが求められるだろう。
- ユニットテストが行える事
- 他のコードと一緒にデプロイが可能である事
- 開発ツールを知っている事
"ETL処理"は分析作業において最も大きな時間を占めている
- ETL/DWH/分析と分割した場合、この部分(ETL)だけで実に70%の時間を割いている形に。
- この割合で分析に避ける時間が増やせないと、データ量が増えれば増えていく程、"Dark data"(分析出来ていないデータ、とでも言えば良いでしょうか)が増えていってしまう。
AWS Glueの構成要素
AWS Glueのコンポーネント(構成要素)は以下3つ。
データカタログ
- データソースのメタデータリポジトリと互換性のあるHiveメタストア (※Hiveメタストアについては以下エントリ等をご参照ください)
- Hiveのメタストアについておさらい | OpenGroove
- HiveServer2, Hive metastore server, Hive metastore databaseの違い | swimmingpython blog
- テーブルやデータ型、パーティションの形式を推論する為にデータソースをクローリング
ジョブのオーサリング(編集、設定、各種統合)
- データを移動させるためのPythonコードを生成
- お気に入りのIDE環境での編集、Gitを用いたコードスニペットの共有
ジョブ実行
- Sparkコンテナでのジョブ実行 - SLAに基づいた自動的なスケーリング
- Glueはサーバレス - 利用費は消費したリソースのみに掛かる形に
データカタログ機能：データセットを発見し、整理する
- HiveメタストアAPIまたはHive SQLを使用してテーブルメタデータを管理
- Hive, Presto, Spark等のツールでサポートされる
- Apache Hive - Wikipedia
- 『Prestoとは何か，Prestoで何ができるか』 - トレジャーデータ（Treasure Data）公式ブログ
- Apache Sparkに手を出してヤケドしないための基本 ～「Apache Spark入門より」～ （デブサミ 2016 講演資料）
- 幾つかの拡張機能を追加
- 検索：データ検出のためのメタデータ
- 情報への接続：JDBC URL、資格情報
- 分類：ファイルの識別と解析
- バージョニング：スキーマの進化、メタデータの追加や更新に追従出来るようにテーブルメタデータをバージョン管理
- Hive DDL、バルクインポート、または自動的にクローラーを使って上記内容を実行する想定。
クローラー：データカタログの自動追加
- スキーマを自動推論
- 組み込みの分類機能がファイルタイプを検知し、スキーマ情報(レコード構造やデータ型)を抽出
- Glueのコミュニティで他のユーザーと情報を共有する事も可能に。GrokとPythonで構成？
- (Grokって単語が出てきましたが初耳。ググって見ましたがこれなのでしょうか？：thekrakken/grok: Grok is simple tool that allows you to easily parse logs)
- Hive形式のパーティションを自動検出し、同様のファイルを1つのテーブルにグループ化
- 新しいデータやスキーマ変更を検知するためにスケジュール上でクローラーを実行
- サーバレスな構造 - 費用はクローラ実行時に発生
クローラー：スキーマの自動推論
- S3オブジェクトを列挙
- ファイルタイプの特定とファイルの解析
- ファイル毎のスキーマを半構造化
- 統一されたスキーマを半構造化
パーティションの検出
- 半構造化されたログやスキーマの変更を処理するために、各レベルのファイル間でスキーマの類似性を推定・検知。
- スキーマの類似性検出：
- スキーマ類似性のヒューリスティック(※heuristic:必ず正しい答えを導ける訳では無いが、ある程度のレベルで正解に近い解を得る事が出来る方法。参考)
- 名前が合致：1ポイント
- データ型が合致：1ポイント
- 類似性のインデックスが0.7より大きい場合『合致』と判定
ジョブのオーサリング(編集、設定、各種統合)
- 独自のツールを使用してETLジョブをコード開発の様にオーサリング(編集、設定、各種統合)。
- コードの自動生成 -- 1.データカタログのソースとターゲットを選択 -- 2.Glueにより変換グラフとPythonコードを生成 -- 3.トリガー条件を指定
GlueのETLスクリプトは寛容かつ柔軟性を備えるもの
- 人間が読める：コードはPySparkのスケーラブルなプラットフォームで稼働。 -- Python Programming Guide - Spark 0.9.0 Documentation -- 生成されたコードは人間が読めるように、またETLグラフに対応するためのアノテーションが設定される。
- 寛容：エラーや不具合に直面した際の対応が可能 -- 冪等性：クラッシュした後のジョブ再起動は中断箇所から処理され、出力データは複製される事はない。 -- 異常データはその場でフラグが立てられ、ジョブはクラッシュしない。ユーザーは後続のエラー処理のために、任意のステップでエラーの情報をS3バケットに連携させる事が出来る。
- 柔軟性：複雑な半構造化データを処理す、ソーススキーマの変更に適応
Glueの変換処理は柔軟かつ適応性を持つもの
- 複雑さを備えた任意の半構造化オブジェクトをその場でリレーショナルなテーブルに展開
- ピボット配列やその他のコレクション型の情報を別テーブルに格納し、外部キー値生成
- ソーススキーマが変更された際にマッピングを変更し、必要に応じてターゲットスキーマを変更
Git統合：好きな環境で開発
- GlueはGitサービスを使ってジョブオーサリングや実行を統合管理する事が可能
- ジョブコードをGitリポジトリにPushすると、ジョブ呼び出しで自動的に最新のものを取得
- ETLジョブのカスタマイズはお好みのIDEで - 新しいツールを学ぶ必要無し
- 開発、テスト、リリースのプロセスに合わせてジョブを追跡し、バージョン管理を行えるように
Git統合：コミュニティを活用
- スクラッチで始める必要はありません
- 無数のユースケースを持つ200万人以上のAWSユーザー - あなたの必要とするものはどこかの誰かが持っています
- リソースやノウハウを共有／再利用／貢献するために、Gitサービスを使いましょう -- GitサービスはPublic/Privateいずれの形でも利用可能 -- 共有した分類器、変換用、ETLスクリプト等のリソースを検索出来るように -- コミュニティベースでのランキング -- オススメ、レビュー
ジョブのオーケストレーション(配備/設定/管理の自動化)＆リソース管理
フルマネージド・サーバーレスなジョブ実行を可能とします。
ジョブの構成とトリガー
- イベントベースの依存関係を用い、ジョブをグローバルに作成
- 組織の境界を越えた作業の再利用と活用が容易に
- 複数のトリガ機構を提供
- スケジュールベース
- イベントベース：データの可用性やジョブ完了
- 外部リソース：AWS Lambda
動的なオーケストレーション
- グラフ展開時にジョブを動的に追加：データに依存する形のオーケストレーションを可能に
- Glueによるフォールトトレラント(Fault tolerant:システムの一部に問題が生じても全体が機能停止するということなく(たとえ機能を縮小しても)動作し続ける)なオーケストレーションを提供：ジョブ失敗時の再試行
- 監視とメトリクス：デバッグのためのジョブ実行履歴とイベント追跡
サーバレスなジョブ実行
- サーバのプロビジョニング、構成、管理は不要に。
- ウォームプール：事前に設定構成されたインスタンス群(フリート)を使う事によりジョブの起動時間が短縮
- VPCとロールベースのアクセスの自動設定
- SLA及びコスト目標を満たすためにリソースを自動的に拡張
- 利用したリソースに対してのみ使用料金が発生
監視、メトリック、通知
- パイプラインや履歴の追跡
- レベルメトリックを変換するためのドリルダウン
- 処理された行
- 入出力スキーマ
- 通知：ジョブの状態、エラー、新しいデータ、およびスキーマの変更
まとめ
以上、AWS re:Invent 2016で発表されていたAWS Glueセッションの内容紹介エントリでした。2016年12月時点での発表内容であり、実際リリースされるであろう内容とは異なる部分も出てくるかと思いますが、おおよそ『このようなコンセプトである』『このような機能を備えており、こんな事が出来る』という方向性の部分についてはある程度把握出来たかなと思います。AWS Glueの正式リリース時期は不明ですが、来たるべきリリース時期に向けて必要そうとなる技術やトピック等(PySparkやGrok等はちょっと気になってます)は調べたり勉強しておきたいなと思う次第です。
