Mango TV の Flink に基づくリアルタイムデータウェアハウス構築の実践

会社概要: Mango TVは、湖南省放送テレビ傘下のインターネットビデオプラットフォームとして、「1つのクラウド、複数のスクリーン、複数の統合」の戦略的指導の下、独占放送から独自性まで、自社制作のコンテンツを通じて核となる競争力を育成します。 Aラウンド、Bラウンドの資金調達を完了し、2018年6月に資産再編を成功裏に実現し、国内初のA株国有ビデオプラットフォームとなった。

ヒント: [原文を読む]をクリックすると、5000CU* 時間の Flink クラウドリソースを無料で受け取ります

Mango TV リアルタイムデータウェアハウス構築プロセス

Mango TV のリアルタイムデータウェアハウスの構築は 3 つのフェーズに分かれており、第 1 フェーズは 2014 年から 2019 年までで、テクノロジーの選択には Storm/Flink Java+Spark SQL が採用されています。20～22年前半は第2ステージで、テクノロジー選定にはFlink SQL+Spark SQLを採用。22年後半～現在は第3段階で、テクノロジー選択にはFlink SQL+StarRocksを採用。より包括的な機能、より高速な速度を実現し、ビジネス側のニーズをより適切に満たすために、各アップグレードは元のベースに基づいて繰り返されます。それでは一つずつご紹介していきます。

第 1 世代は Storm/Flink Java+Spark SQL に基づいています

Mango TV のリアルタイムデータ処理は非常に早くから開始され、最初は Storm が使用され、2018 年に Flink が誕生しました。Flink のステート処理とストリーム処理の利点は印象的であり、オープンソースコミュニティの人気と大手メーカーの成功により断ることができなくなったため、Flink はリアルタイムデータウェアハウスの構築に使用されましたが、当時は煙突型の開発は主に企業のニーズに応えるものであり、関係者のニーズに基づいて実行されます。基本的なプロセスは、上流の Kafka データを接続し、Flink Java を使用して関連するビジネスロジックを処理し、データをオブジェクトストレージに出力することです。次に、Spark SQL を使用してデータの統計などの二次処理を実行し、顧客に提供します。このステージの利点は、Flink の強みを活用してソースから端末までのデータをよりリアルタイムにし、データに対するビジネス側の適時性とビジネスニーズを満たすことです。欠点は、必要なときに機能が作成され、リアルタイムのデータウェアハウスの構築や構築が行われないことです。

第 2 世代は Flink SQL+Spark SQL に基づいています

前段階で発見された技術の蓄積と問題点に基づいて、リアルタイムデータウェアハウスを構築するための新しい計画が提案されます。現時点ではデータウェアハウス構築のあらゆるニーズに対応できるFlink SQL機能が完成しており、Flink Javaに比べて開発や保守などのコストも削減できます。そこで、リアルタイムデータウェアハウスを構築するために Flink SQL が選択されました。この段階では、リアルタイムデータウェアハウスの階層構造設計が実行されます。これについては後で詳しく説明します。基本的なプロセスは、上流の Kafka データを接続してフォーマットし、Kafka に出力します。下位層はフィールド処理、ガベージデータフィルタリングなどの操作のために Kafka データを受け取り、その後 Kafka に出力します。最後の層は次元拡張のために Kafka データを受け取ります。次に、ストレージ内のオブジェクトにデータを書き込みます。Spark SQL が統計やその他の処理のためにオブジェクトストレージ内のデータを読み取った後、そのデータは顧客に配信されて使用されます。この段階の利点は、データウェアハウスの階層化されたアーキテクチャ設計が実現され、各層のデータ定義が標準化され、各層のデータ分離が実現され、煙突型の開発が回避され、開発の繰り返しの問題が回避されることです。問題は解決され、リアルタイムデータウェアハウスは徐々に成熟に向かって進んでいます。欠点は、後続の統計と要約に Spark SQL を使用するのに十分な柔軟性がないことです。事前に指標を設計する必要があり、変化する顧客ニーズにタイムリーに対応できないことも多々あります。

