XL-LightHouse、Flink、ClickHouse ストリーミング ビッグ データ統計システム

Flink タスクは 1 つまたは少数のデータ ストリームのみを並列処理できますが、XL-LightHouse タスクは数万または数十万のデータ ストリームを並列処理できます。

Flink タスクは 1 つまたは少数のデータ インジケーターのみを実装できますが、単一の XL-LightHouse タスクは数万のデータ インジケーターの大規模なバッチをサポートできます。

1、XL-ライトハウス :

  •  1. データを実行するために Flink、Spark、ClickHouse や Redis ベースの肥大化して扱いにくいソリューションを使用する必要はありません。
  •  2. 個人の価値向上にあまり役に立たないデータ統計のニーズに対処することにうんざりする必要はなくなり、些細で反復的なデータ統計のニーズを取り除き、より価値のあるデータに集中できるようになります。個人の向上とビジネスの発展につながります。
  •  3. きめ細かい監視指標を簡単に実現できるため、サービスの運用状況を監視し、さまざまなビジネス データの変動や指標の異常をトラブルシューティングするのに役立ちます。
  •  4. データ思考を養い、従事している仕事のデータ指標システムの確立を支援し、仕事の成果を定量化し、プロフェッショナルで厳格な職場人となり、より大きな個人的価値を創造します。

2. ストリーミング統計はストリーミング コンピューティングの計算形式ですが、

        ストリーミング統計は、Count 操作、Sum 操作、Bitcount 操作 (個別のカウント)、Max 操作、Min 操作、Avg 操作、Seq 操作 (時系列データ)、Dimens 操作 (次元分割)、Limit 操作 (topN/lastN) にすぎません。

3. Flink はストリーミング統計に使用すると欠陥があります。

3-1. リソース使用率が低い

Flink のリソース使用率の低さは、クラスター運用のトポロジーと Flink タスク実行の特性の 2 つの観点から見ることができます。

3-2. 演算性能が低い

3-3. アクセスコストが高い

(1) Flink はビッグデータの専門的な研究開発者を対象としており、多数の統計指標の実現には多額の研究開発費が必要となります。
(2) ストリーミング統計の分野における Flink の基本機能は完璧ではないため、多くのシナリオでは開発者が統計タスクのデータ量、統計サイクルの粒度、データ スキューなどの要素に基づいて特定の最適化を行う必要があります。 。そのため、同様の機能を実現するためにFlinkが多く使われていますが、データ量や統計期間の違いにより、プログラムの実装方法も全く異なる場合があります。

3-4. 高い運用保守コストと高いコンピューティングリソースコスト

XL-LightHouse と比較して、Flink の運用および保守コストは高く、これはいくつかの側面に反映されています。
(1) 同じストリーミング統計要件を達成するために、Flink クラスターのサイズは XL-LightHouse よりも大幅に大きく、その結果、操作量が増加します。そして維持費。
(2) Flink クラスターは専門的な研究開発担当者を対象としているため、Flink クラスターの運用には、クラスターの保守担当者と Flink タスクの研究開発担当者が共同で参加し、クラスターのバージョン アップグレード、クラスターの拡張、日常のメンテナンス、データの移行、その他の業務については、事前に研究開発担当者とコミュニケーションをとり、暗黙の了解を得ることが必要です バージョンアップと同様の業務の多くには、関連業務のバージョンアップや変更が伴います。クラスターの規模が大きく、研究開発担当者が関与し、関連タスクが多数ある場合、このプロセスには必然的に多額のメンテナンス費用がかかります。

