数据API 数据治理 会员 案例 开发者
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

Uber如何做到每秒100万次写入操作?在多个数据中心使用Mesos和Cassandra

如果贵公司是Uber,需要存储每30秒由司机和乘客应用程序发送出去的位置数据,该如何是好?要知道,有许多实时数据是需要实时使用的。

Uber的解决方案很全面。它构建了自己的系统,该系统在Mesos上运行Cassandra。这在Uber的软件工程师阿披谢克·弗玛(Abhishek Verma)的一次畅谈中都得到了解释,那次畅谈题为《Uber:多个数据中心环境下的Mesos上的Cassandra》(多张幻灯片,详见http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016)。

这是不是贵公司也应采取的做法?这是读者在听阿披谢克的畅谈时会忖到的一个饶有意思的想法。

如今,开发人员要做出许多艰难的选择。我们该不该全身心地投入到云?哪一种云?成本是不是太过高昂?我们是否要担心厂商锁定?还是我们应该双管齐下,亲自搭建一种混合架构?还是说由于担心无法获得50%的毛利率,我们就应该完全自己搞?

Uber决定自行构建。或者确切地说,它决定通过结合两种功能非常强大的开源组件,组建一套自己的系统。需要的是让Cassandra和Mesos协同运行的一种方法,这就是Uber构建的方法。

对Uber来说,做出这个决定并不是太难。它财力很雄厚,拥有构建、维护和更新这种复杂系统所需的一流人才和资源。

由于Uber的目标是能够为任何地方准备出行的任何人确保99.99%的可用性,你在扩展到无限庞大的规模时,希望能够控制成本确实有其必要性。

但是你在听畅谈时,会认识到构建这种系统需要投入大量的精力。这果真是普通公司所能胜任的吗?不,胜任不了。如果你属于对云说不的那些人,希望每个人都在最基本的裸机上构建自己的代码,就要牢记这一点。

拿金钱换时间常常很划算。拿金钱换技能常常绝对必不可少。

考虑到Uber在可靠性方面的目标:在10000个请求中,只有1个请求可以失败,它就需要运行多个数据中心。由于事实证明Cassandra可以跨数据中心处理庞大的负载和工作,它成为数据库方面的选择合情合理。

如果你想确保任何地方的任何人都有可靠的出行,就需要高效地利用资源。这正是使用Mesos之类的数据中心操作系统背后的想法。通过在同样的机器统计多路复用服务,你需要的机器数量可以减少30%,这节省了资金。之所以选择Mesos,是因为当时Mesos是被证明唯一可处理数万个机器组成的庞大集群的产品,Uber需要这么大的集群。Uber采取的都是大手笔。

一些更令人关注的结果还有什么?

  • 可以在容器里面运行有状态的服务。Uber发现,在裸机上运行Cassandra与在Mesos管理的容器里面运行Cassandra基本上没什么区别,开销只相差5%至10%。
  • 性能很好:平均读取延迟是13毫秒,写入延迟是25毫秒,P99延迟看起来很短。
  • 针对最大的集群,Uber能支持每秒100多万次写入和约10万次读取。
  • 敏捷性比性能来得更重要。Uber构建的这种架构拥有所需的敏捷性。很容易在集群上构建和运行工作负载。

下面是我对那次畅谈的注释:

开始阶段

  • 针对不同的服务,使用统计分区的机器。
  • 50台机器可能专用于API,50台机器专用于存储,等等,它们并不互相重叠。

