[レポート] データウェアハウスを製品として捉える〜設計から実現までの一貫した流れ #dbtCoalesce #Coalesce23

大阪オフィスの玉井です。

米国時間2023年10月16日〜19日、イベント『Coalesce 2023』が開催されました。主催はdbt labs社です。

本記事は、その中で発表されたData warehouse as a product: Design to delivery（データウェアハウスを製品として捉える：設計から実現までの一貫した流れ）というセッションについて、レポートをお届け致します。

セッション概要

登壇者

• Lance Witheridge, Data Modernisation Lead, Trade Me

超概要

社内のデータ分析基盤をクラウド化しようとしたが、うまくいかず、抜本的な再設計を行った話です。その際、DWH（のデータ）を製品・プロダクトとして捉えるようにした、というのがこの講演のキーになっています。

セッションレポート

前段

今回の講演は、弊社がデータスタックのモダナイゼーション…つまり、主にオンプレミスのSQL Server環境から、Snowflakeへの移行について、その過程で単なるリフトアンドシフトのクラウド移行から、データ分析基盤の全面的な再設計・再構築、つまり完全なモダナイゼーションへと変化していった経緯をお話しするものです。

このプロジェクトが変化していった理由は、単なる技術的な取り組みから、ユーザーを意識したプロダクト開発の視点を取り入れたことにあります。つまり、ユーザーが抱える課題を理解し、それに対してどのように最善のサービスを提供できるかを考えるようになったのです。そして、その過程でdbtが大きな役割を果たしてきたことをご紹介します。

自己紹介

私の名前はLanceです。Trade Me社のデータモダナイゼーションリードを務めています。

データベースの分野で20年以上の経験があり、ITキャリアの始まりはY2Kバグ対応の仕事からでした。その後、いくつかの銀行でインサイトアナリストとして働いた後、約8年前にTrade Meのインサイトアナリストとして入社しました。その後、Trade Meが所有するデータプロダクト会社の立ち上げに携わったり、プロダクトマネージャーやプロジェクトマネージャーを経験したりしてきました。現在は、このデータ移行プロジェクトのリードを務めています。

Trade Me社のデータ分析基盤

Trade Meのデータ環境について少し説明します。

Trade Meは、ニュージーランドで最も大きく人気のあるウェブサイトの1つです。中古品の売買プラットフォームとして始まり、その後不動産ポータル、自動車ポータル、求人ポータルなど、様々なサービスを展開するようになりました。

つまり、当初中古品の売買を想定して設計されたデータベースの上に、これらの新しいサービスが積み重ねられてきたのです。そのため、24年の歴史を持つ数十億ドルの企業にも関わらず、依然として古いコードが残っているのが現状です。本番環境のデータベースはSQL Serverで、最近クラウド上に移行されましたが、依然としてSQL Serverを使用しています。

一日あたり150万件の新規リスティング、2000万件のリスティング閲覧、2600万件の検索結果、250万件のGAセッション、7500万件のGAイベントが発生するなど、非常に大規模なデータ量を扱っています。さらに、M&Aを通じて複数の事業を展開しているため、それらのデータを統合することも課題となっています。

昔のTrade Meのデータ環境を振り返ると、中心にあったのはオンプレミスのSQL Serverデータベース「TM DATA」でした。毎晩、本番データベースのスナップショットを取り、ETLを使ってデータクリーニングを行い、そこに蓄積していきました。その他にも、各種SaaSプラットフォームやAmazon Athenaデータレイク、Googleアナリティクスなどのデータが出たり入ったりしていました。レポーティングにはPower BIを使い、オーケストレーションにはSSISを主に使っていました。そして、長年の間に蓄積された独自の手作りのコードもありました。

数年前、Trade Meがクラウド移行を行ったことで、オンプレミスのTM DATAを閉鎖する必要が生じ、Snowflakeへの移行を決めました。約18ヶ月をかけてこの移行プロジェクトを完了し、新しいデータ環境が完成しました。

単にクラウド化するだけではダメだった

新しいデータ環境は、まるでスパゲッティの上にSnowflakeの形をした巨大なミートボールが乗っているような感じです。その中核となるのが、切り替えようとしているオンプレミスのSQL Serverなのです。つまり、新しい家を建てるときに、古い足場を取り入れてしまっているような状況です。