4. ClickHouse をストリーミング統計に使用すると欠陥があります。

  • ClickHouse適用シナリオの特徴
    (1) アプリケーションシナリオが単一または少数であり、各アプリケーションシナリオに膨大な量のデータが含まれる
    (2) ビジネスシナリオには多数のディメンションフィールドがあり、数十に分割する必要がある場合があるディメンションを自由に組み合わせて、多次元のアドホック クエリ操作を実行できます。
    (3) ビジネス シナリオでは詳細なクエリが必要です。
    (4) 異なるデータ ソース間の結合クエリに対する要件が存在する場合があります。

  • ClickHouseのデメリット
    (1) 各クエリは大量のデータを走査する必要があるため、同時実行のサポートが制限されます
    (2) システムが大量の詳細データを保存するため、クラスタのサイズが大きく、構造が複雑で、メンテナンスコストが高くつきます高;
    (3) 各クエリ 各クエリはデータを走査し、リアルタイムの統計計算を実行する必要があり、これには大量のメモリと CPU リソースが必要です; (4)
    データ アクセスはさまざまなレベルで最適化する必要があり、しきい値は高く設定する必要があります。 (5)アクセス
    コストが高く、メンテナンスコストが高く、サーバーコストが高く、使用しきい値が高く、中小企業には不向き企業。

5.XL-LightHouseの特徴

(1) 同時実行クエリの統計結果をサポートできる

(2) 詳細クエリはサポートされていないため、詳細クエリをサポートしたい場合は、他のツールを使用する必要があります。

(3) 詳細クエリはサポートされていないため、詳細クエリをサポートしたい場合は、他のツールを使用する必要があります。

6. アプリケーションシナリオの統計

クリック数:
1. 5 分ごと_クリック数
2、5 分ごと_各 ICON_クリック数 3、1 時間ごと_
クリック数
4、1 時間ごと_各 ICON_クリック数
5、毎日_合計クリック数
6、毎日_各タブ_合計クリック数
7、毎日_各アイコン_合計クリック数

UV をクリック:
1. 5 分ごと_UV をクリック
2. 1 時間ごと_UV を
クリック 3. 1 時間ごと_各アイコン_UV をクリック
4. 毎日_クリック UV
の合計 5. 毎日_各アイコン_クリック UV の合計

成功した支払い注文の統計

注文量:
1. 10 分ごと_注文量
2. 10 分ごと_各加盟店_注文量
3. 10 分ごと_各州_注文量
4. 10 分ごと_各都市_注文量
5. 1 時間ごと
_注文量 6、1 日あたりの注文量
7、1 日あたりの販売者ごとの注文量
8 、1 日あたりの州ごとの注文量
9、1 日あたりの都市ごとの注文量
10、1 日あたりの価格帯ごとの注文量 11、1
日あたりのアプリケーションごとの注文量 Scenario_Order Volume

取引金額:
1. 10分ごと_取引金額
2. 10分ごと_各加盟店_取引
金額top100 3. 10分ごと_各都道府県_取引金額 4.
10分ごと_各都市_
取引金額 5. 1時間ごと_取引金額
6、毎時_各加盟店_取引金額 7
、毎日_取引金額
8、毎day_各加盟店_取引金額 9
、毎日_各州_取引金額
10、毎日_各都市_取引金額
11、毎日_各加盟店 アプリケーション シナリオ_取引金額

注文ユーザー数:
1. 10分ごと_注文ユーザー数
2. 10分ごと_各加盟店_注文ユーザー数
3. 10分ごと_各都道府県_注文ユーザー数
4. 10分ごと_各都市_ 1時間当たりの注文ユーザー数
は5人1 時間あたりの注文ユーザー数は
6 日あたりの注文ユーザー数は
7 販売者ごとの 1 日あたりの注文ユーザー数は
8 州あたりの 1 日あたりの注文ユーザー数は 9 注文ユーザー数
1 日あたり都市ごとに 9 です。 注文ユーザー数
10、1 日あたり_各価格帯_注文ユーザー数
11、1 日あたり_各アプリケーション シナリオ_注文ユーザー数

プロジェクトアドレス:

https://github.com/xl-xueling/xl-lighthouse

https://github.com/xl-xueling/xl-lighthouse.git

https://gitee.com/mirrors/XL-LightHouse.git

参考ドキュメント:

1. プロジェクト紹介
2.Gitアドレス
3. コミュニケーションコミュニティ
4. プロジェクトの設計
5. ワンクリック導入
6. XL フォーミュラの使用
7. Webサービス操作手順
8、ハローワールド
9. 適用可能なシナリオ
10. 著作権に関する声明
11. フィードバックを活用する
12. 依存コンポーネント

おすすめ

転載: blog.csdn.net/ejinxian/article/details/132775981