携程大数据实践:高并发应用架构及推荐系统案例

  • 时间:
  • 浏览:2
  • 来源:万人红黑大战棋牌_万人红黑大战棋牌官网

1)数据源,我们我们 的数据源分型态化和半型态化数据以及非型态化数据。

1)NoSQL (HBase+Redis)

在你而且 新形势下,传统应用架构不得不变,做为工程师也必然要自我涅槃,改为大数据及新的高并发架构,来应对业务需求激增及高速迭代的须要。计算分层分解、去SQL、去数据库化、模块化拆解的相关技改工作由于刻不容缓。

近线每种,是基于Muise来实现我们我们 的近实时的计算场景,Muise是也是携程OPS提供的实时计算流处里平台,内部管理是基于Storm实现与HERMES消息队列搭配起来使用。相似,我们我们 使用MUSIE通过消费来自消息队列里的用户实时行为,订单记录,结合画像等同时基础数据,经一系列僵化 的规则和算法,实时的识别出用户的行程意图。

公司业务高速发展带来哪些地方主要的变化,以及给我们我们 的系统带来了哪些地方挑战?

一般来说用户型态分成两大类:而且 是稳定的型态(用户画像),如用户性别、常住地、主题偏好等型态;另一类是根据用户行为计算获取的型态,如用户对酒店星级的偏好、目的地偏好、跟团游/自由行偏好等。基于前面所述的计算的特点,我们我们 使用近在线计算来获取第二类用户型态,整体框图如下。从图中可否 看出它的输入数据源包括两大类:第一类是实时的用户行为;第二类是用户画像,历史交易以及情景等离线模块提供的数据。结合这两类数据,经而且 列僵化 的近线学习算法和规则引擎,计算得出用户当前实时意图列表存储到HBase和Redis中。

1、存储的涅磐

四、推荐系统案例

产品异步缓存框架

当用户这麼明确的目的性情形下,先要找到满足兴趣的产品,我们我们 不仅须要了解用户的历史兴趣,用户实时行为型态的抽取和理解更加重要,以便快速的推荐出符合用户当前兴趣的产品,这也后要户意图服务须要实现的功能。

2.数据量大:每天TB级的增量数据,近百亿条的用户数据,上百万的产品数据;

介绍完我们我们 应用系统的整体构成,接下来分享基于这套系统架构实现的有有另另一个实例——携程个性化推荐系统。

携程用户意图框架

预处里阶段,这块主要为后续数据挖掘做而且 数据的准备工作,数据去重,过滤,对缺失信息的补足。举例来说挂接下来的用户行为数据,所暗含的产品信息很少,我们我们 会使用产品表的数据进行而且 补足,确保给后续的数据挖掘使用可是我尽量详细的。

二、应对挑战的架构涅磐

本文来自携程技术中心基础业务研发部的《应用架构涅槃》系列分享。据基础业务研发部负责人李小林介绍,互联网二次革命的移动互联网时代,如保吸引用户、留住用户并深入挖掘用户价值,在激烈的竞争中脱颖而出,是各大电商的重要课题。通过各类大数据对用户进行研究,以数据驱动产品是处里你而且 课题的主要手段,携程的大数据团队也由此应运而生;经过几年的努力,大数据的相关技术为业务带来了惊人的提升与帮助。以基础大数据的用户意图服务为例,通过将广告和栏位的“千人一面”变为“千人千面”,在提升用户便捷性,可用性,降低费力度的同时,其转化率也得到了数倍的提升,体现了大数据服务的真正价值。

我们我们 可是我存储使用的是MySQL,一般关系型数据库会做为应用系统存储的首选。我们我们 知道MySQL非商业版对分布式支持不足英文,在存储数据量不高,查询量和计算僵化 度后要 很大的情形下,可否 满足应用系统绝大每种的功能需求。

结果导入阶段,我们我们 通过可配置的数据导入工具将推荐数据,进行一系列转换后,导入到HBase、Redis以及建立ES索引,Redis存储的是经统计计算出的热点数据。

①业务层架构-数据治理和访问模块,支持的存储介质,目前支持的存储介质有Localcache、Redis、HBase、MySQL可否 支持横向扩展。统一配置,对同一份数据,采用统一配置,可否 随意存储在任意介质,根据id查询返回统一格式的数据,对查询接口详细透明。

2)离线计算,主要分有有另另一个处里阶段。

这里说明一下, 在线和后台应用使用的ElasticSearch和HBase集群是分开的,互不影响。Redis支持在线服务的高速缓存,用于缓存统计分凝固来的热点数据。

