Workers Analytics Engine では、大量のデータを書き込み、低コストまたは無償で素早く取り出せます。妥当なコストで大量書き込みを実現するため、Workers Analytics Engine は重み付き適応 サンプリング ↗ を使います。
サンプリングを使う場合、データセットに関する問いに答えるために、すべてのデータポイントは必要ありません。十分に大きなデータセットでは、必要なサンプルサイズ ↗ は元の母集団の大きさに依存しません。必要なサンプルサイズは、測定値の分散、分析するサブグループの大きさ、見積もりに求める精度によって決まります。
そのため Analytics Engine では、非常に大きなデータセットを、はるかに少ない観測数に圧縮しつつ、ほとんどのクエリに高い精度で答えられます。利用量が非常に多い場合でも、カーディナリティ無制限で、安価かつ予測可能な価格の分析サービスを提供できます。
サンプリングの概要は次のとおりです。
- 書き込み時に、1 つの index へデータポイントが速すぎるとサンプリングします。
- クエリが複雑すぎる場合は、クエリ時にもう一度サンプリングします。
以降のセクションでは、次を説明します。
- サンプリングの仕組み。
- サンプリング済みデータの読み方。
- データのサンプリング方法。
- Adaptive Bit Rate Sampling の仕組み。
- 使いやすい形でサンプリングされるよう index を選ぶ方法。
Cloudflare のデータサンプリングは、Google Maps のようなオンライン地図サービスが、ズームレベルごとに地図を描画する方法に似ています。大陸全体の衛星画像を見るとき、地図サービスは画面サイズと通信速度に合わせて適切な解像度の画像を返します。
地図上の 1 ピクセルは、数平方キロメートルといった広い範囲を表します。スクリーンショットを拡大しても、画像はぼやけます。代わりに、特定の都市へズームすると、地図サービスはより高解像度の画像を選びます。ピクセルの総数はほぼ同じですが、1 ピクセルが表す範囲は数平方メートル程度まで小さくなります。
要点は、地図の品質は解像度や 1 ピクセルが表す面積だけでは決まらないということです。最終的な表示に使うピクセルの総数で決まります。
地図サービスの解像度の扱いと、Cloudflare Analytics が適応サンプリングで分析を返す方法には、次の共通点があります。
- データの保存方法:
- 地図サービス: 複数の解像度で画像を保存します。
- Cloudflare Analytics: 複数のサンプルレートでイベントを保存します。
- ユーザーへの表示方法:
- 地図サービス: 画面サイズが同じなら、選択した範囲に関係なくピクセル総数はほぼ一定です。
- Cloudflare Analytics: データセットの大きさや期間に関係なく、各クエリで読むイベント数は同程度です。
- 解像度の選び方:
- 地図サービス: 1 ピクセルが表す範囲は、描画する地図の大きさに依存します。ズームアウトした地図では、1 ピクセルがより広い範囲を表します。
- Cloudflare Analytics: 結果内の各イベントのサンプル間隔は、元データセットの大きさと選択した期間に依存します。大きなデータセットや長い期間のクエリでは、サンプリングされた 1 件のイベントが、似た多数のイベントを代表します。
クエリを書き、データを分析するには、まず Workers Analytics Engine でサンプリング済みデータをどう読むかを把握しておくと便利です。
Workers Analytics Engine では、すべてのイベントに _sample_interval フィールドが記録されます。サンプル間隔はサンプルレートの逆数です。たとえば 1% のサンプルレートを適用すると、sample_interval は 100 になります。
先の地図の例で言うと、サンプル間隔は、サンプリングされた 1 件（ピクセル）が代表する「サンプリングされていないデータポイント数」（キロメートルやメートル）です。
サンプル間隔は、Workers Analytics Engine に保存される各行のプロパティです。公平サンプリングの実装により、行ごとにサンプル間隔は変わり得ます。そのためクエリ時は、サンプル間隔フィールドを考慮する必要があります。クエリ結果に一定のサンプリング係数を掛けるだけでは不十分です。
サンプリング済みデータに対する一般的なクエリの書き方は、次のとおりです。
| 用途 | サンプリングなしの例 | サンプリングありの例 |
|---|---|---|
| データセット内のイベント数を数える | count() |
sum(_sample_interval) |
| 量（バイト数など）を合計する | sum(bytes) |
sum(bytes * _sample_interval) |
| 量の平均を取る | avg(bytes) |
sum(bytes * _sample_interval) / sum(_sample_interval) |
| 分位点を計算する | quantile(0.50)(bytes) |
quantileExactWeighted(0.50)(bytes, _sample_interval) |
結果の精度は、先の地図の例えと同様、サンプル間隔だけでは決まりません。サンプル間隔が大きくても、精度の高い結果を得られます。精度は、クエリしたデータポイントの総数と分布に依存します。
各イベントのサンプル間隔を決めるうえで、ほとんどの分析には、精度の高い結果が必要な重要なサブグループがあります。たとえば、ユーザーの利用量や特定ホスト名へのトラフィックを分析したい場合があります。Analytics Engine の利用者は、イベント書き込み時に index フィールドを埋めて、これらのグループを定義できます。指定したグループ内で、より的を絞った精密な分析ができます。
次に、これらの index 値ごとに書き込まれるイベント数は、大きく異なる可能性が高いです。実際、ほとんどの Web サービスの利用は パレート分布 ↗ に従い、上位少数のユーザーが利用の大半を占めます。パレート分布はよく見られ、次のような形です。
このデータの 単純無作為標本 ↗ を 1% 取り、母集団全体に適用すると、最大の顧客は正確に追跡できても、より小さな顧客の動きは見えなくなることがあります。
大きな棒は見た目があまり変わらず、精度も十分です。一方、小さな顧客を分析すると結果が 量子化 ↗ され、丸めによって 0 になることもあります。
つまり、大きな母集団では 1% 以下のサンプルでも十分な場合がありますが、小さな母集団で精度を出すには、より大きな割合のイベントを保存する必要があります。
これを実現するのが公平サンプリング（equitable sampling）です。一意な index 値ごとに、保存するイベント数を揃えます。比較的珍しい index 値では、writeDataPoint() で受け取ったデータポイントをすべて書き込むことがあります。一方、同じ index 値へ大量に書き込むと、サンプリングを開始します。
同じ分布に、公平サンプリング（のシミュレーション）を適用した結果は次のとおりです。
最初のグラフとよく似ていることに気づくかもしれません。ただし、全体として保存が必要なデータは <10% だけです。大きな系列のサンプルレートは実際には 10% よりかなり低く（つまり、より大きなサンプル間隔を保存します）、小さな系列ではサンプルレートが高くなります。
先の地図の例えに戻ります。表示する地図の範囲に関係なく、地図のピクセル総数は一定です。同様に、各 index 値ごとに同程度のデータポイントを保存したいと考えます。ただし、地図の解像度（1 ピクセルが表す範囲）は、表示する範囲に応じて変わります。ここでも同様に、保存された 1 件が代表するデータ量は、その index 内のデータポイント総数に応じて変わります。
公平サンプリングにより、特定期間内の各 index について、同程度のデータ量が保たれます。一方、クエリが対象とする期間は大きく異なります。10 分のスナップショットだけでよいクエリもあれば、10 週間分（1 万倍の長さ）の分析が必要なクエリもあります。
この問題に対応するため、adaptive bit rate ↗（ABR）という手法を使います。ABR では、より長い期間を対象とするクエリほど、より高いサンプル間隔のデータを取得し、一定時間内に完了できるようにします。簡単に言うと、地図の例えで画面サイズや帯域が固定リソースであるように、クエリ完了に使える時間も固定です。そのため、データの量に関係なく、クエリへの答えを返すために走査する行の総数を制限する必要があります。これにより公平性を保てます。クエリ対象の元データセットの大きさに関係なく、利用可能な計算時間を各クエリが同等に分け合います。
これを実現するため、公平サンプリング済みデータから、複数の解像度（詳細度の違い。例: 100%、10%、1%）でデータを保存します。クエリ時は、クエリの複雑さに応じて、読むのに最も適した解像度を選びます。クエリの複雑さは、取得する行数と、指定した N 秒以内に完了する確率で決まります。適切な解像度を動的に選ぶことで、クエリ性能を最適化し、割り当てた時間内に収めます。
ABR の大きな利点は、データの大きさや期間に関係なく、固定のクエリ予算内で結果を一貫して返せる点です。大規模データセットでタイムアウト、エラー、高コストに陥りやすいシステムとは異なります。
サンプリング済みデータで精度の高い結果を得るには、index に適切な値を選んでください。index は、利用者がデータをクエリし、表示する方法と一致させる必要があります。たとえば、特定のデバイスやホスト名でデータをよく見る場合は、それらの属性を index に含めることを推奨します。
index には次の性質があり、選ぶときに重要です。
- すべての index 値を横断して、データセット全体の要約統計を正確に取得できます。
- index の一意な値の数を正確に数えられます。
- 特定の index 値内で、要約統計（件数、合計など）を正確に取得できます。
- index に含まれない特定フィールドの
Top N値を確認できます。 - ほとんどのフィールドでフィルタできます。
- 分位点などのほかの集計を実行できます。
考慮すべき制限とトレードオフは次のとおりです。
- index に含まれないフィールドの一意件数を、正確に取れないことがあります。
- たとえば
hostnameで index している場合、一意な URL の数を数えられないことがあります。
- たとえば
- index に含まれないフィールドの、非常に珍しい値を観測できないことがあります。
- たとえば、ホストで index しており一意な URL が数百万ある場合、そのホスト名の特定 URL です。
- 複数の index をまたぐ正確なクエリを、一度に実行できないことがあります。
- たとえば、正確な結果を期待できるのは、一度に 1 ホスト（またはすべて）をクエリする場合だけかもしれません。
- 個別のレコードを必ず取得できる保証はありません。
- イベントの正確な時系列を再構成できるとは限りません。
ほとんどの用途では、各行に UUID のような一意な index 値を書くことは推奨しません。個別のデータポイントは非常に速く取れますが、集計や時系列のほとんどのクエリは遅くなります。
サンプリングに関するよくある質問は、Workers Analytics Engine FAQ の Sampling を参照してください。