XL-LightHouse 汎用ストリーミングビッグデータ統計プラットフォーム

概要

XL-LightHouse は、インターネット分野における複雑なデータ統計のニーズに合わせて開発された、統合されたデータ書き込み、データコンピューティング、データストレージ、およびデータ視覚化機能のセットであり、大容量のデータと高い同時実行性をサポートします [ユニバーサルストリーミングビッグデータ統計プラットフォーム]。
XL-LightHouse は現在、基本的に、count、sum、max、min、avg、bitcount、topN/lastN およびその他の操作を含む一般的なストリーミングデータ統計シナリオをカバーし、多次元計算をサポートし、分レベル、時間レベル、日レベルの複数時間粒度統計をサポートし、カスタム統計期間の構成をサポートします。
XL-LightHouse は豊富な変換機能を内蔵しており、式解析をサポートしているため、さまざまな複雑な条件のスクリーニングや論理的判断に対応できます。
XL-LightHouse は、ストリーミングビッグデータ統計の分野におけるフル機能のデータガバナンスソリューションです。比較的フレンドリーで完全なビジュアルクエリ機能を提供し、外部世界への API クエリインターフェイスを提供します。さらに、データインデックス管理、権限管理、統計的電流制限などの機能も含まれています。
XL-LightHouse は、時系列データのストレージとクエリをサポートしています。

バックグラウンド

インターネット業界を例にとると、現在、モバイルインターネットの発展は比較的成熟しており、トラフィックはピークに達し、配当はなくなり、企業競争はますます激化し、新規ユーザーを獲得するコストは日に日に増加しています。多くの企業は、補助金、価格競争、広告などの単純かつ粗雑な方法ではやみくもに市場を獲得することはできず、そのような経営形態を長期間維持することは困難であることに気づき始めています。洗練されたデータベースの運用を通じてコストを削減し、効率を向上させ、シングルユーザーの価値を最大化するという概念は、徐々に多くの企業に受け入れられるようになりました。洗練されたデータベースの運用の前提は、完全なデータインジケーターシステムを確立することです。このデータインジケーターシステムを利用することで、企業は次のような複数の用途に使用できます。

1. トラブルシューティング: データに基づいた運用は、企業のビジネスを「制御可能な」状態にし、ビジネスが正常に稼働していない場合に企業が問題を迅速に判断できるようにすることです。
2. ビジネスの洞察: データベースの運用により、ビジネス運営のあらゆる側面がより透明になり、企業が現在の「ショートボード」がどこにあるかをより明確に把握できるようになり、製品の最適化の繰り返しが支援されます。
3. 明確な方向性: データベースの運用は、企業が市場動向をより正確に判断し、ビジネス価値のある情報を把握できるように、鋭い嗅覚を養うことです。
4. 科学的な試行錯誤: 試行錯誤のコストがますます高くなっている今日、データベースの運用は、企業が「頭を撫でる」ことで意思決定を行う以前の方法を変更し、過去の経験主義を打ち破り、意思決定者の思考を支援し、アイデアを迅速に検証し、企業がより科学的な「試行錯誤」でコストを削減できるようにするのに役立ちます。企業がデータベースの運用にますます注目するようになると、必然的に大量のデータ統計のニーズが発生します。XL-LightHouse は、ストリーミングビッグデータ統計を多くの業界でのストリーミング統計の急速な普及と大規模な適用を促進するためのエントリポイントとしており、少ないサーバーリソースを使用する一連のサービスで数万または数十万のストリーミングデータ統計のニーズをサポートするビッグデータプラットフォームとして位置付けられています。

所得

XL-LightHouse は、企業が比較的完全で安定した信頼性の高いデータベースのオペレーションシステムをより迅速に構築し、データベースの運用に対する企業の投資を節約するのに役立ちます。これは主に次の側面に反映されます。

