クラウドネイティブビッグデータアーキテクチャにおけるリアルタイムコンピューティングディメンションテーブルと結果テーブルの選択と実践

[[424013]]

1. はじめに

従来のビッグデータテクノロジーは、Google の GFS、MapReduce、Bigtable の 3 つと、そこから派生したオープンソースの分散ファイルシステム HDFS、分散コンピューティングエンジン MapReduce、分散データベース HBase から生まれました。初期のビッグデータ技術と需要は、超大規模データストレージ、データ処理、オンラインクエリなどに集中することが多かった。この段階では、多くの企業が Hadoop を導入するために独自のコンピュータルームを構築することを選択するだろう。ビッグデータ技術と需要は、オフラインコンピューティングと大規模ストレージに集中しています。一般的な例としては、T+1 レポート、大規模データのオンラインクエリなどがあります。

インターネット技術の急速な発展、データ規模の拡大、複雑な需要シナリオの出現により、従来のビッグデータアーキテクチャでは対応できなくなっています。近年のビッグデータアーキテクチャの進化は、主に次の側面に反映されています。

1. 規模: ここでの規模は、主にビッグデータ技術の利用規模とデータサイズの増加に反映されます。ビッグデータ技術の利用の増加は、ますます複雑な要求の出現を意味しており、データ規模の拡大により、従来の準ビッグデータ技術 (MySQL など) ではすべての問題を解決できないことが判明しています。したがって、ストレージコンポーネントを例にとると、通常、それらは異なるデータレイヤーに分割され、さまざまなニーズを満たすために、スケール、コスト、クエリ、分析パフォーマンスなどのさまざまな次元で最適化の偏りが生じます。

2. リアルタイム: 従来の T+1 オフラインビッグデータテクノロジーでは、推奨と監視のほぼリアルタイムの要件を満たすことができません。ビッグデータのエコシステムと技術アーキテクチャ全体は、過去 10 年間で大幅にアップグレードされました。ストレージに関しては、従来の HDFS ファイルストレージや Hive データウェアハウスでは低コストと更新可能性のニーズを満たすことができないため、Hudi などのデータソリューションが登場しました。コンピューティングの観点から見ると、従来の MapReduce バッチ処理機能では、データを数秒で処理することはできません。 Storm の比較的原始的なリアルタイム処理と Spark Streaming のマイクロバッチ処理が相次いで登場しました。現在、データフローモデルに基づく Flink のリアルタイムコンピューティングフレームワークは、リアルタイムコンピューティング分野で絶対的な支配的地位を占めています。

3. クラウドネイティブ: 従来の企業では、独自のコンピュータールームを構築するか、クラウド上でマシンを購入して、クラウドホスト形式でインスタンスを展開することを選択することがよくあります。しかし、このアーキテクチャには、オフピーク時の使用率が低い、ストレージとコンピューティングの統合によりストレージとコンピューティングの弾力性が低い、アップグレードの柔軟性が低いなど、さまざまな問題があります。クラウドネイティブのビッグデータアーキテクチャは、いわゆるデータレイクです。その本質は、クラウド上の弾力性のあるリソースを最大限に活用して、統合管理、統合ストレージ、弾力性のあるコンピューティングを備えたビッグデータアーキテクチャを実装することです。これは、物理クラスターとローカルディスクに基づく従来のビッグデータアーキテクチャのコンピューティングおよびストレージアーキテクチャを変換します。主な技術的特徴は、ストレージとコンピューティングの分離とサーバーレスです。クラウドネイティブのビッグデータアーキテクチャでは、ストレージサービス、コンピューティングサービス、メタデータ管理サービスなど、アーキテクチャの各レイヤーがサービス指向の開発に向けて進化しています。各コンポーネントは、独立して拡張できる異なるユニットに分割する必要があり、これにより、よりオープンで柔軟性と回復力が向上します。

この記事では、クラウドネイティブビッグデータアーキテクチャのシナリオに基づいて、リアルタイムコンピューティングにおけるディメンションテーブルと結果テーブルのアーキテクチャ選択について詳しく説明します。

2. ビッグデータアーキテクチャにおけるリアルタイムコンピューティング

1. リアルタイムコンピューティングのシナリオ

ビッグデータは10年以上にわたって急速に発展しており、コンピューティング規模からよりリアルタイムなトレンドへと進化しています。最も一般的なリアルタイムコンピューティングのシナリオは次のとおりです。