第 3 世代は Flink SQL+StarRocks に基づいています

リアルタイムデータウェアハウスの構築が徐々に深化するにつれ、Spark SQL は柔軟性が十分でなく、処理速度が不十分であるという欠点がますます顕著になってきています。この時点で、StarRocks が目に見えてきました。その MPP アーキテクチャ、ベクトル化エンジン、マルチテーブル結合、およびその他の機能は、パフォーマンスと使いやすさの面で利点を示し、この分野における Spark SQL の欠点をすべて補っています。そこで調査の結果、リアルタイムデータウェアハウスで Spark SQL を StarRocks に置き換えることが決定されました。現段階では、Flink SQL で構築されたリアルタイムデータウェアハウスの階層構造は変わっておらず、Spark SQL による統計分析に関連する下流機能は段階的に StarRocks に置き換えられています。StarRocks の利点と、リアルタイムデータウェアハウスを構築する際に直面する問題点に基づいて、以前の Spark SQL モデルをコピーするのではなく、新しいモデルを選択しました。アドホッククエリは StarRocks を使用して実装されます。以前は、Spark SQL を使用して統計を収集し、データを要約し、最終結果データをオブジェクトストレージに書き込んでいました。しかし現在では、StarRocks を直接使用して詳細データを要約し、フロントエンドページに表示しています。これを行う利点は、ビジネス側のニーズをより迅速かつ柔軟に満たすことができ、開発作業負荷を軽減し、テストとオンライン化にかかる時間を短縮できることです。StarRocks の優れたパフォーマンスにより、アドホッククエリの速度が低下することがなく、機能はより強力で柔軟になり、配信速度も速くなります。

自社開発の Flink リアルタイムコンピューティングスケジューリングプラットフォームの紹介

既存の問題点

ネイティブタスクのコマンドは複雑で、デバッグが面倒で、開発コストが比較的高くなります。
コネクタ、UDF、Jar タスクパッケージなどは管理できず、デバッグは複雑で、依存関係の競合が頻繁に発生します。
リソースに対する統合監視、アラームおよび権限管理を実現することは不可能です。
SQL タスクの開発は複雑で、使いやすいエディターやコード管理およびストレージプラットフォームはありません。
基本テーブル、ディメンションテーブル、およびカタログには、記録および視覚化のプラットフォームがありません。
マルチバージョンおよびクロスクラウドのタスクは適切に管理できません。
適切なログ管理メカニズムがなければ、実稼働環境で問題を迅速に特定することは不可能です。

プラットフォームアーキテクチャ設計

リアルタイム Flink スケジューリングプラットフォームのアーキテクチャ図:

プラットフォームは主に 3 つの部分に分かれています。

1. Phoenix Web モジュールは主にユーザーとの対話を担当します。

クラスターのデプロイメントとタスクの送信。
会社の社内業務権限の管理。
カタログとマルチソース情報管理をサポートします。
UDF やコネクタなどの 3 者は Jar パッケージ管理に依存しています。
複数種類の監視アラームとログ管理。
SQL の視覚的な編集と検証、およびマルチバージョンのストレージ。

2. Flink SQL Gateway と Flink Jar Gateway は両方とも、オープンソースバージョンに基づいて変更およびカスタマイズされたサービスです。ビジネスシナリオに沿った SQL 解析と検証、および Jar タスクの送信をサポートします。ローカルモード、ジョブごとのヤーンをサポートします。モードとアプリケーションモード、自動セーブポイントもサポートされています。

SQL の解析と検証を実行します。
SQL および Jar タスクをロードするには、スリーパーティの依存関係が必要です。
SQL タスクは、関連付けとマッピングのためにカタログストアに接続します。
チェックポイントとセーブポイントの自動管理と回復。
Jarタイプのタスク起動パラメータのインジェクション。
適応型ランタイム構成。
複数種類の提出方法が適応されます。

3. ハイブリッドマルチクラウドモジュールは、主にクラウド間の起動タスクの分散と情報管理を担当します。

