————————————————————前端
互联网二次革命的移动互联网时代,如何吸引用户、留住用户并深刻挖掘用户价值,在激烈的竞争中脱颖而出,是各大电商的重要课题。经过各种大数据对用户进行研究,以数据驱动产品是解决这个课题的主要手段,携程的大数据团队也由此应运而生;通过几年的努力,大数据的相关技术为业务带来了惊人的提高与帮助。算法
以基础大数据的用户意图服务为例,经过将广告和栏位的“千人一面”变为“千人千面”(大数据进行用户分析从而进行针对用户的推荐),在提高用户便捷性,可用性,下降费力度的同时,其转化率也获得了数倍的提高,体现了大数据服务的真正价值。sql
在新形势下,传统应用架构不得不变为大数据及新的高并发架构,来应对业务需求激增及高速迭代的须要。数据库
1、业务高速发展带来的应用架构挑战后端
公司业务高速发展带来哪些主要的变化,以及给咱们的系统带来了哪些挑战?缓存
1)业务需求的急速增加,访问请求的并发量激增,2016年1月份以来,业务部门的服务日均请求量激增了5.5倍。安全
2)业务逻辑日益复杂化,基础业务研发部须要支撑起OTA数十个业务线,业务逻辑日趋复杂和繁多。数据结构
3)业务数据源多样化,异构化,接入的业务线、合做公司的数据源愈来愈多;接入的数据结构由之前的数据库结构化数据整合转为Hive表、评论文本数据、日志数据、天气数据、网页数据等多元化异构数据整合。架构
4)业务的高速发展和迭代,部门一直以追求以最少的开发人力,以架构和系统的技术优化,支撑起携程各业务线高速发展和迭代的须要。并发
在这种新形势下,传统应用架构不得不变,作为工程师也必然要自我涅槃,改成大数据及新的高并发架构,来应对业务需求激增及高速迭代的须要。计算分层分解、去SQL、去数据库化、模块化拆解的相关技改工做已经刻不容缓。
以用户意图(AI 点金杖)的个性化服务为例, 面对BU业务线的全面支持的迫切须要,其应用架构必须解决以下技术难点:
1)高访问并发:天天近亿次的访问请求;
2)数据量大:天天TB级的增量数据,近百亿条的用户数据,上百万的产品数据;
3)业务逻辑复杂:复杂个性化算法和LBS算法;例如:知足一个复杂用户请求须要大量计算和30次左右的SQL数据查询,服务延时愈来愈长;
4)高速迭代上线:面对OTA多业务线的个性化、Cross-saling、Up-saling、需知足提高转化率的迫切需求,迭代栏位或场景要快速,同时减小研发成本。
2、应对挑战的架构涅磐
面对这些挑战,咱们的应用系统架构应该如何涅磐?主要分以下三大方面系统详解:
存储的涅磐,这一点对于整个系统的吞吐量和并发量的提高起到最关键的做用,须要结合数据存储模型和具体应用的场景。
计算的涅磐,能够从横向和纵向考虑:横向主要是增长并发度,首先想到的是分布式。纵向拆分就是要求咱们找到计算的结合点从而进行分层,针对不一样的层次选择不一样的计算地点。而后再将各层次计算完后的结果相结合,尽量最大化系统总体的处理能力。
业务层架构的涅磐,要求系统的良好的模块化设计,清楚的定义模块的边界,模块自升级和可配置化。
3、应用系统的总体架构
认识到须要应对的挑战,咱们应该如何设计咱们的系统呢,下面将全面的介绍下咱们的应用系统总体架构。
下图就是咱们应用系统总体架构以及系统层次的模块构成。
数据源部分, 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 和Spark MLLib是基于Spark平台的SQL查询引擎和数据挖掘相关算法框架。咱们主要用Mahout和Spark MLLib 进行数据挖掘工做。
调度系统zeus,是淘宝开源大数据平台调度系统,于2015年引进到携程,以后咱们进行了重构和功能升级,作为携程大数据平台的做业调度平台。
近线部分,是基于Muise来实现咱们的近实时的计算场景,Muise是也是携程OPS提供的实时计算流处理平台,内部是基于Storm实现与HERMES消息队列搭配起来使用。例如,咱们使用MUSIE经过消费来自消息队列里的用户实时行为,订单记录,结合画像等一块儿基础数据,经一系列复杂的规则和算法,实时的识别出用户的行程意图。
后台/线上应用部分,Mysql用于支撑后台系统的数据库。ElasticSearch 是基于Lucene实现的分布式搜索引擎,用于索引用户画像的数据,支持离线精准营销的用户筛选,同时支持线上应用推荐系统的选品功能 。Hbase 基于Hadoop的Hdfs 上的列存储Nosql数据库,用于后台报表可视化系统和线上服务的数据存储。
这里说明一下, 在线和后台应用使用的ElasticSearch和Hbase集群是分开的,互不影响。 Redis 支持在线服务的高速缓存,用于缓存统计分析出来的热点数据。
四,推荐系统案例
介绍完咱们应用系统的总体构成, 接下来分享基于这套系统架构实现的一个实例——携程个性化推荐系统。
推荐系统的架构图:
一、存储的涅磐
1)Nosql (Hbase+Redis)
咱们以前存储使用的是Mysql, 通常关系型数据库会作为应用系统存储的首选。你们知道Mysql非商业版对分布式支持不够,在存储数据量不高,查询量和计算复杂度不是很大的状况下,能够知足应用系统绝大部分的功能需求。
咱们现状是须要安全存储海量的数据,高吞吐,并发能力强,同时随着数据量和请求量的快速增长,可以经过加节点来扩容。另外还须要支持故障转移,自动恢复,无需额外的运维成本。综上几个主要因素,咱们进行了大量的调研和测试,最终咱们选用Hbase和Redis 两个Nosql数据库来取代以往使用的Mysql,。咱们把用户意图以及推荐产品数据以KV的形式存储在Hbase中,我对操做Hbase进行一些优化,其中包括rowkey的设计,预分配,数据压缩等, 同时针对咱们的使用场景对Hbase自己配置方面的也进行了调优。目前存储的数据量已经达到TB级别,支持天天千万次请求,同时保证99%在50毫秒内返回 。
Redis这块和多数应用系统使用方式同样,主要用于缓存热点数据,这里就很少说了。
2)搜索引擎 (ElasticSearch)
ES索引各业务线产品特征数据,提供基于用户的意图特征和产品特征复杂的多维检索和排序功能,当前集群由4台大内存物理机器构成,采用全内存索引。对比某一个复杂的查询场景, 以前用Mysql将近须要30次查询,使用ES只须要一次组合查询且在100毫秒内返回 。目前天天千万次搜索,99%以上在300毫秒之内返回。
二、计算的涅磐
1)数据源,咱们的数据源分结构化和半结构化数据以及非结构化数据。
结构化数据主要是指携程各产线的产品维表和订单数据,有酒店,景酒,团队游,门票,景点等;还有一些基础数据,好比城市表,车站等,这类数据基本上都是T+1。天天会有流程去各BU的生产表拉取数据。
半结构化数据是指,携程用户的访问行为数据,例如浏览,搜索,预订,反馈等,这边顺便提一下,这些数据这些是由前端采集框架实时采集,而后下发到后端的收集服务,由收集服务在写入到Hermes消息队列,一路会落地到Hadoop上面作长期存储,另外一路近线层能够经过订阅Hermes此类数据Topic 进行近实时的计算工做。
咱们还用到外部合做渠道的数据,还有一些评论数据,评论属于非结构化的,也是T+1更新。
2)离线计算,主要分三个处理阶段 。
预处理阶段,这块主要为后续数据挖掘作一些数据的准备工做,数据去重,过滤,对缺失信息的补足。举例来讲采集下来的用户行为数据,所含有的产品信息不多,咱们会使用产品表的数据进行一些补足,确保给后续的数据挖掘使用时候尽可能完整的。
数据挖掘阶段,主要运用一些经常使用的数据挖掘算法进行模型训练和·推荐数据的输出(分类,聚类,回归 ,CF等)。
结果导入阶段,咱们经过可配置的数据导入工具将推荐数据,进行一系列转换后,导入到HBASE,Redis以及创建ES索引, Redis存储的是经统计计算出的热点数据 。
3)近线计算(用户意图, 产品缓存)
当用户没有明确的目的性状况下,很难找到知足兴趣的产品,咱们不只须要了解用户的历史兴趣,用户实时行为特征的抽取和理解更加剧要,以便快速的推荐出符合用户当前兴趣的产品,这就是用户意图服务须要实现的功能。
通常来讲用户特征分红两大类:一种是稳定的特征(用户画像),如用户性别,常住地,主题偏好等特征;另外一类是根据用户行为计算获取的特征,如用户对酒店星级的偏好,目的地偏好,跟团游/自由行偏好等。基于前面所述的计算的特色,咱们使用近在线计算来获取第二类用户特征,总体框图以下。从图中能够看出它的输入数据源包括两大类:第一类是实时的用户行为,第二类是用户画像,历史交易以及情景等离线模块提供的数据。结合这两类数据,经一些列复杂的近线学习算法和规则引擎,计算得出用户当前实时意图列表存储到Hbase和Redis中。
携程用户意图框架
近线另外一个工做是产品数据缓存,携程的业务线不少,而咱们的推荐系统会推各个业务线的产品,所以咱们须要调用全部业务线的产品服务接口,但随着咱们上线的场景的增长,这样无形的增长了对业务方接口的调用压力。并且业务线产品接口服务主要应用于业务的主流程或关键型应用,比较重,且SLA服务等级层次不齐,可能会影响到整个推荐系统的响应时间。
为了解决这两个问题,咱们设计了近在线计算来进行业务的产品信息异步缓存策略,具体的流程以下。
咱们会将待推荐的产品Id所有经过Kafka异步下发,在Storm中咱们会对各业务方的产品首先进行聚合,达到批处理个数或者时间gap时,再调用各业务方的接口,这样减小对业务方接口的压力。经过调用业务方接口更新的产品状态临时缓存起来(根据各业务产品信息更新周期分别设置缓存失效时间),在线计算的时候直接先读取临时缓存数据,缓存不存在的状况下,再击穿到业务的接口服务。
产品异步缓存框架
4)在线计算(2个关键业务层架构模块介绍)
一、业务层架构-数据治理和访问模块,支持的存储介质,目前支持的存储介质有Localcache,Redis,Hbase,Mysql 能够支持横向扩展 。统一配置,对同一份数据,采用统一配置,能够随意存储在任意介质,根据id查询返回统一格式的数据,对查询接口彻底透明。
穿透策略和容灾策略,Redis只存储了热数据,当须要查询冷数据则能够自动到下一级存储如Hbase查询,避免缓存资源浪费。当Redis出现故障时或请求数异常上涨,超过总体承受能力,此时服务降级自动生效,并可配置化。
二、业务层架构-推荐策略模块,整个流程是先将用户意图、用户浏览,相关推荐策略生成的产品集合等作为数据输入,接着按照场景规则,业务逻辑从新过滤,聚合、排序。最后验证和拼装业务线产品信息后输出推荐结果;
咱们对此流程每一步进行了一些模块化的抽象,将重排序逻辑按步骤抽象解耦,抽象如右图所示的多个组件,开发新接口时仅须要将内部DSL拼装即可以获得知足业务需求的推荐服务;提升了代码的复用率和可读性,减小了超过50%的开发时间;对于充分验证的模块的复用,有效保证了服务的质量。