写点什么

飞猪旅行推荐算法应用实践

2021 年 1 月 06 日

飞猪旅行推荐算法应用实践

本文是葬青在 InfoQ 公开课上的演讲全文,有删减。


每天,海量用户通过飞猪平台浏览和挑选旅行产品,如何在分秒间帮助用户发现、定位、挖掘出心仪的产品,并匹配出最佳的商品组合?这正是飞猪导购算法团队的研究方向。飞猪通过建立个性化导购体系,包括引入用户画像、行程语义表达以及全链路行为排序等,实现对用户需求的预测和匹配,将可能被购买的产品呈现在用户面前。


本文中 ,阿里巴巴飞猪旅行的高级算法专家葬青将从旅行行业的典型场景切入,提炼出飞猪在用户理解领域的普适经验,希望为大家带来启发。


飞猪旅行业务简介

发展历程


飞猪是阿里巴巴旗下的旅游产品,主要面向年轻消费者的休闲度假品牌。在飞猪上,用户可以订酒店、度假、交通等相关产品。



自 2012 年以来,飞猪至今已走过 8 年成长历程。2012 年-2013 年,飞猪是淘宝的一个垂直类目;2014 年-2015 年,开始独立出来做阿里旅行;2016-2017 年,飞猪开始做整个场景的导购;2018 年至今,飞猪开始大力做场景化和内容化导购。



机酒火度假业务


下图展示了飞猪主要的实体,最左边是飞猪的酒店小搜,主推酒店的日历房;中间是飞猪的整个交通小搜,主要是机票相关。最右边是飞猪的度假板块,主要包括度假相关的商品,如门票等。



飞猪旅行问题 &挑战

旅行推荐场景 &特点


首先介绍一下,在飞猪 APP 中哪些是推荐场景。如飞猪 APP 首页中间位置的“百亿补贴”和“特价机票”是两个推荐的场景,主要给用户做特价类相关商品的推荐。在 APP 下方是飞猪的“猜你喜欢”模块,其通过多 Tab 的形式,如有旅行直播、杭州周边、住哪里等。飞猪 APP 采用无限下拉的瀑布流,用户可以无限浏览,在瀑布流里面有很多门票、酒店、景点、攻略等物料的混排,在 Feed 流里有融合主题、榜单等多种场景化的导购。



接下来是一些场景特色的推荐入口,如在左边机票频道页有一个“特价”的“猜你喜欢”模块,其主要通过特价的形式给用户个性化的推荐 OD,推荐出行的机票策略。右边是整个机票、酒店页面,包含上面的“特价”模块,下面的酒店“猜你喜欢”模块,特价的模块,主要包括百亿补贴模块和特价酒店模块。



最下面的“猜你喜欢”,是从用户出行的角度为其推荐合适的酒店,也是采用无限下拉瀑布流的形式,里面结合了各种动态导购的决策信息。最后在用户下单路径结束后,用户会进入度假详情页,这里有“看了又看”,重点为用户提供相似推荐,为其提供更多途径去做相似的比价。右边是用户下完单后,在用户的订单列表详情页会有一个主打行程搭配的交叉导购需求的“猜你喜欢”板块。



以上就是在飞猪 APP 上所有的有较大流量的推荐场景。


那么,旅行场景下的推荐具有哪些特性呢?


众所周知,对于旅行来说,用户有明显的生命周期特性,大体上可以分为四个过程:


一是用户旅行前,一般会有一个激发需求的过程,在这个阶段,用户一开始会带着好玩、热门的心态去找一些自己偏好的东西。用户在逐渐在寻找的过程中,会慢慢过渡到追求性价比阶段。


接下来用户进入到行前阶段,在这个阶段,用户主要划分为两个子阶段 — “寻找”和“决策”,在“寻找”的子阶段中,用户开始刻意的寻找旅行目的地,意向的酒店、交通方式,景点门票等。在寻找阶段,用户背后的行为逻辑是在寻找一个出行方案。在决策阶段,用户会进入到交易过程,开始关注于每一个细节,这背后是寻找最优决策的过程。


