AWS Athenaを使って 30TBのWeb行動ログ集計を試みた

2. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department自己紹介 {"ID" ："fetaro" "名前"："渡部徹太郎" "研究"："東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)" "仕事"：{前職:["証券会社のオンライントレードシステムのWeb基盤", "オープンソースなら何でも。主にMongoDB,NoSQL"], 現職:["リクルートの横断分析基盤,Exadata,Hortonworks,EMR ], 副業:["MongoDBコンサルティング"] } "エディタ"："emacs派" "趣味"： ["自宅サーバ","麻雀"] "好きなAWSのサービス" : "EMR" } 1

4. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department課題と目的  課題  S3→オンプレへの生ログ転送がしんどい  オンプレでの処理が高価（単位容量あたりの処理コストが高い）  オンプレでの処理が時間がかかる  目的  AWS AthenaでS3上の生データを一次加工してからオンプレに持ってこれないか？ 3

5. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department対象データ  データの種類  リクルート約150のWeb行動ログの生ログ  データ量  30T  データ構造  600カラム  ファイル構造  Hiveのデータ構造になっている  パーティション数  1,044,930 4 s3://backet/acc_log/ sc=sc0001/ ←サイト単位 ymdh=20161201000000/ ←時間単位 data.tar.gz ←生データ（TSV＋gzip圧縮） ymdh=20161201010000/ ・・・ sc=sc0002/ ymdh=20161201020000/ ・・・

6. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department対象処理  Webアクセス生ログの一次加工  ５日分前までのデータを加工  必要なカラムの抜き出し • 600カラム→30カラム  prop30 といった機械的な列名を、実際の意味のある列名に変更  幾つかの列の加工  「内部IDのハッシュ値」を「内部ID」に変換する • 具体的にはLEFT OUTER JOINで 5

7. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department作戦  TokyoリージョンにあるS3をオレゴンのAthenaの外部テーブルとして認識する  S3のディレクトリ構造をそのままパーティションにする 6 CREATE EXTERNAL TABLE acc_log ( 600カラム ) PARTITIONED BY (`sc` string, `ymdh` bigint) ROW FORMAT DELIMITED FIELDS TERMINATED BY 't' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3://backet/acc_log/' Athena S3 acc_log メタストア sc=sc0001 sc= sc0002 ymdh=201612010 10000 ymdh=201612010 10000 tsv.gztsv.gz ・・・・・・東京リージョンオレゴンリージョンパーティションロケーション sc=sc0001, ymdh=201612010 10000 s3://bucket/acc_lo g/sc=sc0001/ymdh =20161201010000

8. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentテーブルの作成（発生した問題１）  パーティションの認識が終わらない！  最初は無邪気に1,044,930あるパーティションを一括で認識させようとした • msck repair table acc_log;  数時間放置したが、全く応答がないので帰宅。  翌日タイムアウトしている事がわかった  Javaを書いてJDBCでパーティション追加するしかない  ALTER TABLE ADD PARTITIONにてパーティションを追加  一回に１つのHiveQLしか受け付けてくれないので、パーティションの数だけループを回す  ";"が入ったHiveQLはNG 7 ALTER TABLE acc_log ADD PARTITION (sc='sc0001' , ymdh='20161231230000') LOCATION 's3://bucket/acc_log/sc=sc0001/ymdh=20161231230000/';

9. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentテーブルの作成（発生した問題２）  手動でパーティション追加すると16日かかる  一回のADD PARTITIONにかかる時間：1.3秒（athena内部では0.6秒）  パーティション数： 1,044,930  パーティション追加にかかる総時間=387時間=16日  そもそもパーティション数に20000の制限がある事がわかった  http://docs.aws.amazon.com/athena/latest/ug/known- limitations.html  これでは1サイト26ヶ月分しか処理できない！  諦めて、レポートスイートsc0001の2016年12月分だけにすることにした  720パーティションで、16分程度でパーティション認識完了  データ量が210Gに・・・ 30Tの処理を期待していたひと、ごめんなさい m(_ _)m 8

11. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentクエリ実行（発生した問題１）  1サイト5日分の生ログ加工の実施  HiveQLは「3400万 LEFT OUTER JOIN 4千万 JOIN 10万」といった感じ  結果  30分でタイムアウト！  ここでクエリの30分が上限であるとわかる  http://docs.aws.amazon.com/athena/latest/ug/known- limitations.html 10

12. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentクエリ実行高速化作戦その１  クエリをチューニング  EXPLAINをつかってチューニングを試みる  結果  EXPLAINをつけるとWebコンソールから打つと何も返ってこない  Historyにも計上されない  JDBCで打つとサポート外であることが分かる • Caused by: com.amazonaws.athena.jdbc.shaded.com.amazon aws.services.athena.model.InvalidRequestExceptio n: Queries of this type are not supported (Service: AmazonAthena; Status Code: 400; Error Code: InvalidRequestException; Request ID: 6ed149d3- e723-11e6-968b-91cd0b25a162) 11

13. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentクエリ実行高速化作戦その２  データをオレゴンに移動  オレゴンAthenaから東京のS3にクエリをしているため、データ転送が遅いのかと思い、データを東京に移動  結果は変わらず  他のクエリでも試したが、AthenaのリージョンとS3のリージョンが別れていても性能にインパクトは少ない 12

14. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentクエリ実行高速化作戦その３フォーマット変換  高速化を目指して列志向フォーマット(parquet)への変換  とりあえずAthena上でparquetテーブルへのSELECT INSERTを試みる  結果は失敗  INSERTなどS3に変更を加える操作はサポートされていない • http://docs.aws.amazon.com/athena/latest/ug/language-reference.html  つまりAWS AthenaはS3ビュワー 13 TSV+ gzipフォーマット parquet SELECT INSERT

15. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentクエリ実行高速化作戦その３フォーマット変換  ドキュメントに従いEMRでのフォーマット変換  東京リージョンのEMRで、オレゴンのS3上のデータをSELECT INSERT  ※クラメソさんのブログではApache Drillでフォーマット変換をしていたが、データが多いのでEMRを採用した 14 TSV+ gzip テーブル Parquet テーブル SELECT INSERT EMR S3 東京リージョンオレゴンリージョン

16. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentクエリの実行リトライ（発生した問題１）  1サイト5日分の生ログ加工（列志向フォーマット）の実施  3400万 LEFT OUTER JOIN 4千万 JOIN 10万  列志向フォーマットにして試しても30分でタイムアウト！ 15 ここで残念ながら検証期間の終わりになしました

17. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department結果）Athenaはどれくらいの速度で動いたかオレゴンAthena →東京S3 オレゴンAthena →オレゴンS3 TSV + gzip TSV + gzip parquet Select count(*) sc絞込 ymdhレンジ絞込 52.76 秒スキャン量 6.89GB 51.08 秒スキャン量 6.89GB 22.3 秒スキャン量 0KB ↑統計情報から読むため Select 4列 sc絞込 ymdhレンジ絞込＋２列で絞込 110 秒スキャン量 6.89GB 108 秒スキャン量 6.89GB 83 秒スキャン量 326MB ↑読む列が少ないため Select 28列列の値変換多数 sc絞込 ymdhレンジ絞込他２列で絞込 457 秒スキャン量 6.89GB 454 秒スキャン量 6.89GB 442 秒スキャン量 6.15GB ↑若干少なくなった業務クエリ上記+4000万件と10万件のテーブルとjoin 30分でTimeout スキャン量 13.35GB 30分でTimeout スキャン量 13.35GB 30分でTimeout スキャン量 12.61GB 16 = = = > > >> > > >>= = = ↑リージョンまたいでも大差なし

18. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentその他悲しかったこと  Historyの検索が怪しい  "JOIN"や"MSCK"は検索しても表示されなかった  Historyへの計上が怪しい  異常終了時に計上されるエラーとされないエラーが有る。法則がわかない。  エラーがわかりにくい  HiveQLの文法のどこが間違っていたかわかりにくい。インラインにでることもある  Javaのスタックトレースが出ない  制約が厳しい  クエリ同時実行：５、クエリ時間：３０分、パーティション：20000はきつい  仮に倍だとしても厳しい  ";"で接続した複数のHiveQLは実行できない  例 ALTER SESSION SET `store.format` = 'parquet'; CREATE TABLE・・・  Hiveのパラメータ指定はできない  ジョブの進捗がわからない  30分後にNGの結果がわかるのみ。あと何分早くすればよいかわからない 17

19. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department嬉しかったこと  Twitterで日本語でぼやいたら、AWSのシニアプロダクトマネージャから英語でレスが！  リミットを上げてくれるという話になりましたが、今回の業務ではリミットを上げても成り立たないので、お断りとなりました。  しかし日本語のつぶやきを拾ってくれるとは、頭が下がります 18

20. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Departmentまとめ  Athenaはしばらく成長を見守る  AthenaはS3のビュワー • データ加工はEMRなどでやる必要がある  クエリ時間制限があるため、ジョブの置き換えは出来ない  分析者にアドホックにクエリを打ってもらうのちょっと厳しそう • システム管理者側で性能問題の解析ができない • 分析者が使うにはUIがまだまだ成熟していない  APIがない  利用できるシーン  オンプレに持ってくる前にS3にどんなデータがあるか確認する  自分の反省  ハマりどころが多いので、事前にマニュアルを精読すべきだった 19

21. (C) Recruit Technologies Co.,Ltd. All rights reserved. BIG DATA Department勉強会で出た意見  AWSのサービスがだすログがhive形式(key=value/file)になっていないので、そのままはAthenaテーブルに出来ない  EMRやRedShiftとメタデータを共有してほしい  AWSはAPIファーストなのに、AthenaにはAPIがない  Athenaでクエリをした結果をAthenaで処理できないので、ジョブでは使えない。ビュワーがメインだろう  Group byで結果が重複する？？  PrestoベースなのでJOINは遅いだろう  とはいえS3に置いたままで加工がいらないのはとても魅力！  懇親会の乾杯の挨拶「Athenaの今後の改善に期待して乾杯！」 20

AWS Athenaを使って 30TBのWeb行動ログ集計を試みた

Tetsutaro Watanabe

AWS Athenaを使って 30TBのWeb行動ログ集計を試みた