すべてのシステムが稼働し続けており、複雑さが増していっています。自作のコードを見直すこともできなくなってきており、「そんなに悪くないかもしれない」と思うようになっています。

さらに問題なのが、PoCとして始まったシステムが、ビジネス上不可欠なものになってしまっていることです。レポートなどに依存されており、簡単に切り替えられない状況です。

そこで、全面的な見直しが必要だと判断しました。「ブルースカイアプローチ」と「グリーンフィールド思考」を取り入れて、抜本的な再設計に取り組むことにしたのです。

真のデータ分析基盤刷新

プロジェクトのアプローチを変えることになったきっかけは、次のような問いかけでした。

「もしTrade Meがデータウェアハウスを最初から持っていたとしたら、今移行しようとしているものとは全く違うものになっていただろうか？」

この問いに対して、全員が「そうだ、全く違うものになっていただろう」と答えました。

これを受けて、私たちは「私たちが作ろうとしているものは一体何なのか？」を考え直すことにしました。当初は、レポーティングの継続性を重視していたため、既存のものを単に移行しようとしていました。しかし、レポーティングはプロダクトではなく、データプラットフォームがプロダクトなのだと理解しました。

つまり、私たちのお客様は、レポートを作成するインサイトアナリストたちであり、彼らのニーズに合ったプロダクトを構築する必要があるのです。そのためには、何を解決すべき問題なのか、どのようなツールやスキルが必要なのか、そしてできるだけ早くお客様に価値を提供できるようにするべきだと考えました。

そして、残念ながら、これまでの18ヶ月の取り組みを白紙に戻し、最初から作り直す必要があると判断したのです。

プロダクト思考に立ち返ると、私たちが掲げたミッションステートメントは「データアナリストが使いたくなるデータウェアハウスを構築すること」でした。

多くの企業では、使いづらく、ぎこちないデータウェアハウスを我慢して使っているのが現状です。しかし、私たちは、アナリストたちが自慢したくなるようなクールで使いやすいデータウェアハウスを目指したいと考えています。

ここで2つの注釈があります。

1つ目は、「データウェアハウス」という言葉について。私は、倉庫のような「保管場所」というイメージではなく、図書館のようなイメージ、つまり、必要な情報を簡単に見つけられ、探索して新しいものを発見できる場所として捉えたいと思います。

2つ目は、「アナリスト」という言葉についてです。アナリストを主要なユーザーと位置づけていますが、データサイエンティスト、商品分析担当、マーケティング分析担当など、様々な分析ユーザーを想定しています。

クラウド化直後の課題の洗い出しと改善策

私たちが解決しようとした問題の1つは、データウェアハウスと本番データベースの強い結合関係でした。

毎晩のスナップショット取得によって、本番データベースをそのまま複製しているに等しい状態でした。このため、アプリケーションをマイクロサービス化しようとしても、データウェアハウスとの結合が邪魔になっていました。つまり、データは企業を前に進めるはずなのに、かえって足を引っ張っていたのです。

また、同じ概念を表すカラムが15種類も存在するなど、セマンティックな問題も深刻でした。これらの知識は、長年の経験を持つ社内の「賢者」にしか共有されておらず、スケーラブルでも持続可能でもありませんでした。

データの信頼性の問題もありました。レポートごとに異なるデータソースが使われており、どれが正しいのかわからなくなっていました。

自作のコードを使ってSalesforceやその他のデータソースからデータを取得する際、必要最小限のデータしか取得しないようになっていました。そのため、アナリストが新しいリクエストをする度に、データエンジニアリングのパイプラインを通す必要があり、大変時間がかかっていました。アナリストたちは自力でデータを見つける方法を見つけ出し、スプレッドシートやPowerBIなどに取り込むようになりました。これにより、さらにインフラと認知負荷が増えていきました。

また、膨大な量のストアドプロシージャも問題となっていました。これらは理解が困難で、メンテナンスが難しい状態でした。問題が発生したときは、データ部門に怒鳴り込まれるなど、事後対応に追われるような「インシデント駆動型開発」になっていました。