用户下完单之后出发了,接着会进入行中阶段,这个阶段,用户最主要的需求是与周边好玩儿地方的信息表达和信息的传递。


接下来,用户会到行后阶段,这里存在一个反馈机制,有了这个反馈机制,用户会进入下一次“激发需求-行前-行中-行后”的循环。



在整个用户旅行的生命阶段,我们重点要关注三个关键,第一个是状态,用户的旅行有明显的状态需求、状态变化。第二个是需求,在整个用户旅行状态的切换过程中,用户的需求差异较大。第三个,有了需求后,用户的背后需要决策,整个决策的路径不一样。


飞猪旅行另一重要特点是,因为背靠整个阿里巴巴集团,所以飞猪有很多入口,例如淘宝、支付宝、高德等,每个端上都有旅行相关的商品或内容信息的透出。但每个端用户的心智又千差万别,如在飞猪端,优惠、种草和心智三个需求可能都需要兼顾,在淘宝端和支付宝端,可能优惠的心智占的更大,在高德端是优惠和心智。


用户看到的端不一样,但其实端只是一个表面的场景,背后暗含着用户在不同的端,长期积累下来的心智的转变。在飞猪,用户在追求优惠的心智过程中,其实是在追求一种性价比,因此飞猪端会针对性做“种草”和“心智”的表达,这是激发需求的阶段,因此,我们在做推荐的过程中要考虑多端、多场景的差异。


此外,旅行场景下的推荐有一个通有的特点,我主要从以下三个方面来解读。


第一是旅行本身是低频的,一份公开数据显示,平均一位用户旅行的次数小于等于 3,这占据了大部分的用户比例;下面中间这张图,我统计了用户整个旅行的决策周期,可以看到,用户的平均决策周期大部分在 3 天以上,甚至有一部分用户在 7 天左右,整个用户决策周期非常长,不像在淘系上买商品,用户可能几个小时就能决定是否要下单。



第三个方面,随着现在 OTA 平台越来越多,用户的某一次旅行,不可能在一个 OAT 平台上完成所有交易,一般会横跨很多 APP。这导致的一个问题是,用户的整个行程在单独一个 APP 上是不完整的,我们在推荐过程中要考虑这个问题。


飞猪旅行推荐演进


飞猪旅行的推荐演进,主要从三个方向进行解读— 用户画像、召回体系、排序体系。


飞猪旅行推荐系统的整个技术演进大致经历了三个阶段。


在 2017 年以前,主要通过一些简单的线性和树模型,结合简单的通过率,来实现整基础个性化的逻辑。


在 2018 年到 2019 年,我们针对旅行遇到的一些问题,开始迈入深度学习时代,然后结合一些旅行特点,如周期性召回及热门推荐等做深度个性化推荐。


从 2019 年到现在,开始逐步进入了旅行行业的深水区,我们开始去考虑用户的整个行程,整个旅行生命周期,及针对冷启动问题,多端跨越、用户 Section 理解等问题寻求解决方案。



目前为止,我们建立起了一套完整的旅行特色的推荐算法体系,自下而上分别是基础设施、召回层、排序层和业务层。其中在基础设施层,通过这些年的积累,我们建设了两套用户画像系统 — RTFS 和 RTUS。



RTFS 可以理解成一套用户的 Run  feature 系统,RTUS 是在 RTFS 之上,对用户的各种 Run  feature 进行了各种程度的聚类,及各种意图的深度识别。在这之上,除了传统的协同过滤,弱更新化的召回策略外,我们逐渐发展了长期行为的召回,基于 User Travel State 的召回、行程的向量表达,搭配交叉召回,周期性复购。


特别是针对冷启动,我们做了很多尝试。例如,冷启动时的用户表达,基于时空的用户的聚类,以及用户的全域行为的特征收集。在召回层建设完后,我们分别从速排、精排、混排建设了一套完善的排序体制,分别来解决旅行的多目标问题、时空感知、多端多场景下用户的意图捕捉,以及用户在整个飞猪域旅行的跨域问题,即横跨“机酒火”多种行为注意力模型。最上层是服务,服务整个“猜你喜欢”及前面所说的各种推荐模块。


