【AWS Data Lake】長期間のデータをバッチ分析する環境・バッチレイヤを構築してみた（ハンズオン2）
こんにちは。DA事業本部の春田です。
管理のしやすさや拡張性の高さで注目を集めている、次世代のデータ分析基盤Data Lakeについて、ハンズオンにトライしてみました。
本記事では、Lab4~Lab6のニアリアルタイムデータ分析環境（スピードレイヤ）を構築していきます。今回は前回のLab3が終了した状態で進めているので一部の環境構築は飛ばしていますが、ハンズオンではLab4からでも試せるように手配されています。
Lab4: アプリケーションログの永続化と長期間データの分析と可視化
Lab4: アプリケーションログの永続化と長期間データの分析と可視化
Lab4は、ログデータをKinesis Data FirehoseでS3に保存し、Glueでスキーマを作成し、Athenaでアドホック分析を行う環境を構築します。（月額費用がかかるQuickSightはスキップしました。）
まずはログデータを貯めるS3バケットを作成します。
次にKinesisの設定を行います。出力先に先ほど作成したバケットのパスを指定します。
KinesisからS3へアクセスするためのIAM Roleはこの場で作成します。
次に、EC2からKinesisにアクセスするためのIAM Roleを作成します。Lab1~3でも使用した handson-minilake に AmazonKinesisFirehoseFullAccess ポリシ＝をアタッチします。
ポリシーのアタッチが完了したら、EC2にログインしFluentd から Kinesis Data Firehose にログデータを送信するための設定を行います。FluentdのKinesisプラグインをインストールし、confファイルの中身を書きかえます。
S3バケットにログが吐き出されてることが確認できました。
次は、Glueを設定していきます。立ち上げる前に、既存のIAM Role handson-minilake に対して、 AWSGlueServiceRole と AmazonS3ReadOnlyAccess のポリシーを追加し、このIAM RoleをGlueでも使い回せるように信頼関係の設定を行います。
IAM Roleの設定が完了したら、GlueでS3バケット内のデータを解析するクローラを作成します。ログが出力されているS3バケットのパス、先ほど編集したIAM Roleを設定し、データベースを追加します。
作成したクローラを実行すると、自動的にスキーマ定義やテーブルを作成してくれます。
Glueで作成したテーブルに対して、Athenaでクエリを実行することができます。
データの前処理はGlueが自動でやってくれたので、すぐにAthenaでアドホック分析に持っていくことができました。シンプルなデータに対して、シンプルな分析をするにはこのアーキテクチャはもってこいですね。
Lab5: クラウドDWHを使用したデータ分析
Lab5では、Lab4で使用したGlueやAthenaを、Redshift Spectrumに代替したアーキテクチャです。DWHとして運用する場合の構成ですね。まずはCloudFormationでRedshift用のVPCを構築し、そこにRedshiftを立ち上げます。
立ち上げたVPCの VPC ID と サブネット ID は控えておきます。
Redshiftを起動させる前に、クラスターサブネットグループを作成します。
ここで、先ほど控えておいたVPC ID と サブネット IDを指定します。
作成したクラスターサブネットグループ handson-minilake-dwh に対してRedshiftを立ち上げます。
Redshiftが起動しました。マネジメントコンソールのQuery editorから接続チェックします。
無事繋がりました。次に、S3バケットからRedshiftへログデータをロードします。新しくIAM Roleを作成し、 AmazonS3ReadOnlyAccess ポリシーをアタッチします。
作成したIAM Roleの付与は、Redshiftクラスターの画面の See IAM roles から行います。
copy コマンドを流せば、S3からデータをロードできるようになりました。
Redshift Spectrumは外部スキーマとDBを作成する際、データカタログにAWS Glueのデータカタログを使用しています。Redshift Spectrumを使用するために、まずは先ほど作成したIAM Role handson-minilake-dwh に対して、 AWSGlueServiceRole ポリシーをアタッチします。
Redshift Spectrumのデータカタログから、外部テーブル用の外部スキーマとDBを作成し、外部テーブルのソースにS3パスを指定すれば、S3バケット内のデータを直接参照しているようなテーブルが出来上がります。
データソースの構造は違っていても、普通のRedshiftと同じ感覚でクエリ実行できる点が良いですね。
Lab6: サーバーレスでデータのETL処理
最後のLabでは、GlueのクローラでApache Parquet形式でS3に出力し、AthenaやRedshift Spectrumでクエリ実行するアーキテクチャを構築します。まずは、GlueにS3の書き込み権限を付与します。 AmazonS3FullAccess ポリシーを handson-minilake にアタッチします。
その後、Glueの出力先に指定するS3フォルダを作成します。
Glueの画面から「ジョブの追加」をクリックし、先ほど作成したS3フォルダをターゲットとし、Parquet形式で出力するジョブを作成します。
作成したジョブはその場で実行します。
S3にParquetの形式で出力されいればOKです。
次に、出力したParquet形式のデータに対して、Glueのクローラを作成し、データベースを作成します。
スキーマ定義が確認できたらOKです。
作成したDBに対して、Athenaでクエリを実行してみます。Lab5で出力したCSV形式と今回のParquet形式の比較では、Parquet形式の方がクエリ実行時間が短いことがわかりました。
最後に、GlueのジョブでParquetとパーティショニングを実行してみます。まずは、新しいS3フォルダを作成します。
次に、Glueのジョブの画面で先ほど作成したジョブを編集します。スクリプトの編集画面からパーティションの追加を行います。
ジョブの編集が完了したらすぐ実行させます。その後、出力先のS3フォルダに対して、Glueのクローラを作成します。
パーティションが機能しているようです。Athenaでクエリを実行してみます。
今回はデータ量が少ないため実行時間にほとんど差はありませんでしたが、データ量が多くなるほどパーティショニングは効果を発揮します。
最後に
Lab2~Lab6まで、全５パターンのデータ分析基盤を構築してきましたが、それぞれのユースケースを理解するにはとてもいいハンズオンでした。S3・Glue・Athena/Redshift Spectrumを使う辺りが、AWSのDatalakeスタンダードといったところでしょうか。
手順書もかなり細かく書かれており、終了後の後片付け方法まで用意されているので、一人でも簡単に実施できるかと思います。興味があれば、ぜひ試してみてください。
