Kafka+Flinkプラットフォーム設計に基づいて、リアルタイムデータウェアハウスも次のように構築できます。

この記事は、NetEase Cloud Music のリアルタイムコンピューティングプラットフォーム開発エンジニアである Yue Meng 氏が共有したものです。 NetEase Cloud MusicにおけるFlink + Kafkaの実践的な応用を主に以下の4つの部分から紹介します。

背景

Flink + Kafka プラットフォーム設計
リアルタイムデータウェアハウスにおける Kafka の応用
問題点と改善点

1. 背景

1. ストリーミングプラットフォームの一般的なフレームワーク

現在のストリーミングプラットフォームの一般的なアーキテクチャには、通常、メッセージキュー、コンピューティングエンジン、ストレージの 3 つの部分が含まれます。一般的なアーキテクチャを下図に示します。クライアントまたは Web ログはメッセージキューに収集されます。コンピューティングエンジンはメッセージキュー内のデータをリアルタイムで計算します。リアルタイム計算結果は、追加または更新の形式でリアルタイムストレージシステムに保存されます。

現在、私たちがよく使用するメッセージキューは Kafka です。当初は、コンピューティングエンジンとして Spark Streaming を使用していました。ストリームコンピューティングエンジンにおける Flink の利点がますます明らかになったため、最終的に、Flink を統合リアルタイムコンピューティングエンジンとして使用することを決定しました。

2. Kafka を選ぶ理由

Kafka は比較的初期のメッセージキューですが、NetEase を含む多数のユーザーグループが利用する非常に安定したメッセージキューです。私たちがメッセージングミドルウェアとして Kafka を検討している主な理由は次のとおりです。

高スループット、低レイテンシ: 数十万 QPS とミリ秒単位のレイテンシ。
高い同時実行性: 数千のクライアントによる同時読み取りと書き込みをサポートします。
フォールトトレランスと高い信頼性: データのバックアップをサポートし、ノード損失を許容します。
スケーラビリティ: 現在のオンラインビジネスに影響を与えることなく、ホット拡張をサポートします。

3. Flink を選ぶ理由

Apache Flink は、近年ますます人気が高まっているオープンソースのビッグデータストリーミングコンピューティングエンジンです。バッチ処理とストリーム処理の両方をサポートします。ストリーミングコンピューティングエンジンとして Flink を検討する主な要因は次のとおりです。

高いスループット、低レイテンシ、高パフォーマンス。
非常に柔軟なストリーミングウィンドウ。
状態計算のための正確に 1 回のセマンティクス。
軽量フォールトトレランスメカニズム。
EventTime と順序外イベントをサポートします。
ストリームとバッチの統合エンジン。

4. Kafka + Flink ストリームコンピューティングシステム

メッセージミドルウェアとストリームコンピューティングにおける Kafka と Flink の優れたパフォーマンスに基づいて、次の図に示すように、Kafka と Flink に基づくストリームコンピューティングプラットフォームシステムが登場しました。リアルタイムログは、APP、Web などを通じて Kafka に収集され、その後、共通 ETL、グローバル集計、ウィンドウ集計などのリアルタイム計算のために Flink に引き渡されます。

5. Kafka を使用した NetEase Cloud Music の現状

現在、10 を超える Kafka クラスターがあり、各クラスターの主なタスクは異なります。一部はビジネスクラスターとして使用され、一部はミラークラスターとして使用され、一部はコンピューティングクラスターとして使用されます。現在の Kafka クラスターのノードの総数は 200 以上に達し、単一の Kafka のピーク QPS は 400 万以上です。現在、NetEase Cloud Music には、Kafka + Flink に基づく 500 を超えるリアルタイムタスクがあります。

2. Flink+Kafka プラットフォームの設計

上記の状況を踏まえ、私たちはKafka+Flinkをユーザーの開発コストや運用保守コストを削減するプラットフォームとして開発したいと考えています。実際、2018年にはFlinkをベースにしたリアルタイムコンピューティングプラットフォームの構築を開始しており、その中でKafkaが重要な役割を果たしました。今年は、ユーザーがFlinkとKafkaをより便利に、より簡単に利用できるようにするために、リファクタリングを行いました。