用户画像


用户画像是个有点老生常谈的问题,但在旅行场景,我们把用户画像作为一个非常重要的角色去做。正如前面所介绍的,整个用户有几个通用的问题,低频,冷启动,周期长。


总结起来,面临两个大问题,第一,用户的旅行行为是非常稀疏的,这要求我们在用户画像里必须涵盖的足够全,要横跨机酒火等多个类目,从用户点击到详情页,到用户下单页,整个全链路的用户日志收集的足够全。第二,旅行是低频行为,用户可能三个月或两个月才来一次 APP,这要求我们在每一次用户来的过程中,用户画像必须能够准确实时捕捉用户。如果用户这次的到来,无法精准实时地捕捉到用户,那用户可能在很长时间内都不会来这个 APP 了。



后面整个用户画像,我会从丰富和实时两大特点上来介绍。


首先在“丰富”上,我们旅行的用户、实体、行程、LBS 四个纬度建设了比较全的特征体系。如在旅行实体维度,我们去建模,挖掘各种类目跟类目之间的关系,包括搭配关系,类目和城市的关系,城市和城市的关系,邻居关系,城市和玩儿法的关系,某些城市的热度,类目的热度,玩儿的热度,各种趋势的排名等。



在行程方面,重点建设行程中心,实时建模用户在行前,行中,行后的行程偏好,行程意图,行程结算。


在 LBS 方面,我们主要通过 RBS 挖掘用户的群体特性,及用户的群体偏好。在用户侧除了常用的准实时特征及正负反馈之外,还重点挖掘了用户的长期周期性偏好和目的地偏好。


有了这些比较全的特征后,我们建设了一套比较完善的用户画像中心。主要解决两个问题,一是这么多的用户实时特征,如何保证性能的问题?推荐场景这么多,怎么让各个场景接入用户画像保证一致性?


因此,我们构建的用户画像,主要分两层,第一层是 RTFS(Real Time Feature Service ),把用户在整个旅行域的交通、酒店、度假的浏览、点击、搜索、收藏等行为全部纳入全链路的准实时日志,然后制订了一套完善的日志标准和规范,从行为和场景两个维度,聚合计算出来四大维度的基础特征,如用户的实时状态、用户全域的行为序列,及用户全域和行业的统计类特征,实体的热度和趋势等特征,这是整个 RTFS 的基础特征。有了 RTFS 之后,我们在 2019 年时建设了第一套用户画像中心— RTUS,就是 Real Time User Service 。



在整个 RTUS 里,我们重点建设了四大类特征:


第一是用户的实时类特征,重点做用户是否是新老用户的判定,生命周期的判定及用户的 LBS 状态;


第二是实时行程,对于旅行来说,行程是最主要的信息,因此我们构建了用户的实时行程中心,可以快速捕捉用户行程的切换,行前、行中、行后,快速捕捉用户的行程意图。


第三大类是实时的兴趣,实时的兴趣对用户非常重要,对旅行来说同样如此,我们要快速准实时的捕捉用户的实时兴趣,重点建设了用户的类目偏好,目的地偏好以及玩儿法偏好。


第四类是用户的实时意图,因为旅行场景下实体比较多,需要实时建模用户价格到位的意图。旅行尤其是酒店场景,复购比较多,因此在实时意图里又重点建设了用户的复购类型的意图。


还有一个重点是周期性实名地图,用户画像中心建设完后,推荐的所有场景都会实时介入到用户画像中心,这时大家可能会问,这么多的兴趣偏好,计算非常耗时间,怎么保证性能的问题?


针对这一点,我们联合数据和工程团队,做了一个大胆的尝试。看下图,蓝色的线表示老的流程,老的流程从用户进来首先访问推荐或搜索的业务,之后再去串行请求用户画像中心,每个场景都有一套单独的用户画像中心,串行的请求耗时会比较多,在这里,我们联合工程团队做了一种异步构建用户画像的方式。



