Lightdashはいいぞ

社内でLightdashを試験的に導入し始めたので、導入してみての感想をつらつらと書きます。

ツールの導入方法や使い方の解説記事じゃないです。ただの個人の感想です。

背景

• 今まで社内でのデータ集計の依頼が自分に集中していた
• 依頼側としても自分で自由にデータを集計したいという要望があった
• SQLを非エンジニアに布教するのはハードルが高いので、セルフサービス型のBIツールを導入したい
• データ基盤をdbtで管理してるのでメタデータの管理をdbtに寄せたい
• できればOSSでセルフホスティングしたい🤑

言いたいこと

Lightdashを(試験)導入したばかりですが、今のところ自分の感触としても社内の評判も良い感じです。

Lightdashは後発のプロダクトということもあって、ネット上で口コミ・評判を見ると「機能がまだまだ足りない」、「実運用には厳しい」などの声があるようでしたが、その評判も１年以上前のもので今では大分進化してSupersetやMetabaseにも見劣りしないプロダクトになっていると思います。

dbtを使ってデータ基盤を構築しているのであれば、Lightdashは間違いなくおすすめできるBIツールです。

dbtを使ってないならLightdashは間違いなくおすすめできませんので注意

知名度とか他社の採用実績などは気にせず、まずはローカル環境をサクッと立ててPoCしてみて欲しいです。
使用感くらいの確認であれば、公式のデモ環境も公開されてるので色々触ってみてください。

Lightdashの簡単な紹介

LightdashはセルフサービスBIツール(後述)で、dbtで定義したディメンションとメトリクスを基にデータの可視化ができるという特徴があります。dbtの利用は必須です。

昨今データ基盤界隈ではELT(extract -> load -> transform)のデータパイプラインが流行していて、そのtransform部分のフレームワークとしてdbtが台頭した流れを汲んだBIツールとなります。
そういう背景があるのでBIツールとしては比較的後発のプロダクトです。dbtが必要なこともあり知名度としてはまだまだではありますが、十分に本番運用できるツールかと思います。

国内で採用している企業をググると、RettyさんやUbieさんが採用しているらしいです。

セルフサービスBIツールとは？

セルフサービスBIツールでググるといろんな説明が出てきますが、正確な定義はともかくとしてこの記事内では、

• 利用者がSQLやプログラミング言語の知識を必要とせず、GUI上でデータ集計・可視化ができるBIツール

くらいの定義で話を進めます。

LightdashのGithubページに

Enable everybody in your company to answer their own questions using data

とあるように、社内の誰もがデータの探索を行うことができる状態を目指す思想から発祥した言葉かと思います。よくデータの民主化とか言われる文脈です。

有名なTableau含め、今では多くのBIツールがこのセルフサービスという性質を持っていますが、使い勝手や細かな機能差はあるので、導入前に比較検討した方がいいです。

他BIツールとの比較

選定候補になったのは以下の３つ。OSSに絞っています。

• Superset
• Metabase
• Lightdash

比較する時の観点

個人的には仮説検証サイクルを素早く回すために、使い勝手などのUX面よりもメタデータの管理しやすさや柔軟なクエリビルダーがあるかどうかいった、データ管理者側から見た時の機能性・メンテナンス性の方を重視して選定した方がいいと考えています。（もちろん全て満たせるものがベストですが）

比較表

