カフカも理解していないのに、面接を受けに行くのですか？

[51CTO.com からのオリジナル記事] Apache Kafka は、最も人気のあるエンタープライズ レベルのメッセージング システムとして知られています。当初の目的は、レコード ストリームの公開とサブスクライブを行う分散ストリーミング システムを実現することでした。高速性、高いスケーラビリティ、比較的完璧なフォールト トレランスにより、業界関係者から高い評価を受けています。

[[342854]]

画像はPexelsより

今日のデータ中心の時代では、Apache Kafka とその一般的なデプロイメント アプリケーションを深く理解し、データ アーキテクチャ (Kafka Fast Data Architecture) を迅速に実装することが不可欠です。

以下では、Kafka アーキテクチャ、4 つのコア API、一般的なアプリケーション シナリオ、Kafka ブローカーとメッセージ トピック、クラスターの作成、ストリーム API とその処理モードなど、さまざまな側面について詳しく紹介します。

Kafka: 分散ストリーミング プラットフォーム

Kafka は、メッセージ ストリーム (レコード ストリームまたはデータ ストリームとも呼ばれます) を公開およびサブスクライブするための分散ストリーミング プラットフォームであり、I/O を使用してデータ ストリームを迅速かつ効率的にバッチ処理、圧縮、分離し、データ プール、アプリケーション、リアルタイム ストリーム分析システムにデータ ストリームを送信します。

Kafka はトピック メッセージ パーティションを複数のサーバーに複製し、ユーザーが独自のアプリケーションを通じてこれらのレコードを処理できるようにします。

Kafka の 4 つのコア API

Kafka は、レコード、トピック、コンシューマー、プロデューサー、ブローカー、ログ、パーティション、クラスターで構成されています。

Kafka トピックはレコードのストリームです。各トピックには対応するログがあり、これはディスク上のトピックの保存場所となります。各トピック ログは複数のパーティションとフラグメントに分割されます。

Kafka Producer API は、データ レコードのストリームを生成するために使用されます。 Kafka Consumer API は、Kafka からのレコードのストリームを消費するために使用されます。

ブローカーは、複数のブローカー サーバーで構成される Kafka クラスターで実行される Kafka サーバーです。

①プロデューサー API: メッセージのプロデューサー、Kafka ブローカーにメッセージを送信するクライアント。

クライアントがクラスター内で実行されている Kafka サーバーに接続し、1 つ以上の Kafka トピックにレコード ストリームを公開できるようにします。

Kafka サーバーはブローカーです。クラスターは複数のブローカーで構成され、ブローカーは複数のトピックに対応できます。

②コンシューマーAPI：メッセージコンシューマー、Kafkaブローカーからメッセージを取得するクライアント。

クライアントがクラスター内で実行されている Kafka サーバーに接続し、1 つ以上の Kafka トピックからのレコードのストリームを消費できるようにします。

③Stream API: 入力ストリームと出力ストリームを変換するストリームプロセッサとして機能します。

クライアントがストリーム プロセッサとして動作し、1 つ以上のトピック (メッセージ トピック) からの入力ストリームを消費し、1 つ以上の他のトピック (メッセージ トピック) への出力ストリームを生成して、入力ストリームを出力ストリームに効率的に変換できるようにします。

④コネクタAPI：再利用可能なプロデューサーコードとコンシューマーコードを記述できます。

任意のリレーショナル データベースからデータを読み取ってトピックに公開したり、このトピックからデータを「消費」してリレーショナル データベースに書き込むこともできます。

ご覧のとおり、コネクタ API は、再利用可能なプロデューサーまたはコンシューマーの構築と実行、およびトピックを既存のアプリケーションまたはデータ システムに接続する機能をサポートしています。 (たとえば、リレーショナル データベースの場合、そのコネクタは各テーブルのすべての変更をキャプチャできます。)

Kafka アプリケーション シナリオ

メッセージングシステム

Kafka は、エンタープライズ メッセージング システムとして、ソース システムとターゲット システムを分離することでデータ交換を可能にします。 JMS と比較して、Kafka は高スループットのパーティショニングと、高信頼性およびフォールト トレラントなレプリケーション機能の両方を備えています。

ウェブサイトアクティビティの追跡

ウェブサイト上のユーザーのすべてのイベント情報を追跡して記録し、データを分析してオフラインで処理します。

[[342855]]

ログの概要