如上图红色部分所示,用户在旅行的任何一个端或场景上只要接触过旅行相关的场景,就会自动触发实时机制,实时机制会异步更新用户画像中心,用户画像中心会把用户的实时画像更新到实时画像的存储里,包括全量和增量,其他所有的推荐场景加搜索场景,直接读取计算好的数据。我们通过直接对接整个用户的全链路实时流,保证异步的损耗做到非常小。我们通过这样的搭建,首先解决了异步计算的问题,可以让用户画像实时做计算。


整个用户画像收归到一起,各个场景都可以调用,保证了用户画像的一致性。此外,它的可复用性非常强。以上就是整个用户画像的构建过程。


召回体系


有了用户画像后,我们开始在整个用户画像的基础上去思考旅行的召回体系应该怎么构建。


正如前面所介绍的,旅行有生命阶段,用户会分为静默、“种草”、决策、冲刺,和行中阶段,每个阶段用户的需求不一样,用户在切换状态的过程中,存在切换状态行为不连续,意图没有精准捕捉的问题。


对于静默和种草的用户,可以结合下面这张图看一下,静默和种草的用户的占比,大概占了 40%左右。因为这部分用户的行为属于整个旅行的最基础阶段,他们的行为还不是很多,怎么在召回阶段对这类用户进行比较好的刻画,是一个挑战。



针对这些问题,我们提出了几项解决方案:第一是,要依托于 RTUS 来构建整个用户的行程的理解服务,能对用户的行程做比较精准的理解,准确判断出来用户行程的阶段,及用户行程的意图。


第二个方案是通过规则来对用户进行群体划分,我们利用把用户具体分成静默、种草、决策、冲刺、行中这几个阶段,研究每个阶段用户的群体共性来对一些行为少的用户进行偏好的计算。


首先在召回体系里,一个基础是基于协同过滤的方式,之前不管是基于普通的协同过滤,还是基于阿里集团的 Swing,都面临着几个问题。一是,因为旅行场景下,用户的意图发散较严重,例如下图片左下角这个用户,TA 在决策期,会点很多旅行目的地,如,塞班和大理,在这种情况下,如果用普通的协同过滤和普通的 Swing 阶段方法,会将塞班和大理关联在一起,得出的结论就是“点过塞班的人都喜欢去点大理”,这显然不太准确。另一个典型的例子是,飞猪平台上有很多用户买接送机,例如可能买去西安的接送机,买北京的接送机,如果基于普通协同过滤和 Swing,会得到一个结论,买了西安接送机的用户大概率都会买北京的接送机,这其实是完全没有任何关系的。


这 2 个例子反映出的缺点是,它在计算用户偏好时,没有把实体与实体之间的关系考虑进去,因此我们提出了基于 MetaPath-Swing 的计算方式,即在整个建模排队的过程中,增加了 Path 约束,任意两个实体之间需要有一种“边”可以到达,例如二者不是处于周边的 POI,它俩是不是属于一个 POI,它俩的目的地是不是一样,在整个离线上,我们对 Top20 作了整个离线指标的对比,在 Top20 的准确率大约绝对值有百分之几个点的提升。



接下来是用户行程的刻画,行程是用户旅行里非常重要的一个因素,且用户的行程有明显的连贯性、个性化,如同样是去北京,亲子用户和非亲子用户的需求差异显著。可能另一个行程的用户会重点考虑搭配或者交叉的因素,如买了机票,需要搭配下接送机或当地玩乐服务。


针对行程方面,我们提出了基于行程的个性化召回策略,采用深度召回的方式,重点构建了用户跟行程的关系,及行程跟商品之间的关系,线上通过向量检索的方式来对有行程的用户进行偏好的刻画,我们分别在对召回的不同的 Itia-dm 做了全面评估,相比关键化策略来说,提升比较明显。因为大部分有行程的用户只是有行程,在飞猪平台上还没有触发很多的行为。



