#prestostudy は Treasure Data もりもりだった

今回は、Presto勉強会 at IPROS 〜概要から周辺事情、Hiveとの比較まで！〜に参加してきました。

わたしの記憶が間違っていなければ、、、、、イベントが告知された時点では、 Presto の勉強会なのに Treasure Data さん抜きというかなりチャレンジングというか、もしかしてゆるふわ系な勉強会なのかなってことで登録したつもりだった勉強会のはずだったんだが、、、、

実際蓋をあけてみたら、 Treasure Data さんいるし、かなり猛者の集まった勉強会になってました。

個人的に印象に深かったのは、データ分析基盤と言われると、なんとなくオンプレミスという固定観念があったんですが、今回の話に関して言うと全部 AWS 前提になっていたので、当然といえば当然行き至る考え方とはいえ、「なるほど」という感じでした。

まあ、あと Presto 勉強会と銘を打ってはありましたが、 Treasure Data Tech IPROS 出張編みたいな捉え方をしたほうがいい内容だったのかな、という印象も受けましたね。それだけすごい技術力、影響力というところなんでしょう（いや、ほんと Treasure Data さん、すごい）！

では、毎度のことのなので、いつもどおりわたしの取ってきたメモを公開しておきます（一部、口外無用とあった部分に関しては消してあります）。

概要：

Presto勉強会 at IPROS 〜概要から周辺事情、Hiveとの比較まで！〜

場所：株式会社イプロスセミナールーム東京都千代田区丸の内3-8-1住友不動産丸の内ビル5Ｆ

ハッシュタグ： #prestostudy

Agenda:

19:30-19:40 オープニング（担当：戸辺さん）

19:40-20:10 Prestoの周辺事情と基礎知識（担当：外山さん）

20:10-20:40 Hiveと比べてPrestoが優れてる所とそうでも無い所（担当：リブセンス吉田さん）

20:50-21:20 Presto As A Service - Treasure DataでのPresto運用事例（担当：Treasure Data, Inc. Taro L. Saitoさん）

21:20-21:30 クロージング（担当：戸辺さん）

19:40-20:10 Prestoの周辺事情と基礎知識（担当：外山さん）

Presto の基礎知識
Presto とは
- Facebook が公開した分散処理基盤
- SQL Query Engine という部類
- 日本では TreasureData が積極的に活用、普及活動
- 特徴
  - 複数のデータソースを結合できる
  - SQL
  - 低遅延
- アーキテクチャ
  - JAVA
  - In memory
  - ANSI-SQL
SQL Query Engine.
- 分散 SQL エンジンとか MPP Query Engine
- SQL でデータソースにクエリができ、かつその処理が複数の worker で処理される
- ANSI-SQL
  - SQL の標準仕様
- Presto の競合
  - Apache Drill
  - Cloudera Impala
Coodinator と Worker
- Coordinator が処理を受けつけ、 worker に割り振る
- Coordinator (設定例は資料に)
  - 司令塔
  - ここが落ちたら Presto は動かない
  - ただし Coordinator だけで動作させることも可能
  - Hadoop でいう NN
- Worker (設定例は資料に)
  - SQL が実際に動作する node
  - 台数増やしてスケールアウト
複数のデータソースとの結合（たしかにこれはよい機能だ）
- 外山さんが一番押すのはここ
- イプロスでは、バックエンドにある MySQL, Redshift を Presto で Join.
  - ログを管理する DB と会員情報を管理する DB が分かれている
- Connectora
  - 自作することも可能
  - Java で実装する
  - ドキュメントもあり
- 対応している Connector
  - MySQL
  - PostgreSQL
  - Hive
  - Cassandra etc...
- Catalog (設定例は資料)
  - データソースの接続単位
  - MySQL, PostgreSQL, Hive etc...
  - Catalog を複数用意することによって複数のデータソースを結合できる
  - テーブル名は catalog名.schema名.table名の形式で指定する
    - default を指定すれば省略可
周辺ツールの話
- Presto 単体での問題点
  - メモリを大量使用
  - 接続認証の機能は Presto 自体はもっていない
  - 独自プロトコルで接続するため、 BI ツールが対応していない
- PRESTOGRES
  - Presto に PostgreSQL のプロトコルで接続できる
  - 要は Presto の GW
  - psql コマンドや pgadmin で接続できる
  - 認証機能もある
