0. 关于此投稿

因为我读了一篇关于LinkedIn的Kafka的论文，所以我只记录了摘要。
论文链接
http://sites.computer.org/debull/A12june/pipeline.pdf

1. 简介

• LinkedInでは、コネクション予測、ジョブのマッチング、表示する広告の最適化をユーザーの行動履歴から機械学習を利用してモデリングしている。

 

ユーザーのソーシャルネットワークに関連のあるニュースフィードをactivity drivenに投稿している

1.1 以前的系统

• 行動履歴データをデータウェアハウス(DWH)にInsertするバッチ指向のシステムとサーバのメトリクスとロギングを処理するシステム（監視システムにのみ利用）の２つのシステムを構築していた。

 

• どちらもpoint to point でデータのやり取りを行い、送信先は１つに決まっていた。

 

• ユーザの行動履歴はログファイル（xml形式）に収集してETLサーバにバッチで送信する。

 

• ETLサーバがログファイルのメッセージをパースして、RDBとHadoopにインポートする。

 

• 問題点

リアルタイム性に欠ける。（ファイルに出力されたものをパースしてインポートするので、ファイルローテーションの時間分ラグが出てしまう。）
送信先は一つしかサポートしない
アプリケーションが直接xmlのメッセージを出力するので、予期しないスキーマの変更があった場合に対応できない

1.2 实时基础设施的困难

为了使系统更加实时化，我们尝试了各种方法。
我们尝试了使用ActiveMQ创建原型并进行测试，可以处理每秒2,3000条消息，同时在LinkedIn和其他服务中也有运行记录。然而，出现了以下问题。

• メモリにキューとして保持できるデータ量を超えるとその時点で性能が著しく低下する。（ランダムIOが多いため。）

 

• Consumerプロセス（データを取得するクライアント）自身がバランスをとっているので、与えられたキューにConsumerプロセスがないという事象が発生した。(管理できないので、Consumerからbrokerへの割当をstaticにしたくなかった。)

 

ActiveMQ自体のバグで(brokerのhung up、コネクションリーク、アウトオブメモリー等）

这些成为了他们不想使用现有产品而自行开发基础设施的动力。

2. 管道基础设施

2.1 Kafka的概念总览

• 抽象化したバイト配列としてメッセージをモデリングする。

 

• Producerはあるフィードの全てのメッセージを持つtopicにメッセージを送る。

 

• それぞれのtopicはKafkaのbrokerのクラスターに分散され、brokerはそれぞれのtopicごとのパーティションを持つ。

 

• パーティションはメッセージが書かれた順番に並ぶ。

 

• システムの動作は以下２つ

topicの値に新規メッセージをappend
特定のメッセージidから始まるパーティションからメッセージをfetch

全てのtopicは複数のsubscriberから読み取り可能、かつ、とても小さなoverheadでsubscriberを追加可能
稼働中にグループにノードを追加可能でstaticなconfigurationなしに自動リバランスする。
Zookeeperを利用してグループのハートビートやconsumerへpartitionの割当を行う。　　※この辺りの説明は結構複雑だったので、一旦放置。
多少のデータロスは許容できるものに利用している。高可用性を提供する試みとして、それぞれの機能(producer,broker,consumer)ごとにロスや遅延を発見するためのデータを計測している。

2.2 领英上的卡夫卡使用方式

• Kafkaは１日あたり１００億を超えるメッセージの書き込みを処理する。

 

• 高トラフィックの時間帯は秒間172,000メッセージを扱う。

 

• totalで40のconsumerがありtopicをconsumeしている（8個はreplicationやモニタリングツール用で、それ以外はユーザーやその他機能から書き込まれるアプリケーション）

 

• ユーザー行動履歴データとシステムログをあわせて367topicをサポートしている。

 

• 最大で一つのtopicが１日92GB追加される。小さなものは数KB

 

• メッセージデータは７日間保持され、データがconsumeされたかどうかに関わらず経過した時点でgarbageとして収集される。

 

• Consumerはこのポリシーをtopicごとに変更可能

 

• 全topic合わせて9.5TB（圧縮済み）を保持している。

 

• Kafka用のサーバはデータセンターごとに8台で、それぞれのサーバがStorage　6TB（RAID10で普通のSATAディスク）

 

クラスターにつき、10,000コネクションを捌く

3. 高吞吐量的工程

将设计为将日志文件汇总起来的方式，通过缓冲并采用高效的IO模式进行写入，以提高吞吐量为优势。然而，由于故障，缓冲的消息可能会丢失，并且缺乏实时性。换句话说，在写入文件服务器之前，必须确保写入完成。为了缩短这个时间，可以考虑将文件轮换间隔缩短到每分钟一次或其他短时间间隔，但这样会增加管理大量文件的成本。

作为架构和设计目标，Kafka的目标是通过日志系统管理成本并设计高效的消息系统。

Kafka在技术层面上实现了以下三个效率优化措施（有关详细信息将在以后提供）：
– 分区化
– 优化块大小
– 数据压缩

只要在这里，我自己的经验有许多适用之处，并且很值得参考。之后，如果我有兴致的话，我会补充的。