今回は、いよいよベンチマークということなのだが、実は早々に問題に直面してしまった。
前回説明したように、Snowflakeには
・Local Disk Cache
・Results Cache
という２つのキャッシュがあり、後者は
ALTER SESSION SET USE_CACHED_RESULT = false;
と設定してあげれば、無効にすることができる。
しかし、Local Disk Cacheを完全にリセットするのはなかなか難しいようなのだ。
Results CacheなしでもLocal Disk Cacheはかなり有効に働き、使えば使うほど利口になってしまって、ベンチマークにならない。
厳格に検証を行うのであれば、Warehouseを複数作成して行うのが良いのかもしれない。よく考えれば、Snowflakeの良さはコンピュートリソース（Warehouse）とストレージが分離されていることにあるわけだからWarehouseをたくさん作ってもよいし、Suspendさせておけば課金はされないのだから...
ということで、試行錯誤に時間がかかってしまったが、早速結果をご報告！
Sisenseのサーバはおそらくパフォーマンスにはあまり影響を与えないと考えられるため、普通のインスタンスでいいんじゃないかと考え、以下の環境を準備した。
■評価で使用した環境
- サーバ AWS r5.2xlarger5(vCPU 8 / MEM 64 GB)
- OS Windows Server 2016
- Sisense Version v8.01
Snowflaker側はファクトテーブルが60億レコードのTPCH_SF1000を使用した。60億件であれば、大企業のトランザクションレベルのボリュームがあり、そこそこのビッグデータだが、通常のインメモリBI製品では扱えないレベルだ。
またWarehouseはX-Small, X-Large, 4X-Largeで評価したが、X-SmallでAWSのC3.2XLarge (8 コア, メモリ15GB)程度と考えていいらしい。X-Largeがその16倍、4X-Largeで128倍のスペックということになる。
■Snowflakeの環境
・ターゲットのデータベース
- データベース SNOWFLAKE_SAMPLE_DATA
- スキーマ TPCH_SF1000
- ファクトテーブル LINEITEM (約60億レコード)
・Warehouse（いずれもCluster=1）
- X-Small (1credit / hour)
- X-Large (16credits / hour)
- 4X-Large (128credits / hour)
さっそくSisenseからSnowflakeにライブ接続してみる。
まずSissenseの「データ」メニューから[+Live]ボタンをクリックし、ライブモデル名を登録する
[+データ]ボタンをクリックし、コネクタを選択する（SisenseにはSnowflake専用のライブコネクタが準備されている）
接続設定は至って簡単で、以下のように設定すればよい。
・Connection String
jdbc:snowflake://<ユーザアカウント毎のサブドメイン名>.snowflakecomputing.com/?warehouse=<ウェアハウス名>
※ユーザアカウント毎のサブドメインを含むドメイン名はSnowflakeに接続した時のURLから取得すればOK
例）
jdbc:snowflake://xyz01234.snowflakecomputing.com/?warehouse=COMPUTE_WH
・User Name
Snowflakeログイン時のユーザ名
・Password
Snowflakeログイン時のパスワード
[次へ]をクリックして、「データベース選択」画面に遷移する。
ここでは「SNOWFLAKE_SAMPLE_DATA」を選択し、[次へ]をクリックし、テーブルの選択画面に遷移する。
「TPCH_SF1000」からすべてのテーブルを選択し、[次へ]をクリックすると画面上に選択されたテーブルが表示される
いつもの要領でテーブル間のリレーションシップを設定していこう。
完成形は以下のとおり...
ここで右上の[発行]をクリックすると「接続」は完了だ。
ここからはダッシュボードを作成しながら、ベンチマークを行っていく。
データソースを選択し、ダッシュボード名を入力する。
ウィジェットウイザード表示されるので、ここからがベンチマークとなる
ベンチマークはウィジェットの作成とフィルターに分けて行う。
【1】ウィジェット
縦棒グラフにて測定する。ここでは「値」は60億レコードが格納されているLINEITEMから"L_EXTENDEDPRICE"を合計する（これがY軸）。
カテゴリ（つまり縦棒グラフのX軸）で３つバリエーションの設定を行い、表示までの時間を測定する。
[1-1]縦棒グラフ X軸 [Months 単位 O_ORDERDATE]
[1-2]縦棒グラフ X軸 [N_NAME]
[1-3]縦棒グラフ X軸 [P_TYPE]
【2】フィルタ
ダッシュボードフィルタとして、[R_NAME]と[N_NAME]を追加し、上記の[1-3]で作成したウィジェットの表示までの時間を測定する。
[2-1-1] R_NAMEにて"AFRICA"を選択
[2-1-2] R_NAMEにて再度"AFRICA"を選択
[2-1-3] R_NAMEにて"ASIA"を選択
[2-2-1] N_NAMEにて"ALGERIA"を選択
[2-2-2] N_NAMEにて再度"ALGERIA"を選択
[2-2-3] N_NAMEにて"ARGENTINA"を選択
冒頭で書いたけど、SnowflakeのLocal Disk Cacheは素晴らしくて、一度表示したら２回め以降はmsec単位で返ってくる。キャッシュからそのまま返しているからだ。
しかし、これではベンチマークにならない。Warehouseのサイズアップだけ行うとキャッシュの影響を受けるため、Warehouseを３つ準備して、厳格に初期表示で測定を行ってみた。
レスポンスの計測は、snowflakeの「History」で確認できる。
クエリが完了したら、基本的にはSisenseのダッシュボードは即座に更新されているのも確認済み。
ウィジェットの軸の表示を３パターンでWarehouse毎に計測してみた。
X-Smallは最小で450秒、最大で743秒もかかる。これは運用に耐えられない遅さだ。通常、人間は10秒を超えると「遅い」と待ち時間を意識するようになる。そういう意味ではインメモリBIで求められるレスポンスを満たしているのは4X-Largeということになる。
しかし、そもそも60億件を10秒以内で返せという要求自体に無理がある。
60億件の集計と考えた場合、初期表示が30秒程度かかっても、次回からは1秒も待たずに表示されるX-Largeでも十分な速度ではないだろうか。
むしろ、60億件をキャッシュなしで30秒程度で返せるなら素晴らしい性能だと僕は思う。
フィルター1（R_NAME）とフィルター２（N_NAME）の結果は以下のとおりである。
初期表示で計測すると、60億件だけあって、やはりX-Smallではかなり厳しい結果となった。X-Largeで20秒以内、4X-Largeだと10秒前後のレスポンスとなっている。
また、いずれのWarehouseも２回目の表示は300msec程度でフィルタが完了している。X-Smallでも同程度であるから、キャッシュはWarehouseのサイズに依存せず機能している。
こちらもインメモリBIに求められるレスポンスを出すなら4X-Largeということになるが、4X-LargeはX-Largeの8倍の費用がかかるので、コスト面を考慮してWarehouseを選ぶことになると思う。
以上、SisenseからSnowflakeにライブ接続してベンチマークテストを行った結果をご報告した。
Sisenseは通常はElastiCubeにデータを取り込んで運用する。しかし、
・データをリアルタイムに集計したい
・ElastiCubeでは耐えられないサイズのデータを集計したい
というような時にSnowflakeという高速DWHが非常に有効な手段だということが実証できたと思う。
実際、今現存するインメモリBI製品ではとても扱えないデータサイズなので、レスポンスが多少かかってでも扱えるというのはライブ接続の恩恵に他ならない。
SisenseのElastiCube自体、十分にビッグデータを扱えるのだが、10億レコードを超えるデータでは十分なパフォーマンスは出ないと聞く。
実運用としては、通常のダッシュボードはある程度サマリされたデータ（10億件以内）で運用し（これはSisenseのWeb Data Designerでサマリすればいい）、よりリアルタイムで明細データからしか得られない分析を行うような場合はライブ接続のダッシュボードを利用するハイブリッドな形態が望ましいと思う。
どこかSnowflake+Sisenseを導入してくれるお客様いないかなあ...
今回のベンチマークでFree Trial分をたった１日で使い果たしてしまったもので（笑）
ではまた！
最後に、弊社ではSnowflakeのナレッジサイトも運営していますので、ぜひこちらもご利用下さい。