さまざまなシステム、特にマイクロサービス アーキテクチャの分散環境からのログを処理するために使用されます。このようなシステムは通常、異なるホストに展開されるため、Kafka はさまざまなシステムからさまざまなログを集約し、それらのログを一元的に分析および処理する必要があります。

メトリクス収集

Kafka を使用すると、さまざまなシステム/ネットワークからメトリックを収集および監視できます。 Kafka には、Ganglia、Graphite などの専用のメトリック レポート生成ツールが搭載されています。

Kafka ブローカーと Kafka トピック

Kafka ブローカー

Kafka クラスター内のインスタンスはプロキシ (サーバー) と呼ばれます。 Kafka クラスターでは、任意のプロキシ (サーバー) に接続することでクラスター全体にアクセスできます。各プロキシはクラスター内の ID によって識別されます。

Kafka トピック (メッセージ トピック)

メッセージ トピックは、メッセージ レコードが公開された後の論理名です。 Kafka では、トピックはメッセージを公開するために複数のパーティションに分割されます。

これらのパーティションは、クラスター内のブローカー間で分散されます。スケーラビリティを実現するために、非常に大きなトピックは通常、複数のブローカーに分散されます。

トピックは複数のパーティションに分割できるため、各パーティションは順序付けられたキューになります。

パーティション内の各メッセージには、順序付けられた ID (つまり、オフセット) が割り当てられます。

次の図に示すように、現在 3 つのパーティションを持つトピックがあり、クラスター内に 3 つのブローカーがある場合、各ブローカーには 1 つのパーティションがあります。パーティションに公開されるデータは、オフセットの増分単位で追加されます。

「オフセット」はオフセットを指します。 Kafka ストレージ ファイルの名前は「offset.kafka」です。検索を容易にするために、オフセット命名方法が使用されます。 2046 の位置を見つけたい場合は、ファイル 2045.kafka を見つけるだけです。

パーティションを使用する際に注意すべき重要なポイントは次のとおりです。

• 各メッセージ トピックは名前で識別され、クラスター内で複数の名前付きメッセージ トピックが許可されます。
• 各メッセージの順序の有効性は、トピック全体ではなくパーティション レベルで維持されます。
• パーティションにデータが書き込まれると、上書きされることはありません。これは、Kafka で強調されているデータの不変性です。
• パーティション内のメッセージは、キー、値、タイムスタンプの形式で一緒に保存されます。 Kafka は、指定されたキーを持つすべてのメッセージが同じパーティションに公開されることを保証します。
• Kafka クラスターでは、各パーティションにリーダーがいて、パーティションに対する読み取り/書き込み操作の実行を担当します。

上図は一例です。現在のクラスターにはメッセージ トピック (Topic) が 1 つだけあります。トピックには 3 つのパーティション (partition0、partition1、partition2) が含まれています。クラスターには 3 つのブローカー サーバー (broker1、broker2、broker3) があります。

現在、各パーティションのコピーが他の 2 つのブローカー サーバーにコピーされています。つまり、各ブローカー サーバーには 3 つのパーティションが含まれています。

そのため、プロキシ サーバー (ブローカー) の 2 つに障害が発生しても、データ損失を心配する必要はありません。

前述のように、Kafka でトピックを作成するときは、トピックのレプリケーション係数が 1 より大きく、クラスター内のブローカーの数以下であることを常に確認することをお勧めします。これは強く推奨される方法です。

上記の例では、現在のトピックのレプリケーション係数は 3 (つまり、元のデータ 1 つとレプリカ 2 つ) です。各パーティションのブート プログラムとレプリカの数は合計で「3」であると推測するのは難しくありません。

この例では、各パーティションには 1 つのリーダー (「リーダー」と呼ばれる) と、他の 2 つの同期レプリカ (「フォロワー」と呼ばれる) があります。

パーティション 0 の場合、ブローカー 1 が「リーダー」、ブローカー 2 とブローカー 3 は両方とも「フォロワー」であるため、パーティション 0 のすべての読み取りおよび書き込み操作はブローカー 1 で実行されます。

同時に、更新されたコンテンツは、broker2 と broker3 の対応するパーティションに同期的にコピーされます。

Kafka クラスターの作成 — デモ

上図の 3 つのブローカーで構成された Kafka クラスターを例に、Kafka クラスターを作成する手順を詳しく説明します。

①Kafkaクラスタ環境の準備

まず、Zookeeper がインストールされたマシンを準備する必要があります。 Zookeeper がないと、Kafka クラスターは動作しません。

