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

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

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

AWS からの連絡

イベント情報

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

新着情報

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

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

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" でした。ご紹介だけ。

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

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

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

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