Glue と Athena と Data Lake


1年ほど前に Amazon Athena がリリースされ、半年ほど前に AWS Glue や Redshift Spectrum がリリースされ、この1年で AWSビッグデータ関連のサービスが次々と出てきました。

Athena や Glue は、それ単体でも十分に便利なのですが、データレイクの構成要素としてそれぞれ重要な役割を持っています。

この記事では、データレイクにとって Glue や Athena がどういう位置付けなのか考えてみようと思います。

データレイクとは?

Wikipedia では data lake は次のように説明されています。

A data lake is a method of storing data within a system or repository, in its natural format,[1] that facilitates the collocation of data in various schemata and structural forms, usually object blobs or files. The idea of data lake is to have a single store of all data in the enterprise ranging from raw data (which implies exact copy of source system data) to transformed data which is used for various tasks including reporting, visualization, analytics and machine learning. The data lake includes structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and even binary data (images, audio, video) thus creating a centralized data store accommodating all forms of data.[2]

Data lake - Wikipedia

ざっくり要約すると、データレイクとは、構造化データに限らない様々な形式の生データから、分析や機械学習などに使いやすいように加工した整形済みデータまで、あらゆるデータを1箇所に集積する手法のことです。それにより、データレイク内に存在する非構造化データを含む様々なデータを組み合わせて利用することが容易になります。

よくある使い方としては、生ログを全てデータレイクに保存した後、必要なデータを抽出しきれいに整形した上でデータウェアハウスにロードする、などがあります。

AWS におけるデータレイク

AWS においては、S3 がデータレイクの役目を果たします。

Building a Data Lake on AWS

Building a Data Lake on AWS

S3 をデータレイクとして使う場合は、次のような構成が一般的かと思います。

  • Kinesis Firehose などで S3(=データレイク)にデータを流し込む。
  • EMR を使いデータを抽出し、使いやすい形に整形する。
  • 整形されたデータを Redshift や Presto にロードするなどして、BI ツールなどから参照できるようにする。

データレイクの生命線

データレイクのアイデアはとても単純で「あらゆるデータを1箇所に集める」それだけです。しかし、もう1つ重要な要素があります。

何も考えずにあらゆるデータをデータレイクに流し込んでしまうと、「どこに何のデータがあるのか分からない」状態になります。欲しいデータがどこに保存されているのか分からない、ここにあるデータが何のデータなのか分からない状態です。こうなってしまうと、データレイクから意味のある情報を取り出すことはできません。せっかくのデータがゴミの山になってしまいます。このようなデータレイクは "data swamp"(データの沼)と呼ばれるそうです。

参考: Data Lake or Data Swamp

Data lake を data swamp にしないために最も重要なのは、どこに何のデータがあるのかという情報 です。この情報は メタデータ と呼ばれます。メタデータは次のような情報を含みます。

  • データに対する説明
  • データの場所(S3 bucket と prefix)
  • データのフォーマット(CSV, JSON, XML, raw data, ...)
  • データのスキーマCSVカラム名JSONの構造など)
  • データが保存されている場所のディレクトリ構造など

Hive on EMR で外部テーブルを使ったことがある方なら馴染みがあるかもしれません。Hive で外部テーブルを作成する際には、上に挙げたような情報を指定する必要があります。以下は、S3 上にある CSV ファイルに対して外部テーブルを作成する例です。

CREATE EXTERNAL TABLE csv_data (
-- データのスキーマ
  col_1 STRING,
  col_2 STRING
)
-- データに対する説明
COMMENT '....'
-- データの形式
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
-- データの保存場所
LOCATION 's3://bucket/my-csv-data/'

これらの情報は hive metastore と呼ばれるデータベース(実体は MySQL)に保存されます。

メタデータの難しさ

データレイクを運用していくには、メタデータの管理が非常に重要になります。しかし、メタデータをきちんと管理するのは意外と大変です。