Apache Kafka の最新バージョンを公式 Web サイトから直接ダウンロードすることもお勧めします。現在のバージョンは2.11に更新されています。それを解凍して bin ディレクトリに配置します。

 https://archive.apache.org/dist/kafka/1.0.0/kafka_2.11-1.0.0.tgz

次に、ZooKeeper を起動します。 ZooKeeper はなぜ必要なのでしょうか?主な役割は、サービスの調整、ブローカー サービスの管理、各パーティションのブートストラップの決定、Kafka メッセージ トピックまたはブローカー サービスが変更されたときのタイムリーな警告の発行です。

Zookeeper インスタンスは、次のコマンドを使用して起動できます。

②Kafkaブローカーを起動する

Kafka を正常にインストールし、ZooKeeper インスタンスを起動したら、Kafka ブローカーを起動できます。ここでは、3 つの Kafka ブローカーが起動されます。

具体的な起動方法: まず、Kafka ルート ディレクトリの「config」フォルダーを探し、「server.properties」ファイルを見つけて、それを 3 回コピーします。

次に、それぞれ server_1.properties、server_2.properties、server_3.properties という名前を付け、3 つのファイルの内容を次のように編集して、直接保存します。

保存後、次のコマンドを使用して 3 つのプロキシ サービスを開始します。

③トピックを作成する

次のコマンドを使用してメッセージ トピックを作成します。

④ガイダンスサービスの生成

Kafka コンソール ジェネレーターを使用して任意のプロキシ サービス アドレスを指定し、以前に作成したトピックに基づいていくつかのメッセージを公開します。

この指定されたプロキシ サービスはブートストラップ サービス プログラムと見なされ、クラスター全体にアクセスするために使用されます。

⑤「消費」ニュース

Kafka コンソールを通じてメッセージを消費するには、ユーザー (つまり、メッセージ コンシューマー) が任意のブローカー アドレスをブート サーバーとして指定する必要があります。

メッセージを読むとき、ユーザー (つまり、メッセージの消費者) はメッセージの順序を確認できません。前述のように、メッセージの順序はトピック レベルではなくパーティション レベルでのみ維持されます。

次のコマンドを使用して、トピックを記述し、各パーティションの分布と各パーティションのブート サーバーを表示できます。

上記の実行結果から、次のことがわかります。

• broker-1 はパーティション 0 のブート サーバーです。
• broker-2 はパーティション 1 のブート サーバーです。
• broker-3 はパーティション 2 のブート サーバーです。
• Broker-1、broker-2、broker-3 にはそれぞれ各パーティションのレプリカがあります (相互に同期され、バックアップされています)。

Kafka ストリーム API

Kafka は、ストリーミング データを他のシステムにリアルタイムで送信するためによく使用されます。この場合、Kafka は中間層として機能し、主にリアルタイム データ パイプラインを分離および分離するために使用されます。

Kafka Stream は Kafka エコシステムの一部です。リアルタイム分析機能を提供し、将来のデータ分析のためにストリーミング データをビッグ データ プラットフォームや RDBMS、Cassandra、Spark に送信することをサポートします。

Kafka Stream API はシンプルで使いやすいです。強力な技術的能力により、保存されているすべてのデータを処理できます。同時に、API は Kafka 標準クラスの実装ルールのセットも提供します。

実際の業務でコア業務を支えるリアルタイムアプリケーションを作成するには、Kafka Stream API の大きな助けが必要です。

Kafka Stream API は、これを使用して構築されたアプリケーションが通常のアプリケーションであるという点で独特です。

そのため、これらのアプリケーションは、専用の処理クラスターや同様のインフラストラクチャを別途インストールする必要がなく、他のアプリケーションと同様にパッケージ化、展開、監視することができ、通常はコストがかかります。

ストリームは、Kafka Streams によって提供される最も重要な抽象オブジェクトであり、無限かつ継続的に更新されるデータ セットを表します。

ストリームは、順序、繰り返し性、フォールト トレランスの特性を持つ不変のデータ レコードのシーケンスです。これを単純にレコード ストリーム (KStream として定義) または変更ログ ストリーム (KTable または GlobelKTable として配置) と見なすことができます。

ストリーム プロセッサは、ストリーム データに適用される処理ロジックを含むプロセッサ トポロジ内のノードです。一連のノードがトポロジ内の処理ステップを構成します (データの変換に使用されます)。

Kafka Streams API データ処理 — デモ

Kafka Stream API は、ストリーム データ処理、つまり Kafka でのメッセージの消費と書き込みに 2 つのオプションを提供します。

