Glueで始めるAthena入門

2018年3月からクラウド基盤事業部の T.S です。 初投稿です。

GlueとAthenaを使って、S3に保管したログを分析してみます。 サーバーレスのログ分析基盤と言えますが、まずは省エネで始められる構成をご紹介します。

AWSサービス構成
Athenaの仕組み
テーブル作成の事前処理
Athenaテーブルの作成
Athenaで分析クエリを実行
最後に

 

AWSサービス構成

対象データは、毎月のAWS請求費用(csvファイル)にしました。

Cost Explorerを有効化すると、S3に自動で出力されるcsvファイル群です。

AWSサービス構成

Amazon Athena

S3をデータソースとして、SQLクエリの実行環境をサーバレスで提供しているサービスです。
内部アーキテクチャはPresto、メタデータ管理はAWS Glue、UIは標準SQLです。
サーバレス構成の分析基盤、という位置づけですが、分析を始める際にはテーブルを定義する必要があり、今回はそこでGlueを使用しています。

Amazon Glue

クローラ機能によって様々なデータストアからテーブルを定義でき、ETL機能も持つサービスです。Apache Hiveによるメタデータ管理、Apache SparkによるETL処理、ETLのジョブ機能、があります。
S3のほかRDSやRedshiftがクロール対象としてサポートされ、データ形式スキーマ定義はAWS Glueがデータストアをクローリングする際に自動的に推論し、分類します。 データストアから自動的に作成されたメタデータ定義はデータカタログと呼ばれ、ユーザ自身がら編集することも可能です。
ETLやジョブ機能がありますが、本記事では割愛します。

 

本記事では、Athenaの解説を中心にしていきます。

Athena自体の仕組みについてや、テーブル作成の事前処理ポイントやAWS Glueによるテーブル作成をメインで扱います。
基本的な全体の流れは次の通りです。

 

▼調べたいログをS3に保管する

本記事では省略しますが、今回はCost Exploreの有効化をしています。
AWSサービスが持つログ記録機能の多くは、S3への出力がサポートされているため、今回のようにGlueやAthenaを使い始める条件が揃っています。
ドキュメントのAWS のサービスのログのクエリには、サンプルが色々載ってます。

▼テーブル作成の事前処理
ケースバイケースのため詳細は割愛しますが、元データ(今回はcsvファイル)をLambda関数で事前処理を自動実行しています。

▼テーブルの作成
AWS Glueでクローラを作成・実行します。

▼Athenaで分析クエリを実行
クローラで作成されたテーブルに対して任意のSQLクエリを実行し、欲しいデータを取得します。

Athenaの仕組み

詳しくはAWSのBlackbeltで、というのもつまらないので、クエリエンジンのPrestoを少し調べてみると、prestodb.github.ioに分かりやすい構成図がすでにありました。

OSSコミュニティのおかげですね。

Athenaの仕組み 白状すると、上述のAWSサービス構成はこの構成図に配置を合わせています。

「Hive Metastore」がAWS Glue、「HDFS」がS3、その他コンポーネントがAthenaに相当します。分散システムがマネージドサービスで使えるのは、使いごたえあります。

 

テーブル作成の事前処理

Cost Exploreの出力先バケットにPUTイベント

→(Lambda関数)

→事前処理したcsvファイルをAthenaデータソース用のバケットに出力、

という流れで自動化しています。事前処理が完了したS3バケットは、こんな感じです。

S3バケット

分析クエリの効率もありますが、データソースを準備したりテーブルを定義したりする段階でも、次の点が性能面での設計ポイントになります。
パーティション(where句で頻繁に使用するキー)の生成
・ファイル圧縮(Snappy、Zlib、GZIP、LZO)
・列指向(Parquetフォーマット)
・データソースのファイルマージ(ファイル数は減らしてファイルサイズを増やす)

どれもI/O効率をあげるため、と言えます。
マネージドすぎて分かりづらいですが、DBチューニングの考え方に近い気がします。

Athenaテーブルの作成

Glueのダッシュボードから「クローラの追加」でクローラを作成します。

Glueのダッシュボード

「クローラの実行」をクリックすると、Glueが指定したデータソースに接続し、メタデータ(Athenaテーブル)を自動的に作成します。

サービス仕様としては、クローラ設定でテーブルが所属するデータベースは定義できますが、テーブル名はデータソース(ここではS3バケット名)がそのまま反映されます。

また、クローラの実行ログはCloudWatch Logsに出力されます。正常実行時は、以下のような内容でした。

2019-04-17
17:59:51
[45822449-db05-4348-9a5c-013807a6c238] BENCHMARK : Running Start Crawl for Crawler test-billing-csv
18:00:15
[45822449-db05-4348-9a5c-013807a6c238] BENCHMARK : Classification complete, writing results to database glue
18:00:15
[45822449-db05-4348-9a5c-013807a6c238] INFO : Crawler configured with SchemaChangePolicy
{
"UpdateBehavior": "UPDATE_IN_DATABASE",
"DeleteBehavior": "DEPRECATE_IN_DATABASE"
}
18:00:37
[45822449-db05-4348-9a5c-013807a6c238] INFO : Created table $$テーブル名$$ in database glue
18:00:38
[45822449-db05-4348-9a5c-013807a6c238] INFO : Created partitions with values [[2019, 03], [2019, 04]] for table $$テーブル名$$ in database glue
18:00:46
[45822449-db05-4348-9a5c-013807a6c238] BENCHMARK : Finished writing to Catalog
18:01:54
[45822449-db05-4348-9a5c-013807a6c238] BENCHMARK : Crawler has finished running and is in state READY

 

クローラによって自動生成されたテーブルは、Athenaのダッシュボードにも表示されます。

ただ、詳細な設定内容の確認やメタデータ定義の編集はGlueのダッシュボードからのみ可能です。

Glueのダッシュボード

なお、データソースの事前処理がAthenaパーティションの形式に沿っていれば、Glueクローラは自動的にパーティションまで生成します。これ便利です。

Glueクローラ

 

Athenaで分析クエリを実行

Athenaのクエリ実行はAPI経由でもサポートされているため、Lambda関数で分析結果を外部連携することも可能です。ここまでくると、SQLクエリの効率や分析業務を進めていくだけです。UIをご覧の通り、SQLぢからが試されます。

Athenaのクエリ実行

 

最後に

分析基盤といってもエンジニア以外のユーザがAthenaを使用することは、UIとして考えづらいです。ここは考えどころですが、QuickSightのユースケースにつながる部分でもあります。

また、Athenaのクエリ実行環境はPrestoですが、先にご紹介した通り、元来はHDFSをデータソースとする場合が多いです。 オブジェクトストレージ(S3)も分散システムではある一方でファイルシステムではないため、どうやって対応しているのかと思って探していたら、良い記事がありました。

  Data Lakes without Hadoop

クラウド技術に限らず、良しとされるアーキテクチャは技術の進展にならって変化しているようです。今後も、AWSサービスをOSS関連で記事にしていきたいです。

 

 

 

このブログの著者

 

 

AWS相談会