[レポート] AWS User Group Meetup in Berlin (2019.08.14.) 〜 Athena で生データを扱う

Ito ma

2019.08.14 12:13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Guten Tag、ベルリンより伊藤です。

昨日、Berlin の AWS User Group Meetup に参加してきましたのでブログを書きます。

AWS からの連絡

イベント情報

2019年9月9日(月)にハンブルグで AWS Community Day があります！

トークセッション: SQL on raw data - Michael Muck (Saxonia Systems)

前半・後半で2つのセッションがありましたが、今回は私用につき前半のみしか参加できませんでした。

now Michael Muck (https://t.co/0SfzW7aFro) from @SaxoniaSystems talks about "SQL - on raw data?!" with Amazon Athena.#AWS #UserGroup #Meetup #Berlin https://t.co/iVVUWEjJ1p pic.twitter.com/HZ9lsVWJy2

— Andreas Grimm (@_andreasgrimm) August 13, 2019

Athena とは

インタラクティブなクエリサービス
標準SQLを使用（Presto SQL エンジン、テーブル操作にはApache Hive DDL）
S3へ直接データ分析（ログファイル、監査ログ、JSON/CSV/Parquet/ORC）
サーバーレス
データ読み込みやETLは不要（※）

※ETLは不要だが、実行結果を別のバケットに入れることでETLすることは可能

利用例として、ドイツではBetriebsratにより社員が行う操作を常に追跡・監視してはいけないと定められているため、常に統計や分析を取ることはできないが、保管した監査ログを緊急時に分析するというようなケースを説明していました。

他にも JSON フォーマットでS3バケットに溜め込んでるデータがある場合に、長期的に分析を行うならRedshiftなどテーブル設計から構築することも考えられるけど、短期的に情報が必要な場合に活用できるとのことです。

使い方

対象ファイルには、例えば、ELBアクセスログ、2570ファイル、1TB

テーブル作成
- CREATE TABLE（※ AthenaではデータはS3を読み込み、テーブル削除時も元データは残るため、CREATE TABLEテーブルは常にEXTERNAL）
- SERDEPROPERTIESでデータ構造を指定する（詳細はCREATE TABLEドキュメント）
- LOCATIONでバケットの場所(パス)を指定
クエリ実行
- 30分実行したけどタイムアウトしてしまう可能性もあるので、LIMIT推奨。
- 15秒〜數十分、サーバーレスでマネージドサービスのため、パフォーマンスの詳細は公開されていない
- 別タブで同時にクエリ実行が可能

料金

Athena はスキャンしたデータ量に対してのみ課金
- スキャンされたデータに基づいて課金されるため、DDLクエリやコンピューティングにはお金が発生しない
- そのため、タイムアウトしてしまっても課金なし
- JOINも実行可能だが、すべてのスキャンデータが課金対象となるのでお金がかかる
加えて、通常の S3 のストレージ、リクエスト、データ転送料金
- スキャン対象のS3データの保存方法によって変わる（IAだとアクセスによりお金がかかる等）

詳しくはAthenaの料金ページから。

最適化

パーティションでスキャン対象のデータを減らす
- CREATE TABLE 時に PARTITIONED BY で S3 prefix を使ってパーティションを設定（日付など）
- または、ALTER TABLE ADD PARTITION でパーティションの追加
- ただしパーティション指定はLambda関数などを使用して自動でやるべし（参考Dev.IOブログ）
- 参考: Dev.IOのパーティションに関するブログ
GZIPでデータを圧縮する
- デモではSELECTにかかる時間はほとんど同じで、2.9GB→397MBに減少
Apache Parquet のカラムナーフォーマットを使用する
- デモではさらに小さい18.44MBに
- STORED AS PARQUET を指定するだけで、SERDEの指定は不要
- S3 が year=2015/month=1/day=1 のようにHive形式パスだと、MSCK REPAIR TABLE を実行するだけで自動的にパーティション検出してくれる
- 参考: Dev.IOの試してみたブログによれば、実行時間はCSVの方が速いケースが多いようだが、スキャンデータは削減され利用費に優しいよう

※なお、SELECTで行を1つ指定したからといってスキャンされるデータが減るわけではない。

メリット・デメリット

Pros
- データレイクのインサイト
- 即座のクエリ実行
Cons
- S3バージョニングがサポートされていない
- 既にDWHがある
- 結果キャッシュなし、2回実行したらそのまま2回分課金される
- 暗号化していたら同じリージョンのみ
- ZIPやパーティショニングしていないと、稀にS3のGET制限にかかる可能性がある
- バケット内のプレフィックスごとに1秒あたり5,500 GET/HEADのリクエスト（上限緩和不可）
- 発生はごく稀ではあるけれど、現時点ではメッセージなども出ないため結果データが不足していることに気づけない可能性がある...

最適なクエリ実行ができるよう、あらかじめデータ整備はしてS3に保存しておいた方が良い。例えば、DDoS攻撃が発生した時に急ぎで調査する必要があるケースなどを想定して。一方、定期的にクエリ発行や既存でやりたいクエリがあるケースでは、RDSやRedshiftなど通常のDWHを使うことを推奨とのこと。

終わりに

後半のセッションは Elmar Weber 氏による "Using Infrastructure to Drive Culture - How Amboss enabled autonomous teams with the right technology and DevOps" でした。ご紹介だけ。

now Elmar Weber (@weberelm) from https://t.co/U84TvXopZh talks about "Using Infrastructure to Drive Culture - How Amboss enabled autonomous teams with the right technology and DevOps”#AWS #UserGroup #Meetup #Berlin https://t.co/iVVUWEjJ1p pic.twitter.com/x6DZWe5eKH

— Andreas Grimm (@_andreasgrimm) August 13, 2019

Berlin AWS User Group Meetup、毎月開催しています。参加は無料です。

今回は Saxonia Systems AG のホストにより、 Hauptbahnhof の近く、川沿いの素敵なオフィスでした。

余談ですが、その Saxonia Systems さんのWebサイトドメインが普通に会社名とかではなく "So geht Software" (ドイツ語で「ソフトウェアとはこうだ」) というのがシャレててちょっと素敵です。

次回は9月17日(火)の予定です！