Building LinkedIn’s Real-time Activity Data Pipeline

时间：2024-12-09 13:05:20

转自：http://blog.163.com/guaiguai_family/blog/static/20078414520138911393767/

http://sites.computer.org/debull/A12june/pipeline.pdf
这一套可以成为互联网公司的标准基础架构了，摘要如下：

  • 把数据的 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/)，LinkedIn 的技术还真是牛逼哄哄。。。

相关文章