Uber 的实时数据分析系统架构 - 网站架构札记

标签: | 发表时间:2018-09-03 15:44 | 作者:
出处:http://allenlsy.com

Uber 实时系统的 Use case:

  • 把乘客匹配给司机
  • 计算乘车费
  • 预计乘车时间,司机到达时间等

举一个更详细些的例子,UberEATS 是 Uber 的外卖服务。实时系统也为这个功能估算送餐时间。其中需要考虑的因素有:

  • 餐厅此时的繁忙程度
  • 做这份菜需要的时间
  • 路上的交通状况
  • 大致有多少可以供派遣的送餐车

所有来自乘客和司机的事件 event ,由 Kafka 收集 。Kafka 使用 Pub-sub 的订阅发布模式。Uber 整个系统中各个 microservice 之间的通信也通过了 Kafka。 Uber 使用 Samza 或 Flink 之类的工具做流处理。Kafka 也被用来记录数据库 schema(结构)的变化。

规模

Uber 处理 events 的规模在每天万亿条的级别,大约是百万 events 每秒。数据量在 PB 级。

上图是 Uber real time system 的大体架构。Kafka events 的来源主要是客户端 app,web API / Service 以及数据库。然后 event message 被 Kafka 分发给其他组件。Surge 负责计算乘车费用。ELK 负责做 logging,为 debug 提供数据。 Samza / Flink 处理实时数据,为数据分析和警报功能提供依据。AWS S3 和 Hadoop 也记录 message,供线下数据分析。

Uber 对于这个系统的要求是:

  • 低延迟 Low latancy:API 延迟在 5ms 以内
  • 高可用性 High availability:可用性在 99.99% 以上,意思就是全年宕机大约不超过1小时
  • 多个数据中心之间要可以做数据复制
  • 支持做 message 的数据审计,auditing

Kafka 的架构和流程

02 pipeline

Uber 的 Kafka 架构,是由每个地区的 regional Kafka 将 message 向中心汇总。这其中,Kafka REST proxy 拥有候补服务器 secondary Kafka。因为在 uber 的 Kafka use case 中,有些需求对于高可用性要求非常高,比如用户订车。而有些数据允许丢失,但是要求很低的延迟,比如 logging data。

data flow

为了实现 low latancy 以及 high availability,最重要的两点是:在每个步骤都采用大量批处理(batching)和异步处理(async processing),一定不要阻塞服务器。

举个例子说,从 uber 的手机app上将一条 queue message 发送给 Kafka,是通过 app 里面的 proxy client library。而 proxy client 收到 message 后,立刻 acknowledge,然后将 message 放入一个缓存 buffer 中。当 buffer 填满时,所有 buffer 里面的 message 被打包成一个 batch,一起发送给 Kafka proxy server。这样可以实现 high throughput 和 low latancy 。而在后面, Kafka proxy server 也是一样,收到这个 batch 之后,立刻 acknowledge,然后根据 message 的 broker 不同,重新分类 message,缓存并打包成 batch ,发送给 Regional Kafka。

Uber 的 Proxy client library是自己实现的。它的特点是:

  • 支持高吞吐量 high throughput:非阻塞,异步,批处理
  • 当 kafka server 出现故障时,能缓存 message 在本地。等 server 恢复之后,再逐步发给 server
  • Topic Discovery:类似于 service discovery 的思想。Topic Discovery 负责自动发现哪个 topic 在哪个 kafka cluster 上

uReplicator是为了改进 Kafka 的 mirror maker功能。当一个 broker 被删除时, Kafka 会对 partition 进行 rebalance。从一个 cluster 复制 partition 到另一个 cluster 时,如果一个 cluster 已经有很多 partition 了(比如 500 个以上),mirror maker 功能会变得很慢。

uReplicator 使用了 Apache Helix技术改进了 re-balancing 的过程。

uReplicator 的 github 地址: https://github.com/uber/uReplicator

Uber 开源项目主页: https://uber.github.io/

关于缓存和批处理

有些特别的 use case ,并不适合使用 buffer 加 batch 的机制,比如支付。在前面看到的流程中,如果 app 或者 proxy server 崩溃了,都会造成缓存里的数据丢失。

05 auditing

因此,Uber 的 Kafka 也是要支持同步机制的。类似支付这样的 message,会被 proxy client 同步发给 proxy server ,但不会放进buffer ,proxy client 也不会立刻 acknowledge。Proxy server 发送 message 给 regional Kafka 时,需要至少三台服务器返回 ack ,proxy server 才向 proxy client 返回 ack。此时为了保证高一致性,而增加了延迟。Uber 的系统支持对各个步骤的机制做微调,以找到最适合自己的配置。

审计工具 Chaperone

05 auditing

Chaperone是 Uber 开发的审计工具,主要负责统计和分析 message 的信息,包括 message 的数量,以及延迟。Uber 在这个 pipeline 的每个阶段几乎都插入了 Chaperone。app 客户端会发送数据给 Chaperone web service,Kafka cluster 会发送数据给 Chaperone kafka service。Uber 以每10分钟作为一个时间片,将数据统计给 Chaperone report service,以供数据分析。Report service 使用跨地区的 Cassandra 数据库。根据这些 message 数量的统计信息,如果来自客户端的统计和服务器端的统计有较大不匹配,也可以看出服务器是否出现故障。

Chaperone 服务于2015年在 Uber 上线使用,审计超过2万个 Kafka topic。

