点击蓝色摘客，获得更多IT资讯
文章来源
InfoQ
互联网二次革命的移动互联网时代，如何吸引用户、留住用户并深入挖掘用户价值，在激烈的竞争中脱颖而出，是各大电商的重要课题。通过各类大数据对用户进行研究，以数据驱动产品是解决这个课题的主要手段，携程的大数据团队也由此应运而生；经过几年的努力，大数据的相关技术为业务带来了惊人的提升与帮助。
以基础大数据的用户意图服务为例，通过将广告和栏位的“千人一面”变为“千人千面”，在提升用户便捷性，可用性，降低费力度的同时，其转化率也得到了数倍的提升，体现了大数据服务的真正价值。
在新形势下，传统应用架构不得不变为大数据及新的高并发架构，来应对业务需求激增及高速迭代的需要。
一，业务高速发展带来的应用架构挑战公司业务高速发展带来哪些主要的变化，以及给我们的系统带来了哪些挑战？
业务需求的急速增长，访问请求的并发量激增，年1月份以来，业务部门的服务日均请求量激增了5.5倍。
业务逻辑日益复杂化，基础业务研发部需要支撑起OTA数十个业务线，业务逻辑日趋复杂和繁多。
业务数据源多样化，异构化，接入的业务线、合作公司的数据源越来越多；接入的数据结构由以前的数据库结构化数据整合转为Hive表、评论文本数据、日志数据、天气数据、网页数据等多元化异构数据整合。
业务的高速发展和迭代，部门一直以追求以最少的开发人力，以架构和系统的技术优化，支撑起携程各业务线高速发展和迭代的需要。
在这种新形势下，传统应用架构不得不变，做为工程师也必然要自我涅槃，改为大数据及新的高并发架构，来应对业务需求激增及高速迭代的需要。计算分层分解、去SQL、去数据库化、模块化拆解的相关技改工作已经刻不容缓。
以用户意图（AI点金杖）的个性化服务为例，面对BU业务线的全面支持的迫切需要，其应用架构必须解决如下技术难点：
高访问并发：每天近亿次的访问请求；
数据量大：每天TB级的增量数据，近百亿条的用户数据，上百万的产品数据；
业务逻辑复杂：复杂个性化算法和LBS算法；例如：满足一个复杂用户请求需要大量计算和0次左右的SQL数据查询，服务延时越来越长；
高速迭代上线：面对OTA多业务线的个性化、Cross-saling、Up-saling、需满足提升转化率的迫切需求，迭代栏位或场景要快速，同时减少研发成本。
二，应对挑战的架构涅磐面对这些挑战，我们的应用系统架构应该如何涅磐？主要分如下三大方面系统详解:
存储的涅磐，这一点对于整个系统的吞吐量和并发量的提升起到最关键的作用，需要结合数据存储模型和具体应用的场景。
计算的涅磐，可以从横向和纵向考虑：横向主要是增加并发度，首先想到的是分布式。纵向拆分就是要求我们找到计算的结合点从而进行分层，针对不同的层次选择不同的计算地点。然后再将各层次计算完后的结果相结合，尽可能最大化系统整体的处理能力。
业务层架构的涅磐，要求系统的良好的模块化设计，清楚的定义模块的边界，模块自升级和可配置化。
三，应用系统的整体架构认识到需要应对的挑战，我们应该如何设计我们的系统呢，下面将全面的介绍下我们的应用系统整体架构。
下图就是我们应用系统整体架构以及系统层次的模块构成。
数据源部分，Hermes是携程框架部门提供的消息队列，基于Kafka和Mysql做为底层实现的封装，应用于系统间实时数据传输交互通道。Hive和HDFS是携程海量数据的主要存储，两者来自Hadoop生态体系。Hadoop这块大家已经很熟悉，如果不熟悉的同学只要知道Hadoop主要用于大数据量存储和并行计算批处理工作。
Hive是基于Hadoop平台的数据仓库，沿用了关系型数据库的很多概念。比如说数据库和表，还有一套近似于SQL的查询接口的支持，在Hive里叫做HQL，但是其底层的实现细节和关系型数据库完全不一样，Hive底层所有的计算都是基于MR来完成，我们的数据工程师90%都数据处理工作都基于它来完成。
离线部分，包含的模块有MR,Hive,Mahout,SparkQL/MLLib。Hive上面已经介绍过，Mahout简单理解提供基于Hadoop平台进行数据挖掘的一些机器学习的算法包。Spark类似hadoop也是提供大数据并行批量处理平台，但是它是基于内存的。SparkQL和SparkMLLib是基于Spark平台的SQL查询引擎和数据挖掘相关算法框架。我们主要用Mahout和SparkMLLib进行数据挖掘工作。
调度系统zeus，是淘宝开源大数据平台调度系统，于年引进到携程，之后我们进行了重构和功能升级，做为携程大数据平台的作业调度平台。
近线部分，是基于Muise来实现我们的近实时的计算场景，Muise是也是携程OPS提供的实时计算流处理平台，内部是基于Storm实现与HERMES消息队列搭配起来使用。例如，我们使用MUSIE通过消费来自消息队列里的用户实时行为，订单记录，结合画像等一起基础数据，经一系列复杂的规则和算法，实时的识别出用户的行程意图。
后台/线上应用部分，Mysql用于支撑后台系统的数据库。ElasticSearch是基于Lucene实现的分布式搜索引擎，用于索引用户画像的数据，支持离线精准营销的用户筛选，同时支持线上应用推荐系统的选品功能。Hbase基于Hadoop的Hdfs上的列存储Nosql数据库，用于后台报表可视化系统和线上服务的数据存储。
这里说明一下,在线和后台应用使用的ElasticSearch和Hbase集群是分开的，互不影响。Redis支持在线服务的高速缓存，用于缓存统计分析出来的热点数据。
四，推荐系统案例介绍完我们应用系统的整体构成，接下来分享基于这套系统架构实现的一个实例——携程个性化推荐系统。
推荐系统的架构图：
1存储的涅磐1）Nosql(Hbase+Redis)
我们之前存储使用的是Mysql,一般关系型数据库会做为应用系统存储的首选。
大家知道Mysql非商业版对分布式支持不够，在存储数据量不高，查询量和计算复杂度不是很大的情况下，可以满足应用系统绝大部分的功能需求。
我们现状是需要安全存储海量的数据，高吞吐，并发能力强，同时随着数据量和请求量的快速增加，能够通过加节点来扩容。另外还需要支持故障转移，自动恢复，无需额外的运维成本。综上几个主要因素，我们进行了大量的调研和测试，最终我们选用Hbase和Redis两个Nosql数据库来取代以往使用的Mysql,。我们把用户意图以及推荐产品数据以KV的形式存储在Hbase中，我对操作Hbase进行一些优化，其中包括rowkey的设计，预分配，数据压缩等，同时针对我们的使用场景对Hbase本身配置方面的也进行了调优。目前存储的数据量已经达到TB级别，支持每天千万次请求，同时保证99%在50毫秒内返回。
Redis这块和多数应用系统使用方式一样，主要用于缓存热点数据，这里就不多说了。
）搜索引擎(ElasticSearch)
ES索引各业务线产品特征数据，提供基于用户的意图特征和产品特征复杂的多维检索和排序功能，当前集群由4台大内存物理机器构成，采用全内存索引。对比某一个复杂的查询场景，之前用Mysql将近需要0次查询，使用ES只需要一次组合查询且在毫秒内返回。目前每天千万次搜索，99%以上在00毫秒以内返回。