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

“大数据”做为当下最火热的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。
- 原文地址：http://www.bi168.cn/>>http://www.bi168.cn/thread-4792-1-1.html