Flink 1.0 をベースに Magina バージョンをリファクタリングしました。 API レベルでは、DataStream および SQL 操作を実行するための Magina SQL と Magina SDK を提供しました。次に、Magina SQL Parser をカスタマイズしてこれらの SQL を論理プランに変換し、論理プランを物理的な実行コードに変換しました。このプロセス中に、カタログを介してメタデータ管理センターに接続し、いくつかのメタデータ情報を取得しました。 Kafka を使用する場合、Kafka メタデータ情報をメタデータセンターに登録し、ストリームテーブルの形式でリアルタイムデータにアクセスします。 Magina では、Kafka を主に 3 つの方法で使用します。

クラスターカタログ作成。
トピックストリームテーブル。
メッセージの図式化。

ユーザーは、メタデータ管理センターにさまざまなテーブル情報やカタログ情報を登録したり、DB に Kafka テーブルを作成して管理したりできます。使用中、ユーザーは個人的なニーズに応じて対応するテーブルを使用するだけです。次の図は、Kafka ストリームテーブルの主な参照ロジックを示しています。

3. リアルタイムデータウェアハウスにおける Kafka の応用

1. 問題解決を通じて成長する

リアルタイムデータウェアハウスで Kafka を使用する過程で、さまざまな問題が発生し、さまざまな解決策を試しました。

プラットフォームの初期の頃は、リアルタイムコンピューティング用のクラスターが 2 つと、コレクションクラスターが 1 つしかありませんでした。 1 つのトピックのデータ量が非常に大きかったです。異なるリアルタイムタスクが同じ大容量のトピックを消費し、Kafka クラスターの IO 圧力が非常に高くなりました。

そのため、使用中に Kafka に異常に高い負荷がかかり、遅延や I/O の急増が頻繁に発生することが判明しました。

上記の問題を解決するために、大規模なトピックをリアルタイムで配信することを考えました。 Flink 1.5をベースに、次の図のようなデータ配信プログラムを設計しました。これがリアルタイムデータウェアハウスのプロトタイプです。大きなトピックを小さなトピックに分散するこの方法に基づいて、クラスターへの負荷が大幅に軽減され、パフォーマンスが向上します。さらに、当初は静的な配布ルールが使用されていました。後からルールを追加する必要がある場合、タスクを再開する必要があり、ビジネスに大きな影響を与えていました。その後、動的ルールを使用してデータ配布のタスクを完了することを検討しました。

プラットフォームの初期段階で遭遇した問題を解決した後、Kafka はプラットフォームの進化の過程で新たな問題に直面しました。

クラスターは拡張されましたが、ワークロードも増加し、Kafka クラスターへの負荷は高まり続けました。
クラスターの圧力が増加すると、I/O 関連の問題が発生する可能性があり、コンシューマータスクが互いに影響し合う可能性が高くなります。
ユーザーがさまざまなトピックを消費する場合、中間データの着陸がないため、繰り返し消費することになりやすい。
タスクを Kafka に移行するのは困難です。

上記の問題に対処するために、次の図に示すように、Kafka クラスターの分離とデータの階層化を実装しました。簡単に言えば、クラスターを DS クラスター、ログ収集クラスター、および配布クラスターに分割するプロセスです。データは配信サービスを通じて処理のために Flink に配信され、その後、データクリーニングを通じて DW クラスターに入ります。同時に、DW 書き込みプロセス中にミラークラスターに同期されます。このプロセスでは、Flink を使用してリアルタイム計算統計とスプライシングも実行され、生成された ADS データはオンライン ADS クラスターと統計 ADS クラスターに書き込まれます。上記のプロセスにより、リアルタイムコンピューティング要件が高いタスクが統計レポートの影響を受けないことが保証されます。

上記のプロセスにより、リアルタイムコンピューティング要件が高いタスクが統計レポートの影響を受けないことが保証されます。しかし、異なるクラスターを分散すると、必然的に新たな問題に直面します。

Kafka クラスターのステータスをどのように認識しますか?
ジョブ消費の異常を迅速に分析するにはどうすればよいでしょうか?

