Best practice of real-time update based on EMR StarRocks

Mobvista

グローバルテクノロジープラットフォームとして、Mobvista はデジタル時代におけるビジネスの成長促進に取り組んでいます。2013 年に中国広州で設立され、2018 年 12 月に香港証券取引所のメインマーケットに上場しました。Mobvista は、グローバルな顧客、特に中国の海外展開企業に対し、モバイルインターネットエコシステムの発展に必要な広告技術サービスおよびマーケティング技術サービスの提供に注力しています。ワンストップ SaaS プロダクトマトリックスにより、モバイルアプリケーション開発者は簡単かつ迅速、効率的にフルリンクのマーケティング活動を実現し、グローバル市場での成長を達成できます。

EMR StarRocks リアルタイムデータ更新

Alibaba Cloud E-MapReduce (EMR) は年初に StarRocks サービスをリリースしました（ https://help.aliyun.com/document_detail/405463.html ）。StarRocks は次世代の超高速フルシーン MPP（超並列処理）データプラットフォームであり、超高速かつ統一された分析体験の構築に注力しています。EMR StarRocks には以下の特徴があります。

・MySQL プロトコルに互換性があり、MySQL クライアントや一般的な BI ツールを使用して StarRocks に接続し、データを分析できます

・分散アーキテクチャ：

・データテーブルを水平方向に分割し、複数レプリカで保存

・クラスターサイズを柔軟にスケールでき、10 PB のデータ分析をサポート

・MPP フレームワークをサポートし、並列計算を高速化

・複数レプリカによる弾力的なフォールトトレランスをサポート

・ベクトル化エンジンと CBO をサポート

・弾力的なスケーリングをサポート

・詳細モデル、集計モデル、プライマリキーモデル、更新モデルをサポート。プライマリキーモデルはプライマリキーに基づいて効率的な Upsert または Delete 操作を実行できます。ストレージとインデックスの最適化により、同時更新中でも効率的なクエリ最適化を実現します。

次に、StarRocks がどのように効率的なリアルタイムデータ更新を実現するかについて説明します。

StarRocks プライマリキーモデルによるリアルタイム分析

さまざまな分野で、分析はデータプラットフォームの中心となっています。データインフラ技術の急速な発展に伴い、ユーザーのリアルタイム分析に対するニーズも高まっています。ユーザーはもはや振り返り分析だけでは満足せず、リアルタイム分析を活用して現在のビジネスに影響を与える実行可能なインサイトを模索し始めています。リアルタイム分析には新鮮なデータが基盤として必要です。ユーザーは、リアルタイムダッシュボードシステムやモニタリングシステムなどのアプリケーションを数秒で更新でき、かつデータサイズを PB 以上に拡張できる OLAP ソリューションを求めています。

StarRocks ユーザーのリアルタイムホットデータ分析能力に対するニーズの高まりと、トランザクション処理（TP）データベーステーブルを StarRocks に同期させる需要の拡大により、StarRocks はリアルタイムデータ更新（更新/削除）をサポートする必要があります。

プライマリキーモデルが登場する以前、StarRocks ユーザーは更新モデル（一意キー）に依存してリアルタイムデータ更新を実現していました。

StarRocks 更新モデル

StarRocks がプライマリキーモデルをサポートする以前は、更新モデル（一意キー）によりリアルタイムデータ更新操作を実行できました。更新モデルは本質的にマージオンリード方式です。データインポート時、更新モデルはデータをソートし、重複キーチェックなしで直接新しいファイルに書き込みます。読み取り時に、キー値を比較して複数バージョンをマージし、最新バージョンのデータのみを返します。マージオンリードの更新モードはデータの書き込みが非常に高速です。ただし、読み取り時に複数バージョンをマージする必要があるため、読み取りパフォーマンスは低く不安定で、ビットマップなどのインデックスを使用してさらに高速化することはできません。

StarRocks プライマリキーモデル

更新モデルとは異なり、StarRocks のプライマリキーモデルは delete+insert モードに基づいて実装されています。

更新モデルの読み取り時の増幅問題を解決するため、StarRocks プライマリキーモデルはプライマリキーインデックスを導入しています。データインポート時、各データについてプライマリキーモデルはプライマリキーインデックスを通じて元のレコードの位置を特定します。レコードが見つかったら、Delete Bitmap でそのレコードに削除マークを付けるだけで、そのレコードは削除済みとなります。その後、すべての更新レコードは新しいブロックに新規データとして挿入されます。これにより、読み取り時にすべてのブロックを並列でロードでき、Delete Bitmap のタグに基づいて削除済みレコードをフィルタリングするだけで済みます。