ビッグデータ統計のストリーミングにおける企業の研究開発コストとデータ保守コストを削減します。
企業が時間とコストを節約し、インターネット製品の迅速な反復を支援します。
企業のサーバーコンピューティングリソースを大幅に節約します。
企業内でのデータの共有と相互通信を促進します。さらに、XL-LightHouse は中小企業に優しいため、中小企業がストリーミングビッグデータ統計を使用するための技術的敷居を大幅に下げ、シンプルなページ構成とデータアクセスを通じて複雑なストリーミングデータ統計のニーズに対応できます。

建築

XL-ライトハウス XL-LightHouse には次のモジュールが含まれています。

クライアントモジュール。ビジネス側は SDK にアクセスして、レポートおよび統計的な生のメッセージデータを作成します。
RPC モジュールの機能には、クライアントによって報告された統計メッセージデータを受信し、統計結果をクエリするためのインターフェイスを提供することが含まれます。
タスク計算モジュールの機能には、さまざまなストリーミング統計計算シナリオのカプセル化、電流制限ルールの判定の実行、各統計項目の構成情報の分析、メッセージデータの消費と統計構成に従って計算、統計結果の保存が含まれます。
Web モジュールの機能には、統計グループと統計項目の管理と維持、統計結果の表示、トラフィック制限ルールの設定、統計指標へのアクセス権の管理が含まれます。

システムデザイン

XL-LightHouse は、汎用のストリーミングビッグデータ統計プラットフォームであり、ストリーミングデータ統計の要件を複数のコンピューティングシナリオに抽象化および分類し、さまざまなコンピューティングシナリオの高性能実装を実装することで、各コンピューティングが無制限の多重化を実現できます。XL-LightHouse は、[統計工学-統計グループ-統計項目]の 3 層構造を採用し、あらゆる統計要件を管理します。各統計要件は統計項目と呼ばれ、各統計項目は 1 つ以上のコンピューティングシナリオに基づいています。ユーザーは必要に応じて複数の統計プロジェクトを作成でき、各統計プロジェクトには複数の統計項目を含めることができ、同じメタデータに基づく複数の統計項目を統計グループと呼びます。 XL-ライトハウス Webモジュールでは、統計項目の実行状況を管理できます。ユーザーは、Webページ上で指定した統計項目の開始、停止、削除を行うことができます。実行状態の統計項目は通常の統計操作を実行し、非実行状態の統計項目は統計操作を実行しません。システムにアクセスするには、ユーザーはまず Web 側で対応する構成を構成し、次に SDK を通じて元のデータをレポートする必要があります。システムは、統計サイクルに従って統計生メッセージデータをいくつかのバッチに分割し、統計構成に基づいて対応する計算を実行します。

1. カスタムストリーミング統計仕様 (XL-Formula)