Flink SQL リアルタイムデータウェアハウスレイヤ化の実践

Flink SQL を使用してリアルタイムデータウェアハウスを構築する場合、最初の問題は、データウェアハウスの階層構造をどのように解決するかということです。業界には多くの優れた経験があり、参考になります。同時に、当社の状況に基づいて、最終的に次のデータウェアハウスアーキテクチャが採用されました。

ODS レイヤー: 元のログレイヤーです。このレイヤーでは、上流の Binlog ログ、ユーザー行動ログ、外部データなどのデータソースがデータウェアハウスに同期されます。さまざまなデータソースおよび形式からのデータは、統合された UDF 機能を通じて解析およびフォーマットされます。、最後にフォーマットされた JSON データを出力します。

DW 層: データ詳細層。エラーデータのフィルタリング、フィールドエスケープ、フィールド名の統一などが主に処理され、出力データは日常の基本分析の使用に対応できます。

DM レイヤー: データモデルレイヤー。関連する公開情報を補足するために次元拡張が実行されます。その後、ビジネスに応じてドメインに分割され、出力データの次元がより豊富になり、高度な分析のデータ使用要件を満たすことができます。

ST 層: データアプリケーション層。ビジネス、機能、その他の次元に基づいてまとめられ、フロントエンドページに渡されて表示され、出力データは Web、アプリ、アプレットなどの機能に配信されます。

Flink SQL リアルタイムデータウェアハウスの運用プロセスで発生した問題

リアルタイムデータウェアハウスを構築するときに、多くの問題に遭遇しました。解決策のアイデアを説明するために、いくつかの典型的な問題を次に示します。

1. マルチテーブルの関連付け、これはデータウェアハウスを構築するときに非常に重要で一般的に使用される機能です。Flink SQL を使用してリアルタイムデータウェアハウスを構築する初期段階では、Flink の目まぐるしい結合タイプの配列に本当に混乱しました。特に複数テーブルの関連付けとなると、ディメンション表のデータの一部はHiveにあり、ディメンション表のデータはMySQLにあり、ディメンション表のデータは他のOLAPにもあるため、どのような関連付け方法を選択するかが大きな問題となりました。何度も試行した結果、パフォーマンス、機能、その他の側面のバランスを考慮して、次のルールが要約されました。

フローテーブルは、ルックアップ結合を使用してディメンションテーブル (データ量が少ない) に関連付けられます。ディメンションテーブルのデータ量が 100,000 未満の場合は、ディメンションテーブルのデータのほとんどが Hive テーブルとして使用できます。オフラインデータウェアハウスは Hive にあります。直接再利用できるため、データのインポートとエクスポートの余分な作業が節約され、パフォーマンスにボトルネックがありません。ディメンションテーブルが 1 時間ごとに更新された後、Flink SQL で最新のデータを読み取ることもできます。
フローテーブルはディメンションテーブル (データ量が大きい) に関連付けられています。ルックアップ結合が使用されます。ディメンションテーブルのデータ量が 100,000 ～ 1,000 万未満の場合、MySQL テーブルをディメンションテーブルとして使用できます。現時点では、Hive ディメンションテーブルは満たすことができません性能要件。データは MySQL にエクスポートでき、要件を満たすためにキャッシュメカニズムも使用できます。
フローテーブルとフローテーブルの関連付けはInterval Joinを使用し、2つのフローテーブルの時刻フィールドを用いて関連付け範囲を制御する方法で、現在はこの関連付け方法が多く使用されています。使い方もオフラインに近づきました。