接下来是另外一种用户状态的刻画,旅行是分周期阶段的,在静默和种草阶段,用户的行为非常少,而这部分用户占比又非常高,怎么能找到这些用户偏好的商品?


对此,我们采用了一种群体策略的想法,通过模型来捕捉不同旅行阶段内群体用户的特性,对新用户进行偏好计算,重点经营。我们把用户的基本属性,如年龄、性别、购买力,RBS 位置等,结合用户的 State 来对其进行特征表达。这部分用户的特征表达,代表的是这一个群体内用户的特征表达,当线上有用户过来的时候,我们直接用这个特征表达来去给用户去做召回策略,整个离线和线上的效果提升也比较明显。



排序体系


飞猪整个旅行排序体系大概经历了四个阶段:


第一个是普通的机器学习阶段,如 2017 年的 XFTRL 阶段,而后我们逐渐切换到通用的深度学习排序,主要是基于阿里自建的 XPS 和 XTF 系列。后来,我们开始做场景化深度化排序,及旅行特色排序,如基于旅行 FSL— CVR,稀疏的问题,我们尝试用 MOE 的方式去解,针对于旅行的分阶段提出了基于 Stated- MMOE 的解决方案。



下面挑选几个比较有特色的介绍下。首先,我一再强调旅行是分阶段、分状态的,但之前因为推荐的场景比较多,之前推荐的场景是互相独立的,场景与场景之间没有充分地共享数据行为。


其次,在不同场景、阶段下,背后隐藏的用户需求不一样。一般在首页,TA 是“逛”的需求;进入订单页面后,更多是“决策”的需求;到了客户界面,可能是交叉搭配的需求,之前在各个场景之间,日志没有互通,没有充分地做到场景之间的互补性;


再次,没有全链路的建模,很难捕捉用户的实时意图。所以,我们做了统一的特征协议与埋点体系,构建了全链路统一的用户画像中心;



最后,在模型层面,我们尝试用 State、MMOE 的方式来捕捉用户的状态差异性。首先说整个旅行全域的特征一致性,因为对于推荐的场景来说,它大大小小都有,只要是有用户的地方,可能都会“塞”一个推荐场景,这就导致推荐的场景比较分散,没有形成合力。2019 年我们花了很大精力去做全链路用户的场景梳理,从用户建模,统一埋点协议、各种离线特征,统一一套埋点体系,搭建了统一的离线训练流程,可以支持场景间快速的训练和在线预测。建设完成后,各个场景之间的数据可以充分互通,每个场景可以用其他场景的数据去弥补数据行为稀少的问题;每个场景都可以用其他场景的数据做全链路的建模。



搭建完一套完整的特征体系后,我们提出了针对于旅行场景特色的模型,主要是基于旅行特色的特征体系。重点引入了用户的全网信息,用户实时的正负反馈信息。模型主要有三个特点:


第一个特点是热门现象太严重,因为在旅行场景,很多的,有大量的 ID 特征,但是 ID 特征的规模也比较大,很容易学得不充分,且热门现象较严重,我们引入了图像 Adaptive-L2 正则化,来对热门的 RD 来打压。


第二个特点,考虑到有用户在整个旅行场景,在全链路都有各种实时的正负反馈行为,我们引入了全网场景内的实时正负反馈来去捕捉用户的偏好。


第三个特点,用户的旅行一般是跨域的,即用户的每次旅行一定是需求,如去泰国旅游,一定既需要买机票,又需要买门票,还需要买酒店,针对这种情况,我们提出了利用 CNN 结构来捕捉多业务序列之间的共性,在下图右下角可以看到,蓝色的线是 Base 键,绿色的线是模型的 NUC 的效果,可以看到通过引入了这么多的特征,及模型上结构的变化,离线的效果提升了很多。



前面说道,旅行场景多,每个场景数据之间没有充分地共享,用户旅行完后,从首页到订单列表页到购货页面,是一个多场景触达的过程。我们当时在想,能不能充分地把用户在各个场景之间的数据利用起来,挖掘用户在这些场景背后不同的意图,当时提出了一种 Global-Ranking 的思路,把用户在整个首页,“猜你喜欢”,郊游链路等多场景的日志做统一,统一建模用户的偏好。