SQL 仕様はビッグデータクエリや統計分析で広く使用されており、オフラインデータ分析、OLAP、OLTP などの分野でも SQL は揺るぎない地位を占めています。また、FlinkSQL や SparkSQL などのコンポーネントの機能がますます完成するにつれて、ストリーミング統計の分野でも SQL が使用されるようになりました。ただし、SQL 自体はデータテーブルの概念に基づいてデータを処理するため、より多くの生データと中間データをメモリに保存することは避けられず、大量のメモリの浪費が発生します。分散 SQL はデータ処理中にシャッフルをトリガーし、多数のネットワーク送信が発生し、実行効率に影響します。SQL の一部のグループ化および集計操作により深刻なデータスキューが発生し、プログラムの通常の実行に影響を与える可能性があります。多くの SQL 計算タスクは、データ量と計算ロジックに基づいて最適化する必要があります。リソースの無駄です。SQL 構文は肥大化しすぎて複雑です。明確かつ簡潔ではなく、複数のフィルター条件の組み合わせロジックは実装するのに長い SQL ステートメントに依存する必要があり、理解しにくいため、長い SQL ステートメントを作成するとエラーが発生しやすくなります。SQL 関数のカスタマイズ機能の拡張が不便です。SQL 開発は比較的複雑で、同じ機能を実現するために SQL は複数の方法で記述される可能性があり、記述方法が異なると実行と解析の効率も異なります。これらの問題により、対応する機能の実現は専門のデータ研究開発担当者に依存することになり、その結果、研究開発コストが高くなり、ストリーミング統計タスクのサイクルが長くなります。エンタープライズデータ指標が急激な増加を示すと、SQL 仕様のボトルネックも浮き彫りになり、多額の研究開発コスト、データメンテナンスコスト、サーバーコンピューティングコストが必要になります。SQL 仕様のこれらの問題は、ストリーミング統計の細分化シナリオでの急速な拡張を制限し、この細分化分野での SQL の適用を基本的にカスタマイズされた需要開発の範囲に限定していると思います。SQL 仕様は、ストリーミング統計の開発をある程度妨げ、さまざまな業界でのストリーミング統計の急速な普及と大規模な適用を制限してきました。XL-LightHouse は、汎用ストリーミングビッグデータ統計プラットフォームとして、企業が複雑なストリーミングデータ統計の問題を解決できるよう支援することに重点を置いています。XL-LightHouse は、ビッグデータ分野における現在の業界標準に固執せず、より軽量な技術ソリューションを使用して企業が直面する問題を解決したいと考えています。これは、さまざまな形式のストリーミング統計要件を記述するための比較的完全な構成仕様のセットを定義しており、さまざまな属性の組み合わせを通じて、非常に強力な統計機能を実現できるため、企業を支援します。

2. メッセージ集約処理

システムは、データ消費リンク全体を次の基本リンクに分割します。クライアントモジュールによるメッセージデータのレポートリンク、RPC モジュールによるメッセージデータの処理リンク、計算モジュールによる展開およびグループ化操作の実行リンク、および統計結果の保存リンクです。各リンクでは、システムは非同期処理、バッチ消費、および反復計算の集計処理を使用します。各リンクはメッセージを受信してメッセージバッファプールに置き、システムは各リンクの事前定義された集計ロジックに従ってメッセージをさまざまな計算タイプに分割し、同じ種類のメッセージを単一ノードおよび単一プロセスに集約します。この設計により、下流へのデータ送信が削減され、ネットワーク IO 効率が向上し、下流の計算量と DB の書き込み圧力が直接的に削減されます。メッセージを送信するクライアントから最終統計結果ストレージまでの各リンクは、繰り返し発生するメッセージを集約してメッセージ量を可能な限り削減し、下流の動作に関係のないパラメータは速やかに破棄することで、XL-LightHouse のデータ消費リンクは階層ごとに削減される構造となっています。各リンクのメッセージ集約ロジックは若干異なりますが、クライアントモジュールを例にとると、メッセージ集約には主に以下の内容が含まれます: (1) メッセージボディパラメータのカットメッセージの伝送速度を向上させ、後続のメッセージ集約の効率を向上させるために、クライアントモジュールは統計的に無関係なフィールドを削除するために、元のメッセージをカットする必要があります。統計的に無関係なフィールドは、各統計グループのすべての有効な統計項目に基づいてシステムによって計算されます。すべての有効な統計項目に関連しないフィールドは、クライアントモジュールがデータを報告する前にフィルタリングされ、不必要なデータ送信を回避します。(2) メッセージ本文のタイムスタンプの改ざんメッセージを報告するリンクにおいて、クライアントモジュールは、集約操作を実行する前に、メッセージの元のタイムスタンプを最小バッチ時間に変更します。これは、後続のステップでのデータの正確性を保証することを前提として、できるだけ多くのメッセージを集約し、ネットワーク送信と下流の計算の量を削減することを目的としています。クライアントモジュールは、現在の統計グループ内のすべての有効な統計項目の統計期間の最大公約数をタイムウィンドウとして取得し、タイムウィンドウとメッセージの元のタイムスタンプに従って、メッセージに対応する最小バッチ時間を計算します。クライアントモジュールは、メッセージの元のタイムスタンプを最小バッチ時間に変更し、バッファプールに入れます。(3) 集計操作集約操作では、事前定義された集約ロジックに従って、同じタイプのメッセージをマージします。異なるリンクの集約ロジックは若干異なります。クライアントモジュールの集約ロジックは、一貫したメッセージ内容を持つメッセージ、つまり、同じ統計グループと同じパラメータ値を持つメッセージを参照します。元のメッセージがバッファプールに送信された後、コンシューマスレッドグループは定期的にバッファプールからメッセージをバッチで読み取り、集約ルールを満たすメッセージを集約します。集約操作の後、メッセージ本文のデータ構造は、単一のメッセージ本文の内容から 2 つの属性 (メッセージ本文の内容とメッセージ本文の繰り返し数) に変更されます。