さらに、プライバシーの懸念もありました。顧客の個人情報がデータウェアハウスに残っていたため、適切に管理する必要がありました。

これらの課題を解決するには、現在のアーキテクチャでは難しいと判断し、CTOに新しい環境を構築する許可を求めることにしました。

CTOに新しい環境を構築する許可を求めたところ、承認されました。これで問題を解決できるかと思いきや、新たな課題が生まれました。

問題点を指摘するのは簡単ですが、実際に解決策を立てるのは難しいです。私の助言は、まず自分なりの計画を立てることです。しかし、その計画は絶対に完璧なものではありません。そこで、より優秀な人々にその計画を見せて、徹底的に批判してもらうことが重要です。マイク・タイソンの言葉のように、「誰もが計画を持っているが、相手に殴られたら計画は崩れる」のです。自分の計画を、「顔を殴られる」ような経験を通して、より良いものに磨き上げていく必要があります。

最初に自分で考えた計画を、ホワイトボードに書きました。しかし、10人の人間を部屋に閉じ込めて一緒に計画を立てるのは、非常に生産的ではありません。代わりに、自分の計画を10人の前で提示し、徹底的に批判してもらうのが良い方法です。そうすれば、自分では思いつかなかったはるかに優れた計画が生み出されるはずです。

最終的に立てた計画は、当初の案とはほとんど変わっていますが、この過程を経ることで、より良いものに仕上がったのだと思います。

私たちが立てた主な原則は以下の通りです。

まず、できる限り既製品を活用し、自作は最小限に抑えることです。同じ機能を実現する方法が複数ある場合は、一貫性を保つため、1つの方法に統一します。これにより、ユーザーの認知負荷を軽減できます。

また、データに関する役割と責任を明確に定義しました。データ関連の仕事を1人で全て行うのではなく、必要なスキルセットを組織全体で確保することが重要です。

データ保管コストは問題ではなくなりました。必要なデータは全て生のままストアし、後から必要なものを選別するようにしました。

さらに、本番システムの設計に縛られることなく、アナリストのニーズに合わせてデータを構造化することにしました。用語の統一も徹底し、アーカイブ知識に頼らずに、すべてをドキュメント化することにしました。

そして、ビジネスロジックは1か所に集約し、そこから必要なバージョンを作り出すようにしました。同じ処理を繰り返さないよう、可能な限り早い段階で実装することにしました。

採用したデータスタック（製品・サービス）

私たちが選定したテクノロジースタックはスライドの通りです。

まず、自社で開発したCDCツールを使って、本番データベースからデータを取り込みます。一方、サードパーティのデータソースについては、Stitchを使ってJSON形式でS3やGCSに取り込みます。その後、Snowflakeにデータを取り込み、Terraformを使ってIACとアクセス制御を管理します。

データの加工処理は、dbtで行います。必要に応じて、非同期処理はPrefectを使って実装します。

外部システムへのデータ連携には、Hightouchを活用します。例えば、SegmentやSalesforceなどへのデータ送信に使っています。

最後に、データ可視化にはPower BIを使っています。

最初の大変複雑だったデータ環境から、少しは見通しの良いものになったといえます。しかし、まだスパゲッティのような複雑さは残っています。

今回の取り組みの結果、Snowflakeがデータの中心的な存在になりました。データレイクやBigQueryなどの別のデータソースには頼らず、全てのデータがSnowflakeに集約されるようになりました。これにより、組織全体で共有できる1つの信頼できるデータリポジトリが実現しました。

体制変更

この変革を実現するため、私たちは組織の体制を少し変更しました。

以前は、BIデベロッパーやデータエンジニアといった役割が存在していましたが、時代の変化とともにこれらの役割は陳腐化していきました。一方で、インサイトアナリストという役割は残っていましたが、データモデリングの専門家が不足していました。

そこで、アナリティクスエンジニアという新しい役割を設けることにしました。この役割は、ビジネスサイドのインサイトアナリストと、テクニカルなデータエンジニアの間を取り持つものです。

ただし、役割と個人の能力は必ずしも一致するわけではありません。インサイトアナリストがアナリティクスエンジニアの仕事を行うこともあれば、データエンジニアがアナリティクスエンジニアの仕事を行うこともあります。重要なのは、その時はアナリティクスエンジニアとしての振る舞いをし、ルールや慣例に従うことです。