2. 複雑なテーブル処理: データクリーニングの一部の複雑なシナリオでは、ディメンションテーブルを関連付けるときに、ディメンションテーブル内のデータを使用する前に、1 つまたは複数のレイヤーの処理を受ける必要があります。このようなシナリオでは、オフラインデータウェアハウスを直接使用できます。結合中にマルチレベルのサブクエリを作成して、1 つのステップで完了します。ただし、これは Flink SQL ではサポートされておらず、基礎となるメカニズムで拒否されます。多くの試みと苦闘を経て、最終的な解決策は Hive でディメンションテーブルデータを前処理することであり、リアルタイムデータウェアハウスは前処理されたディメンションテーブルデータを使用します。ただし、これは過渡的な解決策にすぎず、将来的にはディメンションテーブルに対して任意の複雑な計算を実行した後、ディメンションテーブルの関連付けを実現する新しいメカニズムが存在することがコミュニティから現時点でわかっています。Flink コミュニティの更新は依然として非常に速いと言わざるを得ません。

3. 状態が大きすぎる 2 つのフローテーブルが関連付けられている場合、または要約統計が実行されている場合、Flink のメカニズムはデータを状態にキャッシュします。これにより、State が大きすぎて、GC が頻繁に発生し、タスクが失敗します。この状況を考慮して、Flink の記憶メカニズムを検討した結果、解決策は次のようになります。

時間範囲を短縮し、ビジネスニーズに応じて関連付け中に 2 つのストリームの時間範囲を適切に短縮します。
マネージドメモリのサイズを調整すると、マネージドメモリの割合を調整し、他のメモリの使用量を適切に減らすことができます。
過剰なデータのキャッシュを避けるために、状態の TTL を設定します。

4. 完了する前にチェックポイントの期限が切れたという例外がタスクで頻繁に発生します。実際の運用環境では、一部のタスクがこのエラーを頻繁に報告することがわかります。Flink のチェックポイントには、チェックポイントが正常に完了できないことを意味します。データは ExactlyOnce で正確です。一貫性、データのバッチを処理できない場合、チェックポイントは完了できません。興味のある方は調べてください。このエラーには多くの理由があり、問題が異なれば答えも異なります。次に、シナリオと解決策を以下に示します。

チェックポイントのタイムアウト期間が短すぎるこれは比較的一般的な状況であり、解決するのは簡単です。原因は、チェックポイントのタイムアウト期間の設定が短すぎるため、チェックポイントが完了する前にタイムアウトが報告されてしまうためです。解決策は、タイムアウト時間を長く設定することです。タスクの種類に応じて、通常は 6 秒から 2 分に設定します。
タスクにはバックプレッシャーがあり、これも非常に一般的です。タスクには複数の操作があり、そのうちの 1 つの操作がタスク全体の実行に影響を与えるほど長い時間がかかります。また、チェックポイントの完了にも影響しますので、興味があればチェックしてみてください。解決策は、WebUi から実行が遅いタスクを見つけて、具体的な問題を詳細に分析して解決することです。
メモリが不足しています。最初に背景について説明します。通常、本番環境ではrocksdb statebackendを使用します。デフォルトでは完全なチェックポイントが予約されます。この場合、関連付けやグループ統計など、ヒープステートバックエンドを使用するタスクが発生すると、計算の中間結果が State にキャッシュされ、State のメモリはデフォルトで総メモリの 40% になります。これでは十分ではないため、GC が頻繁に発生し、チェックポイントの実行にも影響します。解決策は次のとおりです。
- タスクマネージャーのメモリを増やすタスクマネージャーのメモリを増やすと、それに応じて他のメモリ領域も増加します。
- マネージドメモリのメモリ比率を高めるには、パラメータ taskmanager.memory.managed.fraction を設定します。これは、実際の運用環境では実際の状況に応じて最大 90% まで調整できます。この方法は ManagedMemory を 1 個増やすだけですが、メモリリソースがあまり豊富でない場合は、この方法を使用できます。
- 代わりに増分チェックポイントを使用し、実際の状況に応じて State の TTL 時間を調整し、増分チェックポイントを有効にします。メモリサイズを調整しなくても問題は解決します。

5. Flink SQL で if 関数を使用すると、偶然発見されましたが、String を返す場合、最大長に従って返されます。これはどういう意味ですか? たとえば、if(condition, stringA, stringB)、stringA の長さは 10、stringB の長さは 2 です。条件 = false の場合、stringB が返されると、stringB の長さが埋められます。 10 まで。足りない場合はスペースが与えられます。これは注意すべきことです。しかし、後でこの現象がバージョン 1.16.3 で修正されていることを知り、私たちは 1.15 を使用しているので、この現象が発生した場合は、CaseWhen に置き換えるか、Flink バージョンを 1.16.3 以降にアップグレードすると解決できます。

