挨拶
こんにちは。BALES CLOUDエンジニアの井上（エース）です。
BALES CLOUDは最近アナリティクス機能をリリースしました。この機能は、ユーザーのこれまでのコールやメールのデータをユーザーの好きな形で分析できるものです。
この機能はSisenseの埋め込み機能を利用しています。SisenseはLookerやTableauのようなBIツールの一つですが、アプリケーションへ埋め込みが特に想定されているようで、非常に簡単にアナリティクス機能をBALES CLOUDに組み込むことができました。
話は変わるのですが、前回の私の記事ではLookerをスマートキャンプのデータ分析基盤のBIツールとして利用していることについての記事を書きました。ここで私はLookMLを使って開発をしていました。
どちらも第三世代BIツールとして知られているBIツールですが、２つとも触ってみると、開発者視点で違いが見えてきました。今日はその違いについて語らせて貰えればと思います。
前提
弊社では各ツールを以下の用途で使用しています。
- Looker
- 弊社のデータ分析のためのBIツールとして
- Sisense
- 弊社プロダクトのデータ分析機能として
そのため重点的に触っている機能が多少異なります。記事にするうえで調査はしていますが、抜け漏れがあった場合はコメントなどでお知らせくださればありがたいです！
また、一人のエンジニアとしての観点となるので、マネージャー側の視点（例えばコストなど）についてはスコープ外とさせていただきます。
加えて、この記事は企業としてどちらかのツールを賛美するような記事ではありませんのでご注意ください。
ドキュメント
両者の違いをもっとも感じたのがこちらです。開発をするうえでドキュメントが充実しているかはツールが持つ機能性と同じ程度重要だと私は考えています。
Lookerは公式が用意しているドキュメントが豊富です。またBIツールとして現状メジャーな選択肢ということもあってユーザーが多く、コミュニティにも有用な情報が載っています。公式ドキュメントは日本語もあるので読みやすいです。
Sisenseは機能の豊富さにドキュメントがまだついてきていない印象です。公式ドキュメントは存在するものの足りない部分が多く、特にプラグイン開発をするうえで困りました。また公式ドキュメントは日本語には非対応なので、そのあたりも辛いときがあります。
コードの再利用性
LookerはLookMLという独自言語を利用することでコードの再利用性を高めつつ、非常に柔軟にクエリを書かせてくれます。Lookerでは基本的にデータの定義が分散することは起きづらいですし、それによってデータ定義をDRYにできます。
Sisenseはデータモデルをインポート・エクスポートできます。これによって同じコードを書くことは基本的に避けられるものの、別々のモデルで同じデータ定義を使いたい、などの場合は辛いかもしれません。
データモデルの構築の容易さ
LookerはLookML上で開発が完結するため、あるモデルを作る場合はLookMLを書いていく必要があります。
Sisenseのデータモデルは基本的に図を使って行います。どのテーブルをインポートするのかを定義し、それがどのように紐づくのかをコードではなくほとんどGUI上で行います。特にリレーションの定義がドラッグアンドドロップでできて作業効率が高いです。またこの定義の仕方は非常に直感的で、かつあとで見たときにどれがどれに紐付いているのかがすぐに分かります。モデル構築の容易さについてはSisenseが優れていると感じました。
https://sisense.gaprise.jp/solution/sisense-analytics
デプロイのパイプラインの構築
LookerはLookMLをGit管理できます。これによって、Prodに上げる前に自分のブランチで動作をチェックしたり、プルリクを出してレビューを受けたりできます。これによってデプロイが手間なく安全に行なえます。
Sisenseにはバージョン管理機能は現状ありません。本番に上げる前に確認などしたい場合は、モデルのインポート・エクスポート機能を使うなどする必要があります。ちなみにエクスポートされたファイルを自前のリポジトリでバージョン管理するなどできますが、Lookerのようにネイティブにバージョン管理が組み込まれているものではありません。
クエリのデバッグ
地味ながら大変重要なのが開発していくうえでのデバッグの容易さです。LookerではLookMLから自動生成したSQLを見ることができます。これを見ることで自分のLookMLの誤りに気づくことができます。何度これに助けられたかわかりません。
SisenseはJAQLという言語で動いており、SQLを見ることができません。代わりにクエリ発行時にどういったリレーションでデータが取得されたかを確認できます。ただこれはSQLに慣れているエンジニアであるほど理解しづらいものだと感じました。見方もちょっと独特なので、慣れるまでは時間がかかるかと思います。
クエリの高速さ
Lookerは基本的にライブ接続（自前でデータを保存せずDBにクエリを叩きに行く方式）であるため、クエリ発行時にBigQueryなどのデータソースにクエリを投げ、その結果を表示します。
Sisenseはライブ接続とElastiCubeの二種類がデータソースとして選べます。
ElastiCubeはSisense独自の高性能な分析データベースで、ビジネスインテリジェンスアプリケーションで必要とされる大規模なクエリに耐えられるよう特別に設計された超高速データストアを搭載しています（公式より）。
この説明に引けをとらず、たしかにElastiCubeは非常に高速に動作します。300万件程度のテーブルにさまざまなテーブルをJOINしても結果が出るまで1秒もかかりません。動作が早いというのはユーザーはもちろんですが、開発者としても開発するうえで時間を大幅に節約できるので助かります。
一方でLookerはキャッシュ機能が非常に高機能で、細かく動作を決めることができます。そのためLookerのクエリがすべて遅いわけではなく、キャッシュ戦略次第です。ただそれを差し引いてもSisenseの高速さは魅力です。
注意点として、ElastiCubeは毎回DBからデータを取得し、サーバーにビルドするという作業が発生します。1時間に一回ビルドするなどスケジュールを決められるので、このあたりは考慮が必要です。ちなみにBALES CLOUDではデータ量がまだそこまで多くないため、このビルド作業はあまり気になっていません。このあたりはプロダクトのデータ量次第ですね。
データモデル設計
LookerはLookMLでそれぞれどのテーブルがどのようにJOINされるかを定義したり、あるテーブルには特定のテーブルのJOINが必須であることを定義（required join）できたりとデータモデル設計に柔軟さがあります。
Sisenseはスタースキーマ（スノーフレークスキーマ）をベースにしたデータモデル設計を前提としている感覚があります（スタースキーマについてはこちらの記事が非常に分かりやすいです）。例えばSisenseでは、クエリ発行時、JOINパスが自動で決まります。つまりテーブルAからテーブルBへのテーブルの結合が、テーブルC経由でもテーブルD経由でもできるようにしているときにどちらを経由するかを指定できません。これにより問題が発生します。
分かりやすい例でいうと、行ごとにtenant_idを持つシステムです。下記のような場合、usersからtagsの情報を取ろうとすると、user_tags経由かtenants経由かという二択が存在することになります。当然user_tags経由が正しいのですが、設計上はtenants経由でもデータは取得できます。
このような場合に、勝手にJOINパスが決められる事による問題が発生します。つまりtenants経由でデータが取得されて、意図しない結果となる可能性があります。
これを避けるのであれば、スタースキーマ的な設計をする必要があります。
tenantの情報は冗長化されてそれぞれディメンションテーブルに格納されています。この設計だとusersからtagsへのルートは一つしかないので、さきほどのような問題が起きません。
かなり簡略化しているのですが、イメージが伝われば幸いです。
データウェアハウスを設計するうえでスタースキーマをベースに作ると、ディメンジョンとファクトが分かれているため利用しやすいというようなメリットが多くあります。このような作りを意識することが必要になるため、結果としてSisenseを利用することがより良いデータウェアハウスを作ることに繋がるという考え方もできます。
アプリケーションへの組み込み
Sisenseはアプリケーションへの組み込みが強く想定されているというのが随所に感じられました。たとえばSisenseでは埋め込み用にiframe、Embed SDK、Sisenes.JSの3つの方式が用意されています。Sisense.JSがもっとも高機能で、ウィジェット単位でカスタマイズができます。iframeの埋め込みも簡単にできます。ドメイン制限やCORSの設定やSSOはもちろん対応しています。こういったこともあって、BALES CLOUDでは機能要望に合ったものをあまり開発工数をかけることなく作ることができました。
Lookerの埋め込みについては実際に業務で触っていないのですが、iframeによる埋め込みが可能です。パブリック、プライベート、SSO埋め込みができます。いずれも簡単に実装ができそうですが、LookerについてはAPIを通してデータ取得することができて、かなり高機能なので、こちらを使うパターンが多いかもしれません。
Sisenseについてもう一つ特筆したいのがRow Level Securityにネイティブ対応していることです。企業アカウントごとに見えるデータを分けたいといった要望はアプリケーションへの組み込みでよくあると思いますが、Sisenseは非常に簡単にこれを実装できます。こういう点もアプリケーションへの組み込みを前提としているプロダクトならではだと思います。ちなみにLookerでもUser attributesとaccess_filterを使えば実装は可能ですが、Sisenseに比べると少し工数はかかりそうです。
総括
さくっとアプリケーションに組み込みたい、といった場合はSisenseが適しているかと思います。データモデルの構築は基本的にはほぼノーコードでできますし、iframeによる組み込みやRow Level Securityの対応などもあって、アプリケーションへの組み込みの初動を強力にサポートしてくれます。
一方でドキュメント性やバージョン管理、コードの品質管理、デバッグ、その他総合的な機能性でいうとLookerのほうがやはり優位かと思います。特にドキュメントが整っているのは本当に助かります。Git管理ができるのも開発者としてとても助かるポイントです。
最後に、色々と語ってしまいましたが、まだまだBIツール初心者なのでご指摘などありましたらコメントなどでお待ちしております！ ご一読ありがとうございました！
