Go ahead!

Memoization for Everything

MPP on Hadoop, Redshift, BigQuery

| Comments

Twitterで「早く今流行のMPPの大まかな使い方の違い書けよ！」というプレッシャーが半端ないのでてきとうに書きます．この記事は俺の経験と勉強会などでユーザから聞いた話をもとに書いているので，すべてが俺の経験ではありません(特にBigQuery)．各社のSAの人とかに聞けば，もっと良いアプローチとか詳細を教えてくれるかもしれません．
オンプレミスの商用MPPは使ったことないのでノーコメントです．

MPP on HadoopでPrestoがメインなのは今一番使っているからで，Impalaなど他のMPP on Hadoop的なものも似たような感じかなと思っています． もちろん実装の違いなどがあるので，その辺は適宜自分で補間してください．

前提

アプリケーションを開発していて，そのための解析基盤を一から作る．

簡単なまとめ

  • データを貯める所が作れるのであれば，そこに直接クエリを投げられるPrestoなどのMPPクエリエンジンを立てるのが楽
    • 特にHadoopとかすでにある場合には，まずこれ
  • データマートが必要であれば，RedshiftやBigQueryの方が向いている
  • ストレージもスキーマも運用も何も考えずにやりたいのであれば，BigQueryにFluentdとかでとりあえずJSONでぶち込むのが，多分この候補の中では一番初期コストが掛からない
    • もちろん要求によるので気をつける
  • Presto + Redshiftというケースも有り(アドホックなクエリはPresto，BIからガリガリつなぐのにRedshiftなど)

以下つらつらとリスト形式で書いてます．

Presto/Impala/Drill

PrestoやImpalaやApache Drillは，Redshift/BigQueryと違ってMPPデータベースではなくてMPPクエリエンジンなので，そこに違いがある． Prestoそのものについては，@frsyuki がHCJ 2014で発表したスライドがあるので，そっちも参考に．

  • PrestoやImpalaはそもそもサービスじゃないので，自分ですべて運用する必要がある．
    • 死活監視とか，もう少しワーカーが欲しかったら追加でデプロイみたいなのをする人が必要
  • 外部にストレージが必要
    • すでにある場合には，RedshiftやBigQueryじゃなくて，まずこれで十分かどうか試すという流れになりつつある
    • PrestoならS3とかにもクエリが投げられるので，FluentdでS3にJSONで貯めて，とかで構築コストはかなり軽減出来る
  • ストレージ側にスキーマを要求せず，直接クエリが投げられる
  • MapReduceとかとデータソースを共有出来る
    • データ量が増えてくると，ストレージからMPPデータベースにimportするだけでコストになるので，アドホックにクエリが投げにくくなる
    • PrestoやApache Drillは一つのクエリで複数のデータソースにアクセス出来るので．マスターテーブルとのjoinとかが楽に出来る
  • 速さに関しては，やはりスキーマありでチューニングされたMPPにはまだ基本勝てない．状況によっては勝てる時もある
    • それでも数秒 - 数十秒で返ってきたりするので，どこまでパフォーマンスを求めるかによる
  • クエリ同時実行制御に関しては，まだ商用のものに迫っているのはない印象
    • ここの改善に取り組んでいる人たちがいるので，いずれデータマート的にも使えるようになる可能性は高い
  • オープンソースなので，問題があったら自分で修正可能，処理傾向も把握しやすい

Redshift

  • スキーマが必須なので，アドホックに解析するためのデータベースとしては少し不向き
    • やるならデータをJSON文字列で保存，クエリ時に分解する．効率は落ちる
  • MPPデータベース(ParAccel)がAWSカスタマイズされて載っているので，その辺の知識がないと嵌まりやすい
  • マネージドサービスとはいえ，リーダーノードの挙動がおかしい時など，面倒を見ないと行けないケースはある
  • カラムを弄る場合は基本テーブルを作り直すのがベター．クラスタ再配置中はREAD ONLYになるので，その辺含めて運用を考える必要がある
    • 数時間READ ONLYの場合，貯めようとしていたログはどうするか，など
    • 今時はMPPデータベース単体で運用している所は少ない．RedshiftでもEMRなどからデータを整形して一気にガツンと入れるのが多い
  • クエリの同時実行制御周りはそれなりに頑張っている
  • ストレージと演算パワーが分離してないので，ユースケースによってはコストが割に合わない

BigQuery

  • Redshiftと同じく，アドホックに色々とデータをぶち込んで解析するには，JSON文字列(record型？)で保存する必要がある
  • 既存のMPPデータベースとかで考えないと行けない問題(distkeyとか)を，Googleパワーで強引に解決
  • 運用は完全Google任せ
    • Redshiftと違いGoogleの環境を共有するので，細かなことは出来ない
  • Googleの制約を受ける
    • 負荷が極端に上がるようなクエリとかは望み薄(FULL OUTER JOIN, 数億同士のjoin，count(distinct))
    • Redshift同様，でかいバッチ向けにHDFSとかオブジェクトストレージに生のデータを置いておくのがベター
  • BigQueryもスキーマがあり，alter column的なものがないので，変更する時は適宜テーブルを作り直すのがベター
  • Redshiftと違いクエリ単位の課金なので，どれだけ掛かるか把握するのが難しい
    • 小さい会社だとかなりマネージしやすい(この辺の話)．大きい会社や，マーケや営業の人がガンガン使う場合には，かなりバーストする可能性がある．Reservedがあるが，月200万からなので，判断が難しい
  • Streaming Importが結構パフォーマンスが出るので，importして即クエリがやりやすい(参考記事)
    • リミットがあるので，大量に入れる時には気をつける．2015年から有料．
  • 同時実行制御周りは基本よく動く
    • リソースはGoogle側が管理しているので，バッチ投げたら詰まるとかは起きにくい
    • リソースを占有しているわけではないので，勝手にクエリが死んだり，いきなり遅くなったりすることもある
      • 日本時間の21時当たりで起きやすいらしい．でかいバッチを投げまくっているユーザが海外にいる？

まとめ

基本的にこれらの裏にはHadoopなどの基盤が前提になりつつある(オブジェクトストレージ + 演算リソースでも可)．上のリストを眺めれば，なんとなく使い分けが分かるんじゃないでしょうか！ MPPと一纏めにするにはユースケースや得意なものが違うので，ちゃんと使い分けましょう．基本的にどれもBIツールと接続する方法があり，苦労はそんなにしないはず．

各プロダクトは常に改善されているので，ここに書いてある制約などは，いずれ緩和される可能性があります．常に最新情報をチェックしましょう．

今回はMPPクエリエンジンプロダクトの話なので上のリストでは省きましたが，Treasure Dataが提供しているTQAというMPPサービスは「Prestoで運用とかストレージを考えなくていい版」に近い感じになります．TDはさまざまな外部ストレージと連携出来るので，Treasure Dataを中心に使い分ける感じになります．
最後に宣伝！

P.S

Twitterに流したさらに要約したtweet.

Comments