近似回答、正確な決定：分析のための新しいスケッチ関数

多くの分析クエリは意思決定支援であり、監査ではありません。「約470万ユニークユーザー ±1%」という結果が「4,712,389ユニークユーザー」と同じ意思決定につながるなら、コストのほんの一部で得られる近似値の方が明らかに優れています。

すべてのデータウェアハウスには、計算負荷が最も大きいクエリがいくつか存在します。グローバルソートを強制するパーセンタイル、すべてのユニーク値を追跡するディスティンクトカウント、データセット全体を並べ替えるトップKランキングなどです。Databricksは、Apache DataSketches上に構築された4つの新しいスケッチ関数ファミリーをサポートするようになりました。これらは、これらの正確な計算を、メモリ使用量を制限した近似値に置き換えます。トレードオフは1〜2%の設定可能な相対誤差です。メリットは、計算量が桁違いに少なくなるだけでなく、生データに触れることなく保存、マージ、再クエリできるスケッチが得られることです。

パーセンタイル計算が数分から数ミリ秒に

10億行のテーブルに対してPERCENTILE(response_time_ms, 0.99)を呼び出すと、エンジンはすべての値をグローバルにソートする必要があります。完全なクラスターシャッフルには数分かかり、ギガバイトのメモリを消費する可能性があります。5分ごとに更新されるダッシュボードの場合、このコストを何度も支払うことになります。

KLLスケッチは、クォンタイルクエリに答えるために構築された、コンパクトでマージ可能なサマリーです。これにより、1000個の値でも1兆個の値でも、同じメモリ使用量でこのソートを置き換えることができます。典型的な相対誤差は1〜2%で設定可能であり、レイテンシ監視、キャパシティプランニング、異常検出の実行可能な範囲内です。

真の利点は、スケッチが可能にするワークフローです。毎日のETL中に一度ビルドします。Deltaテーブルの列として保存します。ダッシュボードが任意の時間範囲のP50/P90/P99を必要とする場合、生データを再スキャンする代わりに、ミリ秒単位で事前計算されたスケッチをマージします。kll_get_quantile_bigint(sketch, ARRAY(0.5, 0.9, 0.99))を使用して、単一のスケッチから複数のクォンタイルを1回のパスで抽出します。

計算コストなしでのオーディエンス重複分析

スーパーボウル広告を見たがInstagramキャンペーンを見なかったユーザーは何人いますか？オーディエンス重複分析はマーケティング測定の中核です。総リーチ（いずれかのキャンペーンを見たユーザー）、重複（複数のキャンペーンを見たユーザー）、および排他的リーチ（単一のキャンペーンのみを見たユーザー）を知る必要があります。しかし、正確な計算には、すべてのユーザーIDをメモリに収集し、潜在的に数十億の識別子間でセット操作を実行する必要があります。スケールすると、これは非現実的または不可能になります。

Thetaスケッチは、メモリ使用量を制限した状態で一連のユニークな値を要約し、完全なセット代数（和集合、積集合、差集合）をサポートします。キャンペーンごとにスケッチをビルドし、それらを数学的に結合します。

正確なアプローチでは、重複排除のためにUNIONを実行し、次に重複を見つけるためにJOINを実行し、おそらく生ユーザーIDをクラスター全体で2回シャッフルする必要があります。Thetaスケッチを使用すると、キロバイト単位で測定されるコンパクトなバイナリオブジェクトを生成し、セット操作はマイクロ秒単位でローカルに実行されます。これにより、毎日のリーチカーブ、インクリメンタリティ測定、およびチャネル間重複排除が実用的になります。

データ再処理なしでのリアルタイムリーダーボード

現在何がトレンドですか？これは単純な質問ですが、正確な答えは高コストです。すべてのユニークな値をカウントし、それらのカウントをすべて保存し、クラスター全体でシャッフルし、グローバルにソートします。検索ログやクリックストリームのような高カーディナリティのイベントストリームの場合、これはライブクエリではなくバッチジョブになります。

近似トップKスケッチは、メモリ使用量を制限した状態で最も頻繁に出現するアイテムを追跡し、パーティションや時間ウィンドウをまたいでマージして結果を即座に抽出できます。まれなアイテムはドロップされる可能性がありますが、それは探しているものではないため問題ありません。

approx_top_k_combineを使用すると、「今週のトレンド」ダッシュボードは、数十億の生イベントをスキャンするのではなく、168個の事前計算されたスケッチのマージになります。ストリーミングワークロードの場合、各マイクロバッチのスケッチを実行中の合計にマージし、結果をリアルタイムで表示します。かつてバッチジョブだったものがライブリーダーボードになります。

1回のパスでのカーディナリティと収益アトリビューション

ユニークな顧客をカウントすることは1つのクエリです。それらの収益を合計することは別のクエリです。両方を正しく実行し、複数の期間に登場する顧客を二重にカウントしないことが課題です。

一般的な分析クエリを考えてみましょう。「今月購入したユニークな顧客は何人いて、地域ごとの合計収益はいくらでしたか？」通常、大規模なGROUP BYから始め、数十億のトランザクションにわたる購入を合計しながら顧客IDを重複排除します。また、以前の結果を単純に合計することはできません。両方の期間に登場する顧客は二重にカウントされ、収益が過大評価されます。

Tupleスケッチは、ユニークなカウントとメトリック集計を単一のマージ可能な構造に結合することで、これを解決します。

各スケッチは、ユニークな顧客とその集計された支出をマッピングします。日をまたいでマージすると、顧客カウントは自動的に重複排除され、収益合計は累積されます。正確な増分計算では、データ範囲が変更されるたびに生データから再処理する必要があります。

適切なスケッチでの開始方法

いつスケッチを使用するか: ダッシュボード、トレンド分析、監視、マーケティングアトリビューションなど、近似値で十分なクエリ。データセットが大きいほど効果的です。どのスケッチを使用すればよいかわからない場合は、Genie Codeに適切な選択を支援してもらいましょう。

いつ正確性を保つか: 財務監査、コンプライアンスレポート、または規制やビジネス要件で正確な値が要求されるあらゆるユースケース。

これらの4つの関数ファミリーは、長時間実行されるクエリをデータウェアハウスで最も安価なものに変えます。ETL中にスケッチを一度ビルドし、Deltaに保存し、読み取り時にマージします。監査人が要求した場合でも、生データは依然として存在します。それ以外の場合は、1%のエラーマージンと1000倍の高速化が歓迎されるトレードオフとなります。

すべての関数は、SQL、DataFrame、およびStructured Streamingパイプラインで機能します。Sparkで作成されたスケッチは、Apache DataSketchesエコシステムの他のシステムと相互運用可能です。関数シグネチャと例については、ドキュメント（1、2、3、4）を参照して、今日からスケッチを使い始めましょう。

Apache SparkにThetaスケッチおよびTupleスケッチ関数ファミリーを実装および提供していただいたChristopher Boumalhab（GitHubのcboumalh）に特別に言及します。

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