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
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の話を聞いて意外だったのは、生データをカラム型のデータに変換することを繰り返し勧めていること。何となく生データをS3に置いたまま使えることが製品の売りなのかなと思ってたけど、実務の観点であればやっぱりAthenaに最適化しないと駄目よね
2017-04-06 18:07:20
Takuro SASAKI
@dkfj
Athena。ORCとParquetの使い分けについて。基本的にはデータ依存だが、ORCの方がデータサイズが小さくなり、Parquetの方がパフォーマンスがよくなる傾向がある。
2017-04-06 18:18:32