Pre-computing technology + Hologres acquisition traffic analysis product practice

1、事前計算と Hologres の関係

クエリアクセラレーションチームとして、低コストで高性能な包括的クエリアクセラレーションエンジンを構築し、A+ トラフィック分析、ビジネスアドバイザー、Huang Jince、Youmeng、FBI/QBI などのプロダクトにおける大量データインタラクティブ分析をサポートすることが私たちのビジョンだ。コストが制御可能な範囲内では、AQP や FastMap 事前計算などの技術を活用して大量データのクエリパフォーマンスを大幅に向上させ、応答時間を秒単位またはミリ秒単位に短縮する。

上図の最上部にあるデータプロダクト層は、A+ トラフィック収集分析プラットフォーム、Huang Jince (アリババグループ内の精细化されたユーザー層向け内部運用プラットフォーム)、Circle People (ユーザー層特性分析)、ビジネスアドバイザー (事業者や店舗の商用データ向け分析プロダクト)、FBI/QBI (アリババグループ内の BI プロダクトおよびクラウド BI プロダクト)、Youmeng データ分析プラットフォームなどのプラットフォームをサポートしている。中間層はアクセラレーション層で、その下のストレージとコンピューティングは Hologres によって実装されている。

上層の事前計算は OLAP オンライン分析処理だ。エンジンによると、OLAP は大まかに二つのカテゴリに分類できる。関係モデル — データ冗長性や前処理メカニズムがなく、Spark や Presto などの大規模データ分析に適している。多次元モデル — ディメンションとメトリックに基づいてキューボイドモデルを事前に構築してアクセラレーションを実現し、データ量が大きく高性能が求められる OLAP シナリオに適している。

ダブル 11 (独身の日) に最も売上高の高い商品を検索する従来の方法は次のとおりだ。まず、ダブル 11 のデータを抽出する。次に、データに基づいて商品を集約する。10 億件のデータがある場合、10 億件に基づいて集約する必要がある。クエリ時間はデータ量に対して線形に増加する。

もし売上高を時間と商品のディメンションで事前計算できれば、クエリはデータ量に依存しなくなる。事前計算の核心は、クエリ時間がデータ量に比例して増加するという法則を打破することだ。

事前計算の結果データには、保存と計算のためのキャリアが必要だ。事前計算自体は依然としてデータモデルのディメンションに基づいているためだ。Hologres はデータベースのディメンションとして、主にデータ分散、データストレージ方式、インデックス、クエリ実行計画を担当する。

事前計算と Hologres は異なるディメンションでの最適化であり、互いに衝突しない。事前計算にも強力な演算・ストレージキャリアが必要で、その自然な Cube モデルは Hologres 上でさらに大きな役割を発揮する。

クエリアクセラレーションプラットフォームの観点から、Hologres を選定した理由は次の三つだ。

第一に、オペレーター能力。事前計算では大量のデータがビットマップに変換されるため、強力なビットマップエンジンが必要だ。また、ビットマップだけでは変換サイクルのファネル分析や金額頻度の高いカーディナリティシナリオなどすべての問題を解決できないが、Hologres はこれに対して専門的な解決策を提供する。

第二に、統一クエリ。分析プラットフォームにはセルフサービス分析だけでなく、ミリ秒レベルの応答を必要とするダッシュボードなどの高 QPS シナリオもある。単一のアーキテクチャで異なる分析シナリオを実現したいと考えている。

第三に、コストベースの統合アーキテクチャ。Hologres はホットストレージ、コールドストレージ、外部テーブルなどのソリューションを提供し、企業のコスト削減と効率化を支援する。

2、A+ トラフィック分析の紹介

A+ トラフィック分析プラットフォームはアリババグループの統一グローバルトラフィック分析プラットフォームだ。ページ、スモールサイトキャンペーン、アプリをエントリーポイントとして、トラッキング収集と計算により、ピット効果、カテゴリ転換、トランザクションパス分析、ユーザーセグメンテーションなどのマクロ概要データを構築する。トラフィックデータ分析のループを確立し、ビジネスにおけるトラフィックの問題発見とトラフィックコンバージョンの改善を支援することに注力している。