StarRocks選定の背景と問題点

以前のフレームワークでは、Flink ストリーム処理エンジンを使用して、元のログのクリーニング、データの拡張、および軽い集約を完了してから、分散ファイルシステムまたはオブジェクトストレージに到達し、オフラインを通じて 5 分レベルでバッチをスケジュールしました。 Spark SQL。処理後、結果は Presto などのエンジンを通じてクエリされます。この種のアーキテクチャでは、運用環境での多くの問題が徐々に明らかになります。

例えば：

計算の繰り返しの問題があります。元のデータはさまざまなタスクで繰り返しクリーンアップされ、複数の元のデータを必要とする一部の関連付けも繰り返しクリーンアップされます。これにより、多くのコンピューティングリソースが無駄になり、コードとデータフローの再利用性が低下します。貧しい。
オフラインバッチ処理の履歴累積値と現在の 5 分間ウィンドウの計算インデックスを満たすためには、トラフィックのピーク時間帯やインデックスが1 日は夕方まで蓄積され、タイムアウトの大きなリスクがあり、ビジネスはリアルタイムのメトリクスの遅延をフィードバックします。
オフラインの Spark バッチ処理は、多次元の組み合わせ分析やリアルタイム性が要求される場合には若干弱いためです。オンラインビジネスは多くのリアルタイムシナリオを生み出しましたが、その一方で、業務の高度化と分析の民間化により、多次元分析の要件も生まれました。これらのシナリオでは、非常にきめ細かく、豊富な次元の基礎データが必要になります。この 2 つのシナリオは、これらの結果を重ね合わせることで、リアルタイムの多次元解析シーンが生まれました。現時点では、上記のシナリオを満たすために、ディメンションの組み合わせを継続的に増やし、結果フィールドを増やし、コンピューティングリソースを増やす必要がありますが、まだ少し弱いです。
現在、データの適時性は日に日に高まっています。多くのシナリオでは、データの適時性には数秒から数ミリ秒の時間が必要です。以前の 5 分という方法ではビジネスニーズを満たすことができません。
これまでのリアルタイムタスクでは、Flink メモリ内のストリームとストリームを結合する必要がよくありましたが、これらはすべて Flink タスクメモリ内で行う必要がありましたが、複数の上りデータストリームのデータ到着時間が一致しないため、それが困難でした。エンジン内の幅広いデータ、Flink Interval Join を使用する場合、複数のストリーム間の時間間隔が長すぎ、状態データが非常に大きくなり、mapState などの状態計算が有効になります。カスタマイズされすぎています。
Flinkのクリーニングや計算結果については、複数の記憶媒体が必要になる場合があります詳細なデータについては、分散ファイルシステムやオブジェクトストレージに保存する場合があります現時点ではFlink+HDFSです業務更新ストリームデータの場合は、 Flink CDC+hbase (cassandra またはその他のキーと値のデータベース)、Flink+MySQL(redis) は Flink のリトレースメントフローデータの生成に使用でき、Flink+elasticsearch はリスク管理データまたは従来のきめ細かいバージョンの表示に使用できます。大規模なログデータの指標分析はFlink+クリックハウスの場合があり、統一が難しく、多くのリソースを消費し、メンテナンスコストも高くなります。
オンライン上で大規模なアクティビティや大規模なプログラムがある場合、リアルタイムデータの量が大幅に増加します。リアルタイム大量書き込みの場合、書き込み遅延が大きく、書き込み効率が高くなく、データがバックログ。

全体的に分析すると、初期のアーキテクチャにはいくつかの問題があります。

