この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2023年02月14日(火)、ANAインターコンチネンタルホテル東京、ならびにオンライン配信のハイブリッド形式でSnowflakeのイベント「SNOWDAY JAPAN」が開催されました。
当エントリではその中で、ブレークアウトセッションとして開催された「ビジネスの意思決定を加速する BI on Snowflake 設計の勘所」のレポートをお届けします。
セッション概要
当エントリで扱うレポートのセッション概要は以下の通りです。
[セッションタイトル]
ビジネスの意思決定を加速する BI on Snowflake 設計の勘所
ビジネスの意思決定を加速する BI on Snowflake 設計の勘所
[登壇者]
・三田 泰正氏(Snowflake株式会社 セールスエンジニアリング本部 シニアセールスエンジニア)
[セッション概要]
BI ソリューションは Snowflake に接続するデータアプリケーションの 1 つであり、大規模なデータから意思決定に役立つさまざまなインサイトを得る目的で、数多くのお客様に活用されています。しかしながら、その価値を最大化するためには、高いパフォーマンスで大規模データを可視化することが不可欠です。本セッションでは、BI ソリューションの具体例として Tableau を取り上げ、Snowflake の接続方式やキャパシティプランニングといったパフォーマンスに影響を及ぼす設計の勘所について説明します。
セッションレポート
はじめに
- 本日のテーマは「SnowflakeとBI製品の連携、組み合わせ」。
- メジャーな組み合わせではあるが、コストパフォーマンスを出そうとすると幾つか課題が出てくる。
Snowflake + BI製品のよくある課題
- Snowflakeは数多くのBI製品と接続可能。接続自体はODBC/JDBC、またサードパーティコネクタ経由等で行う事が出来る。
- ただ接続するのは簡単だがうまく使っていこうとするとSnowflake側に色々課題が出てくる。
- (1).コスト：BIからのクエリをSnowflake側で処理＝クエリの処理でウェアハウスを使用するため、想定以上にウェアハウスのコストが掛かる
- (2).ダッシュボードのパフォーマンスが出ない：ダッシュボードが開かない、フィルタ切り替えによる再描画に時間が掛かるなど。またピークタイムにアクセスが集中することでパフォーマンスが落ちる
- Snowflake＋BIの組み合わせで高いコストパフォーマンスを実現するにはどうすれば良いか？
- コストは出来るだけ下げたい
- その上でパフォーマンスを向上させたい
コストパフォーマンスに効く設計ポイント
ライブと抽出
- TableauからSnowflakeに接続する例 - 「ライブと抽出」の活用
- ライブ接続(直接接続)
- ユーザー操作による描画の際はSnowflakeにクエリを発行→クエリ処理はSnowflakeウェアハウス側で実行
- 常に最新のデータがダッシュボードに反映＝都度クエリ発行処理がSnowflake側に対して掛かる
- 抽出接続
- データをTableau Desktop/Serverの"ローカル"に抽出・保存
- ユーザー操作による描画の際はその抽出データに対してクエリが発行される＝Snowflake側に負荷は掛からない
- ただし、最新データの反映には「抽出ファイルの更新」が必要
- どちらを選択すべきか？
- 一長一短ある
- 二者択一では無く、データ更新の頻度や規模に応じて使い分ける
- 併用案
ダッシュボードのパフォーマンス問題
- 症状例
- 開くのに時間が掛かる
- フィルタ切替時の結果表示に時間が掛かる
- ボトルネック
- 同時実行性能、または単体クエリの処理性能に帰結
- ピークタイム(始業時等)に多数のユーザーが実行する場合にのみ発生(同時実行性能の問題)
- ピークタイムやユーザー数の大小に関わらず常に問題が発生(クエリ処理や描画性能の問題)
パフォーマンスのボトルネック
- そもそもBI(Tableau)とSnowflakeでどういった処理の流れがあるのか？を図示したのがこちら。(Tableau ServerからSnowflakeにリクエストがあった場合の例)
- ボトルネックになる場所は2箇所。1つはSnowflake側、もう1つはTableau側。
- Snowflakeではこれらのボトルネックに対する対応方法、ソリューションを説明していく
ウェアハウスの最適化
- 複数クエリの同時実行性能：マルチクラスターウェアハウスが有効。ユーザー数(実行クエリ)の増減に伴い、最大10クラスターまで自動的にスケールアウト(またはダウン)を行ってくれる
- また、ウェアハウスのスケールアップとスケールアウト：Tabjoltというベンチマークツールで色々テストやシミュレーションが出来る。
- 検討するタイミングはどこで取るか：クエリのキュー待ち時間を監視することで見極める
- 単体クエリの処理性能
- 単体クエリや描画処理がボトルネックになる場合は「ダッシュボードデザインの変更」を検討。
- ダッシュボードデザインが悪いとパフォーマンスは出ない
- デザインを変える＝Snowflakeへ発行するクエリを変える
- これは結果的にTableauの描画性能にも効いてくる
- BI製品の特性に応じた効率的なダッシュボードデザインを目指そう
- 単体クエリや描画処理がボトルネックになる場合は「ダッシュボードデザインの変更」を検討。
- Tableauの描画性能
- BI製品のベストプラクティスに沿ったデザインを参考に
- 改善例の紹介
まとめ
- ライブと抽出を併用することでウェアハウスコストを抑制
- 同時実行性能を向上するマルチクラスターウェアハウス
- ダッシュボードデザインのベストプラクティスの重要性
まとめ
という訳で、SNOWDAY JAPANブレークアウトセッション「ビジネスの意思決定を加速する BI on Snowflake 設計の勘所」のレポートでした。こちらの内容を見ててふと「この課題とソリューション、RedshiftとTableauの組み合わせでも同じ問題に直面してたなぁ...」と昔を思い出しました。RedshiftがSnowflakeに変わっただけで、詰まるところ「ボトルネックになっているところ、解決方法は変わらない」のですね。「このノウハウはどのデータベース／データウェアハウスでも有効である」と言い換えることも出来るのだと思います。必要な情報を確認し、取りうる良策を積極的に取り入れて改善していきたいですね。
5
