Lakebaseでシームレスで費用対効果の高いマーケティングキャンペーンを実現

最近、DeichmannはLakebaseがいかにシームレスなオムニチャネルマーケティングを実現したかを説明する顧客事例を公開しました。このブログでは、その技術的な側面について解説します。

すべての小売企業は、パーソナライズされた高性能なマーケティングキャンペーンを提供するためにデータを活用する必要があります。しかし、業界全体でいくつかの非効率性が見られます。

• 企業は十分に活用されていないデータベースリソースに費用を払っています。パーソナライズされたキャンペーンに使用される顧客セグメントは、多くの場合、マーケティングツールが読み取るOLTPデータベースに保存されています。マーケティングキャンペーンが開始されるとデータベースリクエストが急増しますが、それ以外のデータベース利用率は低いです。
• マーケティングチームの変化するニーズは、データチームに運用上の負担を加えています。データ担当者はLakehouseで新しい顧客セグメントを作成しますが、マーケティングからの新しいリクエストごとに、LakehouseからOLTPへの同期パイプラインの作成、維持、監視という一連の作業が発生します。

Lakebaseは、トランザクションデータベースの最高の要素とデータレイクの柔軟性および経済性を組み合わせた、新しいオープンアーキテクチャです。Databricks Lakebase Postgresは、このLakebaseアーキテクチャの実装であり、これらの問題を解決します。

• ストレージとコンピューティングを分離することで、コンピューティングを線形にスケールすることなく、データをオブジェクトストレージに安価に保存できます。これにより、追加のコンピューティングリソースを必要とせずに、顧客属性の数と多様性を大幅に増やすことができます。データが増加してもデータベーストラフィックが増加しないため、Lakebaseのコストは従来のOLTPデータベースよりも低く抑えられます。
• 伸縮自在なサーバーレスPostgresコンピューティングを搭載したLakebaseは、需要に応じて瞬時にスケールアップし、アイドル時には1秒未満でスケールダウンします。コストは使用量に直接連動するため、スケジュールされたマーケティングキャンペーンのようなバースト性の高いワークロードに最適です。Lakebaseのお客様は必要なリソースに対してのみ支払い、コストを削減し、事前にコンピューティングのサイズ設定や計画を行う必要がなくなります。
• Lakehouseとシームレスに統合することで、LakebaseとLakehouse間の同期は完全に管理され、信頼性が高く、効率的になり、データ担当者のパイプライン作成とメンテナンスの負担を軽減します。

LakebaseとSAP Engagement Cloudの統合

Lakebaseをマーケティングキャンペーンプラットフォームのバックエンドデータベースとして使用する利点を示すために、LakebaseをオムニチャネルマーケティングプラットフォームであるSAP Engagement Cloudと統合し、Lakehouseで以前に作成された顧客セグメントに基づいてパーソナライズされたマーケティングキャンペーンを立ち上げる方法を紹介します。

ステップ1：新しいLakebaseプロジェクトの作成と設定

新しいLakebase Autoscalingプロジェクトを作成して、Postgresインスタンスを設定します。プロジェクトは、データベースリソースの最上位コンテナです。新しく作成されたプロジェクトには、SAP Engagement Cloudが接続するPostgreSQLインスタンスとなる本番データベースが含まれます。

マーケティングキャンペーンは時間ベースのトリガーに依存します。キャンペーンがトリガーされると、SAP Engagement Cloudはデータベースをクエリして、指定された基準を満たす見込み客を取得します。これらのメカニズムは、長期的な低利用期間中に定期的なスパイクを引き起こします。このため、コンピューティングに関しては、長期的な低利用期間中は0にスケールし、これらの期間のコンピューティングコストを排除し、スパイク時の最大容量として中程度の16 CU（約32 GB RAM）を設定します。選択されたメモリ範囲が比較的大きくても、Lakebaseのオートスケーリングの速度と応答性により、リソースの過小利用のリスクが排除され、TCOが削減され、データベースのサイジングとプロビジョニングの必要性が軽減されます。

Lakebaseのコンピューティングが設定されたら、SAP Engagement Cloudに必要なロールを作成する必要があります。LakebaseはDatabricksのID用のOAuthロールとネイティブPostgresパスワードロールをサポートしています。Engagement CloudはOAuthロールで発生する時間ごとのトークンローテーションを処理できないため、ネイティブPostgresロールを使用します。Postgresロールはさまざまな方法で作成できます。ここではLakebase UIを使用して高エントロピーパスワードを生成します。パスワードはすぐに取得し、シークレットマネージャーに保存してください。定期的に新しいパスワードを生成してローテーションすることをお勧めします。

次に、Lakebase SQLコンソールでこれらのコマンドを実行して、同期された顧客セグメントに使用されるスキーマに対して、新しく作成されたSAP Engagement Cloud Postgresロールに必要な権限を付与します。

ステップ2：SAP Engagement CloudをLakebaseに接続する

SAP Engagement Cloudは、PostgreSQLインスタンスに接続するためにCA証明書を必要とします。LakebaseはLet's Encryptによって発行された証明書を使用するため、必要なルート証明書はISRG Root X1です。

ルート証明書は次のようにして取得できます。

