解密 Uber 数据团队的基础数据架构优化之路

如果你用过Uber,你一定会注意到它的操作是如此的简单。你一键叫车,随后车就来找你了,最后自动完成支付,整个过程行云流水。但是,在这简单的流程背后其实是用Hadoop和Spark这样复杂的基础大数据架构来支撑的。

Uber 在现实世界和虚拟世界的十字路口有令人羡慕的一席之地。这令每天在各个城市穿行的数十万司机大军趋之若鹜。当然这也会一个相对浅显的数据问题。但是,就像Uber数据部门的主管 Aaron Schildkrout所说:商业计划的简单明了带给Uber利用数据优化服务的巨大机会。

“这本质上来说是一个数据问题”,Schildkrout 最近在一个Uber和Databricks的演讲记录中说道。“因为事情是如此浅显,我们想让用车体验变得自动化。在某种程度上,我们正在尝试为全世界的载客司机提供智能、自动化、实时的服务并且支撑服务的规模化。”

不论是Uber在峰时计价、帮助司机规避事故还是为司机寻找最优盈利位置,这一切 Uber 的计算服务都依赖于的数据。这些数据问题是一道数学和全球目的地预测的真正结晶。他说:”这使得这里的数据非常振奋人心,也驱动我们斗志昂扬地用Spark解决这些问题”

Uber 的大数据之道

在Data bricks的演讲中,Uber 工程师描述了(显然是首次公开演讲)一些在应用扩展和满足需求上公司遇到的挑战。

作为负责Uber 数据架构的总负责人,Vinoth Chandar说道:Spark 已经是”必备神器了”。

在旧的架构下,Uber依赖于Kafka的数据流将大量的日志数据传输到AWS的S3上,然后使用EMR来处理这些数据。然后再从EMR导入到可以被内部用户以及各个城市总监使用的关系型数据库中。

Chandar说道:”原来的 Celery+Python的ETL架构其实运转得挺好的,但是当Uber想要规模化时就遇到了一些瓶颈”。随着我们扩展的城市越来越多,这个数据规模也不断增加,在现有的系统上我们遇到了一系列的问题,尤其是在数据上传的批处理过程。

Uber 需要确保最重要的数据集之一的行程数据,这里成百上千的真实准确的消费记录将会影响到下游的用户和应用。Chandar 说道:”这个系统原来并不是为了多数据中心设计的。我们需要用一系列的融合方式将数据放到一个数据中心里面。”

解决方案演化出了一个所谓的基于Spark的流式IO架构,用来取代之前的Celery/Python ETL 架构。新系统从关系型数据仓库表模型将原始数据摄取做了必要的解耦。Chandar说:”你可以在HDFS上获取数据然后再依赖于一些像Spark这样的工具来处理大规模的数据处理。”

因此,取而代之的是在一个关系模型中从多个分布式数据中心聚合行程数据,公司新的架构使用Kafka从本地数据中心来提供实时数据日志,并且加载他们到中心化的Hadoop集群中。接着,系统用Spark SQL 将非结构化的JSON转化为更加结构化的可以使用Hive来做SQL分析的Parquet文件。

他说:”这解决了一系列我们遇到的额外问题,而且我们现在处在一个利用Spark和Spark Streaming 将系统变得长期稳定运行的节点上。我们也计划从访问和获取原始数据也都用Spark任务、Hive、机器学习以及所有有趣的组件,将Spark的潜能彻底释放出来。”

Paricon 和 Komondor

在 Chandar 给出了 Uber 涉险进入Spark的概况之后,另外两名 Uber 工程师,Kelvin Chu 和 Reza Shiftehfar 提供了关于 Paricon 和 Shiftehfar 的更多细节。而这其实是Uber 进军Spark的两个核心项目。

虽然非结构化数据可以轻松搞定,Uber最终还是需要通过数据管道生成结构化数据,因为结构化数据在数据生产者和数据使用者之间生成的”契约”可以有效避免”数据破损”。

这就是为什么Parino 会进入这个蓝图,Chu说道,Parino 这个工具是由4个 Spark为基础的任务组成的:转移、推断、转化并且验证。”因此不论谁想要改变这个数据结构,他们都将进入这个系统,并且必须使用我们提供的工具来修改数据结构。然后系统将运行多个验证和测试来确保这个改变不会有任何问题。”

Paricon 的一大亮点是所谓的”列式剪枝”。我们有许多宽表,但是通常我们每次都不会用到所有的列,因此剪枝可以有效节约系统的IO。他说道:”Paricon 也可以处理一些”数据缝合”工作。一些Uber的数据文件很大,但是大多数都是比HDFS区块来得小的,因此我司将这些小数据缝合在一起对齐HDFS文件大小并且避免IO的运转失常。加之Spark的”数据结构聚合”功能也帮助我们用Paricon 工作流工具直观简化的方式处理Uber数据。”

与此同时, Shiftehfar 为Komondor、Spark Streaming内建的数据摄取服务提供了架构级别的诸多细节。而数据源是”烹饪”的基础,原始非结构数据从Kafka流入HDFS然后准备被下游应用消费。

在 Komondor 之前,它是用来为每个独立应用确保数据准确性的工具(包括获取他们正在处理的数据的上游数据)并且在必要的时候做数据备份。现在通过 Komondor 可以自动处理或多或少的数据。如果用户需要加载数据,使用 Spark Streaming 就相对简单得多。

为了处理每天百万级的事件和请求正在重金投入 Spark 并且打算撬动更多的 Spark技术栈,包括使用MLib和GraphX库做机器学习和图计算。

