【专访】携程李亚锋:大数据技术融合下的Spark更具魅力

PPV课大数据

“大数据”作为当下最火热的IT行业词汇,在主流的数据处理工具当中Hadoop和Spark都被大家所熟悉。不过,目前基于内存计算的Spark适合各种迭代算法和交互式数据分析,能够提升大数据处理的实时性和准确性,已经逐渐获得很多企业的支持。这是否意味着我们应该彻底抛弃Hadoop?在前不久的北京Spark亚太峰会上 ,记者有机会专访到携程大数据平台高级经理李亚锋,为大家分享如何通过Spark与Hadoop大数据技术间的融合,实现优势互补,引导企业发现用户的潜在需求。

李亚锋,携程大数据平台高级经理,负责大数据底层平台的运营和开发。2002年起一直专注于IT互联网领域,从事过网络会议、IPTV、安全网关、游戏架构、搜索引擎、推荐引擎等,主要偏后台架构和底层开发。加入携程后,开始转向大数据领域。

以下为51CTO记者对李亚锋老师的专访录音整理

您在携程主要负责什么工作?目前我们大数据的应用情况和规模是怎么样的?

目前我是携程DI(Data infrastructure)团队高级经理,主要负责大数据底层平台的运营和开发。我2002年毕业后一直在IT互联网的领域工作,加入携程之后,转向大数据领域。我们从4个节点的hadoop集群做起,目前达到200个节点的规模,数据达3PB,每天job数3万以上,每天数据增量40TB,有力支持了携程大数据相关业务的发展。

大数据对我们公司业务的支持作用非常大,包括海量日志和metrics处理、推荐引擎、爬虫、用户行为日志分析、BI报表、风控、搜索引擎、机器学习、监控报警等都使用到大数据技术。

目前DI团队有多少人?

包括我在内,总共6人。

咱们现在团队里有六个人,成员不是很多,团队的分工情况大致是什么状况?

携程的业务线比较长,部门比较多,相对于我们要支持的业务部门和数据规模来说,DI团队人手确实偏紧。我们采用了一种比较新的工作方式,就是DevOps(开发运维),用来提高整个团队的效率。团队成员既做开发又做运维,把运维的工作化解掉。我们要求团队成员除了能解决生产环境出现的各种问题外,还能修复bug,开发工具,并且为社区贡献代码。这样对团队成员的能力要求比较高,这方面的人才也比较紧缺。

携程大数据平台正在快速发展中,我们希望有志之士加盟,大家一起成长。

作为专门做在线旅游服务的公司,大数据给携程的业务带来什么转变呢?

用户到携程的平台,一般都有一个比较明确的消费目的,但并不等于说他没有个性化方面的需求。这些个性化的需求在传统的小数据时代是不能满足的。当我们积累到足够的用户数据,大数据技术就能分析出用户的喜好与购买习惯,得出的结果有时甚至比用户自己还要了解自己。通过对数据的分析,了解用户的行为特征,以及他们对服务的期待,然后利用这些数据,我们就可以对用户做到精准细分,有针对性地对用户提供个性化服务和推荐,从而使用户得到更好的服务体验。

携程业务正在从PC端往移动端转型,目前大概有一半的业务是在移动端完成的,应该说这个转型还是非常成功的。移动端的用户行为数据会远大于PC端,这对我们来说是一个挑战,同时也是一个机会。

作为OTA(在线旅游服务商)的龙头,携程在这个行业深耕十多年,有非常庞大的交易数据和用户数据,这是我们一个非常大的优势。利用这些庞大的历史数据,加上我们的品牌优势,在大数据方向进行突破,加大投入和研发,未来肯定会产生很多意想不到的成果。

总而言之,利用大数据技术可以帮助公司明确市场定位,分析用户行为,发现潜在需求,进行趋势预测,营销创新,智能决策等等。

在使用Spark之前,我们还用过什么大数据的处理方法?

以前使用Hadoop/HBase,现在我们还在用。目前我们是把Spark和Hadoop/HBase结合起来在用。

我个人认为,实时性要求不高的,传统的MapReduce还是可以的。第一它技术很成熟,第二它比较稳定,缺点就是慢一点,其他没什么。另外,存储那块现在HDFS还是不可能取代的,高容错,高吞吐,分布式,也很稳定。还有实时读写方面,HBase也不会被spark取代。我认为底层存储还是要用Hadoop/HBase。