1つは、実データとメタデータを同期していく難しさです。データレイクにやってくるデータの形式は常に同じとは限りません。サービスに新機能が実装され、新しいフィールドが追加されるかもしれません。データ量を減らすため JSON から MessagePack に変更したくなる日が来るかもしれません。もっと辛い場合だと、オペレーションミスなどである時期だけ CSV のフィールドの順番が変わってしまうなんてこともあるかもしれません。実データの形式が変わるのに合わせてメターデータをアップデートしていく必要があります。

また、新しいデータソースに対応していくというタスクもあります。継続的に発生するデータの場合、特定の期間のデータを効率よく取得するために、データが発生した日付ごとにデータの保存場所を変えるのが一般的です。そうなると、毎日発生するデータの保存場所を日々メタデータに追加していく必要があります。さらに、今まで取得していなかったログを新たに取得し始めるなどして、データの種類が増える場合もあります。その場合は、新たなメタデータを作成する必要があります。

このように、メタデータを常に最新の状態に保つために、実データの変更や追加に常に気を配らなくてはいけません。データの種類が少ないうちはいいかもしれませんが、何種類ものデータが日々発生するようになって来ると、メタデータの運用はとても辛いものになります。

Glue とか Athena とか

AWS Glue (特に Glue Data Catalog)や Amazon Athena は、こうしたデータレイクやメタデータを運用していく上での課題を解決しようとしています。

Glue Data Catalog は、フルマネージドな Hive Metastore のサービスです。Glue Data Catalog は Hive の外部テーブルの情報を管理しています。Hive on EMR から Glue Data Catalog に接続することで、Glue Data Catalog で管理されている S3 上のデータに対して SQL でクエリを投げることができるようになります。Hive だけでなく、Spark や Redshift Spectrum など Hive Metastore に対応した製品であれば、Glue Data Catalog のテーブルを参照することができます。

Glue Data Catalog の便利な機能の1つにクローラーというものがあります。これは、Glue が S3 上に作成されるオブジェクトを監視して、新たに追加されたデータに対して自動でスキーマを検出しメタデータに追加してくれるというものです。これにより、メタデータの運用コストは大きく下げることができるかもしれません。

また、Amazon Athena はデータレイクの中を探索する際に非常に役に立ちます。Athena はフルマネージド Presto のサービスです。ブラウザから Athena のコンソールに行き SQL を打ち込むと Glue Data Catalog のテーブルに対してすぐにクエリを投げることができます。EMR のようにいちいちクラスタを立ち上げる必要はありません。

Glue Data Catalog で検出されたデータに対して Athena で即座に中身を確認する、といった使い方ができるようになるわけです。データレイクの中を気軽に歩き回ることができるようになり、data lake が data swamp になることを防ぐことができるのではないでしょうか。

(おまけ) BigQuery と Athena

最初、Athena のことは「AWS 版 BigQuery」くらいに思っていました。BigQuery に比べると、Athena は遅いし Parquet / ORC への変換は面倒だし、なんだかなあという印象でした。 ただ、こうしてデータレイクについて考えていくと、BigQuery と Athena は若干立ち位置が違うようです。

BigQuery の説明を見るとはっきりと「データウェアハウス」と書かれています。BI ツールと接続してどんな巨大なデータでもストレスなくサクサク見れることを目指しているのでしょうか。それに対して、Athena の説明はどこを探しても「データウェアハウス」という言葉はみつからず、「サーバーレスのインタラクティブなクエリサービス」と説明されています。Athena は、とにかく気軽にS3にクエリを投げられることを目指しているように思えます。

AWS のデータウェアハウスといえば Redshift。Athena と Redshift Spectrum の使い分けも迷うところですが、やはり Redshift / Redshift Spectrum はデータウェアハウスとしての性能を目指しているのでしょうね。

BigQuery と Athena と Redshift / Redshift Spectrum、似てるようでそれぞれ使い勝手も性能も違うので、用途に合ったものをきちんと選択したいものです。

まとめ

  • データレイクはどこに何のデータがあるかわからなくなったら終わり。
  • メタデータがデータレイクの生命線。だけど運用大変。
  • Glue Data Catalog と Athena をうまく使うと幸せになれるかもね。

re:invent 2017 に行ってきました

re:invent 2017 に参加してきました。

参加したセッションのメモなどを残しておきます。

