Apache Kafkaってそもそも何か確認してみます（その１
こんばんは。
最近Stormを調べていると、
データ取得の手段としてApache Kafkaとの連携が記述されています。
そのため、とりあえず何ができるか、の概要を調べてみました。
最初はFlumeを使おうかとも思ったんですが、
下記のようなモデルの祖語もあり、とりあえずApache Kafkaについて調べてみようという。
FlumeはCollectorSinkからデータソースに投入するPush型
StormはSpoutに対して自分からデータを取得しに行くPull型
→ 上記の関係上、Flumeが取得したデータを一時的に蓄えるものが必要になります。
・・・Listener仕掛けてキューに入れるとかですね。
それをKafkaを使えば不要かなぁ、と思って確認しています。
1.何故Kafkaは作られたのか？
元々はLinkedInのActivity StreamとData Processingをパイプライン式に繋ぐために開発されたプロダクト。
最近はTumblr、DataSiftといった企業でも使用されている。
→ SNSや、複数のサービスの情報を統合するようなシステムで使われているようです。
ここでいうActivity Streamとは
Webページで閲覧、検索、リンク設定などを行う活動全般を指す。
これらのデータは通常のシステムならば、ログファイルとして出力し、後で別途解析に用いられる。
もう一つ言葉を定義する。
Operational Dataはサーバのパフォーマンスデータ（CPU、IO等）を指す。
これらのデータの統合には様々なアプローチがある。
Activity DataやOperational DataはWebサイト運営の上で非常に重要なデータとなる。
だからこそ、これらを収集解析するにはこれまでより洗練されたインフラが必要。
Kafkaは上記を達成する『洗練するインフラ』として開発された。
2.Activity Data／Operational Dataのユースケース例
友人内で共有されたニュースフィード
投票結果によって最適解をしぼるランキングコンテスト
APIやメール受信数から攻撃やスパムを検知するセキュリティ対策
運用監視：あるシステムやサイトのレスポンスが悪化していないかを検知
レポーティングやバッチ実行：データ解析に必要なDWHやHadoop等へのデータロードを実行
3.Activity Stream Dataの特徴
高負荷なシステムのストリームデータ解析を行う際、
データ量は既存システムの数十倍、数百倍のオーダーに達する。
上記の前提にの上で、
これまで行われてきたログファイル収集は
オフラインの状況においては厳密かつスケーラブルだった。
だが、リアルタイムプロセッシングを行うには遅すぎる上に、
運用も複雑になる傾向がある。
対して、既存のメッセージング／キューイングシステムは
リアルタイムプロセッシングを行うには適しているが、
永続化層が遅い関係上非常に大きい処理待ちのキューを抱えることとなっていた。
Hadooopのようなオフラインシステムにデータを投入する際にも同様の問題が発生し、
これまでは1時間単位や、1日単位の処理しか提供できなかった。
Kafkaはこれらの遅延、処理待ちキュー肥大化の問題を解決するために
開発されたキューイングプラットフォームである。
Hadoopのようなオフラインのシステム、
リアルタイムプロセッシングのようなオンラインシステムの
両方に対して単一のキューを用いて情報の収集を行う。
4.適用例
下記の画像がLinkedInで使用されている構成の概要となる。
単一のKafkaクラスタが複数の異なるデータソースから収集される
Activityデータを扱っている。
Kafkaクラスタはオンライン／オフラインのデータ利用者に対して単一のデータパイプラインを提供する。
上記のような構成において、Kafkaは実Activityと非同期処理を仲立ちするバッファとして働いている。
また、Kafkaはこれらの全データを別データセンターで使用するために同期する機能も提供している。
Kafkaは1クラスタでデータセンターをまたぐような構成ではないが、
複数のクラスタを構築することでデータセンター間のフローも実現する。
実際の構成として、コピー先のKafkaクラスタはコピー元のKafkaクラスタの
Consumerとして扱うのみであり、非常にシンプル。
また、上記の特徴は複数のデータセンターから
１か所にデータを集約可能であることも示す。
下の図は複数データセンター間でバッチロードを補助するための構成例。
上記の構成において、２つのLocal Kafka Cluster間の通信は行われない。
２つのLocal Kafka Clusterは異なるサイズ、異なる数のノードを保持することが出来る。
また、１つのKafka Clusterは任意の数のSource Kafka Clusterの
データをコピーすることができる。
・・・別ページについては飛ばして、この次はメインページの確認を更に進めます。
