GoogleSQL for BigQuery は、データスケッチをサポートしています。データスケッチは、データ集計のコンパクトな概要です。これには、集計情報の抽出、データ集計の継続、あるいは別のスケッチとの結合に必要な情報をすべてがキャプチャされ、再集計が可能になります。
スケッチを使用した指標の計算は、正確な値の計算よりも大幅に安価になります。計算が遅すぎる場合や一時ストレージが多くなりすぎる場合は、スケッチを使用してクエリの時間とリソースを削減します。
さらに、カーディナリティ（個別のユーザー数など）や変位値（訪問時間の中央値など）の計算をスケッチを使用せずに行うには、通常、元データに対してジョブを実行する必要があります。これは、すでに集計されたデータをこれ以上組み合わせることができないためです。
次のデータがあるテーブルについて考えます。
| プロダクト | ユーザー数 | 訪問時間の中央値 |
|---|---|---|
| プロダクト A | 5 億人 | 10 分 |
| プロダクト B | 2,000 万人 | 2 分 |
このテーブルでは両方のプロダクトを使用しているユーザーの数が不明なため、両方のプロダクトの合計ユーザー数を計算することはできません。
代わりに、テーブルにスケッチを保存する方法があります。各スケッチは、カーディナリティなど特定の入力プロパティの近似かつコンパクトな表現であり、ほぼ正確な結果を保存、結合（または再集計）、クエリ実行できます。前の例では、各プロダクトのスケッチを作成して結合（再集計）することで、プロダクト A とプロダクト B の一意のユーザー数を推定できます。また、同様に結合してクエリを実行できる変位値スケッチを使用することで、訪問時間の中央値を推定することもできます。
スケッチでは元のデータを不可逆圧縮しているため、エラーの範囲または信頼区間（CI）で表される統計エラーが発生します。ほとんどのアプリケーションでは、この不確実度は小さくなります。たとえば、一般的なカーディナリティ計数スケッチの相対誤差は、すべてのケースの 95% に対し約 1% です。スケッチを使用すると、ある程度の精度（正確さ）低下と引き換えに、より速く、より低コストで計算でき、ストレージの使用量が減少します。
まとめると、スケッチには次のような主な特性があります。
- 特定の指標の近似集計を表す
- コンパクトである
- メモリ内、劣線形データ構造のシリアル化された形式
- 通常は固定サイズであり、入力よりも漸近的に小さくなる
- 統計誤差を生じ、その程度は制度レベルで決定できる
- 他のスケッチの結合で、基になるデータセットの結合を近似できる
スケッチの結合による再集計
スケッチにより、データを保存して結合することで、効率的な再集計が可能になります。このため、スケッチは、データセットのマテリアライズド ビューに特に役立ちます。スケッチを結合することにより、各ストリームに対して作成された部分的なスケッチを使用して複数のデータ ストリームの概要を作成できます。
たとえば、毎日個別ユーザーの推定数のスケッチを作成する場合、日ごとのスケッチを結合することで、過去 7 日間の個別ユーザーの数が得られます。結合した日ごとのスケッチを再集計すれば、データセットの全入力を読み取る必要はありません。
スケッチの再集計は、オンライン分析処理（OLAP）でも有用です。スケッチを結合して、OLAP キューブのロールアップを作成できます。ここで、スケッチには、キューブの 1 つ以上の特定のディメンションについてデータが要約されます。OLAP ロールアップは、実際の個別数では実現できません。
スケッチの統合
スケッチを他のシステムと統合できます。たとえば、Dataflow や Apache Spark などの外部アプリケーションで作成したスケッチを、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++ 関数をご覧ください。
近似集計関数
スケッチベースの近似における特定の HLL++、D3A、KLL 関数の代わりに、GoogleSQL では事前定義された近似集計関数が用意されています。これらの近似集計関数は、個別カウント、変位数、トップカウントなどの一般的な評価用のスケッチをサポートしていますが、カスタム精度は使用できません。また、他の種類のスケッチのように再集計するために公開されたり保存されたりすることはありません。近似集計関数は、詳細な構成を行わずに簡単なスケッチベースのクエリを実行するために設計されています。
スケッチベースの近似で使用できる近似集計関数の一覧については、近似集計関数をご覧ください。