博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Building LinkedIn’s Real-time Activity Data Pipeline
阅读量:4593 次
发布时间:2019-06-09

本文共 1138 字,大约阅读时间需要 3 分钟。

转自: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 (),LinkedIn 的技术还真是牛逼哄哄。。。

转载于:https://www.cnblogs.com/DjangoBlog/p/3535514.html

你可能感兴趣的文章
[洛谷P3931]SAC E#1 - 一道难题 Tree
查看>>
设计模式学习总结:(5)装饰模式
查看>>
sql JOIN语句应注意on与where的区别
查看>>
[转载]python 详解re模块
查看>>
【经验】在CSS中定义a:link、a:visited、a:hover、a:active顺序
查看>>
Linux搭建maven私服
查看>>
中兴机试
查看>>
Node.js的颠覆者:PHP的Swoole扩展
查看>>
Binary Tree的3种非Recursive遍历
查看>>
PCL AllInOne msvc2017 下载
查看>>
电影天堂,批量下载,简单实现
查看>>
oracle 12c 加入系统服务
查看>>
未能加载文件或程序集“Oracle.DataAccess”或它的某一个依赖项.试图加载格式不正确的程序...
查看>>
【转载】《Flexpaper二次开发入门教程》(十) Flexpaper简单使用-第一个Flexpaper例子(4.1节) ......
查看>>
如何深入思考
查看>>
用逗号隔开简单数据保存为csv
查看>>
POJ-1860 Currency Exchange SPFA判断环
查看>>
xampp+eclipse环境下使用phpunit
查看>>
python的类和对象(1)
查看>>
一个动态内存管理模块的实现
查看>>