リアルタイムデータウェアハウス: リアルタイムデータウェアハウスは、Web サイトの PV/UV 統計、トランザクションデータ統計、製品販売統計など、さまざまなトランザクションデータシナリオで主に使用されます。このシナリオでは、リアルタイムコンピューティングタスクがリアルタイムのビジネスデータソースをサブスクライブし、数秒以内に情報をリアルタイムで分析し、最終的に意思決定者が使用できるようにビジネス画面に提示することで、ビジネスの運営状況やイベントのプロモーション状況を判断しやすくなります。
リアルタイム推奨: リアルタイム推奨は主に AI テクノロジーに基づいており、ユーザーの好みに基づいてパーソナライズされた推奨を提供します。これは、短いビデオのシナリオ、コンテンツ情報のシナリオ、電子商取引のショッピングのシナリオなどでよく見られます。このシナリオでは、ユーザーの好みを過去のクリック履歴に基づいてリアルタイムで判断できるため、ターゲットを絞った推奨を行ってユーザーの粘着性を高めることができます。
データ ETL: リアルタイム ETL シナリオは、データ同期タスクでは一般的です。たとえば、データベース内のさまざまなテーブルの同期と変換、さまざまなデータベースの同期、データ集約の前処理、そして最終的にアーカイブと沈殿のために結果をデータウェアハウスまたはデータレイクに書き込むことなどです。このシナリオは主に、その後の詳細なビジネス分析の準備に使用されます。
リアルタイム診断: これは金融または取引のビジネスシナリオでは一般的です。これらのシナリオでは、業界の特殊性により、リアルタイムの短期的な行動に基づいてユーザーが不正行為者であるかどうかを判断し、タイムリーに損失を停止するための不正防止監視が必要です。このシナリオでは、タイムリーさに対する要件が非常に高くなります。リアルタイムのコンピューティングタスクを通じて異常なデータを検出し、リアルタイムで異常を発見し、タイムリーに損失を阻止します。

2. Flink SQL リアルタイムコンピューティング

リアルタイムコンピューティングには、バックグラウンドで非常に強力なビッグデータコンピューティング機能が必要です。 Apache Flink は、オープンソースのビッグデータリアルタイムコンピューティングテクノロジーとして誕生しました。 Hadoop や Spark などの従来のコンピューティングエンジンは本質的にバッチコンピューティングエンジンであるため、限られたデータセットを処理するだけでは処理の適時性を保証することはできません。 Apache Flink は当初からストリーミングコンピューティングエンジンとして設計されました。リアルタイムのストリーミングデータをサブスクライブし、データをリアルタイムで分析および処理して結果を生成することで、データがすぐに価値を発揮できるようにします。

Flink は宣言型言語である SQL をトップレベル API として使用しており、これはユーザーにとって便利であり、クラウドネイティブのビッグデータアーキテクチャのトレンドに沿っています。

ビッグデータの汎用化と大規模生産: Flink SQL は、クエリステートメントに応じて自動的に最適化し、最適な物理実行プランを生成し、ビッグデータコンピューティングの複雑さを遮断し、ユーザーの敷居を大幅に下げてビッグデータの汎用化の効果を実現します。
ストリームとバッチの統合: Flink SQL には、ストリームとバッチの統合機能があります。ストリームタスクでもバッチタスクでも、ユーザーに同じセマンティクスと統合された開発エクスペリエンスが提供されるため、オフラインのビジネスタスクをリアルタイムタスクに変換しやすくなります。
基盤となるストレージの違いを遮断: Flink は、SQL 統合クエリ言語を提供することで基盤となるデータストレージの違いを遮断し、多様なビッグデータストレージ間でのビジネスの柔軟な切り替えを容易にし、クラウド上のビッグデータアーキテクチャをよりオープンかつ柔軟に調整します。

上の図は、Flink SQL の基本的な操作の一部を示しています。 SQL 構文は標準 SQL と非常によく似ていることがわかります。例には基本的な SELECT および FILTER 操作が含まれます。組み込み関数（日付の書式設定など）を使用することも、カスタム関数を登録して使用することもできます。

Flink SQL は、リアルタイムコンピューティングをソーステーブル、結果テーブル、ディメンションテーブルの 3 つのタイプに分割します。これら 3 つのテーブルの DDL ステートメント (CREATE TABLE など) は、さまざまな入力および出力データソースを登録し、リアルタイムコンピューティングタスクのトポロジ関係を SQL DML (INSERT INTO など) を通じて表現することで、SQL を通じてリアルタイムコンピューティングタスクの開発を完了するという効果を実現します。

ソーステーブル: 主に、Kafka、MQ (メッセージキュー)、CDC (変更データキャプチャ、MySQL バイナリログをリアルタイムストリームに変換するなど) 入力などのメッセージシステムの入力を表します。
結果テーブル: 主に、MySQL、HBase、その他のデータベースなど、Flink がリアルタイムで処理された各データを書き込むターゲットストレージを表します。
ディメンションテーブル: 主にデータディメンション情報を格納するためのデータソースを表します。リアルタイムコンピューティングでは、データ収集側で収集されるデータは限られていることが多いため、データ分析を行う前に、まず必要なディメンション情報を完成させる必要があります。ディメンションテーブルは、データディメンション情報の格納を表すデータソースです。一般的なユーザーディメンションテーブルには、MySQL、Redis などがあります。

次の図は、完全なリアルタイムコンピューティングの例です。この例の Flink SQL タスクは、さまざまな製品カテゴリの GMV (総売上高) を 1 分ごとに計算することを目的としています。このタスクでは、Flink はユーザー注文データの Kafka ソーステーブルをリアルタイムで消費し、Redis ディメンションテーブルを通じて製品 ID を製品カテゴリに関連付け、1 分間のローリングウィンドウに従って製品カテゴリ別の合計トランザクション金額を計算し、最終結果を RDS (MySQL などのリレーショナルデータベースサービス) 結果テーブルに書き込みます。

 # ソース テーブル - タイムスタンプの価格で製品 (item_id) を購入したユーザー (user_id) を表すユーザー注文データ。
