http://sites.computer.org/debull/A12june/pipeline.pdf
http://blog.163.com/guaiguai_family/blog/static/20078414520138911393767/
这一套可以成为互联网公司的标准基础架构了，摘要如下：
http://blog.163.com/guaiguai_family/blog/static/20078414520138911393767/
这一套可以成为互联网公司的标准基础架构了，摘要如下：
- 把数据的 source of truth 放在数据总线里，而非 Hadoop 和数据仓库里。这是个很违反直觉的做法，但得益与 Kafka 巧妙的数据持久性以及分区、备份的设计，数据总线成了实时系统和批处理系统的非常可靠的数据源头，兼顾两种处理范式；
- ActiveMQ 各种问题，不堪数据收集重任；
- Kafka 的各种巧妙设计，这点在其官方网站文档里说的也很详细；
- Kafka producer 推事件到 Kafka broker，Kafka consumer 从 Kafka broker 拉事件，queue 的核心功能之一本来就是缓存事件，consumer的担子轻松了；
- Kafka broker 单机硬盘容量很大，使用 RAID-10；broker 之间网络带宽很大；两者从硬件上给数据总线这个核心系统的可靠性和高性能打了预防针；
- 使用 Avro 作为事件序列化标准，建立 schema registry service，强制 schema change review，向后兼容，每个事件带有 schema id 和版本信息，所以从来不用担心反序列化时不知道数据格式；
- 因为数据的源头已经把 schema 的事情解决了，所以导入到 Hadoop 以及供 Hive、Pig 等读入就是顺理成章轻而易举了，一个人维护一个 loader 就可以导入各种事件流。HCatalog 集中管理 schema，隐藏 HDFS 文件路径的做法也有类似的哲学，使得 Hadoop 的数据管理拔升一个层次。Schema 这个做法再怎么强调其重要性都不为过，数据格式管理混乱，收集再多数据也是空守宝山两眼一抹黑；
- 用 Kafka 来收集 Kafka 系统自身的各种运行信息，实在是妙招，即统一了基础架构，又吃自家狗粮，大赞！
个人觉得这套设计比起 Facebook 的 scribe -> calligraphus -> HDFS -> { Continuous Copier -> HDFS, PTail -> Puma } 的方式干净许多，加上最近 LinkedIn 开源了基于 Kafka 的流处理框架 Samza (http://samza.incubator.apache.org/)
http://thinkinginjavablog.sinaapp.com/?p=649
对于Linkin这样的互联网企业来说，用户和网站上产生的数据有三种：
- 需要实时响应的交易数据，用户提交一个表单，输入一段内容，这种数据最后是存放在关系数据库(Oracle, MySQL)中的，有些需要事务支持。
- 活动流数据，准实时的，例如页面访问量、用户行为、搜索情况，这些数据可以产生啥？广播、排序、个性化推荐、运营监控等。这种数据一般是前端服务器先写文件，然后通过批量的方式把文件倒到Hadoop这种大数据分析器里面慢慢整。
- 各个层面程序产生的日志，例如httpd的日志、tomcat的日志、其他各种程序产生的日志。码农专用，这种数据一个是用来监控报警，还有就是用来做分析。
Linkin 的牛逼之处，就在于他们发现了原先2,3的数据处理方式有问题，对于2而言，原来动辄一两个钟头批处理一次的方式已经不行了，用户在一次购买完之后最好马 上就能看到相关的推荐。而对于3而言，传统的syslog模式等也不好用，而且很多情况下2和3用的是同一批数据，只是数据消费者不一样。
这2种数据的特点是：
- 准实时，不需要秒级响应，分钟级别即可。
- 数据量巨大，是交易数据的10倍以上。
- 数据消费者众多，例如评级、投票、排序、个性化推荐、安全、运营监控、程序监控、后期报表等
于是，Linkin就自己开发了一套系统，专门用来处理这种性质的数据，这就是Kafka
那么，在整个实践过程中Linkin做了什么样的设计，解决了什么问题？
首先看下数据流动图：
多数据中心怎么管理数据：
集群本身的架构图
Kafka内部架构图，分为数据产生者(Producer)，数据中间者(Broker)，数据消费者(Consumer)
显然，这是一个集群的发布/订阅系统，有如下几个特点
- 生产者是推数据(Push)，消费者是拉数据(Pull)。存在数据复用，在Linkin平均生产1条消息会被消费5.5次。
- 数据生产者和数据消费者的速度不对等，所以要把数据沉淀在Kafka内慢慢处理，Linkin一般在集群内放7天的数据。
- 性能上追求高吞吐，保证一定的延时性之内。这方面做了大量优化，包括没有全局hash，批量发送，跨数据中心压缩等等。
- 容错性上使用的“至少传输一次”的语义。不保证强一次，但避免最多传一次的情况。
- 集群中数据分区，保证单个数据消费者可以读到某话题(topic)的某子话题(例如某用户的数据)的所有数据，避免全局读数据
- 数 据规范性，所有数据分为数百个话题，然后在数据的源头——生产者(Producer)这边就用Schema来规范数据，这种理念使得后期的数据传输、序列 化、压缩、消费都有了统一的规范，同时也解决了这个领域非常麻烦的数据版本不兼容问题——生产者一改代码，消费者就抓瞎。
- 用于监控，这个系统的威力在于，前面所有生产系统的数据流向，通过这个系统都能关联起来，用于日常的运营也好，用于数据审计，用于运维级别的监控也好都是神器啊！
所以，Kafka的设计基本上目前这个领域的唯一选择。我也看了很多其他实现，包括：
scribe(Facebook) | 2 | C++ | 已停止更新，不建议使用
flume(Apache, Cloudera) |1 | Java | 配置较重
chukwa(Hadoop) |12 | Java | 2012发布最后一版，不建议使用
fluentd |1 | Ruby | 比较活跃，看起来不错
logstash |12345| JRuby | 功能全，据说有不少小bug
splunk |12345| C/Python | 商业闭源，功能强大，可做参考
timetunnel(Alibaba) | 2 | Java | 基于thrift，10年左右成熟
kafka(Linkin) | 2 4 | Scala | 性能强劲，设计巧妙，可以作为基础设施
Samza(Linkin) |12345| | =Kafka+YARN+Hadoop
rabbitmq/activemq/qpid | 2 | Java | 传统消息中间件
Storm(twitter) | 3 | Clojure | 实时计算系统
Jstorm(Alibaba) | 3 | Java | storm的Java版，据说更稳定
S4(Yahoo) | 3 | Java | 2013年已停止维护
Streambase(IBM) | 3 | Java | 商业产品，作为参考
HStreaming | 3 | Java | 商业产品，作为参考
spark | 3 | Scala | 基于Hadoop
mongodb | 4 | C++ | 比较浪费硬盘
mysql | 4 | C++ | 无需多说
hdfs/hbase | 4 | Java | 无需多说=
flume(Apache, Cloudera) |1 | Java | 配置较重
chukwa(Hadoop) |12 | Java | 2012发布最后一版，不建议使用
fluentd |1 | Ruby | 比较活跃，看起来不错
logstash |12345| JRuby | 功能全，据说有不少小bug
splunk |12345| C/Python | 商业闭源，功能强大，可做参考
timetunnel(Alibaba) | 2 | Java | 基于thrift，10年左右成熟
kafka(Linkin) | 2 4 | Scala | 性能强劲，设计巧妙，可以作为基础设施
Samza(Linkin) |12345| | =Kafka+YARN+Hadoop
rabbitmq/activemq/qpid | 2 | Java | 传统消息中间件
Storm(twitter) | 3 | Clojure | 实时计算系统
Jstorm(Alibaba) | 3 | Java | storm的Java版，据说更稳定
S4(Yahoo) | 3 | Java | 2013年已停止维护
Streambase(IBM) | 3 | Java | 商业产品，作为参考
HStreaming | 3 | Java | 商业产品，作为参考
spark | 3 | Scala | 基于Hadoop
mongodb | 4 | C++ | 比较浪费硬盘
mysql | 4 | C++ | 无需多说
hdfs/hbase | 4 | Java | 无需多说=
- 数据采集组件
- 数据传输组件
- 数据实时计算/索引/搜索组件
- 数据存储/持久化组件
- 数据展示/查询/报警界面组件
从数据传输这块的设计理念来说，Kafka是最为先进的，
在目前的各种实现中，我猜测可以和Kafka一战的也就只有Splunk了
后面我会分析一下这2个软件的设计和实现
欲知后事如何，且听下回分解 ~~
主要参考文章
日志：每个软件工程师都应该知道的有关实时数据的统一概念 —— 这篇比较抽象，高屋建瓴，理论先行
Building LinkedIn’s Real-time Activity Data Pipeline —— 实践层的论文，把做事情的前因后果都写明白了
分布式发布订阅消息系统 Kafka 架构设计 —— 落地设计
次要参考文章
《Building LinkedIn’s Real-time Activity Data Pipeline》
《分布式发布订阅消息系统 Kafka 架构设计》
《StreamBase简介》
《Yahoo! s4和Twitter storm的粗略比较》
《最火爆的开源流式系统Storm vs 新星Samza》
《架构之淘宝实时数据传输平台: TimeTunnel介绍》
《Graylog2 简介》
《logstash 还是不行》
《日志收集以及分析：Splunk 》
《LogStash日志分析系统》
《LogStash，使日志管理更简单》
《logstash VS splunk》
《个性化离线实时分析系统pora》
《日志：每个软件工程师都应该知道的有关实时数据的统一概念》
《基于Flume的美团日志收集系统(二)改进和优化》
《基于Flume的美团日志收集系统(一)架构和设计》
《对互联网海量数据实时计算的理解》
《流式日志系统启示录》
《flume-ng+Kafka+Storm+HDFS 实时系统搭建》