我们针对这些提出了几点改进:一是把所有推荐链路的用户数据全部统一,或者充分挖掘数据之间的共性;二是另外利用时空模型来提取一些隐藏的信息,来作为特征输入。


另外,针对旅行每个场景背后的意图的明显区分性,如首页“逛”的特性,“猜你喜欢”,用户的“行前、行中”阶段等,引入了 MOE 结构来对建模多端多场景用户的不同心智。



每个场景之间有数据差异性,我们增加了场景之间的 Class  Loss 来解决这个问题,同时在最终的损失上会综合考虑场景,数据的样本差异的 Loss,及场景自身的归属 Loss,但模型是一个中间态模型,它没有对用户的全链路状态做显性的建模,只是把用户在各个场景作为用户的默认状态,这不是很科学。


基于这个模型,我们又引入了 MOE 的结构来做用户的建模。下图是用普通的 MOE 的离线训练的效果,左边最下角,通过不同的 Expert 权重可以看到用户在不同场景下,Expert 权重明显的有区分性。右边是 Base 和 MOE 的离线在一些效果上的对比,可以看到效果非常明显。



前面提到状态的 MOE 模型没有显性的去建模用户的状态切换,用户在不同场景间,它只是一种表象,背后是用户的需求的差异,用户需求是跟用户的状态明显相关的,比如,用户如果是在种草阶段,可能关注于看的内容和“行中”,和在决策阶段看的内容有明显的不同。


我们又对 MOE 做了改进,提出了基于 State 的 MOE 的结构,主要对用户状态做了显性的建模,通过引入 Gate 的方式,对用户的状态做行前建模。由于状态不一样,而导致用户背后的需求不一样。下图右下角是离线的评估效果,可以看到,通过显性的建模用户的状态与数据的关系,拿到了不错的收益。



接下来分享在展现层面的一些想法:


第一个特点是,旅行商品与电商实物商品之间的差异性,比如用户在淘宝上购买一件衣服,可以通过文字、图片、直播知晓商品全貌。但旅行是重服务属性,仅通过图片等,可能无法完全知晓商品的全貌,有一个“所见即所得”的问题,看到的不一定是真正享受的服务。


第二个特点是,有时候旅行是一种社会群体驱动的。可能并不是因为你有多大的偏好而去某一个地方,而是周边人都去了,或者这个地方现在是最热门的。


第三个特征是,旅游的信息有非常大不对称性,很多数据和信息只有去过才知道,实践才是检验真理的唯一标准。但如果只给用户推荐一个酒店或推荐一个商品时,如果展示层面不做任何改变,其实很难让用户有决策或有比较大的冲动去购买推荐给 TA 的商品。这启发我们,去构建旅行特色的导购决策信息。


针对以上,我们在 2019 年启动了旅行导购决策体系建设,具体看下图。该体系主要通过挖掘旅行特色的标签,及行程相关的标签,用户群体的标签,结合用户的行为日志,从排名信息、趋势信息,周期信息、行程信息、行为信息等角度去挖掘一些有体感的 Tab,比如告诉用户商品是“最有潜力的”,或是“最热卖的”,通过构建这样一套完整的导购决策体系,推动产品在整个页面上做展示,效果不错。且用户体验也非常强,用户在浏览整个旅行相关的交通、酒店等时,不再是冷冰冰的一种展示形式,而是可以跟用户产生比较强的互动效应。



展望


接下来,我还有一些对于飞猪旅行的展望。


虽然现在,我们已经做了初步的旅行探索,但距离真正的行业深水区还有一定差距。未来我们希望围绕整个用户的旅行生命周期探索发现、决策购买、行中体验的三个大阶段做更深入地挖掘。


在探索发现阶段:通过算法能力重点挖掘好货,好玩儿的;在决策购买阶段,要建设更加完善的导购决策信息,及导购的方案,野外线路、性价比;在行程中,通过整个用户的行程、规划、信息把行中体验打透。