ビッグデータ関連のセッションがほとんどです。

目次

まとめ&感想

「Data Lake」というワードが頻繁に出てきたのが印象的でした。機械学習や IoT のセッションでも、データの集め方みたいな話になると、Data Lake という言葉と一緒に、必ず Glue Data Catalog と Athena と Kinesis Stream & Firehose がセットで登場していたように思います。

S3にとりあえずデータを貯めておいてあとはよしなに頑張れ、というのは昔から言われていました。そこに Athena や Glue Data Catalog が登場し、S3 がただデータを貯めておくだけの場所から、データ探索が可能な場所に変わったことで、「S3にデータを貯めておく」ことの重要性が大きくなったということでしょうか。

サーバーレスなデータ分析環境の話題も多かった印象です。ストリームに対する分析に関しては Kinesis Analysis が以前からありましたが、Athena と Glue ETL が出てきたことで、バッチ処理に対してもサーバーレスに行うことができるようになりました。ストリーム処理・バッチ処理どちらもサポートしたことで、例えば Lambda アーキテクチャAWS Lambda は関係ない)をサーバーレスに実装できるようになったというのは面白かったです。

新サービスの中でも特に注目だったのは SageMaker でした。Rekognition などのサービスと合わせて、機械学習へのハードルがガンガン下がっていきますね。今までは、無理に機械学習を取り入れなくてもいいかなと思ってましたが、そろそろ本格的に導入したくなってきました。Deep Lens も面白いですね。何か作ろう。

S3 Select & Glacier Select も地味に期待しています。Athena や Redshift Spectrum から Glacier に直接クエリを投げられる日が来るんでしょうか。そうなると、ストレージ料金的にも BigQuery より安くなるかもしれませんね。

あと、ベンチに座って休憩していたら、隣にいた知らない人から「Deep Lens についてどう思う?」と聞かれたのがちょっと衝撃でした。今まで知らない人から議論ふっかけられたことなかったので、面食らってしまいました。「正直まだあまりピンときていない」みたいなことを答えたのは後悔しています。デタラメでもいいから何かでっち上げるべきでした。

セッションは後から動画で観れるから re:invent わざわざ行かなくてもいいのでは?と思った時もありましたが、1週間という長い時間をこのためだけに確保できるというのは大事だと思いました。何より、実際にAWSのサービスを開発しているエンジニアや、海外のエンジニアと直接話をできるというのはとても貴重な体験でした。機会があればまた行きたいです。


以下雑なメモ

MCL303 - Deep Learning with Apache MXNet and Gluon

Deep Learning with Apache MXNet and Gluon
youtubue
slide

  • AI > ML > DL
    • Symbolist
    • Analogist
    • Bayesian
    • Evolutionist
    • Connectionist = DL
    • Booster = random Forest
  • MXNet
    • Distribted Learning
      • データを分割してそれぞれでネットワークを構築。それを average する
      • Parameter server
    • Batch size 大事
      • 1回の操作でどれだけデータを扱うか?
    • MXNet batch size 大きくするとスーパー早くなるよ
    • MXNet 使うと DL 簡単にできるよ
  • Gluon
    • Gluon 使うとさらに柔軟性がUP!
    • 学習の途中にデバッガも挟める

GAM310 - Build a Telemetry and Analytics Pipeline for Game Balancing

Build a Telemetry and Analytics Pipeline for Game Balancing
slide
amzn.to/GAM310

  • EMR はアーミーナイフ
  • Kinesis analysis Kinesis stream source に、Kinesis Firehose destination に指定するみたいなことができる。便利そう

ABD202 - Best Practices for Building Serverless Big Data Applications

