【新機能】作り忘れたまとめはありませんか?31日前まで期間指定してまとめが作れる高度な検索ができました。有料APIだからツイートの漏れはありません!

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

2017年4月6日に開催されたBigData-JAWS セミナー「Amazon Athena Update」に参加して聞いてきたこと。後半の方は、聞き入っていて呟きも無しです
エンタープライズ
2110view 0コメント
1
ログインして広告を非表示にする
Takuro SASAKI @dkfj 2017-04-06 17:27:30
Athena textやcsvなどに対応しているが、ORC or Parquest形式に変換するとパフォーマンスが上がる
Takuro SASAKI @dkfj 2017-04-06 17:30:17
Athenaは、presto(SQLのエンジン)とHIVE(DDL)をベースに作られている。prestoはFacebookで実績のあるエンジンで、数十ペタバイトまでスケールする
Takuro SASAKI @dkfj 2017-04-06 17:30:41
AVROフォーマットって、なんぞや?
Takuro SASAKI @dkfj 2017-04-06 17:38:07
Athenaの使い所。"Data Sources -> S3 -> EMR -> S3 -> Redshift -> QuickSightの流れを置き換えるものではない。S3のRawデータの部分の処理などを補完する。" ⇐この考え方を聞きたかったので良かった
Takuro SASAKI @dkfj 2017-04-06 17:40:38
QuickSightとAthenaを連携させるというのが、一番手っ取り早くて現実的だな。Tableauとの連携もβ版で利用可能とのこと
Takuro SASAKI @dkfj 2017-04-06 17:51:05
AthenaでParquet利用の勧め。とあるデータでは、1TBのテキストデータを処理すると、237秒かかり$5.75かかる。Parquetに変換すると130GBに圧縮されているので、5.13秒で$0.013しかかからない。
Takuro SASAKI @dkfj 2017-04-06 17:52:27
まぁ何度も解析するデータについては変換して、それ以外は元データのままでよいのかな。そもそも1TBのデータ、あんまり持ってないし
Takuro SASAKI @dkfj 2017-04-06 18:02:53
Athena。あまりに細かいファイルを沢山処理しようとすると、I/Oの問題でパフォーマンスが出ない。ある程度のサイズにまとめた方がよい。(大きくしすぎると、たぶん分散できないのでパフォーマンスでなくなると思うけど)
Takuro SASAKI @dkfj 2017-04-06 18:03:44
Athena ファイルサイズは、128~256MBくらいのサイズがパフォーマンス面で最適なことが多い
Takuro SASAKI @dkfj 2017-04-06 18:07:20
Athenaの話を聞いて意外だったのは、生データをカラム型のデータに変換することを繰り返し勧めていること。何となく生データをS3に置いたまま使えることが製品の売りなのかなと思ってたけど、実務の観点であればやっぱりAthenaに最適化しないと駄目よね
Takuro SASAKI @dkfj 2017-04-06 18:09:57
データ変換は、Glueを使え。もうすぐ出てくる
Takuro SASAKI @dkfj 2017-04-06 18:18:32
Athena。ORCとParquetの使い分けについて。基本的にはデータ依存だが、ORCの方がデータサイズが小さくなり、Parquetの方がパフォーマンスがよくなる傾向がある。
ログインして広告を非表示にする
ログインして広告を非表示にする