3. メッセージの展開とグループ化

XL-LightHouse では、クラスター内のすべての統計タスクがクラスターコンピューティングリソースを共有し、コンピューティングモジュールはデータの受信後に統計メッセージの展開およびグループ化操作を実行します。

メッセージの拡張

ほとんどのビジネスシナリオでは、1 つのメタデータに対して複数のデータインジケーターが存在することが多く、統計グループ内のすべての統計項目は 1 つの生データメッセージを共有します。拡張操作は、統計グループ内のすべての有効な統計項目を照会し、各統計項目の関連フィールドを抽出し、各統計項目の個別のメッセージデータをコピーして、その操作に関連するフィールドのみを保持するプロセスです。展開演算の目的は、後続の各統計項目の演算ロジックが相互に影響を与えないようにすることです。

メッセージのグループ化操作

グループ化操作とは、統計項目の統計周期属性を抽出し、統計周期に従って時間窓を分割し、展開操作後のメッセージを時間窓に従ってグループ化し、統計項目に複数の統計演算単位が含まれるか否かを判定し、複数の統計演算単位が含まれる場合には統計演算単位に従って再グループ化し、統計項目に次元属性が含まれるかどうかを判定し、次元属性が含まれる場合には次元情報を抽出して次元ごとに再グループ化する。グループ化操作の目的は、各統計タスクの計算プロセスを異なる計算タイプに分解し、同じタイプのメッセージを集約して処理することであり、異なるタイプのメッセージの計算プロセスは相互に影響しません。

4. メッセージバッファプール

システム集約処理が依存するメッセージバッファプールの実装スキームは、制限された優先順位ブロッキングキューに基づいています。システムはメッセージバッファプールをいくつかのスロットに分割し、各スロットの構造には BoundedPriorityBlockingQueue (制限された優先順位ブロックキュー) とスロットに対応する最終アクセスタイムスタンプが含まれます。メッセージバッファプールの処理ロジックには次のステップが含まれます: (1) プロデューサは、異なるリンクの集約ロジックに従ってメッセージイベントのキーを生成し、そのキーは同じタイプのメッセージであるかどうかを区別するために使用されます; (2) メッセージバッファプールは、メッセージキーのハッシュ剰余に従って対応するスロットを割り当てます; (3) 事前定義された時間ウィンドウに従ってメッセージを異なる処理サイクルに分割します; (6) スロットの使用量がしきい値を超えているかどうかを判断します。しきい値はバッチです。 size * backlog_factor、ここで、batchsize は 1 回の消費で指定された最大メッセージ数、backlog_factor は指定されたメッセージバックログ係数です; (7) スロットの使用容量がしきい値を超えない場合は、スロットの最後の消費アクセス時間の判断を続行し、時間しきい値を超えている場合は、メッセージのバッチ消費を読み取り、それ以外の場合は、このタスクをスキップします。スロットメッセージを消費した後、スロット使用容量と最終アクセス時刻を同時に更新します。メッセージバッファープールを実装すると、同じコンピューティングタイプのメッセージをできるだけ多く処理のために集約できるため、ダウンストリームのコンピューティング負荷と DB への書き込みプレッシャーが軽減されます。