データソースは多様であり、メンテナンスコストが比較的高くなります。
不十分なパフォーマンス、大きな書き込み遅延、大規模なプロモーションシナリオでのデータバックログ、対話型クエリエクスペリエンスの低下。
各データソースは断片化されているため、関連付けやクエリを実行することができず、多くのデータアイランドが形成されます。次に、開発の観点から見ると、各エンジンは対応する学習コストと開発コストに投資する必要があり、プログラムの複雑さは比較的高くなります。
高いリアルタイム要件、迅速な開発効率、およびコードまたはデータの強力な再利用性。
リアルタイムタスクの開発には同じ一連の標準がなく、それぞれが独立して動作します。

この目的のために、テスト環境で簡単なパフォーマンス比較を行いました。詳細は次のとおりです。

比較環境 StarRocks：4×16C×128G Presto：22×32C×256G（非独占）

データ量: イベントテーブル (合計 100 億データ、1 日あたり 1,000 万件の再再利用)

テストケース	もうすぐ	スターロックス
単一テーブルの集計テスト	13.1	5
関連テスト	19	8
保持	24	15
窓関数	16	8
漏斗	3.5	3.2
複数テーブルの関連付け	36	19

このテストでは、16C128G メモリを備えた 4 台の BE サーバーを使用しており、テストの結論は基本的に数百億のデータのクエリ要件を満たすことができます。テスト結果は、リソースに大きな差がある場合、StarRocks のパフォーマンスが Presto のパフォーマンスよりも大幅に優れており、平均効率が 2 ～ 3 倍向上することを示しています。

Flink SQL+StarRocks に基づくデータウェアハウスのリアルタイム分析

構築されたFlink SQLデータウェアハウス階層化システムをベースに、StarRocks2.5XバージョンからStarRocks3.0Xストレージ-コンピューティング分離バージョンにアップグレードされ、大規模な運用環境に導入されました。

リアルタイムおよびオフラインのレイクウェアハウスの統合のアーキテクチャ図:

詳細モデル

ビッグデータ本番環境で最も一般的なログデータは、大量のデータ、多次元の柔軟で複雑な計算、多くの計算インジケータ、強力なリアルタイムパフォーマンス、第 2 レベルの高性能クエリ、シンプルで安定したという特徴があります。リアルタイムのストリーム書き込み、大規模なテーブル結合、高カーディナリティの重複排除。

これらの要素は、Flink SQL+StarRocks で満たすことができます。まず、リアルタイムプラットフォームで Flink SQL を使用して、リアルタイムストリーミングログデータを迅速にクリーンアップして拡張します。同時に、StarRocks は、Flink-Connector-StarRocks コネクタ出力を提供します。 ExactlyOnce とトランザクションのサポート、ストリームロードによる低遅延、高速インポートをサポートします。

例えば：

効率的でシンプルな Flink SQL テーブル構築モードにより、数百万のデータのバッチが書き込まれ、速度が速いと同時に、複数のテーブルが存在する運用環境での単一テーブルに対する多次元ユーザーアクセスの数が減少します。ユーザーの重複排除データは第 2 レベルに達する可能性があります。

主キーモデル

OLAP データウェアハウスでは、一般に可変データは嫌われます。

データウェアハウスでのデータ変更方法の場合:

方法 1: 一部の OLAP データウェアハウスは、(クリックハウスなど) データ変更を完了するための Merge on Read モデルの更新機能を提供します。
方法 2: 簡単に言うと、新しいパーティションテーブルを作成し、古いパーティションテーブルのデータを削除して、バッチでフラッシュします。

変更したデータを新しいパーティションに挿入し、パーティション交換によりデータ変更を完了します。

バッチフラッシュでは、テーブルが再構築され、パーティションデータが削除されますが、データフラッシュのプロセスは複雑で、エラーが発生する可能性があります。

