こんにちは。
dely株式会社でデータエンジニアをしておりますharry(@gappy50)です。
最近はブログを書いたりもせずに、社内の課題解決のため地道に仕事をしていました。
そろそろ、色々と自分のやっていることや方向性について話せそうな状態になったので、筆を取ってみました。
結論
少し前置きが長くなりそうなので、結論からお話すると以下を実現するためのdelyのデータ基盤を連邦制ガバナンスを採用したデータ基盤として刷新しはじめています。
刷新することで以下を実現することを期待しています。
- これまで存在していたプロダクトごとのデータ基盤をそれぞれ論理的に統合し全社データ基盤として機能させる
- 全社データ基盤を通して統一されたガバナンスやセキュリティを担保しやすくする
- データサイロ化を解決し、横断的な分析環境の提供やメタデータ管理がしやすい状態にしていく
- 全社データ基盤におけるデータモデルの構築をData Engineer/Analytics Engineer以外もできるようする
- これまでRedashで行っていたアドホックな仮説検証の速度を失わずに、データライフサイクルが正しく回るようにする
- 一貫したDataOpsの提供でデータライフサイクルを高速に回せる文化を醸成していきます
- アドホックな分析と定型分析の接着をDataOpsとして提供することで、データの品質や意思決定の重要度を意識できるようにする
刷新の技術的なポイントとしては以下のポイントがあります。
- 現状はSnowflakeをベースにしたデータ基盤にする
- 中長期に関してどうあるべきかは後述
- データライフサイクルを高速で回せるようにする
- 現状存在するプロダクトごとのデータ基盤は「プロダクトデータエンジニアリング基盤」として特化させる
- 裏テーマは「壊しやすく、捨てやすい、だけどサスティナブルなデータ基盤」
- 別途データ分析基盤のアカウントをSnowflakeにて作成し、「全社データ分析基盤」として全社の分析ワークロードやセキュリティなどのデータガバナンスを中央集権制にする
- Snowflakeのデータシェアリングを活用し、各プロダクトのデータを横断的に分析できるようにする
- いわゆるDataMartのためのレイヤーとして機能させ、定型分析だけなくアドホックな分析に対してもガバナンスを担保しやすい状態にする
- また、アドホックな分析に対してもガバナンスを効かせながらアジリティを確保するためにdbtを中心とした分析基盤の運用フローを構築する
- 現状存在するプロダクトごとのデータ基盤は「プロダクトデータエンジニアリング基盤」として特化させる
「プロダクトデータエンジニアリング基盤」はデータモデリングでいうところのStagingやDWHレイヤー相当の役割を期待し、「全社データ分析基盤」はDataMartレイヤーの役割を期待しています。それにより、それぞれをSnowflakeのアカウント単位で制御することで、データパイプラインと分析要件によるセキュリティやガバナンスをよりきめ細やかに設定できるようにしています。
一般的なSnowflakeを中心としたデータ基盤では、1つのアカウントにてRBACを設定しながら中央集権制のデータ基盤を構築することが多いと思いますが、アカウント単位で分離をすることで過去の資産をそのままにデータメッシュ的なアプローチも可能になりながらも、中央集権制のメリットであるガバナンスのメリットを享受できるため、現在の我々にとっては最適なアーキテクチャだと考えています。
それもSnowflakeのデータシェアリングやInternal MarketPlaceの恩恵によるもので、アカウントレベルでも柔軟な管理が行えることで成立するアーキテクチャかなとは思います。また、今後数年間でIcebergを代表するオープンテーブルフォーマットが台頭した際にも、適切な切り分け方ができるという意味でも中長期視点でもとてもメリットのある刷新かなと考えています。
データ基盤の座組についての詳細は後ほど詳説しますが、まず今回の刷新にあたって抱えていた課題についてまず説明をします。
めちゃくちゃ長いので気になる方はどうぞ見てってください。
データの課題は技術的課題から適応課題へ
DATA ENGINEER NIGHT #1 #DataEngineerNight にスピーカーとして登壇させていただいた際にもお話したのですが、ここ数年でデータ基盤に関するベストプラクティスは出尽くした感が否めなく、
- Snowflakeとdbtでデータパイプライン構築
- BQとLookerで分析基盤を刷新
みたいな私もここ数年で話していたようなトピックはだいぶ食傷気味なトピックになりつつあるなと思っています。
勿論、近年話題のIcebergのトピックだったりとまだまだ基盤のための技術として語れるものは多いものの、むしろ最低限データからインサイトを得られる状態になっている企業が多くなっている状態では、多少優先度は低く、むしろ今ある基盤をどうやって活用していくかみたいな組織への適応が重要視される傾向があると個人的には分析しています。
データマネジメント、品質、データ契約、ガバナンスなどのトピックがここ1〜2年で多くなってきたのも、データ基盤を手に入れたものの、そこから実際どういう価値が出せるの？に四苦八苦しているデータエンジニアやアナリティクスエンジニアの反動・振り子だと思っています。
そしてそれらの課題は、組織や企業の体制や、文化、課題などに対してデータからのインサイトをどのようにアラインさせるかのエンジニアリングのため「◯◯というツールを入れて解決しました！」ようなベストプラクティスとして語られることはなく、泥臭く向き合い続けることの重要性を示唆してると考えています。
個人的にはこういった組織の課題に対してどうなんだみたいな話は愚直だし向き合い続けるっていう話なので技術的課題をどう解決したかみたいな話と比較すると全然おもしろくないですし、ベストプラクティスでないため早速真似してよくなるような即効性のある話題ではないと思います。
だからベストプラクティスではない、どうやって適応課題に向き合っているのかを伝えることのほうが今後より重要になると考えています。
我々の適応課題とは？
delyでは主要なプロダクトとして、クラシルおよびクラシルリワードを展開していて、それらのプロダクトごとにデータ基盤が存在しています。
しかし、複数プロダクトが独立したデータ基盤を持つことで、運用コストやデータ連携の面で課題が顕在化してきました。
そこで本章では、それらの課題をどのように整理し、今後どのように解決を図っていこうとしているのかをご紹介します。
求められるデータ基盤の性質
我々のプロダクトの開発方針として「仮説検証を早く回して、スピード感のある開発組織に」という方針を掲げており、データからいち早くインサイトを見つけて爆速で仮説検証をしていくスタイルが浸透しています。
仮説検証を早く回して、スピード感のある開発組織にしていくぜ
そのため、Snowflakeをデータ基盤としていたクラシルとは別で、数年前にリリースをしたクラシルリワードに関してはGA4(Firebase)をBigQueryにExportしてそれらをデータ基盤としてそれぞれ独立したデータ基盤として運用・管理をしていました。
それぞれのプロダクトでデータ基盤を構築していた
クラシルリワードがリリースされてからPMF(プロダクトマーケットフィット)するまでに、データエンジニアリングリソースを割くことは費用対効果の面でも説明がしづらいのと同時に、データエンジニアも自分の仕事を増やしたいがためにオーバーエンジニアリングしてしまう傾向があると思っています。
それゆえGA4のデータから最速で意思決定をしていくことに集中して事業成長に向き合うことは何ら違和感もなく、データエンジニアに依存しないデータ基盤を利用していくことは正しい意思決定だったかなと思います。
データから意思決定をする文化
もう一方でdelyはクラシルをリリースしてから、データによる意思決定を重要視しており、エンジニア以外のメンバーもSQLを書いて分析をするスキルを持ち合わせていることも組織の強みでもあります。
そしてデータから仮説検証を早く回す観点から組織の歴史上、Redashを使いこなす文化が醸成されており、分析ができるメンバー以外のBizやマーケのメンバーもRedashの数値を見ることは業務遂行のためには必須となっています。
RedashでSQLクエリをアドホックに書き続けることは、先のプロダクトの開発方針を達成するために最も必要なものとなっています。
データ・分析の品質とアジリティのトレードオフ
Redashはとてもいいツールである反面、Redash以前のデータの上流部分で完璧な品質やメタデータ管理をする構造や運用がなされていないと、一瞬にしてデータカオスや間違った意思決定につながることが多くなるデメリットも存在します。
散々Redashのデメリットとして方方で語られているとは思いますが、以下の課題に容易にぶつかって、そこを乗り越えるだけでも相当な涙を流さないといけなくなります。
- Redashに指標定義が実装されるためAさんが書いたSQLクエリの結果とBさんが書いたSQLクエリの結果が一致しない
- 同じような分析をするにもRedashのフォークをしてロジックが分散してしまうため、何が正しいデータなのかを追うことが困難になる
- 書かれているSQLクエリの品質担保をし続けることができないため、意思決定に使えるデータなのかの保証を誰もできない
我々もLookerをBIツールとして、常に正しいデータはLookerにあるという認識は一般化できているのですが、組織の求めるアジリティに対してデータエンジニア・アナリティクスエンジニアのリソースが不足し、データの整備が追いつかずにRedashのアドホックを書き続けることでしか我々の目指す「仮説検証を早く回して、スピード感のある」プロダクトの開発ができないというジレンマに囚われています。
そして、SQLクエリを書ける人も一定多くいますが、ドメイン知識とデータの構造を正しく理解をしながらアドホックにクエリを書き続けることができることは非生産的であります。また、非エンジニアがそれらの非生産的な活動をこなしながらプロダクトをグロースさせるのは限られた人にしかできないスペシャリティなので、そこのスケールというところも事業や機能が拡大した際のアジリティに対してのトレードオフになっています。
事業戦略を叶えるためのデータ戦略の不在
また、クラシルリワードの急速なグロースに対してデータサイロを許容していたところが事業戦略のボトルネックになることも多くなってきています。
今後、クラシルとクラシルリワードの連携は重要になってくるのですが、現状はデータがサイロ化により横断的な分析がしずらくなっています。現在はウルトラCによってそれを解決することで一定対応はできるようになっていますが、本来はデータのサイロ化はなければよいに越したことはありません。
あるべき論でいえば、事業戦略に対して正しくデータ戦略を立案し遂行していくことが正解であり、データ基盤を構築する際にサイロ化をさせない、サイロ化の解決方法も正しく保持していることもそれらのデータ戦略の不在による負債がここにきて出てきているとも言えます。
アジリティと品質を担保するためのデータ基盤
ここまで述べたように、我々の組織においては「仮説検証を早く回すためのデータ分析」と「データ活用に対しての品質やガバナンスの向上」というトレードオフをトレードオンさせる必要があります。
そのために、まず我々は「データライフサイクルを爆速で回せるデータ基盤」を構築することが重要だと位置づけました。
具体的に想定している運用アプローチとしては以下のようなアプローチを考えています。
- 現在Redashで書いているクエリをdbtのadhocテーブルとして前述の「データ分析基盤」でデータモデルとして作成してもらう
- エンジニアだけでなく非エンジニアにもdbtでデータモデルを作成してメタデータも含めて資産化をする
- ただし、限定的な用途のためのものとし3ヶ月に1回などのルールに基づき定期的にテーブルやモデル削除を実施する
- 事業上重要で定常的に追いたいものはデータエンジニアと協力をしてDWHにデータモデルを構築する
- Adhocのモデルを昇格させる運用フローを踏めるため、アドホックなクエリで意思決定をし続けることを防止できる
- これまでRedashとLookerで別々に分離していた運用の流れを統合し、データ構造や指標定義を正しい形でdbt上でシームレスに組み込めるようにする
- 合わせてこのタイミングで品質を要件に入れる
ただし、それらを実現するにもデータのサイロ化の解消は不可欠であることから、クラシルリワードのデータ基盤の移行を今年は最優先課題として取り組んでいました。
なぜこのアーキテクチャなのか？
上記を実現するだけであれば、中央集権型のデータ基盤にこのタイミングで移行をするのもありだとは思います。もしくは、データメッシュアーキテクチャを採用し、連邦制のガバナンス以外にもデータ契約やチームの組織変更などもあわせて行い、あるべき姿にデータ基盤を進化させることもできるとは思います。
ただし、現在および今後の弊社の状況と今後のデータ関連の潮流を見据えると連邦制のガバナンスを採用しながら、中央集権型データ基盤とデータメッシュのハイブリッドな形を進化をさせた上で連邦制のガバナンスを採用したデータ基盤に刷新していくことが最良の選択だと考えています。
- アジリティを優先するdelyにおいては、データメッシュアーキテクチャへのリアーキはQuick Winを目指す要件としてtoo muchすぎる
- まずは、アジリティを落とさないでどうやってデータライフサイクルを回すかための組織への適応が最優先だから
- delyでは今後もマルチプロダクトの展開を想定していること
- クラシルリワードのローンチ当時と同じで、プロダクトごとにデータ基盤を持つことでデータエンジニア不在の状況からスタートしたときにスケーラビリティを確保したい
- 中央集権型に統一をしてしまうと、常にデータエンジニアが対応をする必要が出てきてしまうことや、中長期でのベンダーロックインにも繋がりかねない
- PMF(プロダクトマーケットフィット)したら「全社データ分析基盤」への統合を考えることができる
- 現状はクラシル比較などもSnowflakeをDWHとしており、これらをスタンダードな手法として確立することで新規プロダクトに対するデータ基盤構築の再現性を高めていける
- クラシルリワードのローンチ当時と同じで、プロダクトごとにデータ基盤を持つことでデータエンジニア不在の状況からスタートしたときにスケーラビリティを確保したい
- Icebergなどのオープンテーブルフォーマットを見据えた対応
- もしかすると「プロダクトデータエンジニアリング基盤」はGA4+BigQueryとして「全社データ基盤」へデータを統合することもできるし、逆に「全社データ基盤」をMotherDuckなどのツールに移行をすることもできるかもしれない
- その時の組織の課題や要件に沿った技術・ツール選定をプロダクト・事業ごとに容易にできる状況を作ることで捨てやすく、変更しやすく、サスティナブルなデータ基盤を目指せる
- ベンダーロックインやDatalakeを構築しているクラウドストレージによるサイロ化を防ぎやすくなる
来年からこちらの基盤も本格的に稼働をするため、ようやくこれらの運用を小さく回せるスタートラインに立つことができました。
これから解決していきたい課題
これらのデータ基盤が稼働したらようやく、DataOpsも本格的に回せるようになります。
現時点では前述したAdhoc⇔定型分析によるアジリティと品質の担保以外にも、
- 事業側がデータに対してオーナーシップをもてるような仕組み
- データパイプラインの異常検知やメタデータの充足、データ契約、データスチュワードなどをどのように実装していくか
- データメッシュもそれらが組織的に対応が可能になったタイミングで検討していきたい
- 非エンジニアでもデータから意思決定ができるような仕組み
- ダッシュボードの構築や分析要件を正しく行えるような機会を創出
- 非エンジニアでもアドホック分析を可能にするための取り組み
- Redash撲滅委員会
など、すでに組織で課題となっているところへの解決を行っていく想定で引き続き地道なエンジニアリングをしていく所存です。
さいごに
いかがでしたか？
日々、目の前の課題に悩みに悩んで、いろんな書籍やブレストをした上で、現在我々の中で最良となるデータ利活用とは何かを考え、地道な対応を日々行っています。
ここらへんのお話は以下でもしていますので、よろしければこちらも是非に。
とはいえ、スタートアップ企業である我々ももれなく変化の激しい中での対応のため、うまくいかないこと、道半ばで失敗してしまう施策もあると思います。
そういった状況でもどれだけ正しいことをやり続けていけるかが勝負になるので、来年もGRITして行きたいなと思っています。
一緒に働く仲間を探しています
というわけで、データエンジニア・アナリティクスエンジニアの皆様、ご興味あれば是非カジュアルにお話させてください！
X(@gappy50)からでもよいですし、以下でも募集しております！
それでは良いお年を！
Discussion