随着技术的不断发展,我们的选择更多了,选择也更趋于理性,关键是要看你的需求是什么。如果两边都差不多,那我们选择一个稳定的。比方说这个job跑一小时能接受,跑两个小时也能接受,但我们要求稳定,肯定用MapReduce更合适。如果只是单纯考虑效率,肯定是选择一个执行速度快的系统。原来是没有选择,只能通过各种手段优化,但是这个治标不治本,因为它受框架限制,性能不可能提升很多倍。现在有像Spark这样更好的分布式计算引擎出来了,能够数倍的提高效率。那么我们的考虑是,对延迟要求比较高的job,可以考虑挪一部分出来放在spark引擎计算;延迟要求不高的,还是放在传统的mapreduce引擎计算。这两个并不矛盾,关键还是要看哪个更适合你的需求。

对Spark来说,最大的优势在于速度,那这个速度是怎么实现的呢?它相当于是用空间换时间,所以它耗资源,占内存。从运营的角度看,它的成本会比MapReduce要高。spark在资源管理这块目前还不够成熟,但这都是发展中的问题,以后应该会解决。从整个架构来讲,我认为Spark和Hadoop两个应该是互补,并不是说完全排斥、对立的。

您认为Spark以后会代替Hadoop吗?

我觉得是不太可能代替。因为Hadoop毕竟被很多大公司验证过,是没有问题的,它肯定是可用的东西。Spark有很多的做法也是参考Hadoop来实现的。现在Spark还在推广阶段,还没有被大规模的使用。我认为Hadoop的地位未来会降一点,这个是肯定的,但是它不会消失,不可能被Spark取代。

Spark基于内存上面进行计算,像您说相当于“空间换时间”,我们会不会考虑它会造成我们资源的浪费?

Spark里面分了几大块,第一块叫Spark SQL,可以部分取代Hadoop hive;第二个是机器学习MLLib,可以取代mahout;第三个是图计算GraphX,可以取代Pregel;第四块是流式计算spark streaming,可以取代storm。每一块解决不同的问题,不同的模块可以有不同的集群,它可以独立扩容。

Spark对资源是有一定的浪费,但浪费也是相对的,要看你使用的频率高不高。如果这个集群很繁忙,经常不断地有人提交工作,RDD重用率很高,那就不是浪费。这就好比建了个大房子,如果一年只住一次,那其实很浪费。如果这个房子住了很多人,而且天天住,那就不浪费。

您觉得在整个行业来看,目前spark发展的是什么样?我们在这块儿有什么优势呢?

我个人的感觉,spark现在已经是逐步走向生产环节,开始真正投入使用了,但是大规模的使用还是不太多。横向比较的话,我们携程应该是走在前面的,我们是真正在用了,很多公司还在尝试使用阶段,有的在测试阶段,还没有真正地在生产环境大规模使用。大家可能认为这个技术还不是非常成熟,从商业角度来讲投入到项目中还是有一定的风险。任何新技术都会有风险,这个是很正常的。但只要在驾驭范围之内,风险还是可以控制的。

整体来看,大家对这个东西比较期待,发展势头很猛,但目前还是比较谨慎。

现在的数据规模增长的这么厉害,数量大,种类多,我们怎么对它进行具体地分析挖掘,来为业务创造价值的?

现在是移动互联网时代,移动互联网时代一个突出的问题是有很多用户数据。PC不便携带和移动,传统手机操作不方便、应用少,智能手机通过APP和触摸屏彻底解决了交互性和易用性问题,从而导致产生更多的用户行为数据。数据增长速度会远远超过业务增长速度,比如携程2014年的大数据增长了6倍,但是业务并没有增长6倍,两者并非1:1关系。

数据大量增加有两个原因:

1)用户的行为确实变多了,因为应用越来越多,操作也越来越便捷。

2)大家尝到了大数据的甜头了,然后就会到处埋点,到处收集数据。这样一来,原来认为没用的数据,现在就变成有用的数据,自然而然数据就多了。

数据规模肯定是爆炸式增长,所有行业趋势都是这样。如果某一天我们换一种角度来思考当下发生的问题,原来可能觉得没有价值的数据,可能一下子变得很有价值。前提是有历史数据,否则无法进行分析。