Merge on Read モードは、書き込み時はシンプルで効率的ですが、読み取り時はバージョンのマージに多くのリソースを消費します。同時に、マージ演算子の存在により、述語をプッシュダウンできず、インデックスを更新できません。が使用され、クエリのパフォーマンスに重大な影響を与えます。StarRocks は、削除および挿入モードに基づいた主キーモデルを提供しており、バージョンのマージにより演算子をプッシュダウンできない問題を回避します。主キーモデルは、データをリアルタイムで更新する必要があるシナリオに適しています。行レベルの更新操作をより適切に解決し、100 万レベルの TPS をサポートできます。MySQL またはその他のビジネスライブラリが StarRocks に同期されているシナリオに特に適しています。

さらに、Flink CDC と StarRocks の完璧な組み合わせにより、ビジネスデータベースから OLAP データウェアハウスまでのエンドツーエンドの完全 + 増分リアルタイム同期を実現でき、1 つのタスクですべてのバッチおよびリアルタイムの問題を高い効率と安定性で解決できます。。同時に、主キーモデルは、Flink でのリトレースメントストリーム出力の問題も解決でき、条件による更新をサポートし、列による更新をサポートするなど、従来の OLAP データベースにはない多くの利点を同時に備えています。

Flink CDC+StarRocks モデルは、実稼働環境における多くの問題を解決できます。リアルタイムデータ分析システムを構築するための StarRocks と Flink の共同ソリューションは、既存の制限をある程度覆し、リアルタイムデータの新しいパラダイムを形成します。リアルタイムのログデータとビジネスデータは、従来のオフラインデータのバッチ抽出の問題も解決し、オフラインデータとリアルタイムデータの統合を実現し、ストリームとバッチの統合プロセスを高速化します。

集約モデル

リアルタイムデータウェアハウスには別のシナリオがあります。元の詳細データはあまり気にしません。それらのほとんどは、SUM、MAX、MIN およびその他の種類のクエリなどの概要クエリです。古いデータは更新されません。頻繁に追加され、新しいデータのみが追加される場合は、集計モデルの使用を検討できます。テーブルの作成時に、ソートキーとインデックス列の定義、およびインデックス列の集計関数の指定がサポートされます。複数のデータが同じソートキーを持つ場合、インデックス列が集計されます。統計を分析してデータを要約する場合、集約モデルにより、クエリ中に処理する必要があるデータが削減され、クエリの効率が向上します。

以前は、統計のためにこれらの操作を Flink に入れることがありました。状態データはメモリ内に存在するため、状態データは増大し続け、多くのリソースを消費します。Flink の単純な統計を Flink SQL+StarRocks 集計モデルに変更します。 , Flink ここでは、詳細データをクリーンアップして StarRocks にインポートするだけで済み、非常に効率的で安定しています。

実際の制作では主にユーザーの閲覧時間やクリック数、注文統計などをカウントするために使用します。

マテリアライズドビュー

データウェアハウス環境のアプリケーションは多くの大きなテーブルに対して複雑なクエリを実行することが多く、これには複数のテーブルにわたる数十億行のデータの関連付けと集計が含まれることがよくあります。リアルタイムの複数テーブルの関連付けとクエリ結果のこの方法を実現するには、このコンテンツを Flink リアルタイムデータウェアハウスに入れて処理し、関連付けの階層化処理、結合、統計、その他のタスクを実行し、最後に結果レイヤーを出力します。このようなクエリの処理には通常、大量のシステムリソースと時間が消費され、クエリコストが非常に高くなります。

この大規模な階層コンピューティングの問題に対処するために、Flink SQL+StarRocks という新しいアイデアの使用を検討できるようになりました。これにより、Flink SQL はここでいくつかの単純なクリーニングタスクを処理するだけで済み、多数の反復計算ロジックをプッシュダウンできます。 StarRocks に転送して実行します。リアルタイムストリームがリアルタイムに到達し、マルチレベルマテリアライズドビューのモデリング方法を StarRocks で確立できます。StarRocks のマテリアライズドビューは、内部テーブルと内部テーブル間の関連付けをサポートするだけでなく、内部テーブルと外部テーブル間の関連付けをサポートします。たとえば、MySQL、Hudi、Hive などにあるデータは、StarRocks マテリアライズドビューを通じて高速化され、定期的な更新ルールを設定して、関連するタスクの手動スケジュールを回避できます。最大の特徴の一つがマテリアライズド・ビューを構築しており、マテリアライズド・ビューを構築した実表に対して新たなクエリが発生した際に、マテリアライズド・ビューの事前計算結果を再利用して処理できるかシステムが自動的に判断します。クエリ。再利用できる場合、システムは関連するマテリアライズドビューから事前計算された結果を直接読み取り、システムリソースと時間を消費する計算の繰り返しを回避します。クエリの頻度が高くなるほど、またはクエリステートメントが複雑になればなるほど、パフォーマンスの向上はより明らかになります。

