Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

Tokyo dbt Meetup #5 で Lightdashについて紹介しました

分析チームの井下田(@hiroki_igeta)です。 Tokyo dbt Meetup #5で登壇機会をいただき、「Lookerから、dbtと相性のよいLightdashに移行してみた話」というタイトルで発表させていただきました。

speakerdeck.com

ちなみに今回のMeetupは、オフラインとオンラインのハイブリッド開催でした。 会場および配信環境の提供をいただいたCARTA HOLDINGS様ありがとうございました!!
また、Meetupの企画をいただいた瀧本さま、発表をお聞きいただいた皆様にもこの場を借りてお礼申し上げます。

↓こちらでイベントの録画をご覧いただけます! www.youtube.com

登壇の概要

登壇では「なぜLightdashに乗り換えたのか」「LookerとLightdashの違い」「今後の展望」について話させていただきました。*1
まだまだLightdashを使い始めたばかりのため、公式ドキュメントに記載されていることをかいつまんで話す形になりましたが、今後もLightdashの利活用について積極的に対外発信できればと考えております。

ちなみに、RettyでDWHの管理をdbtに移行した際の話については下記のTechBlogをご参照ください。
engineer.retty.me

登壇でいただいた質問

dbt Slackコミュニティの #local-tokyo チャンネルのスレッドでいただいた質問に回答させていただきます。
弊社でも、まだまだLightdashは試しながら使っている状況ですので、今後ここで回答した方針と変わる可能性がある点、ご注意ください。

BI使う人の幅が広い故、日本語対応されてないのが結構ネックになるんですが、そこらへんどうしてるんだろ。

A: 実は部分的に日本語対応されてます!
yaml側でlabelやdescriptionを日本語で記載した内容がLightdashに反映できるので、利用者の要望を聞きながら運用したいと考えています。

yamlで日本語も定義できる


・LightdashとTableau他BIツールの比較を過去にしたことありましたが、その当時はビジュアル面の表現が弱くて単純に他BIツールからの移行が難しい印象ありました。今どうなのかは気になるところです
・Looker→Lightdash に切り替える上で、機能不足や仕様の違いで切り捨てた(諦めた)部分はあるのか気になる。

A: 2023年3月31日時点でも、円グラフが使えなかったり、表内で棒グラフで可視化したりといったビジュアル面の表現が弱い部分はまだまだあるのが現状です。現時点では、BIをLightdashに乗り換える際は妥協が必要な部分が一部存在するかと思います。
上記のビジュアル面の弱い点に加え、MergeResultsやBigQueryのdry run(クエリ実行前に処理見積もり機能)が使えない点が、切り捨てたポイントです。(今後の開発に期待です!)


・Lookerみたいに「この人はこのGroupとする」みたいなGroupを紐づけるのと、それによるaccess grantみたいなのできるか気になってます。
・Tableauもよわい、lookerが強いガバナンスまわりは、どうしているのだろうか。権限関係。

A: Lightdashを使い込みながら権限設計を検討している途中ですが、Lightdashでは組織・プロジェクト・Spaces*2ごとに、権限のロールが割り当てられているのである程度アクセス管理は柔軟に行えそうです。
また、メールアドレスのドメインでデフォルトのロールも設定できるのが便利だなと使っていて感じています。 ↓詳しくは下記の公式ドキュメントをご参照くださいmm
Roles and permissions | Documentation | Lightdash


・BI系、スプレッドシート連携したいという要望があまりにも多い・・(ゆえにredashをなかなか捨てられない
・スプシ連携できたら即導入したいけどできるのだろうか

A: わかりみが深いです。現状、Lightdashはスプシと直接連携できない状態です。
したがって弊社では定期的に結果をスプレッドシートに連携したいものに関しては、GASを用いた内製ツールでBigQueryを定期実行し、結果をスプレッドシートに出力する運用を行っています。
上記のツールを利用せずcsvダウンロードしてスプレッドシートで加工する使われ方はLooker時代もされているので、Lightdashでも同じようなことは発生しそうだと考えています。


利用ユーザを自由にセグメント切って、それぞれ毎に見せられるdbtのmodelやカラムを分けれる、までにはならない?いける?のでしょうか。

A: カラム単位は現状不可ですが、model単位なら可能です!
1つの組織アカウント内に複数のプロジェクト作成が可能なため、プロジェクト毎に利用ユーザーと表示するmodelを切り分ける設定を行うことで実現できます。
ちなみに表示するmodelは、yamlのtagで指定することができて便利です。(もちろんmodel名で指定することもできます。)


dbtのモデルとしてjoinするのと、yamlでjoinするの使い分けはどう整理するといいんでしょう?

A: これ難しいですよね。。。基本的にはfactとdimension単位でdbtのモデル管理をしているので、yamlでjoinする方針としています。


そのほか質問等ありましたら、dbtのslackコミュニティ内や、meety、Twitterなどでご連絡ください!
- dbt slackコミュニティ
- ⚡️Lightdashについて話します⚡️ - Retty株式会社の中の人のカジュアル面談 - Meety
- Twitter(@hiroki_igeta)

*1:Lightdashはdbtプロジェクトと接続して利用できるBIツールです。

*2:ダッシュボードやチャート図を格納するフォルダのようなもの