现在很多公司提倡量化管理,或者说数字化管理。量化管理的前提是要有数据,所有的行为和现象都要数字化。所有的决策必须基于事实,数据就是事实,因为数据是不会说假话(尽管存在数据噪音和数据质量问题,但这些可以通过技术手段处理掉)。也许有些数据不一定有用,但是它不会说假话。这样一来就产生了各种各样的数据,全部收集起来,量就非常大。像我们携程每天量化指标数据四百多亿个条,如果放在传统的数据库,而且要实时读写/查询,传统的技术很难实现。我们是通过HBase来处理,可以做到实时读写海量metrics。很多东西在过去认为不可能的,现在变成可能,或者已经做到了,所以大数据整个发展前景还是不错的。

现在在大数据里面有没有其他的技术是您现在还想比较多关注的,还正在研究的,有这样的技术吗?如何做技术选择?

除了HDFS/HBase/mapreduce/hive/spark/storm之外,我们还关注presto。Presto是facebook新发布的产品,与spark sql类似,主要解决hive查询慢的问题。

对下一代大数据处理技术,比如Caffeine、Pregel、Dremel,我们也在关注和跟进相关产品或项目。

我的个人观点是,做技术选择的时候,选择A而不选择B的原因,并不是说A就一定比B好,而是因为它是一个系统,是一个完整的东西。如果形成了一个生态圈的话,那么它有很多东西在内部可以消化掉,不用一会儿跟这个系统做接口,一会儿跟那个系统做接口,数据都在同一个系统内部流动。如果是自成一体,有时一个问题解决了,可能导致三个问题一起解决。如果是三个独立系统,同一个问题可能需要在三个系统分别去解决,效率会低不少。

对于分布式系统而言,扩展性和伸缩性一般都不是问题,all in one系统运营成本更低。比如spark可以同时解决多个问题,无需部署多套不同系统,而storm只解决流式计算问题,因此我个人更偏向spark。

摘自:51CTO

原文发布于微信公众号 - PPV课数据科学社区(ppvke123)

原文发表时间:2014-12-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏华章科技

拨开数据迷雾:如何理清大数据脉络?

之所以有这么一个话题,确实是有原因的。就在前几天,我又收到了一个同行的邮件,是向我咨询关于大数据方向的问题,他们想涉足大数据这个领域,或者说已经涉足大数据这个领...

361
来自专栏云计算D1net

多云管理的7个秘诀

3053
来自专栏DevOps时代的专栏

技术译文 | DevOps“五宗罪”,这样向DevOps过渡注定会失败

913
来自专栏数据科学与人工智能

【陆勤阅读】探索机器学习中的数据科学

原文作者:原微软技术与研究部门合伙人数据科学架构师Mario Garzia 译者:杜红光 数据科学与“大数据”已经成为21世纪高科技产业的流行语。而“大数据”这...

21010
来自专栏SDNLAB

企业网络战略之边缘计算:细数它的5大优势

对于希望超越传统基于云的计算架构的限制的公司而言,边缘计算已迅速成为热门。虽然企业级数据中心依旧在现代网络中发挥重要作用,但物联网设备提供的能够在更接近源的地方...

1062
来自专栏互联网数据官iCDO

Facebook广告投放无从下手?这篇入门级干货你得读一读!

引言:在创建Facebook广告之前,你需要理解并选择你的营销目标。以下是一些可以帮助你评估和选出最合适你的广告系列目标的建议,对于刚开始着手Facebook广...

974
来自专栏EAWorld

DevOps是MindSet:工具也好,文化也罢,人员才是关键

任何变革都需要时间,DevOps亦然。在经过数年的蛰伏期之后,DevOps终于成为了业界聚焦点;不过,从知其然到知其所以然,再到最终完美实现DevOps,依然前...

33413
来自专栏腾讯大讲堂的专栏

产品经理探索之路:如何理清思路确定方向?

导语 在设计和运营产品的过程中,产品经理们或多或少会遇到这样的问题:产品方向不明确,对未来也毫无头绪,不知道要如何走。针对这个问题,我们简单谈谈如何破局,更快的...

20510
来自专栏腾讯大讲堂的专栏

从0到1,浅谈需求的模型转化

作者:张一弛,华中师大硕士毕业。曾就职于阿里巴巴移动事业群,负责UC浏览器海外版产品工作。2014年加入腾讯,先后在QQ群、QQ HD、PC QQ等产品线从事产...

3055
来自专栏张俊红

一起来学习用户活跃的方法

本篇内容来源于图书《增长黑客》与文章《用户活跃计划分析》的学习整理。整篇内容在学习前辈的基础上进行改编,对前辈的一些理论选择性地写出来,并根据理论,配了自己平常...

3305

扫码关注云+社区

领取腾讯云代金券