こんにちは、fluctでデータエンジニアをやっているyanyanです。今回はfluctで新たなBIツール「Lightdash」の利用を開始したので、導入に至った背景と利用を開始してみてどうだったかというのを記事にしてみました。

背景

fluctはインターネット広告の配信をしている会社です。広告を掲載して収益を得たいメディアに対して、いい感じに広告を配信する仕組みを提供しています。そんなfluctでは、主に社内で広告配信の実績を確認したり分析する用途でBIツールを使っています。

これまではAWSのAmazon QuickSightとRedashの２つが使われてきました。Amazon QuickSightは他のBIツールと比較したときにユーザーあたりの単価が安いことや最低限やりたいことができるといった理由で採用されていました。また、Redashは配信実績のデータに限らず様々なデータソースのクエリやSlackへのアラート通知、Googleスプレッドシートへのクエリ結果の書き込みで使われています。

Amazon QuickSightとRedashについて、当初はなにか別のものに乗り換えたいという気持ちはそこまで強くありませんでした。しかし、データエンジニアコミュニティのイベントでLigthdashの話を耳にし調べてみたところ魅力的なポイントがいくつかあり本格的に乗り換えを検討することにしました。

Lightdashの魅力

ユーザー数に依らない料金体系

BIツールは大抵ユーザー数課金です。ユーザー数を増やすことがコストに直接響いてくるのは、組織全体にデータ活用を浸透させることの障壁になりえるためできれば避けたいと考えています。そんな中Lightdashの料金体系は基本固定の料金が月額でかかる形式です。AI Agents機能を使うためにアドオンの課金が必要だったりはしますが、ユーザー数やダッシュボード数に比例してコストが増える料金体系ではないところは非常に魅力を感じました。ちなみに我々のAmazon QuickSightの利用コストも、気づいたらユーザー数が増えLightdashのCloud Proとどっこいどっこいくらいの料金になっていました。

利用状況の把握のしやすさ

Amazon QuickSightのダッシュボードやRedashのクエリが今も使われているかどうかを把握するのが難しいという課題感がありました。特にRedashのクエリ結果がスプレッドシートからインポートされているケースが社内ではそれなりにありました。Redashのクエリ結果のインポートはインポート先のスプレッドシート側でRedashのAPIを叩くというやり方なので、Redash側からインポートされているかどうかを確認することが困難でした。

一方でLightdashでは、チャートやダッシュボード側からSlackやスプレッドシートへの連携を設定するやり方です。そして、設定された連携の一覧や実行状況を確認する画面があるため連携先の把握がしやすくなっています。この違いは利用を促進していきながら、同時にガバナンスも効かせるという観点で魅力的でした。

dbtモデル上でのセマンティックモデルの定義

ディメンションやメトリクス、複数のメトリクスを組み合わせて計算されるメトリクスの定義やテーブル同士のリレーションなどをdbtモデルの定義にメタデータとして書くことができます。Lightdashでクエリするテーブルは基本的にdbtによって作られるので、関連するメタデータの管理もdbtのモデル定義上でできるのでメンテナンスしやすいと考えています。

実際に導入してみて

現在はCloud版のトライアル期間で、簡単なチュートリアル記事を展開し社内の希望した人に各々自由にダッシュボードやチャートを作ってみてもらっています。

現在作られているチャートは39個、ダッシュボードは23個になりました。ビジネスサイドで積極的に使ってくれている人が数名おり、「こんなことできる？」といった質問をしてくれたり、「こういう使い方めっちゃ便利だよ！」というtipsを共有してくれたりと、Lightdashの魅力を広める一助となってくれています。また、トライアルではありますがAI Agents機能も試させてもらっています。ビジネスサイドの有志がAgentのプロンプトを整えて配信実績の分析が自然言語でできるようになりました。

fluct全体へ活用を浸透させていくのはまだまだこれからですが、一部のチームでは先述したようにダッシュボードやスプレッドシートへの同期、AI Agentsが積極的に活用されておりスタートダッシュとしては上々な滑り出しかなと感じています。さらにLightdashの布教をしていくべく、各チームへの勉強会や活用事例の共有などを考えています。

開発部分の整備は最低限しかできておらず、GitHub上でPRを作ると変更が反映されたプレビュー環境の自動作成、PRマージの際の自動デプロイをGitHub Actionsで実装しています。Lightdashに関するGitHub Actionsはテンプレートが公式からいくつか用意されており、参考にさせてもらいました。

地味に嬉しいポイント

Lightdashにはdefault_filtersという機能があり、個人的にはこれが地味に嬉しい機能でした。というのも、我々が扱う広告配信の実績データというのは量が膨大なのでフィルターをうっかりつけ忘れるととんでもない時間とコストがかかるクエリが実行されてしまいます。default_filtersによってユーザーが何もフィルターを指定しなくても見る範囲を絞ることでそういったうっかり事故が防げます。

fluctでの活用例を挙げますと、以下のように日付のディメンションに対してデフォルトで前日のフィルターがかかるように設定し、日付のフィルターを必ずつけるようrequiredフラグをオンにしています。

version: 2
models:
  - name: model_name    
    description: ...
    config:
      meta:
        default_filters:
          - EVENT_DATE_JST: inThePast 1 days
            required: true
    columns:
      - name: EVENT_DATE_JST
        descripton: 日付 (JST)
        meta:
          dimension:
            label: 日付 (JST)
            type: date

この設定により、default_filtersが設定されたテーブルがチャート作成画面で選択されると日付のフィルターが自動的に追加されます。

今後の展望

まずは使ってもらうことに重きを置いているため、作られたチャートやダッシュボードの置き場所に関するルールやユーザーの権限管理の整備などはあまりできていません。利用状況は把握しやすいとはいえ、無秩序にものが作られていくと結局管理しづらくなったり棚卸しが大変になっていくので早いうちに交通整備することを考えています。