GoogleSQL for BigQuery は、データスケッチをサポートしています。データスケッチは、データ集計のコンパクトな概要です。それは、集計情報を抽出するため、データ集計を継続するため、あるいは別のスケッチと結合するために必要な情報をすべて取得して再集計を可能にします。
スケッチを使用した指標のコンピューティングは、正確な値をコンピューティングするよりも大幅に安価になります。計算が遅すぎる場合や一時ストレージが多くなりすぎる場合は、スケッチを使用してクエリの時間とリソースを削減します。
さらに、カーディナリティ（個別のユーザー数など）や変位値（訪問期間の中央値など）の計算をスケッチを使用せずに行うには、通常、元データに対してジョブを実行する必要があります。これは、すでに集計されたデータをこれ以上組み合わせることができないためです。
次のデータがあるテーブルについて考えます。
| 製品 | ユーザー数 | 訪問時間の中央値 |
|---|---|---|
| プロダクト A | 5 億 | 10 分 |
| プロダクト B | 2,000 万 | 2 分 |
テーブルで両方のプロダクトを使用しているユーザー数が不明なため、両方のプロダクトの合計ユーザー数をコンピューティングすることはできません。
代わりに、テーブルにスケッチを保存する方法があります。各スケッチは、カーディナリティなどの特定の入力プロパティの近似かつコンパクトな表現であり、ほぼ正確な結果を保存、結合（または再集計）、クエリ実行できます。前の例では、各プロダクトのスケッチを作成して結合（再集計）することで、プロダクト A とプロダクト B の一意のユーザー数を推定できます。また、同様に結合してクエリを実行できる分位スケッチを使用して、訪問時間の中央値を推定することもできます。
スケッチには元のデータの不可逆圧縮があるため、エラーの範囲または信頼区間（CI）で表される統計エラーが発生します。ほとんどのアプリケーションでは、この不確実度は小さくなります。たとえば、一般的な cardinality-counting スケッチの相対誤差は、すべてのケースの 95% で約 1% です。スケッチは、ある程度の精度（正確さ）と引き換えに、より速く、より低コストでコンピューティングし、より少ないストレージを提供します。
まとめると、スケッチには次のような主要プロパティがあります。
- 特定の指標の近似集計を表す
- コンパクトである
- メモリ内、線形データ構造のシリアル化された形式である
- 通常は固定サイズであり、入力よりも非対称的に小さくなる
- 精度レベルで判断した統計誤差を導入できる
- 他のスケッチと結合して、基になるデータセットの結合を要約できる
スケッチの結合による再集計
スケッチにより、データを保存して結合することで、効率的な再集計が可能になります。このため、スケッチは、データセットのマテリアライズド ビューに特に役立ちます。スケッチを結合し、各ストリームに対して作成された部分的なスケッチに基づいて複数のデータ ストリームの概要を作成できます。
たとえば、毎日個別ユーザーの推定数のスケッチを作成する場合、毎日のスケッチを結合することで、過去 7 日間の個別ユーザーの数を取得できます。結合された毎日のスケッチを再集計すると、データセットの全入力を読み取る必要がなくなります。
スケッチの再集計は、オンライン分析処理（OLAP）でも有用です。スケッチを結合して、OLAP キューブのロールアップを作成できます。ここで、スケッチは、1 つ以上のキューブの特定のディメンションに沿ってデータを要約します。OLAP ロールアップは、実際の個別数では実現できません。
スケッチの統合
スケッチを他のシステムと統合できます。たとえば、Dataflow、Apache Spark、ZetaSketch などの外部アプリケーションでスケッチを作成し、GoogleSQL で使用できます。逆もまた同様です。
スケッチは、GoogleSQL に加え、次のコーディング言語で使用できます。
- C++
- Go
- Java
- Python
削除せずにカーディナリティを推測する
カーディナリティを推測する必要があり、スケッチからアイテムを削除する必要がない場合は、HLL++ スケッチを使用します。
たとえば、ある月でプロダクトを積極的に使用したユニーク ユーザー数（MAU または 28DAU の指標）を取得するには、HLL++ スケッチを使用します。
HLL++ スケッチ
HyperLogLog++（HLL++）は、カーディナリティを推定するためのスケッチ アルゴリズムです。HLL++ は、論文 HyperLogLog in Practice に基づいており、++ は HyperLogLog アルゴリズムに加えられた拡張を表しています。
カーディナリティとは、スケッチの入力に含まれる個別要素の数のことです。たとえば、HLL++ スケッチを使用して、あるアプリを起動したユニーク ユーザーの数を取得できます。
HLL++ は、非常に低い、および非常に高いカーディナリティを推測します。HLL++ アルゴリズムには、64 ビットハッシュ関数、低いカーディナリティの推測でメモリ要件を減らすためのスパース表現、および低いカーディナリティの推測の経験的バイアス補正が含まれています。
精度
HLL++ スケッチはカスタム精度をサポートしています。次の表に、サポートされる精度値、最大ストレージ サイズ、一般的な精度レベルの信頼区間（CI）を示します。
| 適合率 | 最大ストレージ サイズ | 65% CI | 95% CI | 99% CI |
|---|---|---|---|---|
| 10 | 1 KiB + 28 B | ±3.25% | ±6.50% | ±9.75% |
| 11 | 2 KiB + 28 B | ±2.30% | ±4.60% | ±6.89% |
| 12 | 4 KiB + 28 B | ±1.63% | ±3.25% | ±4.88% |
| 13 | 8 KiB + 28 B | ±1.15% | ±2.30% | ±3.45% |
| 14 | 16 KiB + 30 B | ±0.81% | ±1.63% | ±2.44% |
| 15（デフォルト） | 32 KiB + 30 B | ±0.57% | ±1.15% | ±1.72% |
| 16 | 64 KiB + 30 B | ±0.41% | ±0.81% | ±1.22% |
| 17 | 128 KiB + 30 B | ±0.29% | ±0.57% | ±0.86% |
| 18 | 256 KiB + 30 B | ±0.20% | ±0.41% | ±0.61% |
| 19 | 512 KiB + 30 B | ±0.14% | ±0.29% | ±0.43% |
| 20 | 1,024 KiB + 30 B | ±0.10% | ±0.20% | ±0.30% |
| 21 | 2,048 KiB + 32 B | ±0.07% | ±0.14% | ±0.22% |
| 22 | 4,096 KiB + 32 B | ±0.05% | ±0.10% | ±0.15% |
| 23 | 8,192 KiB + 32 B | ±0.04% | ±0.07% | ±0.11% |
| 24 | 16,384 KiB + 32 B | ±0.03% | ±0.05% | ±0.08% |
HLL++ スケッチの精度は、HLL_COUNT.INIT 関数で初期化するときに定義できます。
削除
HLL++ スケッチから値を削除することはできません。
補足情報
HLL++ スケッチで使用できる関数の一覧については、HLL++ 関数をご覧ください。
近似集計関数
特定のスケッチベースの近似関数の代わりに、GoogleSQL では事前定義された近似集計関数が用意されています。これらの近似集計関数は、個別カウント、変位数、トップカウントなどの一般的な評価用のスケッチをサポートしていますが、カスタム精度は使用できません。また、他の種類のスケッチのように再集計するために公開されたり保存されたりすることはありません。近似集計関数は、詳細な構成を行わずに簡単なスケッチベースのクエリを実行するために設計されています。
スケッチベースの近似で使用できる近似集計関数の一覧については、近似集計関数をご覧ください。