一時テーブルuser_action_sourceを作成します（
  `timestamp` BIGINT、
  `user_id` BIGINT、
  `item_id` BIGINT、
  `price` DOUBLE、SQs
 ） と （
 'コネクタ' = 'kafka' 、
 'トピック' = '<トピック>' 、
 'properties.bootstrap.servers' = 'your_kafka_server:9092' 、
 'properties.group.id' = '<あなたの消費者グループ>'
 'フォーマット' = 'json' 、
 'scan.startup.mode' = '最新オフセット'
 );
 # ディメンションテーブル - アイテムの詳細
一時テーブルitem_detail_dimを作成します（
  id 文字列、
  カタログSTRING、
  主キー (id) は強制されません
） と （
 'コネクタ' = 'redis' 、
 'host' = '<your_redis_host>' 、
 'port' = '<your_redis_port>' 、
 'password' = '<your_redis_password>' 、
 'dbNum' = '<あなたのデータベース番号>'
 );
 # 結果表 - 時間（分）とカテゴリ別のGMV出力
一時テーブルgmv_outputを作成します（
   time_minute 文字列、
   カタログSTRING、
   gmv ダブル、
   主キー (time_minute, カテゴリ)
 ） と （
   タイプ = 'rds' 、
   url= '<データベースのあるjdbc_mysql_url>' ,
   tableName= '<テーブル名>' ,
   userName= '<mysql_database_username>' ,
   パスワード = '<mysql_database_password>'
 );
 ＃ プロセス
gmv_outputに挿入
選択
  TUMBLE_START(s.timestamp, INTERVAL '1' MINUTES) をtime_minuteとして、
  d.カテゴリー、
  SUM(d.price) を総取引額として
から
  ユーザーアクションソース
  SYSTEM_TIME AS OF PROCTIME() の item_detail_dim を d として結合します。
    オン s.item_id = d.id
 GROUP BY TUMBLE(s.timestamp、INTERVAL '1' MINUTES)、d.category;

これは非常に一般的なリアルタイムコンピューティング処理リンクです。次の章では、リアルタイムコンピューティングにおけるディメンションテーブルと結果テーブルの主要な機能を分析し、それぞれのアーキテクチャの選択について説明します。

3. ディメンションテーブルのリアルタイム計算

1. 主な要件

データウェアハウスの構築では、テーブルの関係または構造は通常、スターモデルとスノーフレークモデルを中心に設計されます。リアルタイムコンピューティングも例外ではありません。一般的な要件は、データストリーム内のフィールドを完了することです。データ収集側で収集されるデータは限られていることが多いため、データ分析を実行する前に必要な次元情報を入力する必要があります。例えば、収集したトランザクションログには商品IDのみが記録されていますが、業務を行う際には店舗ディメンションや業種ディメンションに応じて集計する必要があります。これには、まずトランザクションログを製品ディメンションテーブルに関連付けて、必要なディメンション情報を完成させる必要があります。ここで言及するディメンションテーブルは、データウェアハウスの概念に似ており、製品ディメンション、ユーザーレベル、場所ディメンションなどのディメンション属性の集合です。

ユーザーディメンション情報のデータストレージとして、リアルタイムコンピューティングシナリオでの大量の低遅延アクセスに対応する必要があります。この位置付けに基づいて、構造化ビッグデータストレージのいくつかの重要な要件をまとめます。

（１）高スループットと低遅延の読み取り能力

まず第一に、オープンソースエンジン Flink 自体のディメンションテーブルの最適化を考慮することなく、ディメンションテーブルは、リアルタイムコンピューティングシナリオで大量の (数万 QPS) データアクセスを処理でき、また、非常に低いレイテンシ (ミリ秒) でクエリデータを返すことができる必要があります。

（２）コンピューティングエンジンとの高い統合能力

ディメンションテーブル自体の機能に加えて、コンピューティングエンジン自体にも、パフォーマンス、安定性、コストを考慮してトラフィックオフロード機能が備わっていることがよくあります。場合によっては、リクエストごとにダウンストリームディメンションテーブルにアクセスする必要はありません。たとえば、Flink は、ディメンションテーブルシナリオでの非同期 IO やキャッシュ戦略などの最適化機能をサポートしています。優れたディメンションテーブルは、オープンソースコンピューティングエンジンと緊密に接続されている必要があります。一方で、コンピューティング層のパフォーマンスを向上させることができ、他方では、一部のトラフィックを効果的にオフロードし、ディメンションテーブルが過度のアクセスによって圧倒されないようにし、ディメンションテーブルのコンピューティングコストを削減することができます。

（３）軽量ストレージにおける計算能力の弾力性

ディメンションテーブルは通常、ディメンション属性などのメタデータ情報を格納する共有テーブルです。アクセス規模は大きいことが多いのですが、ストレージ規模はそれほど大きくないことが多いです。ディメンションテーブルへのアクセスの規模は、リアルタイムデータストリーム内のデータ量に大きく依存します。例えば、リアルタイムストリームのデータ規模が数十倍に増加すると、ディメンションテーブルへのアクセス回数が大幅に増加します。別の例として、ディメンションテーブルにアクセスするために複数のリアルタイムコンピューティングタスクが追加されると、ディメンションテーブルに対するクエリの負荷が急激に増加します。このようなシナリオでは、ストレージサイズが大幅に増加することはあまりありません。