Best Practices for Building Serverless Big Data Applications
youtube
slide

  • Virtualized -> Managed -> Serverless
  • Serverless
    • No server provisioning
    • Never pay for idle
  • Mix and Match Serverless, Managed, and Virtualized
  • Services
    • Lambda
    • Athena
    • Glue
      • Data Catalog
      • Servderless ETL
    • Kinesis
      • Kinesis Analytics の前に Lambda preprocess 可能
  • Stream / Batch どちらも Pipeline AWS はカバーしている
    • Stream — Kinesis -> Lambda -> Kinesis Analytics -> QuickSight
    • Batch — S3 -> Glue -> Athena -> QuickSight
  • Misc
    • Glue Data Catalog 便利くさい
    • Athena — `group by (1)` ??
    • Data Lake Architecture
  • About Existing Hadoop Cluster
    • Hue interface
    • Zeppelin (ゼッペリン)
  • まとめ
    • AWS はデータパイプラインを構築するのに必要な Virtualized / Managed / Serverless なサービスを全て揃えているよ
    • バッチ処理・ストリーム処理それぞれに適切なサービスを選ぼう
    • Serverless なやつがスケーラビリティや安定性などの点で一番いい。
    • だけど大事なのは Virtualized / Managed / Serverless なサービスを要件に合わせてうまく組み合わせること。

ABD327 - Migrating Your Traditional Data Warehouse to a Modern Data Lake

Migrating Your Traditional Data Warehouse to a Modern Data Lake
slide
youtube

  • Result Caching
    • Transparent! -- 何も考えなくても適用されている
    • リソースに余裕ができることで、他の思いクエリの処理も高速化される
  • Short Query Acceleration
    • AI で最適化
    • Customized for your workload
    • Transparent!
  • Nested Data Support!!!
  • Fox の事例
    • よく使うテーブルは Daily vacuum
    • 週1で全テーブル vacuum
    • analyze のタイミングは統計テーブルを見て自動でキック

ABD322 - Implementing a Flight Simulator Interface Using AI, Virtual Reality, and Big Data on AWS

Implementing a Flight Simulator Interface Using AI, Virtual Reality, and Big Data on AWS
slide

フライトシミュレーターを作ってみようワークショップ。

前半は、VR / AR の概要や重要性に関するレクチャー。IoT AI, Big Data などとの関連についても触れていた。

ワークショップとしては、実際はシミュレータ部分は触らず、シミュレーターから出て来たデータを Kinesis に流してゴニョゴニョするところがメイン

http://bit.ly/2zFdJa3

  • Builders fair — Aria — Quad 34
  • Predictive analytics
  • 5 components
    • Simulae
    • Interface
      • Switches, inputs, outputs
    • Process
      • Kinesis
      • To CloudWatch
      • To Redshift
      • IoT / GreenGrass
    • Visualize
    • Interact
      • Lex
    • Learn
      • Redshift
      • DynamoDB
      • Amazon Machine Learning
  • What must consider
  • 感想
    • BigData には IoT AI の話題が必ずついて回ってくるようだ。
    • BigData 領域だけ見ていたらダメだなあと思いました。

 ABD307 - Deep Analytics for Global AWS Marketing Organization

Deep Analytics for Global AWS Marketing Organization
youtube
slide

  • Single Data Repository
    • Redshift 使ってる
  • Self-service
  • 次のステップ
    • Real time

ABD318 - Architecting a data lake with Amazon S3, Amazon Kinesis, and Amazon Athena

Architecting a data lake with Amazon S3, Amazon Kinesis, and Amazon Athena
youtube
slide

  • データレイクを使う理由
    • 利用シーンが多様に
      • 外部の顧客に渡す場合とか
  • Future Proof??
  • Data is not never perfect
  • Glue catalog redshift テーブルってなんだ???
  • S3 Metastore 以外は代替手段が存在する。この2つだけは置き換えられない。
  • Atlassian の事例
    • Transformation as a Service = TaaS
    • Self-service schema
    • コンソールぽちぽちやったら簡単に datalake ができる、なんてことはないよ

ABD304-R - [REPEAT] Best Practices for Data Warehousing with Amazon Redshift & Redshift Spectrum

