Flumeの概要と基本的な使用法

Flume の概要と基本的な使用法#

内容参考: 公式ドキュメント

Flume の基本アーキテクチャ#

外部データソースは特定の形式で Flume にevents (イベント)を送信します。sourceがeventsを受信すると、それを 1 つ以上のchannelに保存します。channelはsinkによって消費されるまでeventsを保持します。sinkの主な機能は、channelからeventsを読み取り、それを外部ストレージシステムに保存するか、次のsourceに転送し、成功した後にchannelからeventsを削除することです。

基本概念#

Event
Source
Channel
Sink
Agent

Event#

Event は Flume NG データ転送の基本単位です。JMS やメッセージシステムのメッセージに似ています。1 つの Event はヘッダーと本文で構成されます：前者はキー / バリューのマッピングで、後者は任意のバイト配列です。

Agent#

独立した (JVM) プロセスで、Source、Channel、Sink などのコンポーネントを含みます。

Source#

データ収集コンポーネントで、外部データソースからデータを収集し、Channel に保存します。
Avro Source、Thrift Source、Kafka Source、JMS Sourceなど、数十種類のタイプが内蔵されています。

Channel#

Channel はソースと受信器の間のパイプラインで、データを一時的に保存するために使用されます。メモリまたは永続化されたファイルシステムである可能性があります：

Memory Channel : メモリを使用し、利点は速度が速いですが、データが失われる可能性があります（突然のクラッシュなど）。
File Channel : 永続化されたファイルシステムを使用し、利点はデータが失われないことですが、速度が遅いです。

内蔵のMemory Channel、JDBC Channel、Kafka Channel、File Channelなどがあります。

Sink#

Sink の主な機能は、Channel から Event を読み取り、それを外部ストレージシステムに保存するか、次の Source に転送し、成功した後に Channel から Event を削除することです。HDFS Sink、Hive Sink、HBaseSinks、Avro Sinkなどが含まれます。

Flume トランザクション#

データが次のノードに転送される際（通常はバッチデータ）、受信ノードに異常が発生したと仮定します。例えば、ネットワークの異常です。この場合、このバッチデータはロールバックされるため、データの再送信が発生する可能性があります（再送信であり、重複ではありません）。
同じノード内で、Source がデータを Channel に書き込む際、バッチ内のデータに異常が発生した場合、Channel には書き込まれず、受信された部分のデータは直接破棄され、前のノードがデータを再送信します。

source -> channel: put トランザクション
channel -> sink: take トランザクション

put トランザクションの手順：

doput : まず、バッチデータを一時バッファの putlist に書き込みます。
docommit：channel に空きがあるか確認し、あればデータを渡し、なければ dorollback でデータを putlist に戻します。

take トランザクションの手順：

dotake：データを一時バッファの takelist に読み込み、データを hdfs に送信します。
docommit : データ送信が成功したか判断し、成功した場合は一時バッファの takelist をクリアします。
成功しなかった場合（例えば、hdfs システムサーバーがクラッシュした場合など）は、dorollback でデータを channel に戻します。

参考リンク: flume トランザクション解析

Flume の信頼性#

ノードに障害が発生した場合、ログは他のノードに送信され、失われることはありません。Flume は 3 つのレベルの信頼性を提供しており、強いものから弱いものまで順に次の通りです：

end-to-end: データを受信した agent はまず event をディスクに書き込み、データ送信が成功した後に削除します。データ送信が失敗した場合、再送信できます。
Store on failure: これは scribe が採用している戦略でもあり、データ受信側がクラッシュした場合、データをローカルに書き込み、復旧後に再送信します。
Besteffort: データが受信側に送信された後、確認は行われません。

Flume のデプロイタイプ#

単一プロセス#

multi-agent flow（複数エージェントのフロー、複数の agent が順に接続）#

複数の Agent を順に接続し、最初のデータソースを収集して最終的なストレージシステムに保存できます。これは最も単純なケースであり、一般的にはこの順に接続される Agent の数を制御する必要があります。データの流れが長くなるため、フェイルオーバーを考慮しない場合、障害が発生すると全体の Flow 上の Agent の収集サービスに影響を与えます。

Consolidation（フローの統合、複数の Agent のデータを同じ Agent に集約）#

この状況は多くのシナリオで適用されます。例えば、Web サイトのユーザー行動ログを収集する場合、Web サイトは可用性のために負荷分散クラスターを使用し、各ノードがユーザー行動ログを生成します。各ノードに Agent を構成してログデータを個別に収集し、複数の Agent がデータを最終的に HDFS などのデータストレージシステムに集約します。

Multiplexing the flow（多重化）#

Flume は 1 つの Source から複数の Channel、つまり複数の Sink にイベントを送信することをサポートしています。この操作は Fan Out（扇出）と呼ばれます。デフォルトでは、Fan Out はすべての Channel に Event をコピーします。つまり、すべての Channel が受け取るデータは同じです。また、Flume は Source 上でカスタムの復用セレクター（multiplexing selector）を定義してカスタムルーティングルールを実現することもサポートしています。

例えば、syslog、java、nginx、tomcat などが混在するログストリームが 1 つの agent に流れ込むと、agent 内で混在したログストリームを分離し、各種ログにそれぞれの伝送チャネルを設けることができます。

Yige