たとえば、左下のアプリページのトラフィックを分析する場合、PV、UV、平均滞在時間、直接誘導インターフェース、フル誘導 PV 指標などを確認できる。

事前計算モデルとより良く統合するため、指標を事前計算の計測形式に変換する。たとえば、UV は重複排除、平均滞在時間は平均値計算、直接誘導インターフェースは四則演算に相当する。

トラフィック分析分野の需要に対して生成された分析モデルは、イベント分析、リテンション分析、ファネル分析、コンバージョン分析、パス分析だ。

イベント分析はトラフィック分析・ソリューション分野で最も重要かつ広範な分析手法だ。核心はイベントを中心に多次元分析を行うことだ。イベントとはユーザーが製品の使用時にトリガーする一連の動作を指し、原理的には閲覧、クリック、露出などいくつかのカテゴリに分類できる。アリババグループは 4 セグメント SPM モデルを使用して、ユーザーがイベントをトリガーしたサイト、ページ、ブロック、位置を一意に特定する。

イベントレポートインターフェースも比較的シンプルで、イベントを閲覧したユーザー数、ユーザー UV のグループ分け、ブランド、時間次元などを表示する。事前計算と組み合わせるため、指標を事前計算モデルに対応させる。ユーザー数は重複排除ユーザー数に、ページと時間は GROUP BY に、ブランドフィルタリングはディメンションフィルタリングにそれぞれ対応する。

リテンションは本質的に初期動作と後続動作を持つ。インターフェース上の分析エンティティはログインユーザーまたはデバイスだ。リテンションを定義する際は二つの動作を定義し、時間に基づいて計算する。事前計算の場合、ログインユーザーは重複排除指標に対応し、フィルタリングディメンションは異なる動作の集約ディメンションに対応する。

3、主要ビジネスにおける Hologres ソリューション

現在、1 日あたり 1 テラバイト未満のデータレベルに対応可能で、分析粒度は週、日、月単位でのクエリが可能だ。この背景において、主な問題は次のとおりだ。第一にパフォーマンスの問題。重複排除指標の計算に平均数分を要し、ユーザーエクスペリエンスが低下している。第二にデータ誤差の問題。顧客が求めるデータ精度を達成できない。

イベント分析は条件内のユーザー ID のカーディナリティを計算し、リテンションは二つの動作セットのカーディナリティを計算する。二つのセットの共通部分とカーディナリティ計算は、データ構造のビットマップと自然に関連付けられる。ビットマップの 0 と 1 はそれぞれ対象者の存在と非存在に対応する。また、ビットマップは 0 と 1 で構成されるシーケンスであり、特定条件を持つ人のグループを表現できる。

したがって、ビットマップの高性能計算を活用して問題を解決できる。しかし、依然として二つの課題がある。第一に、元のビットマップは 1 ビットのみだが、10 億人の人がいる場合、データ量は依然として大きい。第二に、ビットマップを使用して計算するには、ストレージも必要だ。

そこで、Hologres Roaring Bitmap を導入した。Roaring Bitmap は圧縮機能を持つ特殊な構造のビットマップと理解できる。Hologres Roaring Bitmap は分散型の Roaring Bitmap 実装だ。

ストレージ面では、Hologres は Roaring Bitmap データ型を実装している。テーブル作成時に bigint 型、varchar 型、bitmap 型を作成できる。ビットマップレベルの交差、マージ、差集合演算はシングルノードで実装されている。さらに、Hologres は分散ビットマップ実行計画のセットを実装しているため、高性能なビットマップ演算エンジンも備えている。

上図に示すように、異なるディメンションは色で区別されているが、同じ色内のディメンションは一貫している。たとえば、黄色は 9 月 1 日に AB ページを閲覧した人を表し、緑色は 9 月 2 日に AC ページの露出を受けた人を表す。この構造をビットマップに変換するにはどうすればよいか。