现阶段

  • 想在Mesos上运行一切,包括Cassandra和Kafka之类有状态的服务。
  • Mesos是数据中心操作系统,让你可以对数据中心进行编程,数据中心如同单一资源池。
  • 当时,Mesos被证明可以在数万台机器上运行,这是Uber的要求之一,所以这就是为什么当初它选择了Mesos。如今,Kubernetes可能也行。
  • Uber在MySQL上构建了自己的分片数据库,名为Schemaless(https://eng.uber.com/schemaless-part-one/)。其想法是,Cassandra和Schemaless将是Uber的两大数据存储方案。现有的Riak安装系统将迁移到Cassandra。
  • 单单一台机器就能运行不同种类的服务。
  • 同一机器上统计多路复用服务可以将需要的机器减少30%。这是在谷歌的Borg系统上进行的试验得出的结果。
  • 比如说,如果一个服务使用许多CPU,它与使用许多存储或内存资源的另一个服务很相配,那么这两个服务就可以在同一台服务器上高效地运行。机器的利用率就会提高。
  • Uber现在有约20个Cassandra集群,计划将来有100个集群。
  • 敏捷性比性能来得更重要。需要能够管理这些集群,并且顺畅地执行在上面运行的不同服务。
  • 为何在容器中运行Cassandra,而不是就在整个机器上运行?
  • 你想要存储数百GB的数据,但又希望数据复制在多台机器上,而且跨数据中心复制。
  • 你还想要不同的集群之间实现资源隔离和性能隔离。
  • 很难在单一的共享集群中做到这一切。比如说,如果你构建了由1000个节点组成的Cassandra集群,它无法扩展,或者不同的集群之间会出现性能干扰。

生产环境

  • 两个数据中心(东西海岸)约20个集群复制数据。
  • 最初只有4个集群,包括中国,但是自从与滴滴合并以来,那些集群已被关闭。
  • 两个数据中心有约300台机器。
  • 最大的2个集群:每秒100多万次写入,每秒约10万次读取。
  • 其中一个集群存储每30秒由司机和乘客应用程序发送出去的位置数据。
  • 平均读取延迟是13毫秒,写入延迟是25毫秒。
  • 主要使用LOCAL_QUORUM一致性级别(这意味着强一致性)。

Mesos背景知识介绍

  • Mesos将CPU、内存和存储资源从机器抽取出来。
  • 你不是着眼于单台机器,而是着眼于资源池,并针对资源池编程。
  • 线性扩展性。可以在数万台机器上运行。
  • 高可用性。Zookeeper用于数量可配置的副本当中的主节点选举(leader election)。
  • 可以启动Docker容器或Mesos容器。
  • 可插式资源隔离。面向Linux的Cgroups内存和CPU隔离器。有一个Posix隔离器。还有面向不同操作系统的隔离机制。
  • 两级调度程序。来自Mesos代理的资源提供给不同的框架。框架针对提供的这些资源,调度各自的任务。

Apache Cassandra背景知识介绍

  • Cassandra很适合Uber的使用场合。
  • 可横向扩展。新节点添加后,读取和写入可线性扩展。
  • 高可用性。具有容错性,并拥有可调整的一致性级别。
  • 低延迟。可在同一数据中心里面获得亚毫秒级延迟。
  • 操作简单。这是一种同构集群。没有主节点。集群中没有特殊节点。
  • 足够丰富的数据模型。它有列、组合键、计数器、辅助索引等。
  • 与开源软件很好地整合起来。Hadoop、Spark和Hive都拥有可与Cassandra对话的连接件。

Mesosphere + Uber + Cassandra = Dcos-Cassandra-Service

  • Uber使用Mesosphere来生成mesosphere/dcos-cassandra-service,这种自动化服务让用户很容易在Mesosphere DC/OS上进行部署和管理。

  • 最上面的是Web Interface或控制平面API。你可以指定想要多少个节点、想要多少CPU,指定一种Cassandra配置,然后提交给控制平面API。
  • 使用Uber的部署系统,它可以在Aurora上启动,Aurora用于运行无状态的服务,它用于启动dcos-cassandra-service框架。
  • 在例子中,dcos-cassandra-service框架有两个与Mesos主节点对话的集群。Uber在系统中使用五个Mesos主节点。Zookeeper用于主节点选举。
  • Zookeeper还用于存储框架元数据:哪些任务在运行、Cassandra配置以及集群的健康状况等。
  • Mesos代理在集群中的每个机器上运行。代理为Mesos主节点提供了资源,主节点随后单独分配资源。分配的资源可能被框架接受或拒绝。多个Cassandra节点可能在同一个机器上运行。
  • 使用的是Mesos容器,而不是Docker。

  • 覆盖配置中的5个端口(storage_port、ssl_storage_port、native_transport_port、rpcs_port和jmx_port),那样多个容器可以在同一个机器上运行。

  • 使用持久性卷,那样数据可以存储在沙盒目录外面。万一Cassandra失效,数据仍在持久性卷中,并提供给同一任务。

  • 动态预留用来确保有资源可用于重新启动失效的任务。

  • Cassandra服务操作
  • Cassandra用到了种子节点概念,种子节点为加入集群的新节点启动广播进程(gossip process)。定制的种子提供者创建,以启动Cassandra节点,这让Cassandra节点得以自动部署到Mesos集群中。
  • Cassandra集群中的节点数量可以使用REST请求来增加。它会启动额外节点,为它提供种子节点,并启动额外的Cassandra守护进程。
  • 所有Cassandra配置参数都可以更改。
  • 使用API,就可以更换死亡节点。
  • 需要修复,以便跨副本同步数据。逐个节点地在主键区间上进行修复。这个方法并不影响性能。
  • 清理可清除不需要的数据。如果节点已添加,那么数据将迁移到新节点上,所以需要清理来删除已迁移的数据。
  • 多数据中心复制可通过框架来配置。
  • 支持多数据中心
  • 可在每个数据中心独立安装Mesos。
  • 可在每个数据中心独立安装框架的实例。
  • 框架可以彼此对话,并定期交换种子。
  • 这就是Cassandra所需的一切。通过启动其他数据中心的种子,节点就能广播拓扑结构,并搞清楚有什么节点。
  • 数据中心之间的往返ping延迟是77.8毫秒。
  • 异步复制延迟: P50是44.69毫秒,P95是46.38毫秒,P99是47.44毫秒。
  • 调度程序的执行
  • 调度程序的执行被抽象成计划、阶段和block。调度计划有不同的阶段,而阶段又有多个block。
  • 调度程序在打开后经历的第一个阶段是调和。它会查询Mesos,搞清楚已经在运行的对象。
  • 有一个部署阶段,检查配置中的节点数量是不是已经存在于集群中,必要的话部署节点。
  • block似乎是Cassandra节点的一个规格。
  • 有其他阶段:备份、恢复、清理和修复,这取决于遇到的是哪些REST端点。
  • 能够以每分钟一个新节点的速度启动集群
  • 启动速度时间想要达到每个节点30秒。
  • 多个节点无法在Cassandra中同时启动。
  • 通常为每个Mesos节点提供2TB的磁盘空间和128GB内存。100GB被分配给每个容器,32GB栈区被分配给每个Cassandra进程(注意:这不是很明确,所以细节方面可能有误)。
  • 使用G1垃圾回收器,而不是CMS;未经任何调整,它就拥有好得多的99.9th percentile延迟和性能。
  • 裸机vs Mesos托管集群
  • 使用容器有什么样的性能开销?裸机意味着Cassandra不是在容器中运行。
  • 读取延迟。几乎没什么区别:开销相差5%至10%。
  • 在裸机上,平均延迟是.38毫秒,而在Mesos上平均延迟是.44毫秒。
  • 裸机的P99延迟是.91毫秒,在Mesos上,P99延迟是.98毫秒。
  • 读取吞吐量:差异非常小。
  • 写入延迟
  • 在裸机上,平均延迟是.43毫秒,而在Mesos上,平均延迟是.48毫秒。
  • 裸机的P99延迟是1.05毫秒,而在Mesos上,P99延迟是1.26毫秒。
  • 读取吞吐量:差异非常小。

原文来自:云疯报

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
Uber如何做到每秒100万次写入操作?在多个数据中心使用Mesos和Cassandra
发布:2016-10-09

如果贵公司是Uber,需要存储每30秒由司机和乘客应用程序发送出去的位置数据,该如何是好?要知道,有许多实时数据是需要实时使用的。

Uber的解决方案很全面。它构建了自己的系统,该系统在Mesos上运行Cassandra。这在Uber的软件工程师阿披谢克·弗玛(Abhishek Verma)的一次畅谈中都得到了解释,那次畅谈题为《Uber:多个数据中心环境下的Mesos上的Cassandra》(多张幻灯片,详见http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016)。

这是不是贵公司也应采取的做法?这是读者在听阿披谢克的畅谈时会忖到的一个饶有意思的想法。

如今,开发人员要做出许多艰难的选择。我们该不该全身心地投入到云?哪一种云?成本是不是太过高昂?我们是否要担心厂商锁定?还是我们应该双管齐下,亲自搭建一种混合架构?还是说由于担心无法获得50%的毛利率,我们就应该完全自己搞?

Uber决定自行构建。或者确切地说,它决定通过结合两种功能非常强大的开源组件,组建一套自己的系统。需要的是让Cassandra和Mesos协同运行的一种方法,这就是Uber构建的方法。

对Uber来说,做出这个决定并不是太难。它财力很雄厚,拥有构建、维护和更新这种复杂系统所需的一流人才和资源。

由于Uber的目标是能够为任何地方准备出行的任何人确保99.99%的可用性,你在扩展到无限庞大的规模时,希望能够控制成本确实有其必要性。

但是你在听畅谈时,会认识到构建这种系统需要投入大量的精力。这果真是普通公司所能胜任的吗?不,胜任不了。如果你属于对云说不的那些人,希望每个人都在最基本的裸机上构建自己的代码,就要牢记这一点。

拿金钱换时间常常很划算。拿金钱换技能常常绝对必不可少。

考虑到Uber在可靠性方面的目标:在10000个请求中,只有1个请求可以失败,它就需要运行多个数据中心。由于事实证明Cassandra可以跨数据中心处理庞大的负载和工作,它成为数据库方面的选择合情合理。

如果你想确保任何地方的任何人都有可靠的出行,就需要高效地利用资源。这正是使用Mesos之类的数据中心操作系统背后的想法。通过在同样的机器统计多路复用服务,你需要的机器数量可以减少30%,这节省了资金。之所以选择Mesos,是因为当时Mesos是被证明唯一可处理数万个机器组成的庞大集群的产品,Uber需要这么大的集群。Uber采取的都是大手笔。

一些更令人关注的结果还有什么?

  • 可以在容器里面运行有状态的服务。Uber发现,在裸机上运行Cassandra与在Mesos管理的容器里面运行Cassandra基本上没什么区别,开销只相差5%至10%。
  • 性能很好:平均读取延迟是13毫秒,写入延迟是25毫秒,P99延迟看起来很短。
  • 针对最大的集群,Uber能支持每秒100多万次写入和约10万次读取。
  • 敏捷性比性能来得更重要。Uber构建的这种架构拥有所需的敏捷性。很容易在集群上构建和运行工作负载。

下面是我对那次畅谈的注释:

开始阶段

  • 针对不同的服务,使用统计分区的机器。
  • 50台机器可能专用于API,50台机器专用于存储,等等,它们并不互相重叠。

现阶段

  • 想在Mesos上运行一切,包括Cassandra和Kafka之类有状态的服务。
  • Mesos是数据中心操作系统,让你可以对数据中心进行编程,数据中心如同单一资源池。
  • 当时,Mesos被证明可以在数万台机器上运行,这是Uber的要求之一,所以这就是为什么当初它选择了Mesos。如今,Kubernetes可能也行。
  • Uber在MySQL上构建了自己的分片数据库,名为Schemaless(https://eng.uber.com/schemaless-part-one/)。其想法是,Cassandra和Schemaless将是Uber的两大数据存储方案。现有的Riak安装系统将迁移到Cassandra。
  • 单单一台机器就能运行不同种类的服务。
  • 同一机器上统计多路复用服务可以将需要的机器减少30%。这是在谷歌的Borg系统上进行的试验得出的结果。
  • 比如说,如果一个服务使用许多CPU,它与使用许多存储或内存资源的另一个服务很相配,那么这两个服务就可以在同一台服务器上高效地运行。机器的利用率就会提高。
  • Uber现在有约20个Cassandra集群,计划将来有100个集群。
  • 敏捷性比性能来得更重要。需要能够管理这些集群,并且顺畅地执行在上面运行的不同服务。
  • 为何在容器中运行Cassandra,而不是就在整个机器上运行?
  • 你想要存储数百GB的数据,但又希望数据复制在多台机器上,而且跨数据中心复制。
  • 你还想要不同的集群之间实现资源隔离和性能隔离。
  • 很难在单一的共享集群中做到这一切。比如说,如果你构建了由1000个节点组成的Cassandra集群,它无法扩展,或者不同的集群之间会出现性能干扰。

生产环境

  • 两个数据中心(东西海岸)约20个集群复制数据。
  • 最初只有4个集群,包括中国,但是自从与滴滴合并以来,那些集群已被关闭。
  • 两个数据中心有约300台机器。
  • 最大的2个集群:每秒100多万次写入,每秒约10万次读取。
  • 其中一个集群存储每30秒由司机和乘客应用程序发送出去的位置数据。
  • 平均读取延迟是13毫秒,写入延迟是25毫秒。
  • 主要使用LOCAL_QUORUM一致性级别(这意味着强一致性)。

Mesos背景知识介绍

  • Mesos将CPU、内存和存储资源从机器抽取出来。
  • 你不是着眼于单台机器,而是着眼于资源池,并针对资源池编程。
  • 线性扩展性。可以在数万台机器上运行。
  • 高可用性。Zookeeper用于数量可配置的副本当中的主节点选举(leader election)。
  • 可以启动Docker容器或Mesos容器。
  • 可插式资源隔离。面向Linux的Cgroups内存和CPU隔离器。有一个Posix隔离器。还有面向不同操作系统的隔离机制。
  • 两级调度程序。来自Mesos代理的资源提供给不同的框架。框架针对提供的这些资源,调度各自的任务。

Apache Cassandra背景知识介绍

  • Cassandra很适合Uber的使用场合。
  • 可横向扩展。新节点添加后,读取和写入可线性扩展。
  • 高可用性。具有容错性,并拥有可调整的一致性级别。
  • 低延迟。可在同一数据中心里面获得亚毫秒级延迟。
  • 操作简单。这是一种同构集群。没有主节点。集群中没有特殊节点。
  • 足够丰富的数据模型。它有列、组合键、计数器、辅助索引等。
  • 与开源软件很好地整合起来。Hadoop、Spark和Hive都拥有可与Cassandra对话的连接件。

Mesosphere + Uber + Cassandra = Dcos-Cassandra-Service

  • Uber使用Mesosphere来生成mesosphere/dcos-cassandra-service,这种自动化服务让用户很容易在Mesosphere DC/OS上进行部署和管理。

  • 最上面的是Web Interface或控制平面API。你可以指定想要多少个节点、想要多少CPU,指定一种Cassandra配置,然后提交给控制平面API。
  • 使用Uber的部署系统,它可以在Aurora上启动,Aurora用于运行无状态的服务,它用于启动dcos-cassandra-service框架。
  • 在例子中,dcos-cassandra-service框架有两个与Mesos主节点对话的集群。Uber在系统中使用五个Mesos主节点。Zookeeper用于主节点选举。
  • Zookeeper还用于存储框架元数据:哪些任务在运行、Cassandra配置以及集群的健康状况等。
  • Mesos代理在集群中的每个机器上运行。代理为Mesos主节点提供了资源,主节点随后单独分配资源。分配的资源可能被框架接受或拒绝。多个Cassandra节点可能在同一个机器上运行。
  • 使用的是Mesos容器,而不是Docker。

  • 覆盖配置中的5个端口(storage_port、ssl_storage_port、native_transport_port、rpcs_port和jmx_port),那样多个容器可以在同一个机器上运行。

  • 使用持久性卷,那样数据可以存储在沙盒目录外面。万一Cassandra失效,数据仍在持久性卷中,并提供给同一任务。

  • 动态预留用来确保有资源可用于重新启动失效的任务。

  • Cassandra服务操作
  • Cassandra用到了种子节点概念,种子节点为加入集群的新节点启动广播进程(gossip process)。定制的种子提供者创建,以启动Cassandra节点,这让Cassandra节点得以自动部署到Mesos集群中。
  • Cassandra集群中的节点数量可以使用REST请求来增加。它会启动额外节点,为它提供种子节点,并启动额外的Cassandra守护进程。
  • 所有Cassandra配置参数都可以更改。
  • 使用API,就可以更换死亡节点。
  • 需要修复,以便跨副本同步数据。逐个节点地在主键区间上进行修复。这个方法并不影响性能。
  • 清理可清除不需要的数据。如果节点已添加,那么数据将迁移到新节点上,所以需要清理来删除已迁移的数据。
  • 多数据中心复制可通过框架来配置。
  • 支持多数据中心
  • 可在每个数据中心独立安装Mesos。
  • 可在每个数据中心独立安装框架的实例。
  • 框架可以彼此对话,并定期交换种子。
  • 这就是Cassandra所需的一切。通过启动其他数据中心的种子,节点就能广播拓扑结构,并搞清楚有什么节点。
  • 数据中心之间的往返ping延迟是77.8毫秒。
  • 异步复制延迟: P50是44.69毫秒,P95是46.38毫秒,P99是47.44毫秒。
  • 调度程序的执行
  • 调度程序的执行被抽象成计划、阶段和block。调度计划有不同的阶段,而阶段又有多个block。
  • 调度程序在打开后经历的第一个阶段是调和。它会查询Mesos,搞清楚已经在运行的对象。
  • 有一个部署阶段,检查配置中的节点数量是不是已经存在于集群中,必要的话部署节点。
  • block似乎是Cassandra节点的一个规格。
  • 有其他阶段:备份、恢复、清理和修复,这取决于遇到的是哪些REST端点。
  • 能够以每分钟一个新节点的速度启动集群
  • 启动速度时间想要达到每个节点30秒。
  • 多个节点无法在Cassandra中同时启动。
  • 通常为每个Mesos节点提供2TB的磁盘空间和128GB内存。100GB被分配给每个容器,32GB栈区被分配给每个Cassandra进程(注意:这不是很明确,所以细节方面可能有误)。
  • 使用G1垃圾回收器,而不是CMS;未经任何调整,它就拥有好得多的99.9th percentile延迟和性能。
  • 裸机vs Mesos托管集群
  • 使用容器有什么样的性能开销?裸机意味着Cassandra不是在容器中运行。
  • 读取延迟。几乎没什么区别:开销相差5%至10%。
  • 在裸机上,平均延迟是.38毫秒,而在Mesos上平均延迟是.44毫秒。
  • 裸机的P99延迟是.91毫秒,在Mesos上,P99延迟是.98毫秒。
  • 读取吞吐量:差异非常小。
  • 写入延迟
  • 在裸机上,平均延迟是.43毫秒,而在Mesos上,平均延迟是.48毫秒。
  • 裸机的P99延迟是1.05毫秒,而在Mesos上,P99延迟是1.26毫秒。
  • 读取吞吐量:差异非常小。

原文来自:云疯报

电话 0512-88869195