5. 基数演算

ビットカウントのカーディナリティ計算とは、個別（非反復値カウント）を指し、システムは、カーディナリティフィルタリングデバイスを使用して既存のカーディナリティ値をフィルタリングし、フィルタリングデバイスに存在しない基数の数を決定し、DBの統計結果を更新することでカーディナリティ統計を実現します。基数フィルタリングデバイスには、メモリ基数フィルタリングデバイスと分散基数フィルタリングデバイスの 2 つの部分が含まれています。メモリカーディナリティフィルタリングデバイスの機能は、カーディナリティ値がすでに存在するかどうかを事前に判断することであり、その機能は、繰り返しのカーディナリティ判断が全体のパフォーマンスに及ぼす影響を可能な限り回避するために、メモリ判断をより効率化することである。メモリ内カーディナリティフィルターは、RoaringBitMap ツールキットを使用して実装されます。分散カーディナリティフィルタリングデバイスには複数のフラグメントが含まれており、各フラグメントは RoaringBitMap データストレージ構造に対応しています。フラグメントの数は実際のニーズに応じて指定できます。フラグメントの数を増やすことで、カーディナリティ計算の精度を向上させることができます。分散カーディナリティフィルタリング装置の実装スキームは以下のステップを含む。 (1) 元の値を MurmurHash-128Bit に渡し、元の値に対応する Long 型のハッシュ値を生成する。(2) 統計タスクに必要なシャード数を設定します. 各シャードは RoaringBitMap データ構造に対応します. 本システムのフィルタリングデバイスは Redis-Roaring プラグインを拡張する Redis を使用することで実現されます. 元の値に対応するシャードはハッシュ剰余によって取得できます. (3) Long 型の Hash 値を上位 32bit と下位 32bit に応じて 2 つの Int 型整数に分割し、負数の場合はその絶対値をとり、2 つの Int 値を合わせたものが RoaringBitMap データ構造における元の値の Index 値に相当します。(4) 複数のカーディナリティ値に対応する Int 値の組み合わせを Redis に一括送信し、Lua スクリプトを使用してカーディナリティ判定のための複数の操作を組み合わせて実行します。Int 値の組み合わせがフィルタデバイスに存在するかどうかを判断し、両方の Int 値がフィルタデバイスに存在する場合、元の値がすでに存在することを意味します。そうでない場合、元の値が存在しないことを意味します。元の値がフィルタデバイスに存在しない場合、システムは判断が完了した後、対応する Index 値を更新します。(5) フィルタリング装置に存在しない元の値の数をカウントし、DBに更新します。

6. シャッフルを避ける

ビッグデータタスクの実行中、シャッフルはパフォーマンスに影響を与える主要な要素であり、大量のネットワークオーバーヘッドをもたらすだけでなく、データスキューや OOM などの問題も引き起こす可能性があります。システムはシャッフルなどの制御不能な要因を回避し、シャッフルによって引き起こされる可能性のある予期せぬ問題を回避します。Structured Streamingをベースに開発された計算モジュールはシャッフルを完全に回避した計算方式を採用しており、タスク実行の並列度を調整する計算ノード数を設定することで、1つの計算ノード内の統計情報を統計項目識別子、次元識別子、時間バッチ、統計計算単位ごとに異なる計算種類に分割します。統計結果データと中間状態データは外部ストレージに基づいて実装されます。このシステムでは、統計結果は HBase に保存され、bitcount radix 演算の中間状態データは Redis に保存され、limit 演算のソートされたデータは Redis に保存されます。各計算ノードは計算中に外部ストレージとのみ通信し、異なる計算ノードは相互に影響を与えません。

7. 統計的電流制限