したがって、コンピューティングはオンデマンドかつ弾力的に実行するのが最適です。リアルタイムコンピューティングタスクを追加または削除したり、アクセストラフィックを増加させたりしても、アクセスパフォーマンスには影響しません。同時に、コンピューティングとストレージは分離する必要があり、アクセスコンピューティング量の急増によってストレージコストが増加することがないようにする必要があります。

2. アーキテクチャの選択

マイグレーション

ビッグデータとリアルタイムコンピューティング技術の黎明期、インターネットの初期のころには、迅速なサイト開発のために LAMP (Linux + Apache + MySQL + PHP) アーキテクチャが広く普及していました。そのため、MySQL にはすでにビジネス履歴データが存在するため、リアルタイムコンピューティングのディメンションテーブルの初期選択では、ディメンションテーブルとして MySQL が広く使用されています。

ビッグデータアーキテクチャの更新に伴い、MySQL クラウドアーキテクチャも継続的に改善されていますが、ディメンションテーブルのアプリケーションシナリオでは、次の問題が依然として存在します。

ストレージ側の拡張は柔軟性が低く、拡張コストが高くなります。ストレージ側での MySQL 拡張にはデータのレプリケーションと移行が必要であり、拡張サイクルが長く、柔軟性が低くなります。同時に、MySQL のシャードデータベースとテーブルを拡張するたびに 2 倍のリソースが必要になり、拡張コストが比較的高くなります。
高いストレージコスト: リレーショナルデータベースは、構造化データストレージの単位コストが最も高いストレージシステムであるため、ビッグデータのシナリオでは、リレーショナルデータベースのストレージコストが比較的高くなります。

上記の制限により、MySQL はビッグデータディメンションテーブルシナリオでパフォーマンスのボトルネックが発生し、コストも比較的高くなります。しかし、全体として、MySQL は非常に優れたデータベース製品です。データ規模がそれほど大きくないシナリオでは、MySQL は間違いなく良い選択です。

レディス

クラウドアプリケーションアーキテクチャでは、MySQL は増大するビジネス負荷に耐えられないため、MySQL がクエリトラフィックの大部分に耐えられるように、MySQL のクエリ結果セットキャッシュとして Redis がよく使用されます。

このアーキテクチャでは、MySQL がプライマリストレージサーバーとして使用され、Redis がセカンダリストレージとして使用されます。 MySQL から Redis への同期は、binlog リアルタイム同期または MySQL UDF + トリガーを通じて実現できます。このアーキテクチャでは、Redis をキャッシュに使用して、MySQL がヒットするリスクを軽減しながらクエリパフォーマンスを向上させることができます。

Redis にはユーザーデータの弱一貫性コピーがキャッシュされるため、Redis はリアルタイムコンピューティングのディメンションテーブルとしてよく使用されます。ディメンションテーブルとしての MySQL と比較すると、Redis には次のような独自の利点があります。

非常に高いクエリパフォーマンス: データは高速でメモリにキャッシュされ、結果データは高速な Key-Value 形式でクエリできるため、ディメンションテーブルの高パフォーマンスクエリの要件に非常に適合しています。
ストレージ層拡張の柔軟性が高い: Redis は、シャードクラスターを簡単に拡張し、水平拡張を実行し、データの複数のコピーの永続性をサポートできます。

Redis には優れた利点がありますが、無視できない欠点もあります。Redis には優れた拡張ソリューションがありますが、キャッシュされたデータはメモリに保存されるため、コストがかかります。ビジネスデータのディメンション属性が大きい場合 (ユーザーディメンション、製品ディメンションなど)、ディメンションテーブルストレージとして Redis を使用するとコストが非常に高くなります。

テーブルストア

Tablestore は、Alibaba Cloud が開発した構造化ビッグデータストレージ製品です。詳しい商品紹介については公式サイトや公式ガイドをご参照ください。ビッグデータディメンションテーブルのシナリオでは、Tablestore には次のような独自の利点があります。

高スループットアクセス: Tablestore はストレージとコンピューティングを分離したアーキテクチャを採用しており、コンピューティングリソースを弾力的に拡張し、高スループットでのデータクエリをサポートできます。
低レイテンシのクエリ: Tablestore は LSM ストレージエンジンに従って実装されており、クエリを高速化するためにブロックキャッシュをサポートしています。ユーザーは、豊富なインデックスを構成することでビジネスクエリを最適化することもできます。
低コストのストレージと柔軟なコンピューティングコスト: ストレージコストの点では、Tablestore は構造化 NoSQL ストレージタイプに属し、データストレージコストはリレーショナルデータベースやキャッシュよりもはるかに低くなります。コンピューティングコストの面では、Tablestore は、オンデマンドでコンピューティングリソースを弾力的に拡張できるストレージコンピューティングアーキテクチャを採用しています。
Flink ディメンションテーブル最適化との高度な統合: Tablestore は、非同期 IO やさまざまなキャッシュ戦略を含む、Flink ディメンションテーブル最適化のすべての戦略をサポートします。