[REPEAT] Best Practices for Data Warehousing with Amazon Redshift & Redshift Spectrum
slide

  • 歴史
    • 昔は Postgres だった
    • そこに MPP OLAP の機能を加え、さらに IAM やらなんやらもひっくるめて Redshift になった
  • Sort key は4つまで
  • Slice — 各ノードに slice と呼ばれる番号がついていて、DISTKEY の設定に従って、各 slice にデータが振り分けられる。
  • DISTKEY
    • JOIN 性能
    • INSERT INTO 性能
    • GROUP BY 性能
  • DataType はなるべく大きいものを効率的に圧縮されるのでデータ量はそんな気にしなくて大丈夫
    • INT / BIGINT <  NUMERIC
    • VARCHAR
  • Backup
    • 5GB ごとにバックアップする、などが可能
  • Temp table 速いよ(データがレプリケーションされないから?)
  • UPSERT
    • Temp table COMPUPDATE OFF!
    • Temp table は本体テーブルと同じ DISTKEY を。INSERT パフォーマンスが上がる
  • Superuser queue
    • Cancel superuser queue
  • QMR
    • リソース食う処理はひとまずログに残してみるのがいいかも
  • タイムアウト管理は WLM やり QML
  • データのミラーリングのため少なくとも2ノード
  • すくなくとも空き容量 20% は確保
  • Spectrum のスペックはクラスタサイズに依存
    • 1つの Slice で扱える spectrum node の数が決まってる?

KeyNote #2

省略

Analytics JAM

Analytics に関する問題をゲーム形式で解いていく。

チームにスーパーマンがいたので時間内に全問クリアすることができました。

内容はハンズオンに近いものがありました。普段使わないサービスも幅広く触れたのは面白かったです。

ビッグデータに関する問題は1問しかなく、ほとんどが機械学習とIoTに関するものでした。

MCL345 - NEW LAUNCH! Integrating Amazon SageMaker into your Enterprise

  • DataCollection / DataIntegration / Data Preparation Cleaning は引き続き EMR Redshift の仕事??
  • Principle Component Analysis Matrix Factorization などのアルゴリズムも提供しているので、単純な分析環境としても有用そう
  • 内部で Docker をいろいろ使ってるのが面白い
    • 学習環境を提供するのに Docker コンテナを使ってる
    • 全体のフローの一部の挙動を変えたい時に、プラグインを差し込む代わりに、Docker container を渡せるようにしてあるのかな
    • 面倒なところ全部抽象化しつつ、柔軟性も
  • Model artifacts = 学習済みのモデル
  • Inference docker image = 新しいデータを学習済みのモデルのどうやって当てるかを定義した Docker image ?
  • デプロイすると inference API が出来上がる
    • Kinesis のデータを lambda 経由で inference API に投げることも可能

ABD323-R - [REPEAT] Extending Analytics Beyond the Data Warehouse

  • 1430TB — Hive 1000 nodes 5 year -> spectrum 155 seconds
  • Push computation down to spectrum layer
    • Redshift の下にレイヤーがあるイメージなのか
  • Spectrum stateless
  • Spectrum 層のノード同士は通信できない
  • JOIN は基本的には push down されないが、JOIN 対象が十分小さければ push down される
  • Map-reduce のレイヤが spectrum によってもう1段増える
  • Spectrum の方が redshift より早い???
  • Late binding view
  • Order by push down されない
  • データをちょっと覗くには athena が便利、ダッシュボードやBIツールから見るには Spectrum
  • Spectrum 自体にクラスタサイズは関係ないが、spectrum から上がってきたデータを裁くためにクラスタが必要
  • 小さいテーブルが S3 にあっても、JOIN はプッシュダウンされる
    • Hive metastore statistics も管理する必要がある
  • Glacier ??
  • udf push down されない

DeepLens HandsOn

https://github.com/aws-samples/reinvent-2017-deeplens-workshop

これはホットドッグですか?

ABD330-R - [REPEAT] Combining Batch and Stream Processing to Get the Best of Both Worlds

[REPEAT] Combining Batch and Stream Processing to Get the Best of Both Worlds
slide

  • Serverless でやるか EMR を使うかは choice
    • Athena or EMR
    • Kinesis or EMR (Spark Streaming)
  • Kafka は直接サポートはしていない
  • Data plane and controls plane
  • 一般的な Lambda architecture は正確性と速度の両方を保証するものだったけど、それは Kinesis + Lambda を使うことので解消できる。これは kappa architecture の実装になる
  • Kinesis analysis