突発的な大量の統計要求のアクセスや特定の統計項目のトラフィックの突発的な増加によるシステムの不安定を回避するため、統計グループメッセージ量、統計項目結果量、統計項目計算量に対してサーキットブレーカー保護機構を備えています。(1) 統計グループメッセージ量の電流制限統計グループメッセージ量の電流制限は、単位時間当たりに受信する統計グループメッセージの数に対する電流制限方式です。システムに内蔵された統計グループメッセージ量計数装置を使用して、単位時間あたりに受信した統計グループメッセージの数を計算します。単位時間あたりのメッセージの量がしきい値を超えると、電流制限がトリガーされ、現在の統計グループは電流制限状態になります。クライアントモジュールとタスクモジュールは、異常な状態の統計グループメッセージを自動的に破棄します。統計グループは 1 つ以上の統計項目に対応できるため、現在の制限ポリシーは、統計グループ内のすべての統計項目の通常の統計に影響します。統計グループが電流制限状態になると、指定された時間内 (デフォルトでは 20 分) に対応するメッセージが自動的に破棄され、現在の制限時間が時間しきい値に達すると、統計グループは自動的に通常状態に戻ります。(2) 統計項目結果量制限統計項目結果量制限は、統計項目が単位時間当たりに生成する統計結果の数を制限するポリシーです。システム内蔵の統計項目結果集計装置により、単位時間当たりに発生する統計結果の件数を算出します。単位時間当たりの結果の量がしきい値を超えると、電流制限がトリガーされ、現在の統計項目が電流制限状態になります。統計項目の結果の量は 2 つの要素に関連しています。1 つは統計サイクルの時間粒度です。統計サイクルの粒度が細かいほど、インデックスデータの量は増加します。たとえば、秒レベルおよび分レベルの時間単位で生成される統計結果は、時間レベルおよび日レベルの統計よりも多くなります。2 番目に影響を与える要素はディメンションです。より多くのディメンションを持つ統計項目は、単位時間あたりにより多くの統計結果を生成します。たとえば、ディメンションとして都市を含む統計指標は、ディメンションとして州を含む統計指標よりも多くの統計結果を生成します。統計項目の結果フロー制限は、現在の統計項目に対する現在の制限戦略であるため、現在の統計項目にのみ影響し、統計グループ内の他の統計項目には影響しません。統計項目が電流制限状態になると、対応するメッセージは指定された時間 (デフォルトは 20 分) 以内に自動的に破棄され、電流制限時間が時間しきい値に達すると、現在の統計項目は自動的に通常状態に戻ります。

8. タイムスタンプの圧縮

このシステムは、DB のデータスループットの向上を目的として、ストリーミング統計シナリオ向けにデータストレージ形式をさらに最適化します。システム統計結果のデータ保存にはタイムスタンプ圧縮が採用されており、統計周期に従って異なる期間に分割され、各統計項目の同じ次元で同じ期間内の複数の統計結果値が異なる列に保存されます。

9. 異常溶断

サーキットブレーカーメカニズムは、ビジネスパーティ自身のサービスの安定性を確保し、統計サービスの不安定性によるビジネスパーティ自身のサービスへの影響を回避するためのものです。異常ヒューズメカニズムとは、クライアントインターフェイスが呼び出されたときに、単位時間あたりの失敗またはタイムアウトの数がしきい値を超えた場合にヒューズ状態に入り、このときクライアントモジュールは統計メッセージの送信ロジックを自動的にスキップします。ヒューズ状態に入った後、クライアントモジュールは統計サービスのステータスが通常に戻ったかどうかを定期的にチェックし、統計サービスが通常に戻った場合は自動的に再接続します。

システムの機能境界

(1) 元データの詳細なクエリをサポートしていません。

(2) 当面は、ストリーミングスクロールウィンドウデータ統計のみが関係します (スライディングウィンドウ統計は後続のバージョンでサポートされる予定です)。

(3)、一時的に第 2 レベルの詳細なデータ統計をサポートしません (後続のバージョンでサポートされる予定です)。