リアルタイムは未来であり、StarRocks はこの機能を徐々に実現しつつあり、リアルタイムデータ分析システムを構築するための StarRocks と Flink の共同ソリューションは、既存の制限をある程度覆し、リアルタイムデータの新しいパラダイムを形成するでしょう。分析。

今後の展望

湖と倉庫を統合

現在、Mango TV ではストリームとバッチを統合したデータウェアハウスの構築を実現しており、今後は統合されたレイクウェアハウスの構築に注力していきます。

データレイクは、構造化データ、半構造化データ、非構造化データなど、さまざまな種類と形式の生データを保存できる機能を特徴としています。データウェアハウスとは、特定のビジネスニーズを満たすためにデータを構造化および整理することです。

レイクとウェアハウスの統合は、データウェアハウスとデータレイクの特性を統合し、統合されたデータセンターを構築し、データの一元管理を実現します。レイクとウェアハウスの統合アーキテクチャにより、優れたセキュリティ、費用対効果、オープン性が提供され、大量の生データを保存および管理できるだけでなく、データを構造化された形式に整理して分析やクエリを容易にすることもできます。

レイクとウェアハウスの統合を通じて、Mango TV は企業により豊富なデータサービスを提供し、ビジネスの意思決定とイノベーションをサポートし、データの収集、保管、処理、分析を含むデータの包括的な制御と管理を実現できます。同時に、レイクとウェアハウスの統合により、Flink、Spark、Hive などの複数のコンピューティングエンジンとツールの使用もサポートされ、データの処理と分析がより柔軟かつ効率的になります。

ローコード

現在の開発方法は、自社開発プラットフォーム上で SQL 送信タスクを記述することですが、一部のクリーニングシナリオに直面した場合、この方法のほとんどは反復作業であり、改善の余地が多くあります。ローコードは現在人気の概念であり、コストの削減と効率の向上に大きな利点があります。次の計画は、段階的にローコードを実現することです。最初の段階は、リアルタイムプラットフォームとデータレポートプラットフォームを接続することです。レポートプラットフォームで関連するメタデータを読み取ることで、対応するデータクリーニングタスクを自動的に生成し、生産性を解放し、作業の効率化と納期の短縮。

ローコードの利点は、開発プロセスの繰り返し作業を自動化および簡素化できることで、開発者のコーディング作業負荷を軽減できることです。開発者は視覚的にドラッグして構成することができ、多くのコードを記述することなくタスクを完了できます。これにより、開発効率が向上するだけでなく、エラーのリスクも軽減されます。

ローコード開発アプローチを実装することで、Mango TV はデータの処理と分析を高速化し、チームの全体的な効率を向上させることができます。さらに、ローコードにより開発者の技術要件も軽減され、より多くの人がデータの処理と分析に参加できるようになります。

要約すると、Mango TV は、Flink テクノロジーの特性に基づいて、将来のデータウェアハウス構築において、データの包括的な管理と活用を実現するために、レイクとウェアハウスの統合アーキテクチャの実現に焦点を当てます。同時に、Mango TV は開発効率と配信速度を向上させるために、ローコード開発手法を段階的に導入する予定です。これらの取り組みにより、長時間ビデオデータ分析分野における Mango TV の開発がさらに促進され、ビジネスの意思決定とイノベーションをより強力にサポートできるようになります。

▼「Apache Flinkパブリックアカウント提出」、皆様の長期参加を歓迎します▼