上記の 2 つの問題に対処するために、次の 2 つの側面でシステムを監視する Kafka 監視システムを開発しました。これにより、例外が発生したときに問題の詳細を判断できます。

クラスターの概要監視: さまざまなクラスターに対応するトピックの数と実行中のタスク、各トピックで消費されたデータの量、データ流入量、流入量の合計、各データ項目の平均サイズを確認できます。
メトリクスの監視: Flink タスクと、対応するトピック、グループ ID、クラスター、起動時間、入力帯域幅、InTPS、OutTPS、消費遅延、およびラグを確認できます。

2. LambdaアーキテクチャにおけるFlink + Kafkaの応用

ストリーム処理とバッチ処理の統合は現在非常に人気の高いコンセプトであり、多くの企業もこの分野での応用を検討しています。現在、一般的に使用されているアーキテクチャは、Lambda アーキテクチャまたは Kappa アーキテクチャのいずれかです。ストリームとバッチの統合には、ストレージの統合とコンピューティングエンジンの統合を考慮する必要があります。現在のインフラストラクチャには統合ストレージがないため、Lamda アーキテクチャのみを選択できます。

次の図は、Cloud Music における Flink と Kafka に基づく Lambda アーキテクチャの具体的な実践を示しています。上位層はリアルタイムコンピューティング、下位層はオフラインコンピューティングです。水平層はコンピューティングエンジンによって分割され、垂直層はリアルタイムデータウェアハウスによって分割されます。

4. 問題点と改善点

具体的な申請手続きにおいても、多くの問題に遭遇しました。主な問題は 2 つあります。

複数のシンクの下での Kafka ソースの繰り返し消費の問題。
同じスイッチ上のトラフィックの急増により、コンピューティングの遅延の問題が発生します。

1. 複数のシンクを伴う Kafka ソースの繰り返し消費問題

Magina プラットフォームは複数のシンクをサポートしているため、操作中に中間結果を異なるストレージに挿入できます。このプロセスで問題が発生します。たとえば、同じ中間結果の異なる部分を異なるストレージに挿入すると、複数の DAG が存在することになります。これらはすべて一時的な結果ですが、Kafka ソースの繰り返し消費を引き起こし、パフォーマンスとリソースの大きな浪費につながります。

そこで、一時的な中間結果の複数回の消費を回避できるかどうか疑問に思いました。バージョン 1.9 より前では、StreamGraph を再構築し、3 つの DataSource の DAG をマージしました。バージョン 1.9 では、Magina はクエリとソースのマージの最適化も提供しました。ただし、同じデータ更新で同じテーブルへのソース参照が複数ある場合は、それらは自動的にマージされますが、同じデータ更新でない場合はすぐにはマージされないことがわかりました。そのため、バージョン 1.9 以降では、この問題を解決するために、modifyOperations 用のバッファーを作成しました。

2. 同じスイッチでのトラフィックの急増によりコンピューティングの遅延が発生する

この問題は最近になって発生したばかりで、同じスイッチだけでなく、同じコンピュータールームでも発生する可能性があります。同じスイッチの下に多数のマシンをデプロイし、そのうちのいくつかには Kafka クラスターをデプロイし、いくつかには Hadoop クラスターをデプロイしました。 Hadoop では、Spark や Hive のオフラインコンピューティングと、Flink のリアルタイムコンピューティングを実行できます。 Flink はリアルタイムコンピューティングに Kafka も使用します。実行プロセス中に、特定のタスクに全体的な遅延が発生することがわかりました。調査の結果、ある時点でスイッチの閲覧が急増した以外は、異常は見つかりませんでした。さらに調査を進めると、オフラインコンピューティングの閲覧の急増が原因であることが判明しました。同じスイッチの帯域幅制限により、Flink のリアルタイムコンピューティングが影響を受けました。

この問題を解決するために、オフラインクラスターとリアルタイムクラスターの相互影響を回避し、スイッチの展開やマシンの展開を最適化することを検討しました。たとえば、オフラインクラスターは別のスイッチを使用し、Kafka クラスターと Flink クラスターも別のスイッチを使用して、ハードウェアレベルで 2 つが相互に影響を与えないようにします。