【大数据】Uber的数据架构
三月份小编在美国参加MVP峰会的时候，有幸碰到了几个Uber的高级工程师，他们在当天还分享了Uber的消息总线系统如何在每日兆级信息量、PB级数据卷、数万个Topic的情况下，保证低延时（小于5ms），高可用（99.99%）,高稳定（99.99%，核心客户100%）的。
有朋友对Uber这种打车软件公司能达到这样的数据量感到不以为然，认为只有社交类（如Facebook、领英，微信）和在线零售（如Ebay、亚马逊，淘宝）的公司才有这样的体量。其实上述的数据量只是Uber的单个数据副本，作为一家遍布全球超过400个城市的出行公司，Uber需要存储世界各地的地图数据；其次，它还需要对这些城市的交通状况做出精确分析，以便对任意时间的路面进行预测；最后，Uber内部还有分析师和数据科学家需要调阅每周的财务收支情况及用户反馈，以及时调整运营策略或调整路线算法。
总体来说，Uber的数据生产者分为两类，一是核心业务数据，包括：
- 乘客信息、司机信息
- 路程规划、账单
- 司机状态变更
- 订单、可用车辆、定价
以上数据对可用性、实时性要求非常高，因此存储在在线数据库（OLTP）中。
第二类数据是日志和事件数据。就在几年前，Uber从传统SOA框架转为微服务，它使运维和开发变得更灵活，并支持非关系型数据库。
而日志作为非结构化的数据，不适用于关系型数据库，这类数据包括：
- 微服务架构
- 数据分析
- 需求跟踪，调试
- 实时数据
这部分数据使用流式的Kafka消息总线作为其核心传输模块。
上图中左边是消息生产者，包括乘客端App，司机端App，以及第三方应用通过调用Uber的API采集来的消息。消息的生产者还包括一部分数据库，来存放用户操作记录等信息：其中MySQL用于存放结构化数据；Schemaless主要存放非结构化数据；Cassandra用来存放需要在各数据中心之间同步的核心数据（因为其低延迟的复制效率）。通过Kafka的处理，再由不同的消费者各取所需，例如Surge拉取数据计算车费；ELK拉取实时日志数据生成运行状态仪表盘；AWS S3和Hadoop拉取数据做一些实时性要求不那么高的离线数据处理。
为保证总线的高可用，每个站点还部署有备用Kafka，以便在主Kafka集群宕机时，将生产者的数据缓存下来，等主集群恢复了再切换回去。不同数据中心的Kafka通过uReplicator（Kafka的镜像生成器）进行汇总后输出。
当然全局的和本地的数据都有消费市场，比如全局有补丁管理，本地化有计价系统，他们在上图不同的Kafka之后（Regional或Aggregate）被依次消费掉。
不光如此，不同的消费者对于数据是有不同的需求维度的。近些年来新的数据库层出不穷，尤其是NoSQL数据库赶上了好时代而层出不穷，小编常被问及哪个数据库最强大，其实这并没有定论，关键要看需求的维度。
消费者对于数据的要求无非以下六个维度：
- 响应速度：如果数据库性能足够强大，没有附加串联系统，数据都在内存中交互，那响应速度无疑是可以保证的
- 查询便捷性：要开放更多的查询维度（或者说更多的查询条件），势必要定义更多的Key，因此会牺牲数据库性能，最明显的是响应延时；
- 安全性：Uber的数据调取需要经过反欺诈等系统的过滤，因此加强数据安全也会带来延时；
- 数据可靠性：有些高访问量的应用为了提高用户体验，会在（交易）数据入库前就将后续指令返回给用户了。
![2018_08_20_22_54_24]( "2018_08_20_22_54_24")
比如用户在某购物APP上买一双鞋，交易在进入数据库之前可能就会向用户征收费用，这一方面是为了用户体验，另一方面大部分数据库同一时间只有一个读写副本，有时数据写入磁盘确实是个漫长的等待过程，所以APP将交易提交给后端缓存就认为交易已经入库，可以开始收费，但如果这时数据库宕机了，缓存数据丢失了，那就等于收了客户的钱没有给客户发货，因为数据库里没有这笔订单。当然订单入库再返回响应势必会慢很多，因为磁盘读写速度是远不及内存的，这一点又是与用户体验之间的博弈。
很多数据库默认都是异步写入，比如MongoDB，它甚至写入成功后也不会返回给应用任何确认入库的信息；再比如Redis，它完全就是一个不可靠的数据库，他会给数据做快照，但快照不会存入磁盘，因此Redis只能用于数据缓存层。
- 数据一致性：逛论坛的朋友经常会碰到这样的事情，就是一个主题或者一个回复我明明只发了一次，刷新页面却蹦出来一堆，这就是数据库的一致性检查没做好。一般的控制方法是限制单位时间的更新频率，或者优化业务逻辑，当然这也要牺牲一部分数据库性能。
![2018_08_20_22_58_00]( "2018_08_20_22_58_00")
- 系统可用性：可用性，一般是指当某个数据中心发生灾难时，应用是否依然可用，数据是否依然可以访问。
在显然无法兼顾所有维度的前提下，作为一款打车软件，在保证响应速度、安全性、查询便捷性和系统高可用的情况下，适度地放弃数据一致性和可靠性是可以接收的。另外，可延展性（Scalability）是Kafka及其消费端软件本身就具有的特点。