まず、ユーザー ID にビットマップ内で一意の添字を持たせる。たとえば、1001 は 0、1004 は 4 となる。結果として得られるビットマップ構造を下図に示す。同じディメンションは自然に集約される。緑色は 9 月 2 日に AC ページの露出を受けた人を表す。

上図は Hologres Roaring Bitmap に基づくアーキテクチャを示している。

左側はクラウド上の DataWorks で、スケジューリングを担当し、クエリアクセラレーションエンジンシステムに毎日スケジュールされる。メタデータはエンジン内に保存される。MaxCompute は業務データをビットマップデータに変換して Hologres にインポートする役割を担う。Hologres 配下の Pangu ストレージにより極めて高速なインポート性能を実現している。Hologres は MPP 構造を採用しており、ビットマップ自体に基づいてグループ化する必要があり、特定のセグメント内で自動インクリメントを維持する。これはつまり、グループ内の人数が常に固定であることを意味する。

上図の右側はストレージの論理ビューで、異なるグループが同じディメンションを持っている。

9 月 1 日のすべての UV 値をクエリする場合を考える。まず、ビジネス層が SQL を Hologres フロントエンドノードに送信して実行計画を生成する。Hologres はグループごとにセグメント化されているため、グループは並列処理される。9 月 1 日には 2 つのデータがあり、まず Hologres のインデックスが使用される。2 つのデータにインデックスを適用した後、rb_or_agg を実行してビットマップの OR 演算を行い、次に rb_cardinality 関数を呼び出して最初のグループのカーディナリティを計算する。第 6 グループも同様だ。すべてのグループが並列処理され、マージするのは bigint 値のみで、非常に高速だ。

リテンション計算ロジックは、ステップを 1 つ追加するだけでよい。第 2 データにリテンション計算を渡す必要があるからだ。まず JOIN を行い、次に rb_and_cardinality 演算を実行する。パラメータは 2 つのビットマップだ。最後にカウントを計算する。

改善後のクエリでは、数十テラバイトレベルの UV 指標のセルフサービス分析が平均わずか 5 秒で完了する。

ユーザーの囲い込みも Hologres Roaring Bitmap の応用シナリオだ。本質的にはビットマップ間の交差、マージ、差集合だが、結果は単一の数値ではなくビットマップとなる。Hologres は SQL をサポートしているため、ビットマップの INSERT と SELECT が可能で、計算後に自然に Hologres 内でユーザーを囲い込める。後続のポートレート分析も本質的にはビットマップだ。

分析シナリオの QPS は高くないが、ビジネスアドバイザーのシナリオでは、シンプルなマージと差集合という要件がある。分析は必要だが KV にはできない。そこで、非ビットマップグループ化を巧みに活用し、業務データのグループ化と Hologres を組み合わせて、シンプルな分析シナリオで 1,000 以上の QPS を達成した。

Hologres はリアルタイムでビットマップを生成する機能を提供し、パーツリストを Hologres にインポートできる。クエリ時にビットマップをリアルタイムで生成し、クロスマージとオフセット演算を実行する。

統一クエリの構築は、主に以下のシナリオに由来する。

第一に、アクセラレーター非使用および事前計算テーブルの例外ライブラリ。事前計算は顧客の問題を 100% 解決できるわけではなく、痛点のみを解決する。したがって、非常に高速な OLAP エンジンによるサポートも必要だ。

第二に、事前計算とワイドテーブルは Hologres のパフォーマンスを最大限に引き出せる。ワイドテーブルは OLAP エンジンに直接配置される。上層のクエリが非常に自由な場合、分散とインデックスを決定できない。事前計算された自然なキューボイドはテーブル分割形式になり、Hologres と組み合わせてさらに高いパフォーマンスを生み出す。

第三に、分析シナリオにはセルフサービス分析、ダッシュボード分析、高 QPS および高性能シナリオだけでなく、Hologres も含まれる。

