Togetter/min.tを安心してお使い頂くためのガイドラインを公開しました。
2017年4月7日

BigData-JAWS セミナー「Amazon Athena Update」の自分用まとめ

2017年4月6日に開催されたBigData-JAWS セミナー「Amazon Athena Update」に参加して聞いてきたこと。後半の方は、聞き入っていて呟きも無しです
1
Takuro SASAKI @dkfj

Athena textやcsvなどに対応しているが、ORC or Parquest形式に変換するとパフォーマンスが上がる

2017-04-06 17:27:30
Takuro SASAKI @dkfj

Athenaは、presto(SQLのエンジン)とHIVE(DDL)をベースに作られている。prestoはFacebookで実績のあるエンジンで、数十ペタバイトまでスケールする

2017-04-06 17:30:17
Takuro SASAKI @dkfj

AVROフォーマットって、なんぞや?

2017-04-06 17:30:41
Takuro SASAKI @dkfj

Athenaの使い所。"Data Sources -> S3 -> EMR -> S3 -> Redshift -> QuickSightの流れを置き換えるものではない。S3のRawデータの部分の処理などを補完する。" ⇐この考え方を聞きたかったので良かった

2017-04-06 17:38:07
Takuro SASAKI @dkfj

QuickSightとAthenaを連携させるというのが、一番手っ取り早くて現実的だな。Tableauとの連携もβ版で利用可能とのこと

2017-04-06 17:40:38
Takuro SASAKI @dkfj

AthenaでParquet利用の勧め。とあるデータでは、1TBのテキストデータを処理すると、237秒かかり$5.75かかる。Parquetに変換すると130GBに圧縮されているので、5.13秒で$0.013しかかからない。

2017-04-06 17:51:05
Takuro SASAKI @dkfj

まぁ何度も解析するデータについては変換して、それ以外は元データのままでよいのかな。そもそも1TBのデータ、あんまり持ってないし

2017-04-06 17:52:27
Takuro SASAKI @dkfj

Athena。あまりに細かいファイルを沢山処理しようとすると、I/Oの問題でパフォーマンスが出ない。ある程度のサイズにまとめた方がよい。(大きくしすぎると、たぶん分散できないのでパフォーマンスでなくなると思うけど)

2017-04-06 18:02:53
Takuro SASAKI @dkfj

Athena ファイルサイズは、128~256MBくらいのサイズがパフォーマンス面で最適なことが多い

2017-04-06 18:03:44
Takuro SASAKI @dkfj

Athenaの話を聞いて意外だったのは、生データをカラム型のデータに変換することを繰り返し勧めていること。何となく生データをS3に置いたまま使えることが製品の売りなのかなと思ってたけど、実務の観点であればやっぱりAthenaに最適化しないと駄目よね

2017-04-06 18:07:20
Takuro SASAKI @dkfj

データ変換は、Glueを使え。もうすぐ出てくる

2017-04-06 18:09:57
Takuro SASAKI @dkfj

Athena。ORCとParquetの使い分けについて。基本的にはデータ依存だが、ORCの方がデータサイズが小さくなり、Parquetの方がパフォーマンスがよくなる傾向がある。

2017-04-06 18:18:32

コメント

コメントがまだありません。感想を最初に伝えてみませんか?