ソリューションの比較

上記は、さまざまなディメンションにおける上記のいくつかのディメンションテーブルソリューションの比較です。次に、コストを詳細に比較するために、いくつかの具体的なシナリオを示します。

1. 大容量ストレージと大容量コンピューティング: ディメンションテーブルには 100 億オーダーのディメンションデータを保存する必要があり、総ストレージ容量は 1T 必要です。ビジネスでは Flink タスク側でキャッシュ戦略を構成していますが、ディメンションテーブルにシンクされる高 KV クエリが依然として存在します。ディメンションテーブルへのピーク QPS は 100,000 で、平均は 25,000 です。さまざまなディメンションテーブルの構成要件と購入コストは次のとおりです。

2. ストレージ容量とコンピューティング容量が少ない: ディメンションテーブルには 100 万個の地域ディメンションデータを保存する必要があり、合計ストレージ容量には 10M が必要です。ビジネスエンドでは、トラフィックの大部分に耐えられるように、Flink タスクのディメンションテーブルに対して LRU キャッシュ戦略を構成します。ディメンションテーブルの QPS のピークは 1000 で、平均は 250 です。さまざまなディメンションテーブルの構成要件と購入コストは次のとおりです。

3. 高いストレージ容量と低いコンピューティング: ディメンションテーブルには 100 億のオーダーディメンションデータを保存する必要があり、合計ストレージ容量には 1T が必要です。ビジネスエンドでは、トラフィックの大部分に耐えられるように、Flink タスクのディメンションテーブルで LRU キャッシュ戦略を構成します。ディメンションテーブルの QPS のピークは 1000 で、平均は 250 です。さまざまなディメンションテーブルの構成要件と購入コストは次のとおりです。

4. 少ないストレージと高いコンピューティング能力: インメモリデータベースである Redis は、超高頻度データ KV クエリ機能を備えています。わずか 4 つのコアと 8G のメモリを備えた Redis クラスターは、160,000 QPS の同時アクセスをサポートでき、推定コストは月額 1,600 元です。ストレージ容量が少なく、コンピューティング能力が高いシナリオでは、コスト面で明らかな利点があります。

上記のコスト比較レポートから、次のことがわかります。

1) ストレージとコンピューティングの弾力性の欠如とリレーショナルデータベース固有の欠点により、MySQL はさまざまなストレージとコンピューティングの規模でコストが高くなります。

2) インメモリデータベースとして、Redis は、ストレージ容量が少ない (約 128G 未満) 場合やコンピューティング負荷が高いシナリオでは、明確なコスト上の利点があります。ただし、メモリストレージはコストが高く、弾力性に欠けるため、データ規模が大きくなるにつれてコストは指数関数的に増加します。

3) Tablestore はクラウドネイティブアーキテクチャに基づいており、ボリュームに基づいてストレージとコンピューティングを柔軟に管理できるため、データストレージとアクセスの規模が小さい場合にコストを削減できます。

4) NoSQL データベースである Tablestore は、ストレージコストが非常に低く、大容量ストレージ (128G 以上) のシナリオでは明らかなコスト上の利点があります。

4. リアルタイム計算結果表

1. 需要分析

リアルタイムコンピューティングが完了した後のデータインポート用のストレージシステムとして、結果テーブルは主にリレーショナルデータベース、検索エンジン、構造化ビッグデータオフラインストレージ、構造化ビッグデータオンラインストレージに分けられます。具体的な違いは次の表にまとめられています。

これらのデータ製品は、それぞれのシナリオで独自の利点があり、その起源も異なります。調査を容易にするために、問題領域を絞り込み、リアルタイムコンピューティングシナリオでより優れた結果テーブルストレージが果たすべき役割のみを考慮します。

前述のリアルタイムコンピューティングの主なシナリオの中で、リアルタイムデータウェアハウス、リアルタイム推奨、リアルタイム監視の 3 つのシナリオで結果テーブルの選択を考慮する必要があります。一つずつ分析してみましょう。