- SHIB
  - Hive, Presto, BigQuery に対応
  - クエリを共有できる
  - CSV エクスポート機能
  - 簡易な認証機能
- Libraries
  - PresotoClient Python
  - Presto JDBC Driver
  - presto-client-ruby
  - presto-client-node
Performance を出すために (MySQL, PostgreSQL を前提に)
- ベースとして心がけること
  - データソースと Presto は同じネットワーク内に
  - Memory は多めに (Memory が少ないとすぐ落ちる)
  - select 時の column は最低限に
  - where 句はできるだけつける
  - いかに FULL SCAN を回避するか
- ダメなパターン
  - select *
  - table 名をつかった join
  - limit をつかったサンプリング
  - timestamp や date での範囲検索
- 心がけること (ふたたび)
  - join は基本サブクエリ
  - 接続先の index は最大限に活用
  - where は基本つける
- がんばったこと
  - ログ系のテーブルには unixtimestamp の column を追加した
    - 数値比較の場合は接続先の index が使える
AWS at IPROS
- worker に関しては r2.2xlarge x 2
- Coordinator は normal 契約で r3.large (落ちたら困るので)
よいところまとめ
- SQL のみでできる領域が広がる
- かなり開発は活発
- SQL という学習コストがほぼいらないものが使える
- 内部向けの分析用途であれば構築、運用はそんなに難しくない
懸念点のまとめ
- サービスとの組み込みとなると JVM との格闘になる
QA (全部はとれてないが)
- Oracle, SQL Server への Connector は？
  - 現状はない (Official には)
- MySQL Connector
  - MySQL から結果をとってくるところは分散処理になるのか？
  - 結果は Worker で分散処理されると思うが。
  - Coordinator が処理を分散させる（？）
- AWS 2 インスタンスでやってる
- 構築にかかった期間
  - Presto だけ立てるだけなら 1 日でもちろんできる (document みながら)
  - 周辺ツールとの組み合わせの調整で 1w くらいでやった

20:10-20:40 Hiveと比べてPrestoが優れてる所とそうでも無い所（担当：リブセンス吉田）

@yoshi_ken
TresureData 201205 から使用している
Presto を使う理由
- 使い始めて 4 ヶ月ほど
- 初期学習コストの低減
- すぐ結果が返ってくる
Presto のメリット
- Query が高速
  - Try and Error をテンポよく繰り返せる
- 学習コストが低い
  - ANSI-SQL
- 分析集計が捗る
Presto と Hive の棲み分け
- Presto
  - 長くても 2-3 分で終わる集計に最適
  - コンパクトな処理を素早く実行したいとき
- Hive
  - 数分〜数時間かかるバッチ処理
  - メモリにのり切らないオーダー処理
    - Varchar などの長い文字列処理
Presto のスピード
- select count(1) from access where status = ...
  - 150 億レコード、 800GB
  - Presto: 36sec
  - Hive: 12min20sec
  - select count(1) だけならメタデータアクセスなので一瞬で終わってしまう
- チラ見
  - select *
  - P 1sec, H 14sec
- 指定条件に該当する件数カウント
  - select count(1)
  - P 6sec, H 57sec
- 部分一致結果を用いて集計
  - group by
  - P 2sec, H 83sec
Presto 雑感
- with 句がとても便利
- cast を使うことが多い
- like 句よりも正規表現 regexp_like() が速いので積極的に使うべき
- join 結果が数十〜数百万業となるクエリで、文字列型のキーを使うとメモリを使いきって Fail
  - TD には smart_digest があるのでそれをつかう
Hive から Presto への書き換え Tips (Qiita にまとめているらしい Hive/Presoto クエリ関数の挙動の違い)
- 正規表現のエスケープ挙動が異なる
  - regexp_extract
- INT 型の割り算で結果が Float/Double 型となるとき結果が異なる (cast して解決)
- substr() などでマルチバイト文字をあつかうときの結果が異なる
- length(）
- 文字列置換関数は translate() ではなく replace() を使う
まとめ
- Presto を導入することで調査分析業務が捗る
  - MySQL テーブルを Hadoop にインポートして join している
- Prestgres を用いると PostgreSQL のように使えて便利
- TD のオプションサービス契約してよかつた
- よくないこと
  - マルチバイト対応があまい
  - リソースコントロールがあまい
    - 重たいクエリがあると次のクエリが実行待ちになってしまう
宣伝
- サーバインフラエンジニア養成読本（買ってあげましょう）

サーバ/インフラエンジニア養成読本ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)