エクスポートされた証明書を検査して、正しいことを確認できます。

SAP Engagement Cloudで新しいPostgreSQL接続を設定する際、CA証明書を求められたらこのファイルの内容を貼り付けます。

ステップ3：顧客セグメントをLakebaseと同期する

接続とロールが作成されたら、LakehouseからLakebaseに顧客セグメントを同期できます。そのためには、同期するテーブルから同期テーブルを作成する必要があります。Databricks Synced Tablesは、Unity CatalogデータをLakebaseにマネージドコピーとして作成し、OLTPスタイルの低レイテンシーなクエリを必要とするアプリケーションで利用できるようにします。

いくつかの同期モードが利用可能です：スナップショット、トリガー、連続。私たちの場合、そして非常に頻繁に、顧客セグメントは夜間にバッチで再計算され、データセットの大部分が置き換えられます。データの10%以上が更新される場合、トリガーモードよりも10倍優れたパフォーマンスを提供するスナップショットモードを推奨します。そこからマネージドパイプラインが作成され、データが同期されます。新しい顧客セグメントをEngagement Cloudで利用できるようにする作業は、数回のクリックで完了し、市場投入までの時間を短縮し、運用上の負担を軽減します。

さらに、Lakebaseはコンピューティングとストレージが分離されているため、従来のデータベースのようにコンピューティングリソースをスケールすることなく、Engagement Cloudで利用可能なデータのサイズと多様性を増やすことができ、コストを低く抑えることができます。ただし、Databricks Lakebaseは、大規模なスキャンや従来のOLAPではなく、高並行性のポイントルックアップと短いOLTPクエリに最適化されていることに留意することが重要です。

運用データをLakehouseに同期する

生成された顧客セグメントに加えて、マーケティングキャンペーンは他のアプリケーションからのデータも組み込むことができます。たとえば、顧客は特定のカテゴリやブランドの製品の再入荷や新着に関する通知を受け取るためにサインアップするかもしれません。アプリケーションはLakebaseを標準のPostgresデータベースとして使用してこの通知データを保存し、キャンペーンターゲティングのためにEngagement Cloudで利用できるようにすることができます。Lakebaseに書き込まれたデータは、Lakehouse Sync（Lakebase PostgresからUnity Catalog Deltaテーブルへのネイティブで継続的なCDCベースのパイプラインで、運用データをよりリッチな分析とAIに利用できるようにします）を介してLakehouseに同期できます。

パフォーマンスの最適化

LakebaseはPostgresであり、従来のPostgresデータベースと同様にパフォーマンスを最適化できます。

インデックスの構築は、最も簡単で、最も効果的で、一般的な最適化の一つです。マーケティングキャンペーンがトリガーされると、SAP Engagement CloudはWHERE句でフィルタリングされた顧客IDを取得するためにクエリを発行します。

このフィルタリング条件に基づいてインデックスを作成します。インデックスは、Lakebase SQLコンソールに書き込むことでLakebaseに作成できます。

SAP Engagement Cloudの場合、インデックスはすでに必要なパフォーマンスを提供しているはずです。追加の最適化が必要な場合は、まず最も長く、最も頻繁なクエリをpg_stat_statementsを使用するか、クエリのパフォーマンスとデータベースを監視するための一連のメトリクスを提供するDatabricks Lakebase UIを使用して特定する必要があります。

最も長く、最も問題のあるクエリは、以下を使用して分析できます。

PREFETCHとFILECACHEはLakebaseに固有のものであり、それぞれ発行/ヒット/無駄になったプリフェッチリクエストの数と、ローカルファイルキャッシュ（LFC）に対するヒット/ミスを示します。Databricks Lakebase UIは、これらの分析を実行するための便利なインターフェースも提供します。

そこから、次のような追加の最適化オプションを検討できます。

• work_memの設定を変更する - より大きなコンピューティングのために256 MBに増やすことは有益です。
• チャーン率の高いテーブルではautovacuum_vacuum_scale_factorを低く調整し、pg_stat_user_tablesで肥大化を監視します。

結論

Lakebaseは、独自のテクノロジーとLakehouseとの緊密な統合により、分析およびAIワークロードによって作成された顧客セグメントに低遅延でサービスを提供できます。

Lakebaseは、リソースが使用されていないときに積極的にオートスケーリングし、ゼロにスケールすることでTCOを大幅に削減し、アイドルリソースのコストを排除します。

LakebaseとLakehouseの統合により、同期パイプラインの維持にかかる運用上の負担が軽減され、新しい顧客セグメントの市場投入までの時間が短縮され、よりパーソナライズされたマーケティングキャンペーンが可能になり、より短期間でエンゲージメントを高めることができます。

マーケティングスタックを最新化する準備はできていますか？今すぐDatabricks Lakebase Postgresを試して、サーバーレスOLTPとLakehouseの組み合わせがどのようにTCOを削減し、キャンペーン配信を加速できるかをご覧ください。DatabricksのLakebase製品ページにアクセスするか、Deichmannの顧客事例を読むか、Databricksアカウントチームに連絡して、マーケティングキャンペーンのワークロードに合わせた概念実証を検討してください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事