データインポート時に完全なデータ更新（削除＋挿入）が行われ、各データの最新状態のみが保持されます。プライマリキーモデルでは、クエリ時に複数バージョンをマージする必要がないため、インポート中でもクエリパフォーマンスは基本的に影響を受けません。

クエリパフォーマンスの優位性だけでなく、プライマリキーモデルには他にも多くの特徴があります。

・Upsert、Delete、部分更新操作を完全にサポート

・リアルタイム更新中もクエリパフォーマンスに影響なし

・クエリパフォーマンスは詳細モデル以下にならない

・メモリ消費量が低く、プライマリキーインデックスの永続化をサポート

プライマリキーモデルのまとめ

マテリアルプラットフォームの概要

Mobvista には豊富なプロダクトラインがあります。XMP は海外メディア向け統一広告運用 SaaS ツール、CAS はマーケティングクリエイティブ分析システム、ADS は国内メディア向け統一広告運用 SaaS ツール、Gatlin は広告素材の一括制作 SaaS ツール、Topon はグローバル広告集約プラットフォームです。これらのプロダクトラインはいずれも広告素材を取り扱っています。統一管理を実現するため、マテリアルプラットフォーム Creative Service を構築し、素材の管理、保存、検索、共有を一元化することが提案されました。

Creative Service は 5 つのデータソース（ADS、XMP、CAS、Gatlin、Topon）からデータを取得します。データは構造化データと非構造化データに分類されます。広告素材の音声、動画、画像は非構造化データとしてオブジェクトストレージに保存されます。これらの非構造化データのメタデータは構造化データとして OLAP データウェアハウスに取り込まれ、下流のリアルタイム運用業務に利用されます。これにより、リアルタイムのデータ駆動型広告戦略調整が可能となり、コンバージョン率の向上につながります。

マテリアルプラットフォームのビジネス特徴は以下の通りです。

・データソースが複雑で、5 つ以上のデータソースからデータを取得

・リアルタイム運用には秒レベルのデータ新鮮さが必要

・大量のデータを保有し、構造化データは 50 億件以上

・データディメンションが多く、データウェアハウスのテーブルフィールドは 80 以上

OLAP の選定

マテリアルプラットフォームが OLAP エンジンに求める要件は以下の通りです。

・クエリ速度：マテリアルプラットフォームの OLAP レイヤーは、下流のビジネス担当者（プロダクトマネージャーなど）がアドホッククエリを実行するために使用され、クエリ返却の適時性に対する要件が高い（秒レベル/サブ秒レベル）。従来の OLAP エンジンでは、クエリに通常数分以上かかり、分析効率が大幅に低下します。

・統一性：クエリシステムが統一されていない場合、オフラインとオンラインで異なるクエリエンジンが併存し、ビジネス担当者の学習コストが増加します。複数システムが併存するもう一つの問題はデータの島が生じることです。システム間でのデータ関連付けが困難になります。

・リアルタイムデータ更新：リアルタイム運用（リアルタイム広告戦略の調整など）には秒レベルのデータ新鮮さが必要であり、これが下流の広告戦略の有効性を決定します。OLAP データウェアハウスのストレージエンジンには、効率的かつ頻繁なデータインポートおよび更新操作のサポートが求められます。

これらの要件に基づき、StarRocks と ApsaraDB for ClickHouse エンジンを主に比較しました。比較は主に以下の観点から行いました。

調査の結果、StarRocks のリアルタイム分析シナリオでのネイティブサポートと、より効率的なクエリパフォーマンス（特にマルチテーブル）が、マテリアルプラットフォームのビジネスシナリオをより良くサポートできると判断し、StarRocks を使用してマテリアルプラットフォームの構造化データ向け OLAP 分析プラットフォームを構築することにしました。

StarRocks リアルタイム分析の実践

全体のアーキテクチャは以下の通りです。

・コアストレージレイヤー：コアストレージコンポーネントで、Creative Service のメタデータおよび StarRocks データウェアハウスを保存

・ApsaraMQ for Kafka：一括更新リクエストのキャッシュ、ピークシェービングと負荷平準化に使用

・Java スレッド：Kafka データを消費し、コアストレージコンポーネントである StarRocks にデータを更新

・OSS：マテリアルファイルの保存に使用

StarRocks プライマリキーモデルによるリアルタイム分析の実現

マテリアルプラットフォームは StarRocks のプライマリキーモデルをビジネスデータ保存モデルとして選択し、モデル選定時に更新モデル（一意キー）との比較を行いました。