リアルタイムデータウェアハウス: リアルタイムデータウェアハウスは、Web サイトのリアルタイム PV/UV 統計やトランザクションデータ統計などのリアルタイム分析シナリオで主に使用されます。リアルタイム分析 (OLAP) シナリオは、事前集計、検索エンジン、MPP (超並列処理) の 3 つの OLAP モデルに分かれています。事前集計モデルの場合、Flink コンピューティングレイヤーを介してデータを集計して結果テーブルに書き込むことも、結果テーブル自体の事前集計機能を介してデータ全体を結果テーブルに書き込んで保存することもできます。この形式では、結果テーブルデータのクエリおよび分析機能のサポートが大きく依存されます。検索エンジンモデルの場合、すべてのデータは結果テーブルに書き込まれ、検索エンジンの転置インデックスと列ストレージ機能を通じてデータ分析が実行されます。この形式では、結果テーブルに高スループットのデータ書き込み機能と大規模なデータ保存機能が必要です。 MPP モデルはコンピューティングエンジンです。列ベースのストレージにアクセスすると、分析クエリ機能をより有効に活用できます。リアルタイム OLAP ストレージおよびコンピューティングエンジンは数多くあります。完全なデータシステムアーキテクチャでは、複数のストレージコンポーネントが共存する必要があります。また、クエリおよび分析機能のさまざまな要件に応じて、必要に応じてデータ導出機能を他のタイプのストレージに拡張する必要があります。また、リアルタイムデータウェアハウスのビジネス規模が拡大するにつれ、ストレージ容量も大幅に増加します。比較すると、データクエリなどのコンピューティング規模の変化は、一般的に特に顕著ではありません。したがって、結果テーブルでは、リソースコストを大幅に制御するために、ストレージコストとコンピューティングコストを分離する必要があります。
リアルタイム推奨: リアルタイム推奨は、主にユーザーの好みに基づいたパーソナライズされた推奨に基づいています。ユーザー製品のパーソナライズされた推奨の一般的なシナリオでは、ユーザー特性を構造化ビッグデータストレージ（HBase など）に書き込み、それをディメンションテーブルとして別のユーザーのクリック消費行動データと関連付け、ユーザー特性と行動の関連付け入力を推奨アルゴリズムの入力として抽出するのが一般的です。ここでのストレージは、結果テーブルとして高スループットのデータ書き込み機能を提供する必要があり、また、ディメンションテーブルとして高スループットかつ低レイテンシのデータオンラインクエリ機能も提供する必要があります。
リアルタイム監視: アプリケーションのリアルタイム監視は、適時性に対する要件が非常に高い金融または取引のビジネスシナリオでは一般的です。異常なデータを検出することで、異常な状況をリアルタイムに発見し、ストップロスアクションを取ることができます。このシナリオでは、しきい値で判断する場合でも、異常検出アルゴリズムを使用する場合でも、リアルタイムで低遅延のデータ集約およびクエリ機能が必要です。

2. 主な機能

上記の需要分析を通じて、リアルタイムビッグデータ結果テーブルのいくつかの主要な機能をまとめることができます。

1. 大規模データストレージ

結果テーブルストレージは、集中型の大規模ストレージとして位置付けられます。オンラインデータベースの要約として、またはリアルタイムコンピューティング (またはオフライン) の入出力として、PB レベルのデータストレージをサポートできる必要があります。

2. 豊富なデータクエリと集計分析機能

結果テーブルには、豊富なデータクエリおよび集計分析機能が必要であり、効率的なオンラインクエリをサポートするように最適化する必要があります。一般的なクエリの最適化には、キャッシュ、高同時実行性と低レイテンシのランダムクエリ、任意のフィールド条件の組み合わせによる複雑なクエリ、およびデータ取得が含まれます。クエリ最適化の技術的な手段はキャッシュとインデックス作成であり、その中でインデックスのサポートは多様化しており、さまざまなクエリシナリオにさまざまなタイプのインデックスを提供します。たとえば、固定組み合わせクエリ用の B+ ツリーベースのセカンダリインデックス、地理的位置クエリ用の R ツリーまたは BKD ツリーベースの空間インデックス、または複数条件組み合わせクエリとフルテキスト検索用の逆インデックスなどです。

3. 高スループット書き込み機能

リアルタイム計算用のデータテーブルは、ビッグデータコンピューティングエンジンからの膨大な結果データセットのエクスポートに耐えられる必要があります。そのため、高スループットのデータ書き込みをサポートできる必要があり、通常は書き込みに最適化されたストレージエンジンが使用されます。

4. データ導出機能

完全なデータシステムアーキテクチャでは、複数のストレージコンポーネントが共存する必要があります。また、クエリおよび分析機能のさまざまな要件に応じて、データ派生システムの下でストレージを動的に拡張する必要があります。そのため、ビッグデータストレージでは、データ処理能力を拡張するためにストレージを拡張できる派生的な機能も必要です。ストレージコンポーネントのデータ導出機能が優れているかどうかは、成熟した CDC テクノロジを備えているかどうかによって決まります。

5. クラウドネイティブアーキテクチャ: ストレージとコンピューティングコストの分離

クラウドネイティブのビッグデータアーキテクチャでは、ストレージサービス、コンピューティングサービス、メタデータ管理サービスなど、アーキテクチャの各レイヤーがサービス指向の開発に向けて進化しています。各コンポーネントを異なる単位に分割する必要があり、結果テーブルも例外ではありません。独立して拡張でき、よりオープンで、柔軟性と弾力性を備えた能力が必要です。

結果表だけから判断すると、クラウドネイティブアーキテクチャに準拠したコンポーネント、つまりストレージとコンピューティングの分離アーキテクチャに基づいて実装された製品だけが、ストレージとコンピューティングのコストを分離し、独立して拡張できます。ストレージとコンピューティングを分離することの利点は、ビッグデータシステムではさらに明らかになります。簡単な例を挙げると、構造化ビッグデータストレージのストレージ容量はデータが蓄積されるにつれて増加しますが、書き込まれるデータの量は比較的安定しています。そのため、ストレージは継続的に拡張する必要がありますが、データの書き込みや一時的なデータ分析をサポートするために必要なコンピューティングリソースは比較的固定されており、オンデマンドです。

3. アーキテクチャの選択

マイグレーション

