第１回 Vertica 勉強会

DeNAでVerticaの勉強会が開かれるということで行ってきた．皆さんお疲れ様 & ありがとうございました．

VerticaはMPPデータベースと呼ばれるプロダクトの一つ．まとめみたいなのはすでに他の人が用意してくれているので，そちらを参照してください．

• 第1回 Vertica 勉強会 - Togetterまとめ
• 第1回Vertica勉強会に参加してきた - INPUTしたらOUTPUT!
• 第１回 Vertica 勉強会に行ってきた - wyukawa’s blog

はじめてのVertica！（はじめのて方にも、20分で分かりやすく解説）

Verticaの基本的な話．C-Storeが元になっていて， やはりC-Storeの論文に書かれている機能がベースになってた．

ここで出てきた

• 列指向フォーマット
  • そして列毎の圧縮
• Shared Nothing
• ANSI SQL準拠

とかはMPPでは基本的な特徴で，それらを一通り持っている感じ．

少し珍しいものとしては，マルチマスタみたいにすべてのノードがクエリを受け付ける所． 複数クエリが飛んでいる時にどういう負荷分散をするか分かってないけど，クエリを投げた時にあるノードが自動でリーダーになるっぽい．
Impalaも似たような仕組みだけど，Statestoreみたいな外部サービスすら存在してないようなので， クラスタがどういう風に状態を共有しているのかが，個人的には気になっている．

あとで言及するけど，DB Designerというツールが一番の肝.

DeNAでのverticaを活用したアナリスト業務のご紹介

DeNAでどうやってVerticaを利用しているかの話．まだPrestoやImpalaが広まる前から利用しているようで， やはりHiveやPigをAd-hocクエリの代わりに使うのはつらかったという．

もちろんすべてをVerticaでやっているわけではなくて，データはHadoopクラスタにも入れていて， でかいサービスなどの場合はHadoopで中間データをつくってVerticaに入れているという，よくある構成.
ストレージと密結合しているMPPデータベースはこまめなロードが大抵苦手なので， データ量が大きいところでは皆この構成を取っている．

leadとかlagとかのWindow関数はHiveやPrestoでも使えるんだけど，timeserieseというgap-fillingな関数は少し面白いなと思った．

DeNAでのVertica運用について

FluentdとKafkaを使ってデータを収集している話があって，ここでもFluentdが！

ここでHadoopを機械学習にも使っているという話をしていた．何のプロジェクトを使っているんだろうか？懇親会で聞くの忘れてた．

運用に関して色々とTipsを話されていて，参考になる発表だった． データインポート時に型が一致してないレコードをデフォルトで捨てるのが，なかなか豪快だなぁという感じ．

あとクエリは基本Resource Poolで細かく制御するのが複数ユーザで使う時の前提． これはどこのMPPデータベースでも同じで，何もしないと一人がでかいクエリ投げると他の処理が止まってしまう．

CTC、Vertica はじめました！－テスト結果を共有！

「Verticaがすごい」という話だったんだけど，テスト内容の詳細がなくて， どういうスキーマで，どれくらいのデータがあって，どういうクエリかが分からずかなりふわっとしていた． あとグラフに目盛りとかもなかったので，さらにすごさがよく分からなかった…

お客さんのテスト結果ということらしいので詳細を話せないのは分かるのだけど， こういうオープンなイベントだとTPCとか使って分かるデータで見せないと， ちょっと厳しいかなぁという感じ(特にパフォーマンスとかを気にするエンジニアには)．

Verticaの速さの秘密、プロジェクションに関して20分で！

Verticaでのテーブルは単にどういうカラムがあるかというスキーマを持っているだけで， 実際にデータを保持するのはプロジェクションという単位．誰かがtweetしていたけど，Materialized Viewみたいなもの．

ここでDB Desingerというのが使えて，データやクエリを登録すると，それに最適なプロジェクションを構築してくれるらしい． プロジェクションは一つのテーブルに何個も構築出来るので，それぞれ必要なプロジェクションを作っておけば， 後でクエリエンジンが勝手に最適なプロジェクションを選んで実行してくれる．

Vertica，てきとうにやっても速い，みたいなの前聞いたことあったけど，実際はDB Designerにお任せという感じのようだ． DB Designer便利だけど，当たり前だけどプロジェクション作るとそれだけ容量食うので，作りすぎに注意．

データロード時に集計してしまうLive Aggregate Projectionという仕組みがあるのだけど， ロードの負荷が結構無視できないVerticaだと，大規模だと使いにくい印象を受けた．

懇親会

色々と生の声が聞けた．

懇親会でユーザに聞いた話だと，OOMみたいなので落ちることはないらしく，20-30人とかで投げてもキューに貯めて順次処理する． ただメモリ使用量が大きすぎたり，キューが貯まりすぎると，落ちるより先にクエリがRejectされる．

K-safetyといういわゆるレプリケーションの仕組みがあるのだけど，DeNAさんや他のユーザも1とのこと． 2にするとデータロードの負荷が高くなり，色々と大変になるらしい．
個人的には，K-safetyの数を増やせばデータの分散具合が増してクエリの処理効率がよくなると思っていたんだけど， Verticaは基本マスターデータしか見に行かないので，増やしても意味ないらしい．

K-safe 2ってレプリケーションすることでデータを分散させるわけだから，その分各ノードでのデータのローカリティがあがってクエリが高速になる気もするし，安易に減らすのはアンチパターンな気もする #vertica_meetup

— Mr. Fiber (@repeatedly) March 25, 2015

@repeatedly Verticaの場合K-safe1でも2でも基本的にはマスターデータのノードにしかアクセスはいかなくて、レプリの方にはアクセスいかないです！#vertica_meetup

— Civitaspo (@Civitaspo) March 25, 2015

@Civitaspo @repeatedly 　レプリカはノード障害あった際に使われます。基本的には、レプリカは同じソートパターンを採用し、クエリーの高速性には寄与しません。K-safe=1のパターンが多いです。　#vertica_meetup

— Projection_man (@Projection_man) March 25, 2015

PrestoとかのようなMPPクエリエンジンと違ってストレージと結合しているし， この辺うまく使ってデータの読み込み効率化出来そうだなぁと思っているんだけど，ソースが見られないので何とも言えない…

あとクラスタの再配置やデータのリバランスは結構時間が掛かるらしく，数日かかることもあるとのこと． パフォーマンスはそんなに落ちないらしいけど，別クラスタを立てて一気に入れ替えるのが楽なのかなぁーという．

まー，やはり銀の弾丸はないので，皆それぞれ苦労するポイントはあるなという感じだった． 話を聞かせてくれた人達に感謝 (-人-)

まとめ

第一回ということもあり，基本的な話が多かった印象でした． ただ実際に使っている人の話とかはやはり参考になる．

第二回もあるかもとのことなので，またその時は参加するかもしれません． オープンソースではないので，気になる所の実装がチェック出来ないのがやっぱりつらい所…