現在のデータ分析基盤のデータの流れ

まず、すべてのデータがRawデータとして着地します。そこから2つのメインの経路を経て、最終的な形になります。

1つ目の経路は、ソースシステムの要件に合わせて構造化・命名されたデータです。例えば、NetSuiteではCustomerがAccountと呼ばれているなど、ソースシステムの表現に合わせています。

2つ目の経路は、エンドユーザーであるインサイトアナリストの要件に合わせて構造化・命名されたデータです。これにより、分析しやすい形になっています。

また、データは、ソースシステムごとに整理されるとともに、ビジネスエリア別にも整理されています。

最終的に、データマートでは、これらのSSOTから、必要なデータを組み合わせて、分析用のデータセットが作られます。インサイトアナリストは、このデータマートから、必要なデータを抽出・統合して、分析に活用することができます。

この新しいデータアーキテクチャを図で表すと、まるでせせらぎのような形になります。

ここで、最も重要なのは、複雑なビジネスロジックがすべて左側の部分に集約されていることです。インサイトアナリストは、この部分の詳細を知る必要がありません。

中央の「リスティング」テーブルが、SSOTとなっています。ここには、リスティングに関する全ての情報が集約されています。

その後、右側では、様々な目的に応じた「SSOTの複数のバージョン」が作られます。例えば、データサイエンス用、バーティカル市場別、集計テーブルなどです。

これらのバージョンは、全て左側のSSOTから派生しています。したがって、ビジネスロジックを変更する必要がある場合は、左側の部分で1回行えば、全てのバージョンに反映されます。

別の見方をすると、リスティングテーブルの右側にあるものは、すべて正規のものだと考えられます。つまり、ここにあるデータは信頼できるものです。一方、リスティングテーブルの左側にあるものは、自由に変更できるものです。もし、ここで自分で何かをやりたいと思っても、それは自己責任になります。正規のデータパスから外れてしまうため、私たちはそこまでサポートできません。

dbtを導入した理由

dbtを採用した主な理由は、SQLベースであるということです。インサイトアナリストにデータモデリングを担ってもらう際に、彼らはSQLを使いたがっていたため、dbtが適していると判断しました。

また、dbtでは全てのロジックが1か所に集約されているため、特にデータマートでデータを組み合わせる際に便利です。さらに、CI/CDパイプラインも整備されており、本番環境と同じ環境でテストを行えるため、リリースリスクを大幅に低減できます。

dbtはモジュール性も高く、以前のようにロジックが散在することがありません。一度書けば、どこでも再利用できます。加えて、自動的にドキュメンテーションが生成されるため、大きな変革点となりました。

ドキュメンテーションについては、みんなが嫌がるものですが、dbtはそれを少し楽にしてくれます。ただ、それでも面倒な部分はあります。特に、40カラムもある大きなテーブルをドキュメント化するのは大変です。

そこで私たちが考えたのが、auto_model_ymlというマクロです。これは、データベースとスキーマを指定すると、Snowflakeのインフォメーションスキーマを使ってスキーマ定義をYAMLファイルに自動生成してくれるものです。カラム名やテーブル名の命名規則を整備していれば、ユニークキーや外部キーなども自動で判別し、テストも生成してくれます。あとは、その自動生成されたYAMLファイルにコメントを追加するだけで、ドキュメンテーションが完成します。これにより、手作業でドキュメンテーションを作成する必要がなくなり、大変な負担が軽減されました。

プライバシー保護については、Snowflake Enterprise Editionにアップグレードすることで、自動ハッシュ化機能を使えるようにしました。

具体的には、まず、個人を特定できる情報（PII）のあるデータソースを特定し、それらにタグ付けをしています。次に、ステージングテーブルを生成するコードジェネレーターが、そのタグを読み取り、自動的にハッシュ化を行います。その後、制限付きのスキーマ内にルックアップテーブルを作成します。ここには、元の値とハッシュ値の対応関係が保存されます。インサイトアナリストは、この制限付きのスキーマにアクセスできますが、ロールを切り替える必要があります。そして、その使用状況はすべて記録されるため、不正な利用があれば指摘されることになります。