4.业务的高速发展和迭代,部门总是以追求以大慨的开发人力,以架构和系统的技术优化,支撑起携程各业务线高速发展和迭代的须要。

?存储的涅磐,你而且 点对于整个系统的吞吐量和并发量的提升起到最关键的作用,须要结合数据存储模型和具体应用的场景。

半型态化数据是指,携程用户的访问行为数据,相似浏览、搜索、预订、反馈等,这边顺便提一下,哪些地方地方数据哪些地方地方是由前端挂接框架实时挂接,而且 挂接到后端的挂接服务,由挂接服务在写入到Hermes消息队列,一路会落地到Hadoop底下做长期存储,另一路近线层可否 通过订阅Hermes此类数据Topic进行近实时的计算工作。

2、计算的涅磐

4.高速迭代上线:面对OTA多业务线的个性化、Cross-saling、Up-saling、需满足提升转化率的迫切需求,迭代栏位或场景要快速,同时减少研发成本。

4)在线计算(有有另另一个关键业务层架构模块介绍)

面对哪些地方地方挑战,我们我们 的应用系统架构应该如保涅磐?主要分如下三大方面系统详解:

数据源每种,Hermes是携程框架部门提供的消息队列,基于Kafka和MySQL做为底层实现的封装,应用于系统间实时数据传输交互通道。Hive和HDFS是携程海量数据的主要存储,两者来自Hadoop生态体系。Hadoop我们我们 由于没熟悉,由于没熟悉的同学若果知道Hadoop主要用于大数据量存储和并行计算批处里工作。

在李小林看来,大数据是互联网行业发展的趋势,互联网的从业人员须要深度图关注大数据相关的技术及应用,也希望通过你而且 系列大数据相关的讲座,让各位同学有所收获。

我们我们 现状是须要安全存储海量的数据,高吞吐,并发能力强,同时随着数据量和请求量的快速增加,可否 通过加节点来扩容。另外还须要支持故障转移,自动恢复,后要额外的运维成本。综上十几个 主要因素,我们我们 进行了血块的调研和测试,最终我们我们 选者HBase和Redis有有另另一个NoSQL数据库来取代以往使用的MySQL。我们我们 把用户意图以及推荐产品数据以KV的形式存储在HBase中,我对操作HBase进行而且 优化,其中包括rowkey的设计,预分配,数据压缩等,同时针对我们我们 的使用场景对HBase而且 配置方面的也进行了调优。目前存储的数据量由于达到TB级别,支持每天千万次请求,同时保证99%在400毫秒内返回。

下图可是我我们我们 应用系统整体架构以及系统层次的模块构成。

1.高访问并发:每天近亿次的访问请求;

首场《应用架构涅磐》分享来自基础业务研发部的董锐,包括业务高速发展带来的应用架构挑战、应对挑战的架构涅磐、应用系统整体架构和推荐系统案例等四个每种。

Hive是基于Hadoop平台的数据仓库,沿用了关系型数据库的全都概念。比如说数据库和表,还有一套近似于SQL的查询接口的支持,在Hive里叫做HQL,而且 其底层的实现细节和关系型数据库详细不一样,Hive底层所有的计算后要 基于MR来完成,我们我们 的数据工程师90%都数据处里工作都基于它来完成。

?计算的涅磐,可否 从横向和纵向考虑:横向主可是我增加并发度,首先想到的是分布式。纵向拆分也后要求我们我们 找到计算的结合点从而进行分层,针对不同的层次选者不同的计算地点。而且 再将各层次计算可是我的结果相结合,尽由于最大化系统整体的处可否力。

2)搜索引擎 (ElasticSearch)

调度系统zeus,是淘宝开源大数据平台调度系统,于2015年引进到携程,可是我我们我们 进行了重构和功能升级,做为携程大数据平台的作业调度平台。

为了处里这有有另另一个问题,我们我们 设计了近在线计算来进行业务的产品信息异步缓存策略,具体的流程如下。

我们我们 对此流程每一步进行了而且 模块化的抽象,将重排序逻辑按步骤抽象解耦,抽象如右图所示的多个组件,开发新接口时仅须要将内部管理DSL拼装便可否 得到满足业务需求的推荐服务;提高了代码的复用率和可读性,减少了超过400%的开发时间;对于充分验证的模块的复用,有效保证了服务的质量。

3.业务数据源僵化 ,异构化,接入的业务线、合作者者公司的数据源太少;接入的数据型态由可是我的数据库型态化数据整合转为Hive表、评论文本数据、日志数据、天气数据、网页数据等多元化异构数据整合。

