読者です 読者をやめる 読者になる 読者になる

INPUTしたらOUTPUT!

忘れっぽいんでメモっとく

第1回Vertica勉強会に参加してきた

HP様のVerticaとDistributed Rに興味があって第1回Vertica勉強会に参加してきたのでメモしとく。

参考:何故DeNAがverticaを選んだか?


はじめてのVertica!

  • Verticaとは
    • 列指向RDBMS
    • 2005年から開発。日本導入は2011年から。
    • マイケル・ストーンブレーカー
      • INGRES → Postgres → C-store
  • Verticaの特徴
    • Speed
      • 列指向 + 超並列構成
      • プロジェクション
    • Scalability
      • マスターノードを持たない
      • リニアに性能向上
    • Simple
      • 標準SQL
      • 複雑なチューニングが不要
      • BIツールHadoopとの連携が容易
    • Cost
  • ネイティブな列指向 & 高度な圧縮
    • 必要な列だけ取得するのでIOコストが小さい
    • 自動的に最適なアルゴリズムで圧縮
      • RLE, Delta Encoding, LZO
    • 圧縮されたデータを解凍せずに演算する
  • MPPスケールアウト & クエリ分散
    • k-safetyで可用性を担保
    • Shared Nothing MPP
      • すべてのノードがクエリを受け付けられる
  • プロジェクション
    • 普通のDBでいうテーブル
    • カーディナリティの小さい順に列を並び替えて圧縮
    • ANSI 99 SQL完全準拠
  • 推奨ディスク構成

    • すべて内蔵ディスクで構成する
    • OS, カタログ領域とVerticaの領域はパーティションを分ける
  • マスターノードがないがユーザーはどのサーバーにクエリを投げたら良い?

    • どのサーバーでもよい。どのサーバーに投げても自動的に割り振られる
  • コミュニティエディションはどの程度試せる?
    • データ量1TB
    • クラスター構成3ノード
    • 評価期間の制限はない


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

  • DeNAのアナリストの業務
    • 収集・蓄積
      • KPI設計
      • ログ設計
    • 集計・加工
    • 分析
      • 仮説の設定と検証
      • 改善案の提案
  • Vertica効果
    • Pig, Hiveで数十分〜数時間かかっていたのが数秒〜数分になった
  • Argus効果
    • Excelなどに取り込む時間が削減できた
  • 分析業務のスケール化
    • アナリストがいなくてもSQLが書ければエンジニアや企画でも分析できるようになった
  • 集計効率化

    • Time series
      • TS_LAST_VALUE
      • 時系列で欠損となるデータに前回の値でIMPUTE
    • Lead, Lag
      • LAG : 時系列で前回イベントを取得
      • LEAD : 時系列で次回イベントを取得
    • Sum over Partition
  • 中間テーブルの作成は夜間バッチ?

    • Hadoopからの場合はバッチ
  • ゲームのログがVerticaに入るまでのタイムラグは?
    • 基本的にリアルタイム


DeNAでのVertica運用について

  • Verticaのセットアップつらい
  • VerticaとHadoopの使い分け
  • fluentdとkafkaでログをリアルタム収集
  • データ投入時に注意すること
    • 大量データ投入でInsertは遅い
      • copy, insert select
    • 欠損が生じることがある
      • 型が一致していないレコードは捨てられてしまう
      • abort on error オプションつけるとエラー検知できる
  • テーブル定義変更時の注意事項
    • 列は末尾にしか追加できない
    • 型の変更ができない
  • 突然クエリが実行できなくなった
    • あるクエリがリソースを占拠していた
      • Resource Poolによるリソースの制御
  • スキーマ、テーブル一覧を出すのが異常に遅い
    • MaxROSPerStratum, SortWorkerThreadsを設定していた
    • CHANGE_UNDER_SUPPORT_GUIDANCEのパラメータを調整する場合は要注意
  • データ量増加に伴いレスポンス悪化
    • 実行計画を見てプロジェクション作成していたがつらい
    • database designerを使用すると便利
  • Vertica自身の情報の保存期間が短い

    • set_data_collector_policy
  • 複数人同時に実行して突然落ちることはある?

    • キューにたまるだけで落ちることはない
  • 経験上、どういったクエリが遅くなる?
    • 適切なプロジェクションが作られていない状態でのJOINは結構遅い
  • 1テーブルあたりのレコード数はある?
    • 100GBを超えるとつらくなる
    • 中間テーブルやプロジェクション作ると大丈夫
  • ロードするときに気をつけることはある?
    • k-safetyを2にすると負荷かかったので1にしている


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

  • 検証結果
    • 集計やランクを伴う複雑なクエリにおいてはVerticaが圧倒的に高速
    • 圧縮率も高い
  • Tips
    • パラレルロード
    • 日付の絞込みに多くのコストが費やされている場合、run length encoding形式に圧縮モードを指定


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

  • verticaではテーブルは論理スキーマとして定義
  • データそのものはプロジェクションに格納される
  • プロジェクションの設計が性能に大きく影響する
  • RLE(Run Length Encoding)

    • 連続して現れるデータを繰り返しの回数で置き換えることによりデータ量を削減する方式
    • 「AAABBBBBCCCCCCCC」→「A3B5C8」
  • Comprehensiveモード

    • カーディナリティの低い順に全ての列を並び替え
    • 列内のデータをソート
    • RLEで符号化
    • 圧縮
  • Incrementalモード
    • 必要な列のみを使いチューニング
    • よく使用されるクエリに特化
  • 集計プロジェクション
    • ロードと同時にcount,max,min, top-kなどを実行して保持
  • mergeout
    • データがinsertされた場合、バックグラウンドで最適化される
    • デフォルトだと5分に1回
  • vertica日本語ガイドが作られた

  • 別製品で圧縮されたデータの解凍のオーバーヘッドで遅くなったがVerticaではどうか?

    • 列指向なのでselect * from〜は得意ではないがMPPを使って工夫はできる

  • 容量のカウントはどのように行なわれるんだろう?
    • k-safetyで冗長化した分はカウントされるのかな??
  • 時系列データのWindow関数便利そう!
  • チューニングなしでも速い!と聞いてたけどそうでもなさそう
    • プロジェクションの設計が重要そう
  • 懇親会の食事美味しそう。。。参加すれば良かったorz