posted with ヨメレバ

鈴木健太,吉田健太郎,大谷純,道井俊介技術評論社 2014-08-08

Amazon

Kindle

楽天ブックス

QA
- リブセンスの場合
  - TD の Presto を使わせてもらってる
  - Hive を使っていたのも TD
- ベンチマーク結果は TD の PlasmaDB がベースになってる

20:50-21:20 Presto As A Service - Treasure DataでのPresto運用事例（担当：Treasure Data, Inc. Taro L. Saito）

Presto とは？は割愛
Hive との違い
- MR 系とちがって処理途中を Disk に書き出さない
- 途中のタスクが失敗すると処理そのものが失敗する (Presto)
  - TD では独自にリトライ機構を導入している？！
TD とは？
- シリコンバレーで日本人創業
  - 日本支社は丸ビルに
Treasure Data Service
- ログを集めて解析するまでワンストップで提供
- 今は 1 ヶ月 1 兆レコード
Treasure Data: Presto as a Service
- TD Presto
  - Presto 0.100
  - AWS, IDCF クラウドで運用
  - PlazmaDB にアクセスするコネクター
    - データは切り離されている
      - Hive, Presto ともに接続可能
  - S3, RiakCS からデータ取得
  - 列志向 DB
Web Console からクエリをかける
Optimizing Scan Performance (スライドに図解)
- MPC (MessagePack Columner) Format
Presto のアーキテクチャ
- Query Planner
  - Logical query plan (3段階)
    - Output
    - Group by
    - Table Scan
  - Distributed query plan
- さらに Stage を Task に分割して並列度を上げる
  - はまりやすいポイント Order by
    - 大きなデータを Sort するとメモリが枯渇してしまう
    - そもそもそんな大きなデータを Sort して何がしたいの？ (facebook engineer)
クエリの実行時間
- 2 分以内におわる Presto クエリが 9 割 (TD の場合)
- 1 億レコードを処理することも珍しくはない
- 1 sec で数百万レコード処理することはざら
エラーからの回復
- 文法、関数名の誤り
- 存在しないテーブル、カラム
- insufficient resource
- internal failure
  - IO error
  - node error
クエリ再実行の頻度
- 99.8% が一回で成功、再施行は稀
COUNT(DISTINCT x)
- 何種類の値があるかチェック
- 種類が多い時メモリを多く消費
- count(distinct x ) を approx_distinct(x) に置き換える
- approx_percentile(column, persentile)
便利な WINDOW 関数
- さらに PARTITIONING もできる
カラーチャートもできる
Presto + BI tool = Prestogres
Database As A Service
- Claremont Report on Database Research
- 機能が制限されていることがいいこと
  - SQL の重要な役割
  - サービスとして提供するには好都合
  - 難しい例 Spark
- Beckman Report on Database Research
- TD の挑戦
  - さまざまなデータをさまざまなソースから集めて解析する
- PlazmaDB
  - スキーマはあるけど拡張可能
    - Familiar Table
    - Time-based Partitioning
    - Schema-Flexible
    - MessagePack
      - レコードは MessagePack 形式
    - Dynamic Data Type COnversion
      - Json -> Explicit Schema -> Select
Monitoring
- Using Fluentd
  - DataDog
    - Monitoring CPU, memory and NW usage.
    - Query stats etc...
Memory Usage
- G1GC
  - -XX:+UseG1GC
  - -Xmx の値は低めに設定
    - システムメモリの 8 割程度
      - GC のタイミングでプロセスのメモリ使用量がはねあがることがある
    - Out of memory 対策
Query Collection in TD
- SQL Query Log
Deployment
- CircleCI を使っている
Production: Blue-Green Deployment をしている
- Presto の upgrade 時
- PlazmaDB を使ってるからこそできる (データが外にあるから)
Admission control is necessary.
Challenge: Auto Scaling.
Long Running Queries
- Cross Join すると遅くなる
- IN (a, b, c.....) と並べてしまう
- Tuple materialization
- Many Aggregation Columns
- Full scan
Hog Query Processing Issue.
Presto Team at Facebook.　ここは内密ということで
- 今月 facebook にいって discussion してきた
- Raptor connector
  - MySQL からの移行を考えてる (facebook) 内部専用