此外,我们会紧紧围绕用户的整个旅行生命周期(行中、行前、行后)来激发需求。重点要做内容化,通过引入大量内容来激发用户的新需求,针对冷启动的用户,重点去通过其他的行为或者其他的知识表达去引导这部分用户激发需求。


这背后就需要意图识别更加精准。现阶段,我们主要通过给用户更加精准的推荐酒店、更智能的交通规划方式,及更加意想不到的度假、门票等产品,来完善整个用户的旅行方案,而不只是推一个单品。


在决策阶段,后续我们会充分利用阿里的多端多场景资源,充分提升多端的转化,提升最优的决策。在“行中”阶段,会结合知识及 RBS 引擎的能力,让用户知道“行中”周围的好吃的,好玩儿的,好住的等等。在“行后”阶段,重点从评论中挖掘用户的决策因子,及针对旅行特色的复购,为用户推荐智能的复购,即 TA 在确切的时间、确切的地点,最确切需要的东西。


以上就是全部的分享。


作者介绍:


葬青,阿里巴巴飞猪旅行/高级算法专家。葬青深耕旅游导购算法多年,带领团队 0-1 搭建了飞猪旅行导购算法体系。葬青曾负责过百度知道相关问题推荐以及淘宝人群推荐,是淘宝人群推荐算法主要贡献者,以及 2015 年淘宝个性化元年算法成员之一。

2021 年 1 月 06 日 15:15963
用户头像
刘燕 InfoQ记者

发布了 483 篇内容, 共 150.2 次阅读, 收获喜欢 869 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营第十二周总结

xiaomao

28 天带你玩转 Kubernetes-- 第三天(K8s 安装)

Java全栈封神

Kubernetes k8s 28天写作 k8s安装

十二、数据应用(一)

Geek_28b526

给我结果

三只猫

28天写作

精选算法面试-栈

李孟

算法 堆栈 28天写作

第 12 周 系统架构总结

心在那片海

【架构师训练营 1 期】大作业二

诺乐

漫谈中台系列:《1小时带你深入理解中台》学习整理

程序员架构进阶

架构 中台 技术 探索与实践 28天写作

读《专访朱啸虎》,我学到了什么?

李忠良

学习 写作 投资 创业者 读后感

Java并发编程

topsion

Java 并发编程 多线程

架构师训练营第 1 期 - 大作业 (二)

wgl

架构师训练营第 1 期

一个技术主管的年终管理心得

陆陆通通

程序员 技术管理 28天写作

架构师训练营第 12 周:数据应用(一)

xiaomao

架构师训练营 - 大作业(一)

树森

SpringMVC学习!

程序员的时光

程序员 28天写作

第 12 周 系统架构作业

心在那片海

架构师训练营第十二周作业1

韩儿

架构师训练营 week12 学习笔记

花果山

架构师训练营第十二周作业2

韩儿

架构师训练营大作业(二)

月殇

架构师训练营 4 期 第2周

引花眠

架构师训练营 4 期

架构师训练营大作业(一)

Bear在挨踢

架构师训练营第 1 期

架构师训练营第 1 期 - 大作业 (一)

wgl

架构师训练营第 1 期

架构师训练营-大作业二

石子头

架构师训练营大作业二

一马行千里

架构师训练营第 1 期

【架构师训练营 1 期】大作业一

诺乐

架构师训练营 week12 课后作业

花果山

【薪火计划】10 - 目标计划管理

brave heart

管理 28天写作

架构训练营第十二周作业

一期一会

hdfs hive 大数据MapReduce

python 变量

老赵

Python 28天写作

算法:罗马数字转换为整数,RxSwift的好处,git pull问题解决error: cannot lock ref,产品经理新人如何落地 John 易筋 ARTS 打卡 Week 34

John(易筋)

ARTS 打卡计划 算法:罗马数字转换为整数 RxSwift的好处 git pull cannot lock ref 产品经理新人如何落地

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

飞猪旅行推荐算法应用实践-InfoQ