データレイクハンズオンでデータレイクを実感してみる

前回のAWS Innovateで、データレイクのハンズオンが掲載されていました。データレイクのイメージを掴むのに有益になればと思いましたのでご紹介します。

AWS Innovateのサイトは既にクローズされていますが、ハンズオン資料のサイトはありますので参考にしてください。
amazon-s3-datalake-handson

本ハンズオンのゴール

以下、ハンズオン資料から引用

幅広いデータソースからの構造化データまたは非構造化データの集中リポジトリとして使用できる Data Lake は、データの保存と分析の方法として多くの企業に取り入れられています。

AWS のビッグデータ関連サービスを使用して実際に分析パイプラインを構築することを通して、 Data Lake とビッグデータ分析基盤構築の実感を持って頂くことをゴールとしています。

ということで、データレイクを実感するにはとても良いハンズオンとなっています。

このハンズオンの良いところ

• アプリケーションログのデータレイクイメージが分かる
  • ハンズオン用の環境（EC2）から、アプリケーションログが出力され、随時出力されるログを分析するイメージの理解が深まります。
• １つソースから、スピードレイヤ、バッチレイヤの２パターンの作成ができる
  • 各 Lab を組み合わせることにより、スピードレイヤ、バッチレイヤのハンズオンを実施することが可能です。
    （1） ニアリアルタイムデータ分析環境（スピードレイヤ）の構築：[Lab1] → [Lab2] → [Lab3]
    （2） 長期間のデータをバッチ分析する環境（バッチレイヤ）の構築と、パフォーマンスとコストの最適化：[Lab1] → [Lab4] or [Lab5] → [Lab6]
• その他
  • Lab1、Lab2、Lab3、Lab4、Lab5、Lab6とハンズオンが分かれていますので、興味のあるところまで進めて、機能を理解できます。

＜構築イメージ＞（ハンズオン資料のREADME.mdから引用）

１．準備

以下のサイトのハンズオン用のデータを使用します。
amazon-s3-datalake-handson JPフォルダの配下を参照します。
今回は、ハンズオンの構築イメージのご紹介を中心に、各画面のキャプチャは省略しています。

２．ニアリアルタイムデータ分析環境（スピードレイヤ）の構築

各手順については、各Labフォルダの手順に細かく記載されているので迷うこともなく進められます。ここではポイントだけ記載します。 ※一部のキャプチャはハンズオン完了後、後日採取したものもありますのでご了承下さい。

Lab1：はじめの準備

• ハンズオン内容
  • 5つの Lab で必要となる共通の環境を構築します。
  • アプリケーションログを出力するEC2を作成します。これが以降のハンズオンで使用するデータソースとなります。
  • 手動でログ収集ソフトウェアのFluentdをインストールします。
• ハンズオン結果
  • 以下のようなログが出力されることを確認できました。
  • 10分ごとに ERROR が300件出る設定になっています。このログの出力設定をポイントに以降の分析のシナリオがあります。

Lab2：アプリケーションログをリアルタイムで可視化

• ハンズオン内容
  • Lab1で作成済みのEC2で出力されるログをFluentd を使ってストリームでElasticsearch Serviceに送信します。
  • Elasticsearch Service に付属しているKibana を使って、これを可視化します。
    
• ハンズオン結果
  • 以下のように可視化できました。（10分毎にErrorが300件出力されていることが確認できます。)

Lab3：アプリケーションログのリアルタイム可視化とアラーム

• ハンズオン内容
  • Fluentd から Elasticsearch Service に送信する前段にCloudWatch、 Lambdaを配置して、アラーム通知をする処理を追加します。
  • CloudWatchアラームの設定で１分間に50以上のErrorが発生したらメール送信する設定を行います。
  • スピードレイヤ構築の最終形となります。 アラートメールをトリガーにして、可視化された異常値を確認、データに対して深堀りを行うシナリオが想像できます。
• ハンズオン結果
  • Lab1で構築したEC2から、10分ごとに ERROR が300件出る設定になっている為、実際に10分に１回、メールが飛んでくるようになります。
    今回は機械的に10分に一回メールが飛んできますが、実際は異常値のエラー発生時にメールを受信し、アクションが起こせるようになります。

  • 可視化もうまくいきました。基本的にLab2の見た目と同等です。
    

３．長期間のデータをバッチ分析する環境（バッチレイヤ）の構築