第四に、事前計算のカテゴリ問題。リアルタイム更新シナリオ。たとえば、ディメンションテーブルをリアルタイムで更新する必要があり、元のディメンションテーブルをインポートできない場合、クロスデータベースの問題が発生する可能性があるため、単一のデータベース内にある必要がある。

上図は左から右へのデータ生産プロセスを示している。左側が元のテーブルで、中間プラットフォームはモデルキューボイドディメンションだ。テーブルのディメンションは都市、イベント、ページ、日付だ。PV を検索する必要がある場合、キューボイドは 2 の n 乗になる。キューボイドが生成された後、Hologres の論理構造に集約される。1 つのキューボイドが 1 つのテーブルに対応し、自然に分離されている。

キューボイドは自然にディメンションを削減する。分散時には、共通のクエリを分散キーとして使用できる。この層がクエリの完全な分散を決定する。第二段階は Hologres のセグメントキーフィールドの使用で、通常は日付付きの時系列フィールドだ。日付はシャード内のファイルの高速検索を決定する。次にクラスターキーを高頻度フィルターインデックスに設定してブロックを高速に検索する。最後に、非高頻度フィルターをビットマップ列を介して設定し、ビットマップインデックスを使用して各ブロック内のデータを高速に検索する。

上記のクエリの事前計算セルフサービス分析プラットフォームでの平均 RT は 1 秒未満で、KV インデックス RT は約 10 ミリ秒であり、数百万の QPS をサポートできる。

コストは企業が注目するポイントだ。クエリアクセラレーションプラットフォームとして、最下層の詳細テーブル、サブテーブル、サンプリングテーブルなど、多くの種類のテーブルを維持している。業務システムは自らサブテーブルを作成するが、BI 製品などの汎用プロダクトはビジネスのサブテーブル作成を支援しない。テーブル作成も OLAP クエリアクセラレーション分野の要件であり、準リアルタイム計算によるサンプリングが行われる場合がある。

複数テーブルのクエリタイプとサービス寿命は異なり、コストと密接に関連している。Hologres はホットストレージ、コールドストレージ、外部テーブルなどのストレージメディアを提供し、パフォーマンスは順に低下し、コストは順に増加する。実際のビジネステーブルの分析要件と時間周期のクエリ要件に応じて自由に選択できる。

Q&A

Q：ビットマップグループが 5 億人のグループで、第一グループの人々が閲覧し、第二グループの人々が事前に支払っている場合、二つのグループの人々はどう対応するか。

A：ビットマップストレージのビット位置はテーブルディメンションとは関係がない。たとえば、第 6 グループの 5 番目の人は常に 5 番目の人だ。

Q：コールドデータは MaxCompute に Hologres の形式で保存されるか。

A：いいえ。コールドデータと外部テーブルの違いは、外部テーブルが外部ストレージ (MC 内のストレージなど) であるのに対し、コールドデータは Hologres 自体のもので、OSS を介して実装されているだけだ。

Q：ホットデータとコールドデータはどう使用されるか。

A：直接使用する。コールドストレージデータは Hologres によって管理されるが、Hologres 内の OSS に保存される。ホットストレージには SSD が使用される。ストレージ形式は依然として Hologres 独自の内部形式で、インデックス付きだ。使用方法としては、ポリシーを設定できるパーティションテーブルがある。7 日間または 14 日間の保持期間を指定できる。14 日を超えるすべてのデータパーティションはコールドストレージにまとめて転送される。

Q：Hologres でパーティションテーブルを作成することを推奨するのはどのような場合か。

A：事前計算シナリオではパーティションテーブルは不要だ。事前計算を実装していない場合、小規模なデータ量ではパーティションを作成することを推奨しない。小規模パーティションが増えるとフラグメントとファイルが増加するためだ。また、パーティションデータの定期的な日次クエリや日次データ置換などのシナリオではパーティションの作成を推奨する。一般的に、1 億件を超える場合はパーティションの作成を推奨する。