• 高度な Kafka Streams DSL (高レベル DSL)。
• 低レベル プロセッサ API: 基本的なデータ処理、複合処理、およびローカル状態ストレージに使用されます。

①高レベルDSL

高レベル DSL は、レコード ストリーム (KStream) とログ ストリーム (KTable/GlobalKTable) という 2 つの主要な抽象クラスで構成され、これらには呼び出し用の一連の実装メソッドが含まれています。

KStream はレコード ストリームの抽象化であり、各データは無限のデータ セット内の単純なキー値です。 KStream は、データ ストリームを処理するためのさまざまな関数を提供します。

例: map、mapValue、flatMap、flatMapValues、filter;また、複数のストリーム接続とストリーム データの集約もサポートします。

KTable は、同じキーを持つ行が上書きされ、各データ レコードが挿入または更新されたと見なされる変更ログ ストリームの抽象化です。

②プロセッサAPI（下位プロセッサ）

低レベル プロセッサ API は、抽象クラス (AbstractProcessor) を拡張し、ビジネス ロジックを含む処理メソッドをオーバーライドして、ストリーム データへのクライアント アクセスを実現します。これにより、入力データ ストリームに基づいて対応するビジネス ロジックが実行され、その結果がダウンストリーム データとしてクライアントに転送されます。

高レベルの DSL は関数型のスタイルですぐに使用できるメソッドを提供しますが、低レベルの Processor API はオンデマンドの処理ロジックを提供します。

③Kafka ストリーム API アプリケーション - 高度な DSL デモ

前提条件: 現在の環境で次の依存関係が使用可能である必要があり、バージョンは現在の状況によって異なります。

次のパッケージをインポートします。

Kafka 構成プロパティ:

KStreamBuilder をインスタンス化し、KStream オブジェクトを作成します。

KStreamBuilder には、トピック名をパラメーターとして受け取り、指定されたトピックをサブスクライブするインスタンス化されたオブジェクトである KStream オブジェクトを返す Stream メソッドがあります。

KStream オブジェクトに基づいて、Kafka Streams の高レベル DSL によって提供される多くのメソッド (map、process、transform、join など) を使用して、処理されたデータを別のトピックに送信できます。

最後に、ストリーミングはビルダーとストリーム構成を介して実行されます。

Kafka Streams API を使用すると、別のクラスターをデプロイせずに Kafka でデータ ストリーム処理を実行できます。

Kafka Streams API がもたらす利便性には、主に次の側面が含まれます。

• 高いスケーラビリティ、柔軟性、分散性、耐障害性を備えています。
• ステートフル処理とステートレス処理をサポートします。
• ウィンドウ処理、結合、集計を使用したイベント時間処理。
• Kafka Streams DSL または下位レベルの Processor API を通じて、既に定義されている一般的な変換操作を使用します。
• 処理に別のクラスターは必要ありません (Kafka と統合されています)。
• 一度に 1 つのレコードを処理することで、ミリ秒単位の処理遅延を実現します。
• さまざまなアプリケーションやデータベースに接続するための Kafka Connect をサポートします。

要約する

Kafka の便利な操作性は、業界関係者から広く注目を集めている理由の 1 つです。しかし、さらに重要なのは、優れた安定性、信頼性、耐久性を備え、柔軟な公開/キューイングを備え、N 個の消費者グループにうまく適応でき、再現性が高く、プロデューサーに一貫性の保証を提供できることです。

この共有では、Kafka のコア要素とその共通展開に基づいた詳細な分析を提供し、この分野に関心のある人々に技術的な普及と補完的な情報交換を提供することを目指しています。

著者: 羅小洛

紹介: 英国でトップ 10 のコンピューター サイエンス専攻であり、コンピューター サイエンスとテクノロジーの修士号を取得。HSBC、JP モルガン、HP、交通銀行、アリババなど国内外の有名企業で勤務。主なプロジェクト分野は、インターネット金融、電子商取引、教育、医療などです。現在はフォーチュン500企業でテスト開発チームの責任者として働いており、チームを率いて自動テストフレームワークの構築と継続的な最適化を行い、自動テスト補助ツールを開発しています。専門分野: ユニット/インターフェース/パフォーマンス/セキュリティ/自動テスト/CD/CI/DevOps。個人的な継続研究分野: 自動テストモデル/データ分析/アルゴリズム/機械学習など。

編集者：タオ・ジアロン

論文募集: 論文の提出や掲載を希望する技術者の方は [email protected] までご連絡ください。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]