时间: 2024-11-08 21:37:57

解密 Uber 数据团队的基础数据架构优化之路的相关文章

天弘基金移动App客户端架构优化之路

天弘基金移动App客户端架构优化之路 随着移动互联网时代的到来,移动技术也随之飞速发展.如今,APP已成为绝大多数互联网企业用来获取用户的核心渠道.与此同时,伴随着业务量的增长,愈来愈多的APP也在不断地挑战着每一个移动端研发人员的知识深度,而移动端技术人员也在这个不断接受挑战的过程中,成就了今天的移动互联网时代. 天弘基金作为一家在基金,金融行业高速发展的公司,APP面临着多重挑战,如庞大的用户群体.高频的基金业务.交易安全可靠性等等.天弘基金移动端的开发小伙伴在技术和业务的多重压力下,不断推

企业级Nginx服务基础到架构优化详解--25条

1.隐藏nginx header版本号 2.更改源码隐藏软件名称 3.更改nginx默认用户及用户组 4.配置nginx worker进程个数 5.根据CPU核数进行nginx进程优化 6.nginx事件处理模型优化 7.调整Nginx worker单个进程允许的客户端最大连接数 8.配置Nginx worker进程最大打开文件数 9.开启高效的文件传输模式 10.设置连接超时时间 11.上传文件大小设置(动态应用) 12.fastcgi调优(配合PHP引擎动态服务) 13.配置nginx gz

企业级Nginx服务基础到架构优化详解

1.隐藏nginx header版本号 2.更改源码隐藏软件名称 3.更改nginx默认用户及用户组 4.配置nginx worker进程个数 5.根据CPU核数进行nginx进程优化 6.nginx事件处理模型优化 7.调整Nginx worker单个进程允许的客户端最大连接数 8.配置Nginx worker进程最大打开文件数 9.开启高效的文件传输模式 10.设置连接超时时间 11.上传文件大小设置(动态应用) 12.fastcgi调优(配合PHP引擎动态服务) 13.配置nginx gz

【转】秒杀业务架构优化之路

原文地址:http://www.infoq.com/cn/articles/flash-deal-architecture-optimization/ 一.秒杀业务为什么难做 IM系统,例如QQ或者微博,每个人都读自己的数据(好友列表.群列表.个人信息). 微博系统,每个人读你关注的人的数据,一个人读多个人的数据. 秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万.又例如12306抢票,

Twitter 架构优化之路--Twitter是如何做到每秒处理3000张图片的

如今,Twitter每秒可以创建并保存3000张(20GB)的图片.2015年,Twitter甚至从对媒体存储策略的优化中节省出了600万美元. 但并非一开始就是这样的,2012年Twitter还主要是基于文本的,就像<哈利波特>中的霍格沃茨魔法学校没有了那些悬挂在墙上的炫酷活动照片一样.如今已经是2016年,Twitter已进入了富媒体未来时代.在新媒体平台发展的过程中,Twitter可以支持照片预览.多张照片.gif图.Vine短片以及在线视频. Twitter的软件开发工程师Henna

C# 从字节数组读取基础数据

C#的byte[]和AS3中的ByteArray都是字节数组.但是明显的AS3的ByteArray更加好用一些.因为在ByteArray当中有一个position属性,可以读取相应的字节后,自动指向下一个没有读取的字节的index.这样你永远不用自己再建一个index来手动的处理这件事情了.当然,ByteArray还有其他的一些方法和属性,是byte[]没有的.我这里强调,并非贬低C#,只是在这一块,需要做一些多余的事情,显得相当的繁琐.为此我封装了一个类库,核心类 BytesDecode 如下

数据进入MaxCompute的N种方式,大数据实战Demo系统数据上云实践

摘要: 2018"MaxCompute开发者交流"钉钉群直播分享,由阿里云数据技术专家彬甫带来以"MaxCompute数据仓库数据转换实践"为题的演讲.本文首先介绍了MaxCompute的数据架构和流程,其次介绍了ETL算法中的三大算法,即更新插入算法.直接加载算法.全量历史表算法,再次介绍了在OLTP系统中怎样处理NULL值,最后对ETL相关知识进行了详细地介绍. 2018"MaxCompute开发者交流"钉钉群直播分享,由阿里云数据技术专家彬

1年时间业务量疯长40倍,谈人人车的平台架构演进之路

人人车业务平台从最初典型的LNMP单机单服务部署架构,发展到如今分布式服务化架构,五百多台虚拟机部署,一路走来,踩过不少坑,也遇到过不少挑战,特别是对于基于云服务进行业务开发的场景,以及从零开始服务化与SOA之路更是颇有心得,希望通过此次分享全面回顾人人车业务平台技术架构发展之路,重点分享如下内容: 创业初期技术架构选型思考,那些年我们趟过的坑,云服务与三方服务使用心得: O2O型互联网创业公司,重线下团队技术型公司,技术架构优化之路,分享我们人人车是如何做服务拆分.如何做服务化.如何做SOA.

VFP的数据策略:基础篇

VFP的数据策略:基础篇 作者:Doug Hennig  翻译:老瓷 概述 在VFP应用程序中,有很多方法可以访问非VFP数据(如SQL Server):远程视图.SQL Passthrough(SPT--译者著).ADO.XML……本文件将探讨不同机制的利弊,并讨论何时适合使用特定策略.我们还将研究VFP中一种令人兴奋的新技术CursorAdapter,它将使访问远程数据比早期版本更容易. 介绍 越来越多的VFP开发人员将数据存储在VFP表以外的其他地方,如SQL Server或Oracle.