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

2017年4月6日に開催されたBigData-JAWS セミナー「Amazon Athena Update」に参加して聞いてきたこと。後半の方は、聞き入っていて呟きも無しです
dkfj 1642view 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の方がパフォーマンスがよくなる傾向がある。

コメント

カテゴリーからまとめを探す

「エンタープライズ」に関連するカテゴリー

ログインして広告を非表示にする
ログインして広告を非表示にする