Halo、毎日ニコニコしているニコです。
データエンジニアとして、今delyでデータに関するいろいろな楽しいことをしています。
日本語は自分の母語ではないのにガタガタ書いてみましたw! 日本語でブログを書くのは少し難しいですが、もっと上達したいため、今回挑戦しようと思っています！
それでは、早速今日のトピックに入りましょう。Let's get started 👍
はじめに
最近、私たちはすべてのproductを一つのデータ集権化platformに統合しようと多くの計画を立てています。
なぜ私たちがすべてのproductを一つのデータ中央集権化platformに統合したいのかというと、この統合によって統一されたガバナンスを実現し、セキュリティを維持することができると信じているからです。また、これにより、今まで異なるデータ基盤やワークフローで分かれていたチーム間のsiloを解消することができます。
さらに、platformの統一により、私たちはPDCA（Plan-Do-Check-Action）サイクルをよりスムーズに回し、意思決定を迅速かつ正確に行えるようにすると、1つのproductのデータだけで意思決定をするのではなく、delyのすべてのproductのデータを考慮することができます。
私たちのデータ中央集権化プラットフォームの方向性についてもっと知りたい場合、ハリーさんが詳細に解説していますした。詳細はこちらです：
このブログでは、特にアドホック分析を改善するために、チームがより良い分析を行えるようにする方法について、Lightdashという新しいツールを導入し、Redashから移行する過程を話していきます。ぜひ読み続けてください！
Redashの撲滅
こちらのプロジェクトを進める中で、私たちはデータ提供の方法やセキュリティの強化も進めていきたいと考えています。また、現在利用しているツール、Redashが、このプロジェクトをサポートするには不十分だと感じています。そのため、より優れたフローとセキュリティを提供できる新しいプラットフォームに移行することを決定しました。
歴史上、delyはRedashをad-hoc分析の主なツールとして使用しています。利用当初は私たちのニーズにぴったりでした。しかし、過去2年間でデータスタックをSnowflakeなどのModernなdata stackに移行し、意思決定に必要なモデルを定義するためにdbtを使用してる中で、Redashを使うことに対していくつかの課題に直面しました。そのいくつかの主な問題点は：
新バージョンリリースの遅さとセキュリティの脆弱性
Redashは更新が遅く、securityに関する問題もありました。Databricksに買収されて以来、開発が停滞し、セキュリティの脆弱性が悪化しました。私たちは、ほぼ3年間新しいリリースやpatch updatesがない時期があったことを経験しています。
クエリ結果の信頼性の欠如
Redashはクエリを迅速に作成できましたが、結果の信頼性を確保する仕組みがありませんでした。クエリを書いた人が退職したり異動したりすると、クエリのロジックやデータ変換を追跡するのが難しくなり、不確実な結果を招きました。
サーバーの負荷とシステムの不安定性
Redashは大きなデータセットを処理する際にserver resourcesを大量に消費し、システムが不安定になることが多くありました。その結果、頻繁に再起動が必要となり、迅速なアドホック分析に支障をきたしました。
これらの問題を解決するために、Redashの問題を解決できる最適なツールを調査してきました。複数回の議論とテストを経て、Lightdashへの移行を決定しました。まずは、delyでのアドホック分析を含む分析プロセスに関する私たちの課題について、少し話します。
アドホック分析のプロセス
私たちのアドホック分析プロセスはシンプルですが、とても重要です。新しいProductやビジネスプロセスの結果を迅速に分析する必要がありますが、データチームが検証してデータマートを作成するのを待っていられるのは時間がかかることが多く意思決定のタイミングが遅くなる傾向があります。それは新しいビジネスプロセスにおいては、事前に定義されたメトリクスやKPIがないことが多く、データチームにモデル作成と検証を頼むと時間がかかり、PDCAサイクルが遅くなります。
そのため、データオーナー（ビジネスプロセスの責任者）が自分で素早く分析できるようにする必要があります。このプロセスは、delyのビジョンにも合致しています。完璧を求めず、すぐに結果を共有することが大切だと考えています。Ad-hoc分析の必要性は、ビジネスニーズに素早く対応するためにますます重要になっています。
Lightdashの導入
なぜ私たちがLightdashを導入し、移行することを決めたのでしょうか？こちらは、delyでLightdashを使用できるかどうか調査したときにまとめた理由です。
dbtの友人
私たちのチームはdbtを使って信頼できるモデルとメトリクスを作成しています。これにより、信頼できる唯一のソースを維持できます。Lightdashはdbtとの統合が素晴らしく、dbtのメトリクスをLightdashで簡単に使うことができると、すべての変更を追跡できます。これにより、チーム全体での連携がしやすくなり、アドホック分析が一貫性と精度を持つようになります。
セルフサービスad-hoc分析
Lightdashの素晴らしい点は、セルフサービス型の分析ができることです。特に、「write back to dbt」という機能が私たちにとって重要です。この機能を使うことで、チームがクエリを作成、その進捗を追跡できます。
さらに、Lightdashでは自分で定義したディメンションやメトリクスを使用できるため、ビジネスユーザーがデータを探索し、自分でクエリを実行できるようになります。以前はデータチームにメトリクスの作成と検証を依頼していましたが、今ではビジネスユーザーがすぐにデータを分析し、重要なメトリクスを追跡してリアルタイムで意思決定を行えるようになりました。この変化により、意思決定が加速し、チームのagilityが向上します。
より良いガバナンス
Lightdashは素晴らしいガバナンス機能を提供し、データアクセスの管理を支援します。私たちはアクセスをspace（関連する分析をグループ化）、モデル、さらにはdbtスキーマを使ってカラムごとに制御できます。ユーザー属性を使ってアクセスをフィルタリングすることで、データオーナーや各チームが自分のアクセスを管理し、全体的なガバナンスを保つことができます。
コスパ
Lightdashのスタータープランは非常にリーズナブルで、登録ユーザー数に制限がないため、チームが成長しても問題なく使用できます。
素晴らしいサポートと開発
Lightdashはオープンソースであり、サポートが非常に迅速で優れています。Trial中にバグを見つけても、チームはすぐに対応して修正してくれました。Updatesとリリースもスムーズで、機能が壊れる心配もなくなりました。
delyにおけるLightdashの導入
以前のブログでハリーさんが説明したように、私たちのdata mesh-hybridな中央集権化の取り組みには変更はありません。引き続きLookerを使って、決まったメトリクスやKPIを表示し、意思決定者が常に信頼できる分析を得られるようにします。しかし、Lightdashを導入することで、特にad-hoc分析において、ビジネス側が自分たちのデータをよりコントロールできるようになり、非エンジニアでも意思決定ができるようにします。
私たちは、以下のフローを実現するために、データオーナー（エンジニアも非エンジニアも）が自分でad-hocクエリを作成できるようにしています。これには、dbtのwrite-back機能とGithub Actionsを使っています：
グラフはわかりやすいと思いますが、特に興味深い点について説明します。
dbtのwrite-back
ユーザーが自分でアドホッククエリを書いたら、それをGithubにプッシュする必要があります。これにより、変更を追跡して、将来の改善に役立てることができます。
ユーザーがアドホッククエリのタイトルを追加すると、Lightdashは自動的にプルリクエストを作成します。その後、他のチームメンバーやデータチームがクエリをレビューします。これにより、間違ったテーブルを接続したり、コストのかかるクエリを作成したりする問題を防ぐことができます。
自動フォーマットとAIレビュアー
Lightdashでクエリを作成する際、現在のクエリ形式（この場合はSnowflake）で作成されるため、dbtのjinjaやmacroを使用した書き方には準拠しません。さらに、そのままクエリを提出すると、dbtモデルのリネージュを追跡できず、信頼できないシャドウad-hocモデルが作成される可能性があります。これを解決するために、AIを使ってクエリをSnowflake形式からdbt形式に自動的に変換します。
このように：
自動的にこの形式に変換されます：
また、AIレビュアーを追加しました。このレビュアーは、クエリの基本的なレビューを行います。これにより、データオーナーや開発者がdbtのモデリング基準に従っているか確認できます。現在、私たちは大規模言語モデル（LLM）を使って、モデルの構造、ドキュメント、テスト、パフォーマンスをレビューしています。
次のChallenges
私たちは、データライフサイクルを超高速で処理できるデータインフラを構築したいと考えています。Lightdashはアドホッククエリを迅速に作成する手助けをしてくれますが、さらにハリーさんの以前のポイントに沿って、以下のようなことを探求していきたいと考えています：
より多くの非エンジニアがAIを使って分析できるように、データ構造とメタデータをより強化すること。例えば、text2sqlやLightdash独自のソリューション（Slackを使ったAI分析）を活用することです。
データ品質とインシデントを自動で監視し、データチームだけでなく、全員がアドホッククエリで処理されたデータの問題を素早く追跡し、特定できるようにすること。
メトリクスやKPIをBIツールに依存しないようにし、セマンティックレイヤーを実装すること。
結論
delyでのデータ分析の改善を続ける中で、RedashからLightdashに切り替えることは、私たちのツールやワークフローを成長するニーズに合わせるための重要なStepです。すべてのデータを中央集権化にて、PDCA（Plan-Do-Check-Action）サイクルをスムーズ、迅速、かつ信頼性高く回すことを目指し、より速く良い意思決定をできるようにします。
Redashでの問題、例えば更新の遅さ、信頼性のないクエリ結果、システムの不安定さは、私たちに強力なsolutionsが必要だと示しました。Lightdashを導入することで、これらの問題を解決し、エンジニアだけでなくビジネスユーザーにもアドホック分析をもっと簡単に行えるようになりました。
今後は、データ処理をさらに速くし、メタデータを改善し、プロセスを自動化するための強力なデータインフラを構築することに集中します。また、BIツールに依存しないメトリクスやKPIを作成し、AIを使った分析をチームに導入できる新しいツールを探し続けています。
結論として、Lightdashの導入は単なるツールの変更ではなく、delyにおけるよりアジャイルでセキュア、そして自立したデータ文化を構築するための大きな一歩です。今後の新しい機会と挑戦を楽しみにしながら、データ分析のプロセスをさらに改善していきます。
一緒に働く仲間を探しています
Alright, that's sums it up!
私のブログを楽しんでいただけると嬉しいです！もちろん、excitingなデータエンジニアリングの最新情報があれば、また別のブログを書きますので、楽しみにしてください!
というわけで、データエンジニア・アナリティクスエンジニアの皆様、ご興味あれば是非カジュアルにお話させてください！以下でも募集しております！
Discussion