現在、私たちのデータプラットフォームには、さまざまなソースから取り込んだ多数のテーブルが存在しています。具体的には、NetSuite、Salesforce、その他のSaaSプロダクトから、単純にデータを取り込んでいます。

この段階では、まだステージング処理や、データウェアハウスやデータマートへの移行が完了していません。しかし、とりあえずデータを取り込んでおくことで、後々必要になった際に、素早くモデリングできるようになっています。

今後、取り込んだデータの中で、実際に活用されないものも出てくるかもしれません。でも、必要になった時に取り出せるようにしておくことが重要だと考えています。

dbtの最大の利点は、データプラットフォームの変更が劇的に容易になったことです。以前は、手作業で大量のストアドプロシージャやDMLを書かなければならなかったところ、dbtでは1行のコマンドで全体を再構築できるようになりました。

例えば、Snowflakeのコストが高くなっていることに気づいた際、メタデータのカラムを変更するだけで、コストを半減できました。以前なら、300近くのストアドプロシージャやステージングプロセスを手作業で変更する必要があったところ、dbtでは1つのマクロ変更で済ませられたのです。

このようにdbtを使うことで、素早く試行錯誤を繰り返せるようになりました。そして、分析ユーザーにも早期に成果を提供でき、フィードバックを得て迅速に改善できるようになりました。以前のような大規模な一括移行ではなく、段階的な改善が可能になったのです。

「先に作って、後で最適化する」というアプローチを取っている私たちですが、実際にその最適化の取り組みも行っています。

その一環として、独自の「ソースマクロ」を作成しました。これにより、ソーステーブルから最新のデルタデータのみを取得できるようになりました。

また、カスタマイズした増分ロード用の機能も開発しました。SCD2形式での保持や、増分マージ時の条件設定など、私たちの要件に合わせて最適化しています。

ただし、増分マージの際の条件設定には課題もあります。アプリケーションの特性上、5年前のデータが突然再登場することがあるため、固定の時間条件では対応できません。そこで、merge_hintsと呼ぶ独自の機能を作りました。これにより、マージ元の最古の日付から比較するようにできるため、パフォーマンスが大幅に改善されました。

この取り組みの結果、Snowflakeのコストも大幅に削減できました。

今後やること

ユーザーからの良いフィードバックを受け、私たちは成果を実感しています。特に、マーケティングチームは、データが1時間単位で更新されるようになったことを高く評価しています。

ユーザーが積極的に使ってくれているおかげで、さらに改善の余地が見えてきました。理解できないシステムも、もはや必要がないと判断できるようになり、それらを安心して停止することができます。これにより、時間とコストの節減、認知負荷の軽減につながっています。

次の課題は、モニタリングの改善やマスターデータ管理の強化です。また、Trade Meの新しいイベント駆動型アーキテクチャにも対応していく予定です。これにより、本番データベースからの完全な切り離しが実現できると期待しています。

さらに、この取り組みで得られた知見は、他のプロジェクトにも活かせることが分かりました。例えば、請求システムの再構築プロジェクトでは、ほとんどそのまま流用できたそうです。

以上が、私の発表の内容となります。ありがとうございました。

所感など

令和におけるデータ分析基盤リニューアル案件の教科書みたいな内容でした。

データ分析基盤に限りませんが、オンプレミス上のシステムを、そのままクラウドに上げても、根本的な解決にはなりませんね。登壇者の方が言っていた「私たちが作ろうとしているものは一体何なのか？」というプロジェクト開始時の問いかけがとても大事なんだと改めて感じさせられました。

また、「なるべく既製品を使う」という考えも良いと思います。大規模なデータを処理する基盤をスクラッチで一から開発する時代は終わったと思います。一刻も早くユーザーがデータを分析できるようにするために、すでに完成されている製品を組み合わせる方法をとるべきです。

上記とは別観点の感想として、「データをプロダクトとして扱う」「データを分析する人を（プロダクトを使用する）ユーザーとして扱う」という考え方を取り入れているのも印象的でした。海外の事例ではよく見かけるようになった考え方ですが、日本ではまだまだ普及していないので、気になっている方はどんどん取り入れていってほしいと思います。