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 の数を制御する必要があります。なぜなら、データが流れる経路が長くなり、failover を考慮しない場合、障害が発生すると全体の 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