ディメンションテーブルと同様に、MySQL はビッグデータとリアルタイムコンピューティングテクノロジの黎明期における汎用ストレージシステムでした。ほぼすべての要件は MySQL を通じて満たすことができたため、その適用範囲は非常に広く、結果テーブルも例外ではありませんでした。データ規模が拡大し続け、需要シナリオがますます複雑になるにつれて、MySQL の取り扱いは少し難しくなります。結果テーブルのシナリオでは、主に次の問題が存在します。

1. ビッグデータの保存コストが高い: これは、ディメンションテーブルに関する以前の説明でも触れました。リレーショナルデータベースの単位ストレージコストは非常に高くなります。

2. 単一のストレージシステムではクエリ機能が制限されます。データのサイズが大きくなるにつれて、MySQL の読み取りおよび書き込みパフォーマンスの不十分さが徐々に明らかになります。さらに、分析 AP の需要が高まるにつれて、TP シナリオに適した MySQL のクエリ機能は比較的制限されます。

3. 高スループットデータ書き込み能力が低い：TP 型リレーショナルデータベースであるため、高スループットデータ書き込みは特に得意ではありません。

4. スケーラビリティが低く、拡張コストが高い: これは、ディメンションテーブルに関する以前の説明で説明しました。 MySQL のストレージ側での拡張には、データの複製と移行が必要となり、2 倍のリソースが必要になります。そのため、拡張の柔軟性が低く、コストが比較的高くなります。

上記の制限により、MySQL はビッグデータ結果テーブルのシナリオでパフォーマンスのボトルネックが発生し、コストが比較的高くなります。ただし、リレーショナルデータベースであるため、ビッグデータの結果テーブルとして使用するには特に適していません。

HBase

リレーショナルデータベースの自然なボトルネックにより、BigTable コンセプトに基づく分散 NoSQL 構造化データベースが誕生しました。現在、オープンソースコミュニティで最もよく知られている構造化ビッグデータストレージは Cassandra と HBase です。 Cassandraはワイドカラム型NoSQLカテゴリーのトップ1製品であり、海外でも広く利用されています。この記事では、国内における HBase の幅広い応用に焦点を当てます。 HBase は、HDFS のストレージとコンピューティングの分離アーキテクチャに基づく WideColumn モデルデータベースです。非常に優れたスケーラビリティを備えており、大規模なデータストレージをサポートできます。その利点は次のとおりです。

1.大規模なデータの大規模なストレージとハイスループットライティングのサポート：LSMに基づくストレージエンジンは、大規模なデータストレージをサポートし、ライティングに最適化され、ハイスループットデータライティングを提供します。

2。ストレージとコンピューティングの分離アーキテクチャ：基礎となる層は、HDFに基づいています。分離されたアーキテクチャは、必要に応じてストレージとコンピューティングを拡大することができます。

3.開発者のエコシステムは成熟しており、他のオープンソースのエコシステムとよく統合されています。長年にわたって開発されてきたオープンソース製品として、中国には多くのアプリケーションがあり、開発者コミュニティは非常に成熟しており、HadoopやSparkなどの他のオープンソースのエコシステムとよく統合されています。

HBaseには優れた利点がありますが、無視できないいくつかの大きな欠陥もあります。

1.弱いクエリ機能とデータ分析のサポートはほとんどありません：効率的なシングルローのランダムクエリと範囲スキャンを提供します。複雑なコンビネーション条件クエリは、スキャン +フィルターメソッドを使用する必要があります。注意しないと、完全なテーブルスキャンが発生しますが、これは非常に非効率的です。 HBaseのPhoenixは、クエリを最適化するためのセカンダリインデックスを提供します。ただし、MySQLのセカンダリインデックスと同様に、左端の一致するクエリ条件のみを最適化でき、最適化できるクエリ条件は非常に限られています。

2.弱いデータ派生能力：前の章で述べたように、CDCテクノロジーはデータ派生システムをサポートするコアテクノロジーですが、HBaseにはCDCテクノロジーがありません。

3。非クラウドネイティブサーバーレスサービスモデル、高コスト：前述のように、構造化されたビッグデータストレージの重要な要件の1つは、ストレージとコンピューティングコストの分離です。 HBaseのコストは、コンピューティングに必要なCPUコアの数のコストとディスクのストレージコストに依存します。固定比率の物理リソースに基づく展開モデルでは、CPUとストレージの間には常に削減できない最小比があります。つまり、ストレージスペースが増加するにつれて、必要な実際のコンピューティングリソースに基づいてコストを計算する代わりに、CPUコアコストもそれに応じて増加します。したがって、クラウドネイティブサーバーレスサービスモデルのみが、ストレージとコンピューティングコストの完全な分離を実現できます。

4。複雑な操作とメンテナンス：HBaseは標準のHadoopコンポーネントです。そのコア依存関係は、ZookeeperとHDFSです。専門的な運用とメンテナンスチームなしでは、運営および維持することはほとんど不可能です。

中国の上級者のほとんどは、HBaseに基づいて二次開発を行います。基本的に、彼らはHBaseの弱いクエリ機能を補うためにさまざまなソリューションに取り組んでいます。彼らは、自己開発のセカンダリインデックスソリューション、フルテキストインデックスのためのSOLRに接続する、または低い差別化などのデータセットなどのビットマップインデックスソリューションなど、独自のビジネスクエリ特性に従って独自のインデックスソリューションを開発します。