こちらについても、各手順については、各LabフォルダのREADME.mdに細かく記載されているので迷うこともなく進められます。ここではポイントだけ記載します。

Lab4：アプリケーションログの永続化と長期間データの分析と可視化

• ハンズオン内容
  • アプリケーションログデータを Kinesis Data Firehose に送信後、 S3 に保存することで長期保存します。
  • その後、 Amazon Athenaを用いて、アドホックな分析を可能にします。
  • 更に、Amazon QuickSightで可視化します。
• ハンズオン結果
  • S3にデータレイクとして保存しましたので、AthenaからSQLが発行できるようになりました。

  • QuickSightでの可視化もできるようになりました。

Lab5：クラウドDWHを使用したデータ分析

• ハンズオン内容

  • アプリケーションログデータを Kinesis Data Firehose に送信後、 S3 に保存することで長期保存します。（Lab4と同じ）
  • その後、 Redshift Spectrumを用いて、クエリを実行し、 QuickSight で可視化します。
• ハンズオン結果
  • ハンズオンでは、Redshift内部にデータをインポートして、QuickSightで可視化しました。
  • Redshiftへ蓄積することにより、長期的なデータの活用度はさらにあがると思われます。

Lab6：サーバーレスでデータのETL処理

• ハンズオン内容
  • データレイクに対して、アクセスを効率的にする為のデータ加工処理を行います。Lab4をさらに発展させたイメージです。
  • アプリケーションログデータを Kinesis Data Firehose に送信後、 S3 に保存することで長期保存します。（Lab4、5と同じ）
  • その後、 AWS Glueを使ってデータの加工処理を行います。
    • (1)ファイルフォーマットを Apache Parquet 形式に変換します。
    • (2)ファイルをパーティショングした配置するための処理を実行し、その結果を S3 に保存します。
  • その後、 Athenaでクエリを実行し、 QuickSightで可視化します。
• ハンズオン結果
  • ここではパーティショニングの結果、クエリのパフォーマンスが改善していることを確認します。
  • データが小さいので、実行時間に大きな変化は確認できませんが、スキャンしたデータ量の違いが確認できます。
  • データが大量になることで、クエリパフォーマンスが心配になりますが、こういったETL処理で解決できます。

  • CSVの場合

        SELECT count(user) FROM "minilake"."minilake_in1"
        where user='uchida' AND timestamp >= '2020-05-14 07%' AND timestamp <= '2020-05-14 09%';

    (Run time: 3.03 seconds, Data scanned: 48.62 KB)

  • Parquet 形式の場合

        SELECT count(user) FROM "minilake"."minilake_out1"
        where user='uchida' AND timestamp >= '2020-05-14 07%' AND timestamp <= '2020-05-14 09%';

    (Run time: 2.2 seconds, Data scanned: 3.02 KB)

  • Parquet 形式（Userでパーティショニング）した場合

        SELECT count(user) FROM "minilake"."minilake_out2"
        where user='uchida' AND timestamp >= '2020-05-14 07%' AND timestamp <= '2020-05-14 09%';

    (Run time: 3.56 seconds, Data scanned: 1.01 KB)

まとめ

• リアルタイムにEC2から出力されるアプリケーションログを扱うことで、データレイクを実感できるハンズオンでした。
• スピードレイヤ構成とバッチレイヤ構成を作成することでそれぞれ目的の違いをイメージできたと思います。
  • スピードレイヤでは、アラートメールを設置することでニアリアルタイムに反応でき、更に可視化することで、的確な対応が可能となります。
  • 一方、バッチレイヤでは、蓄積したデータから精度が高く、柔軟な分析に向けての基盤構築が可能となります。
• 段階的なハンズオンLabが示す通り、少しずつ段階的に導入、拡張ができますので、データレイク構築イメージの参考になればと思います。

あわせて読みたい

実は、同ハンズオンの記事は以前も掲載がありました。 こちらは、手順がより詳細に記載されていますので、実際のハンズオンを実施される際には参考にしてください。

【AWS Data Lake】ニアリアルタイムデータ分析環境・スピードレイヤを構築してみた（ハンズオン1） | Developers.IO

【AWS Data Lake】長期間のデータをバッチ分析する環境・バッチレイヤを構築してみた（ハンズオン2） | Developers.IO

データレイクと分析 - ユースケース別クラウドソリューション | AWS

Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