大阪オフィスの玉井です。
米国時間2023年10月16日〜19日、イベント『Coalesce 2023』が開催されました。主催はdbt labs社です。
本記事は、その中で発表されたOperationalizing Ramp’s data with dbt and Materialize（Ramp社のデータ基盤運用：dbtとMaterializeの活用法）というセッションについて、レポートをお届け致します。
セッション概要
登壇者
- Nikhil Benesch, CTO, Materialize
- Ryan Delgado, Staff Software Engineer, Data Platform, Ramp
超概要
リアルタイムでデータを分析する要件に対して、従来のDWHだけではうまくいかなかったので、Materializeというサービスを導入して解決した、という話です。
セッションレポート
※最初はRyan氏が登壇
前段
今日は、RampがdbtのMaterializeを使ってどのように不正行為と戦っているかについて話します。また、Materializeの仕組みと、dbtとの統合方法についても深掘りしていきます。
まず、Rampについて説明します。Rampは、企業の支出に関する可視性、柔軟性、管理を提供するファイナンス自動化プラットフォームです。同時に、NetSuiteなどの会計システムとの統合を通じて、不必要な摩擦や手間を削減することで、企業の能力を高めています。
Rampには、Ramp Card、Ramp Bill Payなどの製品があり、最近では新しい仕入先管理ソリューションも導入しました。今回の発表で最も関連があり、私にも説明しやすい製品は、Ramp Cardという法人カード・経費管理ソリューションです。これは、アメリカン・エキスプレスの法人カードやコンカーなどと似ていますが、カードとソフトウェアを一体化させたことで、ファイナンスチームにより良い可視性と管理を提供しています。
Rampのデータプラットフォームチームは、私が率いています。私たちは、DevOpsとデータエンジニアリングの要素を併せ持つハイブリッドのチームだと考えてください。つまり、Rampがデータから価値を引き出せるようなインフラストラクチャーやツールを構築するとともに、そのプラットフォームの上にアプリケーションを構築し、関係する部署と協力して展開しているのです。
Rampには独自のPEDDポッド（プロダクト、エンジニアリング、デザイン、データのチーム）があり、これらのポッドは新しいビジネス目標を達成するために立ち上げられます。データエンジニア、アナリティクスエンジニア、データプラットフォームエンジニアなどが、エンジニアリングチームと協力して、顧客アプリケーションに組み込まれるデータ分析プロダクト、データサイエンスモデル、内部の分析ツールなどを構築しています。このようなアプローチにより、ビジネス目標の達成につながる優れた成果が得られています。その1つの目標が、不正検知プラットフォームの構築です。
Ramp社の当初の不正行為対策と課題
不正行為への対策は、Rampが過去1年間に注力してきた重要な課題です。最近では、Materializeへの移行も行いました。
法人カード事業を運営する上で、不正行為は常に脅威となります。様々な種類の不正行為がありますが、今回の発表では特に、アカウントハイジャックと取引詐欺（Transaction Fraud）に焦点を当てます。
アカウントハイジャックとは、攻撃者が以前に盗み取った認証情報を使ってアカウントにログインし、無秩序に支出を行うことです。例えば、ジュエリーやバッグ、さらには電動工具などを購入し、即座にそれらを転売して利益を得るといった具合です。
一方、取引詐欺は、不正な方法で入手したカード情報を使って支出を行うものです。アカウントハイジャックと共通しているのは、不正行為が素早く行われ、被害額に上限がないという点です。そのため、迅速な対応によって被害を最小限に抑えることが非常に重要なのです。
約1年前、Rampは自社の不正検知システムを構築しました。これは、バッチ分析インフラストラクチャーに基づいたものです。
不正検知の機能は、SQLで導出できる定量的なものです。そのため、dbtとも頻繁に連携しています。
具体的な仕組みは、まず、アプリケーションデータベース（Postgres）からデータを取り込み、Airflowを使って1時間ごとにETLを実行します。その際、リスクに関連するdbtモデルの一部を実行して、Snowflakeに保存します。次に、別のスケジュールされたNotebookが、これらのテーブルにクエリを投げて不正の有無を判定します。不正が検知された場合は、Slackアラートなどの通知を行います。ただし、この2つのシステムは必ずしも同時に動作するわけではないため、不正行為が発生してから検知されるまでに最大1時間ほどの遅れが生じてしまうのが課題となっています。
先ほど述べたように、不正行為の検知と通知の間には最大1時間の遅れがあり、これは理想的ではありません。データの新鮮さと迅速な対応が不正行為への対策において非常に重要です。しかし、この課題に取り組むことで、別の問題が生じてきました。
まず、Snowflakeの利用コストが年間120,000ドルにも上ってしまったのです。これは、私のファイナンスチームにとって大きな負担となっています。さらに、ビジネスの成長に伴い、処理すべきデータ量が増加しているため、dbtの実行時間が長くなってしまいました。当初は30分ごとの実行を目指していましたが、実行時間の増加により、最終的には1時間15分に1回の実行となってしまいました。これでは、迅速な対応ができなくなってしまいます。つまり、コストの増大と処理の遅延が、時間とともに悪化していく悪循環に陥っているのです。
不正行為が発生すると、顧客体験に大きな影響を及ぼします。顧客は自分のお金のコントロールを失ったと感じるでしょうし、Rampの収支にも大きな影響が出ます。Rampがその損失を負担することになるのです。
先ほど述べたように、不正行為への迅速な対応が非常に重要です。しかし、Snowflakeのようなバッチ型の分析用データウェアハウスでは、この種のオペレーショナルワークロードには不十分です。
これについて、これからNikhil氏がより詳しく説明し、Materializeがどのように機能するかも解説していきます。
Materializeとは
※ここからNikhil氏が登壇
ありがとうございます、Ryanさん。
データワークロードには大きく分けて2つのタイプがあります。一つはアナリティカルワークロード、もう一つはオペレーショナルワークロードです。
アナリティカルワークロードとは、過去の週、月、年の企業パフォーマンスを振り返り、これからの週、月、年の事業計画を立てるものです。バッチ型のデータウェアハウスがこの分析ワークロードに最適です。
一方、オペレーショナルワークロードとは、新しい事実が発生した際に、数分や数秒以内に対応する必要があるものです。オペレーショナルワークロードでは、データの新鮮さがほとんど価値を左右します。Rampの事例でも、クレジットカードを5分ではなく5秒で停止できれば、数万ドルの不正被害を防ぐことができます。
バッチ型のデータウェアハウスはアナリティカルワークロードに適していますが、オペレーショナルワークロードでは対応が追いつきません。日単位なら何とかなりますが、分単位や秒単位の新鮮さを要求されると、もはや対応できなくなります。そのため、オペレーショナルワークロードには、専用の操作ツールが必要となるのです。
バッチ型のデータエコシステムにはたくさんの魅力があります。データウェアハウスは、企業の様々な部門に散在するデータを一つにまとめられるため、非常に強力なツールです。
マーケティングチームのシステム、営業チームのシステム、エンジニアリングチームが構築したカスタムアプリケーションなど、バラバラになっているデータを一元化できるのがデータウェアハウスの役割です。そうすることで、経営レポートやダッシュボードを作成することができます。さらに、SQLを使えば、ファイナンスチームやオペレーションチームのメンバーでも、データウェアハウスのデータを活用した分析が可能になります。また、リバースETLツールを使えば、分析結果をSalesforceなどのSaaSアプリケーションにも送り返すことができます。
ただし、Rampの不正検知の事例で指摘されたように、データウェアハウスにはデータの更新が遅いという課題があります。せいぜい30分ごとの更新が限界で、1日前のデータしか持っていないことが多いのです。しかし、データウェアハウスの持つ他の多くの利点は捨てたくありません。
そこで、RampはMaterializeという、世界初のオペレーショナルデータウェアハウスを構築しました。これは、既存のパイプラインにそのまま組み込めるものです。
Materializeは、データウェアハウスと同じ上流のデータソースに接続し、BIダッシュボードの基盤としても活用できます。また、CensusのようなリアルタイムのリバースETLツールを使えば、マーケティング、営業、ファイナンスのSaaSツールにデータを即座に送り返すこともできます。
つまり、Materializeは、データウェアハウスの持つ利点をそのままに、遅延の問題を解決したのです。これまでの30分単位のバッチ処理ではなく、即座にデータが流れ込み、同じようなSQLクエリで処理され、すぐに下流のアプリケーションに反映されるのです。
Materializeの内部構造を見ていきましょう。
Materializeの中核となる概念はVIEWです。ビジネスロジックや興味深いSQLクエリは、VIEWとして定義されます。dbtを使っている場合は、dbtモデルがこれに相当します。
従来のバッチ型システムでは、アナリストがデータを探索したり、BIツールがデータを可視化したりする際に、データウェアハウスがすべてのデータを処理して結果を返していました。これには数分もかかり、データも30分以上古いものでした。
一方、Materializeでは、CREATE INDEXを行うことで、増分計算を行うデータフローが自動的に構築されます。新しいデータが入ってきても、わずかな量しか処理する必要がないため、クエリの応答速度が非常に速くなります。つまり、Materializeにクエリを投げると、すでに計算済みの最新の結果が即座に返ってくるのです。データの新鮮さは数秒以内に保たれています。
Materializeとdbtの統合
Materializeとdbtの組み合わせは非常に強力です。
dbtの魅力の1つは、宣言型のプログラミングスタイルにあります。しかし、バッチ型のデータウェアハウスでは、データを更新するタイミングを明示的に指定する必要があるという課題がありました。データ量が増えるにつれ、dbtの実行時間が長くなり、頻度を上げられなくなってしまいます。Rampの事例でも、30分ごとの実行が限界となっていました。
一方、Materializeでは、dbtモデルの定義を変更した際にのみdbtを実行すれば良く、その後は Materializeが自動的に増分計算を行います。つまり、開発者がモデルをマージしている間も、夜間も、Materializeが即座に更新を行っているのです。さらに、dbt上のテストも、Materializeの継続的なクエリとして定義できるため、データ品質の問題を即座に検知できるようになります。
これらの機能について、RampのRyanさんから詳しく説明していただきます。
Rampの新しい不正行為対策
※再びRyan氏が登壇
Rampは、不正検知システムをSnowflakeや他のアナリティクスデータウェアハウスではなく、Materializeベースに再構築しました。
具体的な仕組みは、まず、PostgreSQLのWALをKafkaに取り込むCDCストリーミングパイプラインを構築しました。MaterializeはKafkaとネイティブに統合されているため、PostgreSQLのテーブルとほぼ同一のソースがMaterializeに取り込まれます。そして、このソースデータに基づいて、不正検知のためのVIEWやINDEX付VIEWを定義しています。
この結果、特徴量の計算までのエンドツーエンドの遅延が1〜3秒になりました。以前は1時間ごとでしたから、大幅な改善です。
ただし、ポリシー決定エンジンの部分は、まだスケジュールされたNotebookで実行されており、これを数分ごとに実行するよう変更中です。これにより、クレジットカードの停止などの対応を、ホームデポでドリルを購入しようとしている最中に行えるようになります。
Materializeとdbtの管理については、Rampでは、Snowflakeベースのdbtコードと同様のアプローチを取っています。
Snowflakeの場合は、dbtのリポジトリとCI/CDプロセスを使ってmasterへのマージ時にデータウェアハウスに変更を適用しています。また、AirflowのデイリーDAGで、dbt runとdbt testを実行しています。
一方、Materializeの場合は、dbtモデルを変更した際にのみdbt runを実行すれば良く、その後はMaterializeが自動的に下流のモデルを更新します。そのため、Materializeの管理には別のリポジトリとCI/CDプロセスを設けています。
また、Materializeの大きな利点の1つは、ストリーミングパイプラインの定義が容易になったことです。これまでは、Flinkなどの専門知識が必要でしたが、MaterializeではSQLさえ分かれば、アナリティクスエンジニアや不正検知の分析担当者でも、ストリーミングパイプラインを構築できるようになりました。
Materialize導入の成果
事業成果について見ていきましょう。
8月に最近あったイベントでは、良好な結果が得られました。以前は不可能だった、ハッキングされたアカウントの50%を、不正支出が発生する前に検知できたのです。前回のイベントと比較すると、総損失額は約60%減少しました。これは大きな金額の削減につながり、Materializeへの投資と開発努力が十分に正当化されたと言えます。
今後の計画については、まだNotebookベースのポリシー決定エンジンを使っているという話がありました。Rampはスタートアップなので、そのような形から始めたのだと思います。
次に取り組むのは、イベントドリブンな決定エンジンの構築です。Kafkaベースのものを検討しているようで、おそらくPub/Subモデルを採用し、特徴量を公開してコンシューマーが不正判定を行い、下流システムに通知するといった仕組みになるのではないでしょうか。
質疑応答
Dynamic Tablesではこの問題は解決しないのですか？また、Materializeとはどのように違うのでしょうか？
Dynamic TablesはMaterializeよりも速度は劣りますし、最終的な整合性は保証されません。一方、Materializeは一貫した状態を維持しつつ、秒単位の新鮮さを実現できます。
Materializeとデータウェアハウスを逆の順序で使うとメリットが失われるのでしょうか？
その通りです。
Materializeの利点を最大限に活かすには、重要な変換処理をデータウェアハウスから移し、Materializeで即時に処理し、その結果をデータウェアハウスに書き出すのが理想的です。
MaterializeはSnowflakeと比べてコストはどうなのでしょうか？
大量のデータを処理する場合、Snowflakeのようなデータウェアハウスの方が費用対効果が高くなります。
一方、100GB程度のデータであれば、Materializeの方が適しています。今後、Materializeのメモリ効率が向上し、より大規模なデータセットにも対応できるようになるでしょう。
KafkaやPostgres以外の他のソースはサポートされているのでしょうか？
YES。KafkaとPostgresの他にも、Webhookなどが利用できます。また、CDCプロバイダとの連携も検討中です。
最終的にはすべてがリアルタイムになるという将来像はありますか？
YES。リアルタイム処理が容易かつ費用対効果の高いものになれば、分析と業務の区別がなくなっていくことが理想です。Materializeではオートスケーリングなどの機能を検討しており、Snowflakeのようなデータウェアハウスとの使い分けも可能になると考えています。
データサイエンスモデルの特徴量抽出にMaterializeは使えるのでしょうか？
YES。Materializeはデータサイエンスモデルの特徴量抽出に適しています。ルールベースのポリシーレイヤーをモデルベースに置き換えることも検討できるでしょう。
所感など
まず、Materializeを導入したことによるビジネス的成果がはっきりと出ていることのが素晴らしいですね。しかも、「詐欺による損失額の減額」ですから、経営にダイレクトに響く部分なはずで、会社全体によって非常に良い施策だったと思います。
Materialize自体は私も少し使ったことがあり、そのスピードには驚かされました。ニアリアルタイムとかではなく、ガチのリアルタイム分析ができるレベルです。なので、プロダクトとしては素晴らしい品質のものだと思います。
ただ、2024年3月現在、Snowflakeを始めとする各種DWHはどんどん新しい機能を開発しており、ここらへんのリアルタイム分析に対するニーズも、近いうちにDWH単独で拾うんじゃないか、というのが個人的な予想です。なので、Materializeというプロダクトが、今後も存続し続けられるかどうか、非常に気になっています。
4
