本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
この記事は、ユーザープロファイルのビジネス特性から出発し、なぜ大データ向けのストレージソリューションとしての Lindormがユーザープロファイルに適しているのかについて包括的かつ多角的な分析を提供します。これにより、読者が類似のニーズに直面した際には迂回を避けて、適切なストレージ選択を直接行えるよう支援することを目的とします。
-
背景
従来のショッピングモールでは、販売スタッフが顧客の表情や行動を観察し、彼らの好みに応じて対応し、マーケティング目標達成と収益最大化を図っていました。インターネット時代になると、店舗はオンラインに移り、買い手と売り手は仮想世界で接するようになりました。相手が男性か女性か、魅力的かどうか、普通のオフィスワーカーか裕福な個人かは不明ですが、そのような情報は得難いです。インターネットの仮想性から、顔見せや行動観察の問題を技術的な手段で解決することが求められます。幸いにも、特にモバイルインターネットの時代において、ユーザーは常時、場所を問わず自分の言葉や行動の痕跡をオンライン上に残しています。これらのデータを声にしていくことがますます重要になっています。そのために、ユーザープロファイリングが登場し、ターゲットマーケティング、推薦システム、広告、リスク管理、インテリジェントカスタマーサービスなど多くの分野で広く活用されています。それでは、ユーザープロファイルデータとその適用シナリオにはどのような特徴があり、これらの特徴に基づいてどのようなデータストレージを選択すべきでしょうか？ -
ユーザープロファイルデータの特徴
アーキテクチャ図からわかるように、システムは一般にデータ収集システム、オンラインクエリシステム、オフライン解析システム、そしてデータストレージシステムの四つの部分を含んでいます。データが収集されると、データストレージシステムに書き込まれ、同時にデータはオフラインシステムにアーカイブされます。オフラインシステムは定期的にデータを学習し、新しいユーザー・プロファイルを作成し、これら新しいプロフィールはオンラインシステムに戻されて、上位層のビジネスクエリに利用されます。オンラインシステムは詳細データと過去のプロフィールの両方を持っています。
ユーザープロファイルデータの範囲の定義とビジネスシーンでの応用に基づいて、ユーザープロファイルデータの課題は何でしょうか？
- 大量のデータ: インターネットアプリケーションの特徴として、数百万人から数十億人に及ぶ大量のユーザーが存在する。このような膨大なユーザー基盤が、大量の行動データ生成につながります。また、いくつかの製品は外部データのスクレイピングを行うことでデータの次元を豊かにする必要があります。豊富な詳細データに基づいてオフラインでモデル学習を行い、最終的なユーザー・プロファイルを生成する際、それは通常数十から数千、数万乃至数十万の項目を持つ数十億規模の高次元データになります。
- 高い読み書き并发性: 大量のユーザーが生み出す大量のデータはリアルタイムでバックエンドストレージシステムに書き込まれるため、データ書き込みの并发性は数万から数十万、数百万乃至それ以上に達することがあります。同時に、ユーザープロファイルデータのオンライン適用シーン、例えば推薦や広告は配信効果の向上や運営プロモーション意欲の増強に伴い増加し、クエリ数やそれらのクエリの并发性も高まります。
- 詳細データのアーカイブ必要性: 後ろのストレージに書かれたユーザー行動の詳細やその他の基本データは、ほぼリアルタイムでオフラインシステムにアーカイブされる必要があります。
- 大量データのフィードバック: オフラインシステムにアーカイブされたデータを解析して新たなプロファイルデータを生成し、オンラインシステムに戻す必要があります。
- 动的カラム要件: ユーザープロファイルデータの次元は常に変化し、豊かになり続けるため、テーブル構造も常に進化しています。
- 多様で複雑なクエリタイプ: 異なるビジネスニーズによって、ユーザープロファイルデータに対するクエリ要件も多様化します。例えば、キーに基づく単一レコードクエリ、ユーザーIDによるユーザーベースのバッチ取得、または特定次元に基づく統計データの要望によるオペレーションスタッフによるクエリなどがあります。
これらのユーザープロファイルデータの課題を踏まえ、プロファイルデータが強いトランザクション要件を持っていないことを考えると、どのようなストレージソリューションが適しているでしょうか？
- 大データシーン向けのLindorm
ユーザープロファイリングが強いトランザクション要件を持っておらず、大量のデータと高い読み書き并发性がある場合、関係型データベースは適していないでしょう。そこで、LindormというNoSQLデータベース製品をおすすめします。Lindormは大データシーン向けに開発され、アリババ内で約10年間開発され続け、急速なアップデートと技術的な進化を遂げています。現在、アリババ生態系内のビジネスを支えるコアデータベース製品の一つとなっています。長年にわたり、大規模な構造化データのストレージと処理に関する内部需要によって駆動され、Lindormは機能性、パフォーマンス、安定性において大規模な実践検証を経験しており、アリババグループ、アントグループ、菜鳥ネットワーク、アリババ・デジタルメディア&エンターテイメントなどアリババグループ内様々な事業部門で広く採用されており、アリババ内で最大のデータ量と最も広いビジネスカバー率を誇るデータベース製品となっています。Lindormストレージに基づくユーザープロファイリングのアーキテクチャは次の図で示されます：
3.1 コスト効率性
大データは5Vの特徴を持ち、その中でもボリュームが最も重要です。そのため、大データシーン向けのデータストレージソリューションは高い密度とコスト効率を備えなければならないでしょう。Lindormは大データ時代に生まれたNoSQLデータベースであり、大量のデータを効率的に低コストで保存・検索できる能力を備えています。Lindormのコスト効率性は以下のように示されます：
- 多様なストレージタイプのサポート
性能ストレージ：高いパフォーマンスに最適化。標準ストレージ：パフォーマンスとコストのバランスを取ったストレージ。容量ストレージ：低コストで大容量を重視し、アクセス頻度の低いデータに適しています。ビジネスシーンに合ったストレージタイプは必ず見つかります。 - 深い圧縮最適化
最もコスト効率の高いストレージシステムは、ストレージを必要としないシステムですが、これは現実的ではありません。実現可能な解決策は、保存する必要のあるデータ量を最小限に抑えることです。ストレージコスト削減のために、Lindormは高速で高い圧縮率を実現する新しい無損失圧縮アルゴリズムを導入しています。このアルゴリズムはLZMAやZPAQのような最高圧縮率を目指さず、LZ4のような極端な圧縮速度も求めていません。代わりに、それをバランスさせ、圧縮速度が200MB/s、デコンプレッション速度が400MB/sを超える（ラボデータ）水準を達成しており、Lindormのスループット要件に十分に対応しています。実際のシーンでは、この新しい圧縮最適化によりLZOに比べて圧縮率が大幅に改善され、ストレージコストを50％から
3.4 バルクロード技術
関係型データベースと異なり、LindormはLSMツリーのアーキテクチャを使用しています。Lindormに格納されたレコードを読み取るには、対応するシャード（つまり、memestore）のメモリ内のデータと、そのシャードが所有する複数のLDFile内のレコードデータの最新バージョンをマージし、その後、マージ結果をクライアントに提出する必要があります。この原理に基づいて、Lindormは直接新しいLDFileを作成し、システムに挿入することで、新規データのロードを実現します。これにより、他のリレーショナルデータベースやNoSQLシステムよりも大きな利点を提供します。このデータローディングプロセスはストレージエンジン、WAL、Memstoreを完全に迂回し、必要な物理的IOとネットワークオーバーヘッドのみを伴うため、データローディングのパフォーマンスを大幅に向上させ、オンラインビジネスリクエストへの影響を最小限に抑えることができます。
3.5 動的カラム
Lindormのワイドテーブルモデルは、複数のカラムファミリー、動的カラム、TTL、複数バージョンなどの機能をサポートしており、ユーザープロファイルのようなテーブル構造が不安定で頻繁に変更が必要なユースケースに最適です。
3.6 多次元・複雑な問い合わせ
行キーに基づく単一キーの問い合わせや行キープレフィックスに基づくスキャンに関しては、Lindorm自体でビジネスニーズを十分に満たすことができます。少量の複合カラムと固定問い合わせパターンを持つ多次元問い合わせの場合でも、Lindormの組み込みの高性能グローバルセカンダリインデックス機能は、高いスループットとパフォーマンスを維持しながらビジネス要件を満たすことができます。
さらに複雑な問い合わせ、例えば曖昧検索やランダムな条件組み合わせ問い合わせに対処する場合、セカンダリインデックスの解決策が不十分になることがあります。そこで、Lindorm検索エンジンであるLSearchが登場します。LSearchは大規模なデータセット向けに設計された分散型検索エンジンであり、オープンソースのSolr標準インターフェイスと互換性があります。これにより、ワイドテーブルエンジンやタイムシリーズエンジンのためのインデックスストレージとしてシームレスに動作し、検索問い合わせを加速します。全体的なアーキテクチャはワイドテーブルエンジンと整合しており、自動データパーティショニング、パーティション複製、Luceneに基づいた構造を特徴とします。LSearchはフルテキスト検索、集計計算、複雑な多次元問い合わせをサポートし、水平方向のスケーリング、一重書き複数読み取り、クロスデータセンターのディザスタリカバリ、TTL（有効期間）を提供し、大量データに対する高効率な検索ニーズを満たします。
4. Lindormのコア機能概要
Lindormは、大量のデータ、高い并发性、リアルタイムのアーカイブ、効率的かつ安定したバッチデータローディング、動的カラム、複雑な多次元問い合わせなど、ユーザープロフィリングの要求が高いニーズを効果的に満たすために包括的で多面的な機能を提供しています。もちろん、Lindormの能力はこれらだけではありません。ビッグデータや大規模データ量の文脈においてストレージシステムが必要とする一連の機能を備えています：
- 複数モデルデータベース: ワイドテーブル、タイムシリーズ、検索、ファイルをサポート。
- 計算とストレージの分離: 計算とストレージを分けるアーキテクチャに基づき、計算とストレージの両方で極めて柔軟性とスケーラビリティを提供し、サーバーレスサービスを導入して、オンデマンドでの即座な拡張性と課金制サービスを可能にします。
- コスト効率: ホットデータとコールドデータの分離をサポートし、最適な圧縮ソリューションを追求してコスト効率を最大化します。
- 高度なインデクシングと検索: グローバルセカンダリインデックス、多次元検索、タイムシリーズインデックスなどの機能を備えています。
- LDInsightツール: 無コードインターフェイスでシステム管理、データアクセス、障害診断を実現するインテリジェントサービスツールを提供します。
- LTS (Lindorm Tunnel Service, 元々のBDS): データ交換、処理、サブスクリプションの使いやすい機能をサポートし、データ移行、リアルタイムサブスクリプション、データレイクストレージ、データウェアハウスのバックフロー、ユニット間アクティブ・アクティブ設定、バックアップ、復旧などのユーザー要件を満たします。
5. ケーススタディ
大手第三者決済会社の金融リスク管理システム
リスク管理システムは金融システムの基盤となります。この第三者決済会社が提供するリスク管理システムは業界最高水準の安全性を提供しており、損失率は1兆分の0.5にまで低く抑えられています。比較すると、世界で2番目に低い損失率は2018年に発表されたデータでは1万分の6でした。この成果の背後に、セキュリティチームによって作成された様々なモデルやルールがあります。これらのルールとモデルを実行するために必要なデータストレージサポートは、Lindormが提供しています。支払いやQRコードスキャンを行うとき、わずかな秒のうちのほんの一瞬ですが、その約100ミリ秒以内に、取引の安全性確認のためにユーザーのセキュリティプロフィールデータが取得されます。これには、支払いシーン、受取人の背景、支払い時の環境、そしてあなたの行動特性、ショッピングの好み、普段の買い物時間などが含まれ、取引にリスクがないか評価されます。リスクが識別されると、システムは取引の双方に警告を発信したり、取引を中断したりすることもあります。各取引の背後には、約百以上のリスクモデルと五百以上のリスク戦略が計算されていることになります。上述のユーザーのセキュリティプロフィールデータとは、下の図に示されたような詳細データであり、アーカイブされ、分析され、その後再びLindormに日次口座データとして取り込まれます。
このような大量のモデルとルールを1つの取引で必要とする場合、可想議以上に、ダブルイレブンの購入祭りのピーク時にはデータシステムにどのような要求がかかるか想像できます。
阿里巴巴グループ内でのベストプラクティス:
広告: 大量の広告・マーケティングデータのリアルタイムストレージ:
