リアルタイム データ システム設計: Kafka、Flink、Druid

下の「JavaEdge」をクリックし、「スターとして設定」を選択します。

技術情報はお早めに!

免責事項~

どの記事も考えすぎないでください。

世界には同じ成長環境や同じレベルの認知が存在しないため、すべてが精査に耐えることはできません。また「すべての人に適用できる解決策はない」 a>;

記事に記載されている意見を急いで判断する必要はありません。ただ自分の気持ちを取り入れて、自分自身を適度に観察してください。部外者の視点から見た状況。あなたは一般人になる前のどの段階にいますか?

何を考え、何をするかはすべてあなた次第です「継続的な練習を通じて、自分に合った道を見つけてください」

0 まえがき

バッチ ワークフローを使用するデータ チームにとって、今日のリアルタイムの需要を満たすことは簡単ではありません。なぜ?データの配信から処理、分析までのバッチ ワークフローには多くの待ち時間がかかるためです。

データが ETL ツールに送信されるのを待機し、データがバッチ処理されるのを待機し、データがデータ ウェアハウスにロードされるのを待機し、さらにはクエリの実行が終了するのを待機します。

ただし、オープンソースの世界からこの問題に対する解決策があります。 Apache Kafka、Flink、Druid を組み合わせて使用​​すると、これらの待機状態をすべて排除するリアルタイム データ アーキテクチャが作成されます。このブログ投稿では、これらのツールを組み合わせてさまざまなリアルタイム データ アプリケーションをどのように実現できるかについて説明します。

9825e74927a7019bf1c98b6305e2d9ef.png

Kafka-Flink-Druid のソースからアプリケーションへの回路図データ フロー。

1 リアルタイム データ アプリケーションを構築するためのアーキテクチャ

まず、リアルタイム データ アプリケーションとは何ですか?最新のデータを使用してリアルタイムの洞察や意思決定を提供する UI または API 駆動のアプリケーションを考えてみましょう。これには、アラート、モニタリング、ダッシュボード、分析、パーソナライズされた推奨事項などが含まれます。

これらのワークフローを提供するには、イベントからアプリケーションまでのパイプライン全体を処理できる特殊なツールが必要です。ここで、Kafka-Flink-Druid (KFD) アーキテクチャが登場します。

7ef93e05f50af6d31708a29d22559061.png

オープンソースのリアルタイム データ アーキテクチャ

Lyft、Pinterest、Reddit、Paytm などのリアルタイム ニーズを持つ大企業は、この 3 つすべてを使用しています。これらはすべて、リアルタイムのユースケースの度合い、規模、信頼性に必要なデータの鮮度をシームレスに提供できる、補完的なストリーミング ネイティブ テクノロジーで構築されているためです。 。

このアーキテクチャにより、可観測性、IoT/テレメトリ分析、セキュリティ検出/診断、顧客向けの洞察など、高スループットの QPS リアルタイム データ アプリケーションを簡単に構築できます。

各ツールをさらに詳しく見て、それらがどのように連携するかを見てみましょう。

2 パイプライン: Apache Kafka

過去数年間で、Apache Kafka はストリーミング データの事実上の標準になりました。以前は、RabbitMQ、ActiveMQ、およびその他のメッセージ キュー システムを使用して、プロデューサーからコンシューマーにデータを配信するためのさまざまなメッセージング モードが提供されていましたが、規模の制限がありました。

今日に遡ると、Kafka は至るところに普及しており、Fortune 100 企業の 80% 以上が Kafka を使用しています¹。これは、Kafka のアーキテクチャが単純なメッセージングをはるかに超えているためです。 Kafka は、そのアーキテクチャの多用途性により、ミッション クリティカルなアプリケーションをサポートするフォールト トレランスとデータの一貫性を備え、大規模な「インターネット」規模でのストリーム処理に最適であり、Kafka Connect を介したさまざまなコネクタがあらゆるデータ ソース統合に接続します。

9c4ec0f0fa415192ed5bf703b1089ccf.png

3 ストリーム処理: Apache Flink

Kafka はリアルタイム データを提供するため、その速度とスケールを活用するには適切なコンシューマーが必要です。人気のある選択肢の 1 つは Apache Flink です。

フリンクを選ぶ理由まず、Flink は、統合されたバッチおよびストリーム処理エンジンを備えており、大規模な連続データ ストリームの処理において非常に強力です。 Kafka のストリーム プロセッサとして Flink を選択するのは自然な選択です。その理由は、システム障害が発生した場合でも、各イベントが確実に 1 回だけ処理されるように、シームレスに統合して 1 回限りのセマンティクスをサポートできるからです。

使用方法は非常に簡単です。Kafka トピックに接続し、クエリ ロジックを定義し、継続的に結果を出力します (つまり、「設定して忘れる」)。これにより、ストリームを即座に処理して信頼性を確保する必要があるユースケースにおいて、Flink は非常に柔軟になります。

Flink の一般的な使用例をいくつか示します。

  • 豊かにして変革する

  • 継続的な監視とアラート

豊かにして変革する

ストリームで使用前にデータ操作 (データの変更、強化、再構築など) が必要な場合、Flink は継続的な処理を通じてデータを最新の状態に保つことができるため、これらの変更や強化を行うのに最適なエンジンです。

たとえば、スマート ビルディングの温度センサーを扱う IoT/テレメトリのユースケースがあるとします。 Kafka に渡される各イベントには、次の JSON 構造があります。

{
  "sensor_id": "SensorA",
  "temperature": 22.5,
  "timestamp": "2023–07–10T10:00:00"
}

各センサー ID を場所にマッピングする必要があり、温度を華氏で表す必要がある場合、Flink は JSON 構造を次のように更新できます。

{
  "sensor_id": "SensorA",
  "location": "Room 101",
  "temperature_Fahreinheit": 73.4,
  "timestamp": "2023–07–10T10:00:00"
}

アプリケーションに直接送信するか、Kafka に送り返します。

![img](https://miro.medium.com/v2/resize:fit:700/0*GZfCTvfy)

hhQOxZqb.png)

Flink を使用したイベントベースのデータ エンリッチメントの例 (画像提供: Simply.io)

ここで、Flink の強みの 1 つは、1 秒あたり数百万のイベントに達する巨大な Kafka ストリームをリアルタイムで処理できるスケールです。さらに、エンリッチメント/変換は通常ステートレスなプロセスであり、永続的な状態を維持する必要なく各データ レコードを変更できるため、コスト効率とパフォーマンス効率が最小限になります。

継続的な監視とアラート

Flink は、リアルタイムの連続処理とフォールト トレランスの組み合わせにより、さまざまな重要なアプリケーションに対するリアルタイムの検出と応答のための理想的なソリューションにもなります。

検出の感度が非常に高く (1 秒未満を考えてください)、サンプリング レートも高い場合、Flink の連続処理は、状態を監視し、対応するアラートとアクションをトリガーするデータ サービス レイヤーとして使用するのに理想的です。

アラートに関する Flink の利点の 1 つは、ステートレス アラートとステートフル アラートの両方をサポートしていることです。 「温度が X に達したら消防署に通知する」などのしきい値やイベント トリガーは簡単ですが、必ずしも十分に賢明であるとは限りません。したがって、Flink は、連続的なデータ ストリームを通じて状態の監視と更新を行って逸脱と異常を特定する必要があるユースケースで、状態を監視して更新して逸脱と異常を特定できます。

考慮すべき点の 1 つは、クエリの実行中にのみ CPU を使用するデータベースとは異なり、Flink を使用した監視とアラートには、しきい値やパターンに照らして条件を評価するための継続的な CPU、つまり継続的なコストとリソースが必要であるということです。したがって、継続性が必要かどうかを知ることは良い考えです。

4 リアルタイム分析: Apache Druid

Apache Druid はデータ アーキテクチャ パズルの最後のピースであり、Kafka や Flink とともにストリーム コンシューマとなり、リアルタイム分析をサポートします。これは分析用のデータベースですが、その設計の中心と目的は他のデータベースやデータ ウェアハウスとは異なります。

まず第一に、ドルイドはカフカとフリンクの兄弟のようなものです。ストリームネイティブでもあります。実際、Kafka コネクタに接続せずに Kafka トピックに直接接続し、1 回限りのセマンティクスをサポートします。 Druid は、大規模なストリーミング データを迅速に取り込み、メモリ内のイベントが到着するとすぐにクエリを実行できるように設計されています。

95a5522dfa824b12823d65416a871159.png

Druid の取り込みプロセスは、各イベント取り込み用にネイティブに設計されています。

クエリ側では、Druid は大規模かつ負荷に応じて 1 秒未満のクエリを実行できる高性能のリアルタイム分析データベースです。ユースケースがパフォーマンスを重視し、テラバイトからペタバイトのデータ (集約、フィルタリング、GroupBy、複雑な結合など) と大量のクエリを処理する必要がある場合、常に超高速のクエリを提供する Druid が理想的なデータベースです。また、1 台のラップトップから数千ノードのクラスターまで簡単に拡張できます。

これが、Druid がリアルタイム分析データベースと呼ばれる理由です。リアルタイム データがリアルタイム クエリにフィードされる場合に理想的です。

Druid が Flink をどのように補完するかは次のとおりです。

  • 高度にインタラクティブなクエリ

  • リアルタイムデータと履歴データ

高度にインタラクティブなクエリ

エンジニアリング チームは Druid を使用して分析アプリケーションを強化します。これらは、内部 (つまり、運用) と外部 (つまり、顧客対応) の両方のユースケースを含むデータ集約型アプリケーションであり、観察、セキュリティ、製品分析、IoT/テレメトリ、製造業務などの領域をカバーします。 Druid を利用したアプリケーションには通常、次のような特徴があります。

  • **大規模なパフォーマンス:** 大規模なデータ セットに対して分析クエリが必要な場合、事前計算は必要ありません。 Druid は、アプリケーションのユーザーがテラバイトからペタバイト規模のデータを任意にグループ化、フィルタリング、スライス/ダイスした場合でも、非常に高いパフォーマンスを実現します。

  • **高いクエリ量:** 分析クエリには高い QPS が必要です。ここでの例としては、100 ~ 1000 個の (個別の) 同時クエリを生成するワークロードに対して 1 秒未満の SLA を提供する必要がある外部向けアプリケーション (つまりデータ製品) が挙げられます。

  • **時系列データ:**時間次元でデータに関する洞察を提供する必要があるアプリケーション (Druid の強みですが、制限ではありません)。 Druid は、その時間分割とデータ形式により、時系列データを非常に高速に処理できます。これにより、時間ベースのフィルターが非常に高速になります。 WHERE

これらのアプリケーションは、実行時にクエリを変更できる柔軟性を備えた非常にインタラクティブなデータ視覚化/合成結果セット UI を備えているか (Druid が非常に高速であるため)、多くの場合、Druid の API を利用して 1 秒未満の速度でクエリを配信します。大規模な意思決定ワークフロー。

以下は、Apache Druid を利用した分析アプリケーションの例です。

f7ece258f54b0ef5bc0d3ebcd99bd8c0.gif

Confluent Health+ は Apache Druid を利用しています。

Apache Kafka のオリジナルの作成者である Confluent は、Confluent Health+ を通じて顧客に分析サービスを提供しています。上記のアプリケーションは非常にインタラクティブであり、顧客の Confluent 環境に関する豊富な洞察が得られます。舞台裏では、イベントが 1 秒あたり 500 万イベントの速度で Kafka と Druid に流れ込み、アプリケーションは 1 秒あたり 350 のクエリを処理しています。

リアルタイムデータと履歴データ

上の例は、Druid が非常にインタラクティブな分析アプリケーションをサポートしていることを示していますが、「ストリーミング データがこれにどのように関係しているの?」と疑問に思われるかもしれません。 Druid はストリーミング データに限定されないため、これは良い質問です。大量のファイルを取り込むのに最適です。

ただし、Druid がリアルタイム データ アーキテクチャに関連する理由は、より豊富なコンテキストを実現するために、リアルタイム データと履歴データに基づいたインタラクティブなデータ エクスペリエンスを提供できることです。

Flink は「今何が起こっているか」(つまり、Flink ジョブの現在の状態を出力する) に答えるのが得意ですが、Druid は「今何が起こっているのか、以前と比較してどうなのか、結果に影響を与えた要因/条件は何か」に技術的に答えることができます。これらの質問を組み合わせると強力で、たとえば、誤検知を排除し、新しい傾向の検出に役立ち、より深いリアルタイムの意思決定につながる可能性があります。

「以前と比べてどうですか」に答えるには、相関関係を作成するために、過去のコンテキスト (日、週、年、またはその他の時間枠) が必要です。そして、「どの要因/条件が結果に影響を与えたか」をデータセット全体から掘り出す必要があります。 Druid はリアルタイム分析データベースであるため、ストリームを取り込んでリアルタイムの洞察を提供しますが、データも保持するので、アドホックな探索のために履歴データやその他すべての次元をクエリできるようになります。

9b5eac30c040e4db23f6c2434dac2b4b.gif

Apache Druid はリアルタイム取り込みを拡張し、トピックを取り込みタスクにマッピングします。

