大数据”作为当下最火热的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。
原文发布时间为：2014-12-24