hbase + elasticsearch

HBaseの弱いクエリ機能の問題を解決するために、多くの国内企業はElasticsearchを使用して、HBase + Elasticsearchソリューションに従ってデータの検索をスピードアップし、アーキテクチャを実装しています。 HBaseはビッグデータストレージと履歴コールドデータクエリに使用され、Elasticsearchはデータの取得に使用されます。 HBaseにはCDCテクノロジーがないため、ビジネスアプリケーションレイヤーはHBaseとElasticSearchをデュアルワイトするか、HBaseをElasticSearchに同期するためのデータ同期タスクを開始する必要があります。

このソリューションは、ElasticSearchを介したHBaseの弱いクエリ機能を大幅に補うことができます。ただし、HBaseとElasticsearch自体の能力がないため、次の問題が発生します。

1.開発コストとより複雑な操作とメンテナンス：顧客は、HBaseからElasticSearchまでの少なくとも2つのクラスターと完全なデータ同期を維持する必要があります。 HBaseとElasticsearchの一貫性を確保する場合は、上記のアプリケーションレイヤーマルチライターメソッドを使用する必要があります。これは分離されたアーキテクチャではなく、拡張するのがより複雑です。さらに、全体的なアーキテクチャは比較的複雑で、多くのモジュールやテクノロジーが関与しており、運用とメンテナンスコストも高くなっています。

2。高コスト：顧客は2つのクラスターを購入し、HBaseとElasticsearchの間でデータの同期を維持する必要があります。これにより、リソースコストが高くなります。

3.まだデータの導出機能はありません：このアーキテクチャでは、データはそれぞれHBaseとElasticsearchにそれぞれ書き込まれますが、HBaseもElasticsearchもCDCテクノロジーを備えておらず、データを他のシステムに柔軟に導出することはできません。

TableStore

TableStoreは、Alibaba Cloudによって開発された構造化されたビッグデータストレージ製品です。詳細な製品の紹介については、公式ウェブサイトと権威あるガイドを参照してください。 TableStoreの設計概念は、データシステム内の構造化されたビッグデータストレージの需要を主に考慮し、派生データシステムの設計概念に基づいていくつかの特別な機能を設計および実装しています。以下は、TableStoreの技術的概念を簡単に要約しています。

1。ハイスループットライティングの大規模なデータストレージとサポート：LSMとB+ツリーは、2つの主流のストレージエンジンの実装です。 TableStoreはLSMに基づいており、大規模なデータストレージをサポートしており、ハイスループットデータライティングに最適化されています。

2。多様なインデックスを介してリッチクエリ機能を提供する：LSMエンジンの特性は、クエリ機能の欠点を決定し、クエリを最適化するためにインデックスが必要です。さまざまなクエリシナリオにはさまざまなタイプのインデックスが必要なため、TableStoreはさまざまなタイプのシナリオでのデータクエリ要件を満たすために多様なインデックスを提供します。

3. CDCテクノロジーをサポートし、データ派生機能を提供する機能：TableStoreのCDCテクノロジーはトンネルサービスと呼ばれます。トンネルサービスは、フルおよびインクリメンタルなリアルタイムデータサブスクリプションをサポートし、Flink Stream Computing Engineにシームレスに接続して、テーブルデータのリアルタイムストリームコンピューティングを実装できます。

4。ストレージとコンピューティングの分離アーキテクチャ：ストレージとコンピューティングの分離アーキテクチャが採用されており、基礎となる層は、ストレージとコンピューティングコスト分離を達成するための基礎であるFeitian Pangus分散ファイルシステムに基づいています。

5。クラウドネイティブアーキテクチャ、サーバーレス製品フォーム、およびメンテナンスフリー：クラウドネイティブアーキテクチャの最も重要な要因は、ストレージとコンピューティングの分離とサーバーレスサービスです。ストレージとコンピューティングの分離とサーバーレスサービスのみが、統一された管理、統一されたストレージ、弾性コンピューティングを備えたクラウドネイティブアーキテクチャを実現できます。サーバーレス製品であるため、ビジネス側はTableStoreを展開および維持する必要はありません。これにより、ユーザーの操作とメンテナンスコストが大幅に削減されます。

ソリューション比較

たとえば、結果テーブルは、合計ストレージ容量が1Tで、数千億の電子商取引注文データを保存する必要があります。ユーザーは、このタイプのデータをクエリして柔軟に分析する必要があります。毎日の注文クエリとデータ検索の頻度は1秒あたり1,000回で、データ分析は1分あたり約10回クエリされます。

以下は、さまざまなアーキテクチャの要件を満たすために必要な構成と、Alibaba Cloudでの購入コストです。

V. 結論

この記事では、クラウドネイティブビッグデータアーキテクチャのリアルタイムコンピューティングディメンションテーブルと結果テーブルのアーキテクチャデザインと選択について説明します。その中で、Alibaba Cloud Tablestoreには、これらのシナリオにいくつかの特別な機能があります。この記事が私たちにより深い理解を与えることができることを願っています。

<<: パブリッククラウドを導入する前に慎重に検討する必要がある理由

>>: 2021年中国産業インターネット会議が間もなく開幕します。誰を観るべきでしょうか？