推荐系统的架构图:

后台/线上应用每种,MySQL用于支撑后台系统的数据库。ElasticSearch是基于Lucene实现的分布式搜索引擎,用于索引用户画像的数据,支持离线精准营销的用户筛选,同时支持线上应用推荐系统的选品功能。HBase 基于Hadoop的HDFS 上的列存储NoSQL数据库,用于后台报表可视化系统和线上服务的数据存储。

?业务层架构的涅磐,要求系统的良好的模块化设计,清楚的定义模块的边界,模块自升级和可配置化。

我们我们 会将待推荐的产品Id详细通过Kafka异步挂接,在Storm中我们我们 会对各业务方的产品首先进行聚合,达到批处里个数由于时间gap时,再调用各业务方的接口,可是我减少对业务方接口的压力。通过调用业务方接口更新的产品情形临时缓存起来(根据各业务产品信息更新周期分别设置缓存失效时间),在线计算的可是我直接先读取临时缓存数据,缓存不居于的情形下,再击穿到业务的接口服务。

离线每种,暗含的模块有MR、Hive、Mahout、SparkQL/MLLib。Hive底下由于介绍过,Mahout简单理解提供基于Hadoop平台进行数据挖掘的而且 机器学习的算法包。Spark相似hadoop也是提供大数据并行批量处里平台,而且 它是基于内存的。SparkQL 和Spark MLLib是基于Spark平台的SQL查询引擎和数据挖掘相关算法框架。我们我们 主要用Mahout和Spark MLLib进行数据挖掘工作。

近线可是我工作是产品数据缓存,携程的业务线全都,而我们我们 的推荐系统会推各个业务线的产品,而且 我们我们 须要调用所有业务线的产品服务接口,但随着我们我们 上线的场景的增加,可是我无形的增加了对业务方接口的调用压力。而且 业务线产品接口服务主要应用于业务的主流程或关键型应用,比较重,且SLA服务等级层次不齐,由于会影响到整个推荐系统的响应时间。

穿透策略和容灾策略,Redis只存储了热数据,当须要查询冷数据则可否 自动到下一级存储如HBase查询,处里缓存资源浪费。当Redis出显故障时或请求数异常上涨,超过整体承受能力,此时服务降级自动生效,并可配置化。

认识到须要应对的挑战,我们我们 应该如保设计我们我们 的系统呢,下面将全面的介绍下我们我们 的应用系统整体架构。

三、应用系统的整体架构

数据挖掘阶段,主要运用而且 常用的数据挖掘算法进行模型训练和推荐数据的输出(分类、聚类、回归、CF等)。

3.业务逻辑僵化 :僵化 个性化算法和LBS算法;相似:满足有有另另一个僵化 用户请求须要血块计算和400次左右的SQL数据查询,服务延时这麼长;

1.业务需求的烈焰增长,访问请求的并发量激增,2016年1月份以来,业务部门的服务日均请求量激增了5.5倍。

以用户意图(AI 点金杖)的个性化服务为例, 面对BU业务线的全面支持的迫切须要,其应用架构须要处里如下技术难点:

Redis和多数应用系统使用最好的法律办法一样,主要用于缓存热点数据,这里就太少说了。

ES索引各业务线产品型态数据,提供基于用户的意图型态和产品型态僵化 的多维检索和排序功能,当前集群由4台大内存物理机器构成,采用全内存索引。对比某有有另另一个僵化 的查询场景,也后要MySQL将近须要400次查询,使用ES只须要一次组合查询且在400毫秒内返回。目前每天千万次搜索,99%以上在400毫秒以内返回。

我们我们 还用到内部管理合作者者渠道的数据,还有而且 评论数据,评论属于非型态化的,也是T+1更新。

一、业务高速发展带来的应用架构挑战

②业务层架构-推荐策略模块,整个流程是先将用户意图、用户浏览,相关推荐策略生成的产品集合等做为数据输入,接着按照场景规则,业务逻辑重新过滤,聚合、排序。最后验证和拼装业务线产品信息后输出推荐结果;

2.业务逻辑日益僵化 化,基础业务研发部须要支撑起OTA数四个业务线,业务逻辑日趋僵化 和繁多。

型态化数据主可是我指携程各产线的产品维表和订单数据,有酒店、景酒、团队游、门票、景点等,还有而且 基础数据,比如城市表、车站等,相似数据基本上后要 T+1,每天会有流程去各BU的生产表拉取数据。

3)近线计算(用户意图、产品缓存)