Clsuter Balancing 服务器集群平衡工具

06

Kafka 的数据是采用 consistent hashing 的方式存储的。上图展示了 consistent hashing 的结构。当一个 partition 的数据过多时,Kafka 并没有一个自动的 balacing 解决方案。 Uber 开发了一个工具,当一个 cluster 的数据过多时,会自动生成一个后台任务,创建一个新的 partition,并且做数据迁移。


原演讲地址:How Uber scaled its Real Time Infrastructure to Trillion events per day

https://youtu.be/K-fI2BeTLkk


相关 [uber 实时 数据分析] 推荐:

Uber 的实时数据分析系统架构 - 网站架构札记

- -
Uber 实时系统的 Use case:. 举一个更详细些的例子,UberEATS 是 Uber 的外卖服务. 实时系统也为这个功能估算送餐时间. 所有来自乘客和司机的事件 event ,由 Kafka 收集. Kafka 使用 Pub-sub 的订阅发布模式. Uber 整个系统中各个 microservice 之间的通信也通过了 Kafka.

使用Storm实现实时大数据分析

- - 开源软件 - ITeye博客
摘要:随着数据体积的越来越大,实时处理成为了许多机构需要面对的首要挑战. Shruthi Kumar和Siddharth Patankar在Dr.Dobb’s上结合了汽车超速监视,为我们演示了使用Storm进行实时大数据分析. 简单和明了,Storm让大数据分析变得轻松加愉快. 当今世界,公司的日常运营经常会生成TB级别的数据.

Excel 数据分析

- - ITeye博客
用Excel做数据分析——直方图. 已有 0 人发表留言,猛击->> 这里<<-参与讨论. —软件人才免语言低担保 赴美带薪读研.

Uber 是如何利用大数据的

- - 博客 - 伯乐在线
这篇文章概述了 Uber 是如何利用大数据分析实现商业上的成功. 文章首次发表于作者在 Data Science Central 的专栏中. Uber 是一款基于智能手机应用的出租车预定服务,将需要出行的用户和愿意提供驾驶服务的司机联结起来. 由于传统出租车的司机认为这破坏了他们的生计,而且大众对 Uber 对司机在管理上的不足也有所顾虑,这项服务已经引起了巨大的争议.

关于Uber机制的思考

- - KantHouse 追从本心,笑斩荆棘
昨天写了一篇关于滴滴打车改版的文章(文章链接),引发了一些关于Uber和滴滴的对比讨论. 质疑明显歪了楼,大家主要讨论的是,Uber忽略目的地的问题和它的派单机制,而我在昨天文章中说的是Uber的首页设计的一些问题,具体来说,是它的出发地和开始用车的按钮不在一起的问题,以及出发地带搜索icon带来误解的问题.

扯扯数据分析

- - 互联网分析
在别人的眼里数据分析既是很深奥的职业,也是被人挑战的职业,更是让你又恨又爱的职业. 其实这些都不重要的,重要的是对此行感兴趣,骨子里有量化一切的 意识. 很多人首先脑海中出现的是1、2、3……等等,为何有这样的印象. 其实是我们数据分析师为了更好的运用“统计学”所以要将许多 数据想尽办法来转化为1、2、3这样的数据形式,从而更深入、科学的分析data,不扯这个了,这个没什么意思,看图:.

数据分析那些事

- - 小蚊子乐园
今早突然有个想法,就是经常有网友会对数据分析方面有一些困惑,并且咨询我该怎么办. 并且经常是同样的问题,所以觉得有必要对一些经典共性的问题进行整理,与大家分享,这里并非标准答案,仅作参考. 欢迎提出自己对数据方面的疑问,将在此篇将持续更新,敬请关注. ----------------------------------------我不是完美的分割线--------------------------------------- .

谈大数据分析

- - 人月神话的BLOG
对于数据分析层,我们可以看到,其核心重点是针对海量数据形成一个分布式可弹性伸缩的,高查询性能的,支持标准sql语法的一个ODS库. 我们看到对于Hive,impala,InfoBright更多的都是解决这个层面的问题,即解决数据采集问题,解决采集后数据行列混合存储和压缩的问题,然后形成一个支撑标准sql预防的数据分析库.

Uber 在运营策略上到底厉害在哪?

- - 知乎每日精选
感谢各位知友提醒,博客昨两天访问量太大,一下子冲挂了. 已经升级服务器配置,现在可以正常访问了:). 看不下去了,一些事实+各种吹捧+美化缺点+你学会了吗. 明显的朋友圈文章居然有700多人点赞,特别是还有一个敬佩的前辈点赞,心碎……我觉得真的要学习的话,应该在好的地方辩证思考,在不好的地方承认并且想解决办法,而不是一通乱夸.

Uber火了!它改变了哪些营销游戏规则?

- - 互联网的那点事
一面是专车司机揽客被抓罚款弄得人尽皆知,一面又被媒体视为宠儿上着各大媒体、自媒体的头条要闻. 作为与Airbnb、facebook等同样令人瞩目的创新先锋,为了拉动车源和客源,Uber表现出了许多灵光乍现的创意,如“一键呼叫英雄”、“一键叫高管”、“一键叫人力三轮”、“打船”等,那么除了被媒体曝光的看的见的那些创意噱头,还有哪些Uber修炼的真功夫值得市场营销者学习借鉴的呢.