(4) 元のデータ収集の詳細は含まれません。システムのすべての計算は、アクセスパーティによって報告された元のメッセージに基づいています。各オリジナルメッセージデータは、アクセスパーティによって組み立てられ、SDK を通じてレポートされる必要があります。また、SDK は現在 Java 版のみが提供されており、JVM 言語のサービスについては、アクセス側がサービス内で直接呼び出すことができます。他の言語で開発されたサービスは、データを収集して Kafka などのメッセージキューに保存し、データを消費する形で XL-LightHouse にアクセスできます。

プロジェクトアドレス

依存コンポーネント

このプロジェクトが依存する主なコンポーネントは次のとおりです: Hadoop (Apache2.0)、HBase (Apache2.0)、Spark (Apache2.0)、Kafka (Apache2.0)、Zookeeper (Apache2.0)、Redis (BSD3)、Redis-Roaring (MIT)、Guava (Apache2.0)、Caffeine (Apache2.0)、、ZeroICE (GPLv 2) 、ECharts (Apache2.0)、AdminLTE (MIT)、Aviator、SpringBoot (Apache2.0)、MySQL (GPLv2)、LayUI (MIT)、ZTree (MIT)、JQuery (MIT)、Jedis (MIT)、Freemark (Apache2.0)、RoaringBitMap (Apache2.0)、Redisson (Apache2.0)、Jackson (A pache) 2.0)、ACEエディター(BSD)、ディスラプター(Apache2.0)

フィードバックを交換する

https://dtstep.com

最後にいくつかの言葉

XL-LightHouseは、ストリーミング統計の急速な普及と大規模応用の促進に特化した汎用ストリーミングビッグデータ統計プラットフォームであり、少ないサーバーリソースで数万、数十万のストリーミングデータ統計ニーズをサポートするビッグデータプラットフォームとして位置づけられています。XL-LightHouse は、企業の上層部から下層部までのすべての機能担当者の共通使用を指向しており、汎用のストリーミングデータ統計を出発点として提唱し、企業が人間の神経系のように全身に広がる比較的完全で安定した信頼性の高いデータベースのオペレーションシステムを構築できるように、より軽量な技術ソリューションを選択する傾向があります。ストリーミング統計テクノロジーは完璧ではなく、実際にはストリーミング統計の実装に適さないシナリオもいくつかあるため、他の技術ソリューションを完全に置き換えることは不可能です。しかし、エンタープライズデータ運用分野のあらゆる技術ソリューションの中で、主力となり得るのは汎用のストリーミングデータ統計だけであると私は今でも思っています。ストリーミング統計が好まれる理由の1つは適時性ですが、最も根本的な理由は技術をどれだけ普及させることができるかにあると思います。多くの場合、使用コストがすべてを決定します。ソフトウェアの研究開発の分野において、汎用ストリーミング統計は現在のソフトウェア製品開発に多大な影響を与えると考えており、今後ログと同様に重要な役割を担うことになると考えられますが、汎用ストリーミング統計はログとは独立した、ログと同様に重要な補助ツール体系となる可能性があります。様々な職種のプログラマがログを追加するのと同じように、必要に応じてストリーミング統計コードを追加することになります。エンタープライズレベルのサービス市場において、汎用ストリーミングデータ統計は、その膨大な応用シナリオと大きなビジネス価値から、企業の中核となる基本サービスの一つとなり、汎用ストリーミングデータ統計をコアコンセプトとし、その他の技術ソリューションを補助手段とするデータベースの運用製品は、エンタープライズレベルのBエンド市場に欠かせないバックボーンとなると考えています。さらに、ソフトウェア技術とハードウェア技術の協調的な発展とモノのインターネット時代の到来により、汎用ストリーミングデータ統計も現実世界のあらゆる側面に浸透し、社会の基礎的なコンピューティング能力となり、さまざまな産業で広く使用されるようになると思います。

著者：雪灵連絡先：[email protected]