選定候補のBIツールをそれぞれローカル環境を立てて実際に使ってみて比較してみた結果が以下の表です。(2024年3月時点での個人的な評価です。）
データ基盤をdbtで管理しているという前提ありです。

	Superset	Metabase	Lightdash
ビジュアリゼーションの豊富さ	○ third-party含めると何でもできそう	△ 基本的なものはある	△ 基本的なものはある
カスタムSQLの実行	○	○	△ 実行できるけど保存できない
カスタムディメンション	△ 簡単なSQLを書く必要がある	△ ビルトインの関数しか使えない	△ dbt側で記述する必要がある
カスタムメトリクス	△ 簡単なSQLを書く必要がある	△ ビルトインの関数しか使えない	△ dbt側で記述する必要がある
テーブルのJOIN	△ カスタムSQLのみ対応	△ GUIで何でもJOINできてしまう	⚪︎ dbt側でJOINできるテーブルを定義可能
定期通知機能	○	○	○
アラート機能	○	○	○
dbtとの統合	△ presetが提供するツールを使えば部分的には可能	△ third-partyのツールで部分的には可能	○ 公式で対応(そもそもdbtが必須)
dbt Semantic Layer連携	×	×	△ Cloud版(有償)のみ)
権限管理の柔軟さ	○	△ 一部機能はCloud版(有償)のみ	○
日本語対応	△ 一部のみ	△ 所々変な日本語	× ローカライゼーション自体できない

まず、SupersetはテーブルのJOINがGUIで不可能という点で、利用者がSQLを書けないという想定にアンマッチなので残念ながら不採用としました。

次にMetabaseですが、おおよそ要件に合っているものの、メタデータの管理をdbtで一元管理したいというデータ管理者目線での都合から不採用としました。

Lightdashは他ツールと比べてまだ細かい機能的に足りていない部分はあったりしますが、自分の希望や社内で求められている要求はひとまずクリアできそうなことと、機能の改善が今後も見込めそうなことから採用しました。

Lightdashの特にいいところ

ネイティブでdbtとの連携機能がついているのはdbtでデータ基盤を管理している身としてはデータガバナンス面で楽できます。dbtで管理できるということはコード管理が可能になるということなので、最近のGithub Copilot等のコード補完環境の充実も相まってBIツールの管理にかかる工数の短縮にもつながっていると感じます。

例. こんな感じでディメンションやメトリクスの定義をdbtモデルの定義内で記述可能です

models:
  - name: bus_all_reports
    description: >
      成果レポート
    columns:
      - name: referer_site
        data_type: STRING
        description: '成果発生元のサービス'
        meta:
          dimension:
            label: 成果発生元
      - name: booking_date
        description: >
          予約発生日時  
        data_type: DATE
        meta:
          dimension:
            label: 予約発生日
            time_intervals: ['DAY', 'WEEK', 'MONTH', 'QUARTER', 'DAY_OF_WEEK_NAME', 'DAY_OF_MONTH_NUM', 'MONTH_NUM', 'YEAR_NUM']
      - name: amount
        description: >
          サイト掲載価格
        data_type: INT64
        meta:
          metrics:
            total_amount:
              label: 流通額
              type: sum
            average_amount:
              label: 平均流通額
              type: average

また、JOINできるテーブルをdbt側で定義可能というところが他のツールにはあまりない機能で地味に気に入っています。テーブル間の結合方法を管理者側が定義できると利用者側にテーブルのリレーションの事前知識を求めずに済むので、利用者の教育コストも減らせます。（ちなみに、近年データエンジニアリング界隈で話題のSemantic Layerでもこのような機能があるようです。）

例. テーブル間の結合方法をdbt側で記述すると、、、

    meta:
      label: 予約明細
      joins:
        - join: buses
          label: バス便
          sql_on: ${buses.id} = ${bus_all_reports.bus_id}

LightdashのGUI上ではディメンションをクリックするだけでテーブルを結合した集計ができます

最後に

個人的にLightdash推しですが、要件や利用者のスキルに合わせて最適なBIツールを選択するのが重要です。ネット上の口コミ・評判は古かったりするので、最新の公式ドキュメントを確認したり、OSSであればローカル環境を立ててPoCするのが一番確実です。

予算があってデータ集計に関して技術者のサポートが十分に受けられる環境だったり、利用者側が扱うデータについて十分に事前知識を持っているのであれば、有償のTableau等も当然検討候補にはなると思います。
ただ、dbt(またはSemantic Layer)とのインテグレーションに対応しているBIツールって案外少ないんだな、、、という印象でした。

Lightdashでは機能不足感があると感じたら、Public Roadmapも公開されているので、今後どのような機能が追加予定なのか見るのもいいと思います。