たとえば、安全なログインで不審な動作がないか監視するアプリケーションを構築しているとします。 5 分以内のしきい値を設定するとよいでしょう。つまり、ログイン試行のステータスが更新され発行される時間です。 Flinkを使えば簡単です。ただし、Druid を使用すると、現在のログイン試行を履歴データと関連付けて、セキュリティ上の問題がなかった過去の同様のログインの急増を特定することもできます。したがって、ここでの歴史的背景は、現在のスパイクが問題を示しているのか、それとも単なる通常の動作であるのかを判断するのに役立ちます。

したがって、アプリケーションが、現在の状態、さまざまな集計、グループ化、時間枠、複雑な結合などの変化するイベントに関する多くの分析を提供する必要がある場合に、同時に履歴コンテキストを提供し、非常に柔軟な API を通じてそのデータセットを探索することもできます。今回はドルイドが最強エリアです。

5 フリンクとドルイドのチェックリスト

Flink と Druid はどちらもストリーミング データ用に構築されています。これらは高レベルでいくつかの類似点を共有していますが、両方ともインメモリであり、両方ともスケーリング可能で、両方とも並列化可能ですが、これらのアーキテクチャは実際には、上記のようなまったく異なるユースケース向けに構築されています。

ワークロードに基づいた簡単な意思決定リストを次に示します。

  1. ストリーミング データ上でリアルタイムにデータを変換または結合する必要がありますか? Flink をチェックしてください。これが最も優れた機能であり、リアルタイム データ処理用に設計されています。

  2. 多くの異なるクエリを同時にサポートする必要がありますか? Druid は、クエリ/ジョブの管理を必要とせずに高い QPS 分析をサポートしているため、確認してください。

  3. 指標は継続的に更新または集計する必要がありますか? ステートフルな複雑なイベント処理をサポートしている Flink をチェックしてください。

  4. 分析はより複雑で、比較のために履歴データが必要ですか? Druid を使用すると、履歴データを使用してリアルタイム データを簡単かつ迅速にクエリできるようになります。

  5. ユーザー インターフェイス アプリケーションまたはデータの視覚化に対するサポートは提供されていますか? Flink を見てエンリッチメントを行い、データをデータ サービス レイヤーとして Druid に送信します。

ほとんどの場合、答えはドルイドかフリンクではなく、ドルイドとフリンクです。それぞれが提供する技術的特徴により、さまざまなリアルタイム データ アプリケーションのサポートに総合的に適しています。

6 結論

企業はデータ チームからのリアルタイム データをますます必要としています。これは、データ ワークフローを最初から最後まで再検討する必要があることを意味します。これが、多くの企業がリアルタイム データ アプリケーションを構築するための事実上のオープン ソース データ アーキテクチャとして Kafka-Flink-Druid を考慮している理由です。彼らは完璧な三銃士です。

Kafka-Flink-Druid アーキテクチャを試すには、ここからオープン ソース プロジェクト (Kafka、Flink、Druid) をダウンロードするか、Confluent Cloud と Imply Polaris、Kafka-Flink (Confluent) および Druid (Imply) の無料トライアルを入手してください。それぞれクラウドサービスです。

参考:

  • 番組選択ネットワーク

最後に書きます

プログラマー向けの生涯学習 Web サイトである Programming Select Network (www.javaedge.cn) がオンラインになりました。

クリックして原文を読み、ウェブサイトにアクセスしてください。

欢迎长按图片加好友,我会第一时间和你分享软件行业趋势面试资源学习途径等等。

c401a9a825bedaad4df690cc35246c47.jpeg友人のメモ [テクニカル グループ コミュニケーション] を追加してグループに参加すると、より多くのチュートリアル リソースが見つかります。

公式アカウントをフォローした後、バックグラウンドでプライベート メッセージを送信します。

  • 返信[アーキテクト]、アーキテクト学習リソースのチュートリアルを入手してください

  • [面接] に返信すると、大手インターネット企業の最新かつ完全な面接資料が入手できます。

  • [履歴書] に返信すると、美しいスタイルと豊富なコンテンツを備えたさまざまな履歴書テンプレートを入手できます。

  • 回复 路线图,获取直升Java P7技术管理的全网最全学习路线图

  • 返信ビッグデータ、Java 変換を取得ビッグデータの研究開発のためのインターネット全体の最も包括的なマインド マップ

  • WeChat [ssshflz] プライベート メッセージ [副業]、副業コミュニケーション グループに参加する

  • クリック[元のテキストを読む] にアクセスしますプログラマー向けのワンストップ学習 Web サイト

おすすめ

転載: blog.csdn.net/qq_33589510/article/details/134980217