プライマリキーモデルは、プライマリキーインデックスによる delete+insert 更新方式を使用し、インポート時にマルチバージョンのマージ操作を効率的に完了します。更新モデル（マージオンリード）と比較して、プライマリキーモデルはクエリ時に集計操作を行う必要がなく、述語およびインデックスのプッシュダウンをサポートします。リアルタイムかつ頻繁な更新などのシナリオをサポートしながら、効率的なクエリを提供できます。

以下の図は、インポート中およびインポート後のプライマリキーモデルと更新モデルのクエリパフォーマンス比較を示しています。テスト結果から、継続的にデータをインポートするシナリオでは、更新方式の違いにより、プライマリキーモデルがクエリパフォーマンスで更新モデルに対し 3 〜 15 倍の優位性を持つことがわかります。

プライマリキーモデルの使用にあたり、ビジネスシナリオの要件に合わせて、以下の 2 つのプライマリキーモデル機能に注目しました。

・Partial Update によるビジネス部門でのカラム更新ニーズへの対応

・プライマリキー永続インデックスによるプライマリキーモデルのメモリ使用量の削減

リアルタイム部分カラム更新インポート

StarRocks プライマリキーモデルは、データインポート時の部分カラム更新をサポートしています。インポート時、プライマリキーカラムを指定する前提で、更新が必要な少数のカラムのみを提供すれば、プライマリキーモデルは自動的にプライマリキーインデックスを使用して残りのカラムを効率的に補完し、更新操作を完了します。上流でのデータ結合操作は不要で、より柔軟な更新シナリオをサポートします。

OLAP レイヤーでの集計データソースは複雑で、5 つの異なるデータソース（ADS、XMP、CAS、Gatlin、Topon）から取得する必要があります。典型的な分析シナリオでは、広告素材自体の情報（サイズ、ソースなど）と広告素材の効果（コンバージョン、クリック、インプレッションなど）が必要です。これらの指標は 5 つのデータソースに分散しており、これらを効率的に結合してリアルタイムデータ分析を行う方法が必要でした。

5 つの異なるデータソースは同じ一意のプライマリキー（広告素材の一意識別コード）を持ち、データ量が大きく、下流のアドホッククエリは結果の返却遅延に対して高い要件があるため、事前ワイドニングによりデータをワイドテーブルに保存することにしました。

更新時、OLAP レイヤーは一度に 1 つのデータソースから数カラムのデータしか取得できません。プライマリキーモデルの部分カラム更新機能を使用して、このような更新操作を完了します。インポート時、既存のカラムとプライマリキーカラムのみを入力すれば、不要な操作なしで数カラムのデータをテーブルに更新でき、上流でのデータ再検索やマルチストリームマージなどの複雑で高コストな操作を回避できます。

現在、プライマリキーモデルのカラム更新機能は、複数テーブルからのリアルタイムインポートで数億件のレコードをサポートしています。典型的なテーブルには約 10 カラムあり、毎回 2 〜 3 カラムを更新し、更新頻度は約 10 秒です。

プライマリキー永続インデックス

初期段階で StarRocks プライマリキーモデルをテストした際、まずプライマリキーインデックスを純粋にメモリ内で維持する方式（persistent_index=off）を選択しました。データインポート時、純粋メモリで維持されるプライマリキーインデックスはメモリ内でインデックスを構築する必要があり、大量のメモリを消費します。さらに、テスト中のデータ量が膨大で、プロセス中にメモリ不足が頻発しました。

StarRocks のプライマリキーインデックスはディスクを通じて永続化でき、データインポート時にディスクから直接インデックスファイルを読み取れます。テスト結果によると、純粋メモリのプライマリキーインデックスと比較して、インポートパフォーマンスを大きく損なうことなく、メモリ使用量を 90% 以上削減できました。

プライマリキーモデルの永続インデックスを有効化した後、テスト環境と本番環境でのプライマリキーインデックスに起因するメモリ不足問題を完全に解決できました。

今後の計画

今後、マテリアルプラットフォームは StarRocks の新機能に基づき、サービス能力をさらに向上させていきます。具体的な計画は以下の通りです。

・マテリアルプラットフォームの分析機能を強化し、広告マーケティングをさらに支援

・システムおよびデータモニタリングアラームの改善

・プライマリキーモデルが Conditional Update をサポートした後、データインポートのための Routine Load を検討

・プライマリキーモデルがソートキー指定後のパフォーマンス継続的最適化をサポート