了歹 2020年我们如果问企业IT最大的趋势是 什么，我觉得云计算必然会排在前列。今天，上 云是IT基础设施继续向企业提供能力升级的必 然趋势，通过稳定、快捷、高性能和高弹性的底 座，帮助企业迅速实现已有业务的数字化，以及 推动现有数字信息的实现业务价值。 IT的基础设施上云只是一个开始。云的最大价值，用一句话来说， 就是“数据让应用智能化”。从阿里巴巴经济体的角度来说，未来数据智 能技术发展的两大方向，一是实时化的大数据能力，二是人工智能技术。 云时代的数据智能，可以真正处理海量的数据，可以真正实时地进行数 据的分析，也可以真正把人工智能和大数据完美结合，提炼数据的内在 规律。 在阿里云提供的统一技术平台上，阿里巴巴的各个业务部门沉淀了 很多优秀的方法论。我们非常高兴用这一本实践手册作为给开发者社区 和企业用户的献礼。通过这些最佳实践的分享，我们希望能够和企业， 和开发者一起探索，进一步推动数据智能领域的创新和落地。 序言 贾扬清 阿里云智能 计算平台事业部总裁 解密 淘宝 推荐实战，打造 “比你还懂你” 的个性化 APP 5 优酷 背后的大数据秘密 18 阿里集团 风控大脑关于大数据应用的探索与实践 29 可闭环、可沉淀、可持续的企业级数据赋能体系 友盟云 数据中台 产品实践 44 MaxCompute 在 高德 大数据上的应用 59 MaxCompute 在 阿里妈妈 数据字化营销解决方案上的典型应用 74 实时计算助力 1688打造实时挑货系统 93 实时计算在 阿里影业 实时报表业务技术解读 103 目录 解密淘宝推荐实战， 打造 “比你还懂你” 的个性化APP 作者：欧文武 ( 三桐 )阿里集团 淘宝事业群 资深算法专家 简介 ：如今，推荐系统已经成为各大电商平台的重要流量入口，谁才能够做到比 用户更懂用户，谁占据了新零售时代的主动权。手机淘宝的推荐更是淘宝最大的流量 入口和最大的成交渠道之一，其背后是最为复杂的业务形态和最复杂的场景技术，那 么究竟如何打造手淘背后的推荐系统呢？本次首席技术官大数据专享会上，阿里巴巴 搜索推荐事业部资深算法专家欧文武（三桐）为大家解密了淘宝的推荐实战。 手淘推荐简介 手淘推荐的快速发展源于 2014 年阿里“All in 无线”战略的提出。在无线时代， 手机屏幕变小，用户无法同时浏览多个视窗，交互变得困难，在这样的情况下，手淘 借助个性化推荐来提升用户在无线端的浏览效率。经过近几年的发展，推荐已经成为 手淘上面最大的流量入口，每天服务数亿用户，成交量仅次于搜索，成为了手淘成交 量第二大入口。 6 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 今天的推荐不仅仅包含商品，还包含了直播、店铺、品牌、UGC，PGC等，手 淘整体的推荐物种十分丰富，目前手淘的整体推荐场景有上百个。推荐与搜索不同， 搜索中用户可以主动表达需求，推荐很少和用户主动互动，或者和用户互动的是后台 的算法模型，所以推荐从诞生开始就是大数据 +AI 的产品。 手淘推荐特点 相比于其他推荐产品，手淘推荐也有自身的如下特点： 1. 购物决策周期 ：手淘推荐的主要价值是挖掘用户潜在需求和帮助用户购买决 策，用户的购物决策周期比较长，需要经历需求发现,信息获取，商品对比 和下单决策的过程，电商推荐系统需要根据用户购物状态来做出推荐决策。 2. 时效性 ：我们一生会在淘宝购买很多东西，但是这些需求通常是低频和只在 很短的时间窗口有效，比如手机12才买一次但决策周期只有几小时到几 天，因此需要非常强的时效性，需要快速地感知和捕获用户的实时兴趣和探 索未知需求 , 因此，推荐诞生之初就与 Flink、Blink 实时计算关系非常紧密。 3. 人群结构复杂 ：手淘中会存在未登录用户、新用户、低活用户以及流式用户 等，因此需要制定差异化的推荐策略，并且针对性地优推荐模型。 4. 多场景 ：手淘推荐覆盖了几百个场景，每个场景都独立进行优化显然是不可 能的，而且每个场景的条件不同，因此超参也必然不同，无法依靠人工逐个 优化场景模型的参数，因此需要在模型之间进行迁移学习以及自动的超参学 习等，通过头部场景的迁移学习来服务好尾部场景。 5. 多目标和多物种 。 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 接下来将主要围绕数据、基础设施以及算法模型进行介绍。 数据-基础数据 手淘的推荐数据主要包括几种，即描述型数据比如用户画像,关系数据比如二部 图或稀疏矩阵,行为序列和图数据等。基于用户行为序列推荐模型在手淘商品推荐应 用最为广泛，图模型则是近两年发展较快的模型，因为序列通常只适合于同构的数 据，而在手淘里面，用户的行为有很多种，比如看视频、搜索关键词等，通过graph embedding 等技术可以将异构图数据对齐或做特征融合。 数据-样本 数据样本主要包含两部分元素，label和特征。label一般在手淘推荐中有几类， 比如曝光、点击、成交以及加购等。特征则比较多了，比如用户自己的特征、用户上 下文特征、商品本身特征以及两两组合特征等。根据用户的特征和行为日志做Join 就形成样本表，这些表格存储的时候就是按照稀疏矩阵方式进行存储，一般而言是按 天或者按照时间片段形成表格，样本生成需要占用很大一部分离线计算资源。 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 离线计算-模型训练 模型训练也有三种主要的模式，即全量学习、增量学习和在线学习。全量学习这 里是指模型初始化从0开始学习，如果日志规模比较小，模型简单并不需要频繁更新 时，可以基于全量日志定期训练和更新模型,但当日志和模型参数规模较大时，全量 学习要消耗大量计算资源和数天时间，性价比很低，这时通常会在历史模型参数基础 上做增量学习，用小时/天日志增量训练模型和部署到线上，降低资源消耗和较高的 模型更新频率。如果模型时效性非常强需要用秒/分钟级别样本实时更新模型，这是 就需要用到在线学习，在学习和增量学习主要差别是依赖的数据流不一样，在线学习 通常需要通过流式计算框架实时产出样本。 离线计算-训练效率 因为机器资源总是不够的，训练优化是如何用更快的速度，更少的计算和更少的 数据训练出更好的模型，这里为大家提供一些加速训练的方式： 1. 热启动 ：模型需要不断升级和优化，比如新加特征或修改网络结构，由于被 修复部分模型参数是初始值，模型需要重新训练，热启动就是在模型参数只 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 云和端 随着5G和IOT的发展数据会出现爆炸式的膨胀,将数据放在云上集中存储和计 算，这样做是否是一个最合理的方式呢？一些数据和计算能否放在端上来做？端上相对 于云上而言，还有几个较大的优势，首先延时低，其次是隐式性，各个国家对于隐私的 保护要求越来越严厉，因此需要考虑当数据不能发送到云端的时候如何做个性化推荐。 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 召回技术-动态实时多兴趣表达(MIND) 早些年大家在做推荐协同过滤可能使用Item2Vec召回、标签召回等，比如像 Item2Vec召回而言，确实比较简单，而且时效性非常好，在很长一段时间内主导了 推荐技术发展的进程，后续才诞生了矩阵分解等。但是Item2Vec召回存在很大的问 题，如果商品的曝光点不多其实是很难被推荐出来的，因此推荐的基本上都是热门的 Item。其次 Item2Vec 召回认为每个点击都是独立的，缺少对于用户的全局认知，此 时需要做的是就是将用户的行为和标签进行全局感知并做召回。基于这样的出发点， 我们提出了基于行为序列的召回模型，但这种方式存在的问题就是用户的兴趣不会聚 焦在同一个点，单个向量召回通常只能召回一个类目或者兴趣点，因此如何通过深度 学习做用户的多需求表达等都是挑战。这样的问题，阿里巴巴已经解决了，并且将论 文发表在 CIKM 2019 上面。现在，淘宝所使用的是在线多向量化并行召回。 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 推荐序列优化-生成式推荐 推荐一般都是基于打分的，打完分之后在做一个贪心排序和打散，这样的做法 得到的结果其实并不是最优的，因为这样做并没有考虑结果与结果之间的依赖性， 使用贪心算法得到的结果并不是最优的。推荐本质上应该是对于集合而不是序列的 优化，因此手淘推荐是用的是生成式排序模型。更多可以参考我们在 KDD 2019 发 表的论文。 多目标均衡优化 在推荐时，大家往往会遇到多目标均衡问题，比如商品推荐的浏览深度，点击和 成交，由于目标量纲不一致，不存在全局唯一最优解，需要同时优化多个目标或在多 个目标之间做合理取舍，对此我们提出了基于帕累托的多目标优化排序模型。更多可 参考我们发表在 RecSys 2019 的文章。 解密淘宝推荐实战，打造 “比你还懂你” 的个性化 APP 17 优酷背后的大数据秘密 作者：门德亮阿里集团 新零售技术事业群 数据技术专家 在本文中优酷数据中台的数据技术专家门德亮分享了优酷从Hadoop迁移到阿 里云 MaxCompute 后对业务及平台的价值。 大家好，我是门德亮，现在在优酷数据中台做数据相关的事情。很荣幸，我 正好见证了优酷从没有MaxCompute到有的这样一个历程，因为刚刚好我就是入 职优酷差不多5年的时间，我们正好是在快到5年的时候，去做了从Hadoop到 MaxCompute 的这样一个升级。这个是 2016 年 5 月到 2019 年现在的 5 月优酷的 发展历程，上面是计算资源，下面是储存资源。大家可以看到整个用户数，还有表的 数据，实际上是在呈一个指数式增长的。但是在2017年5月，当优酷完成了整个 Hadoop迁移MaxCompute后，优酷的计算消耗，还有储存的消耗实际上是呈下降 趋势的，整个迁移得到了一个非常大的收益。 优酷背后的大数据秘密 优酷背后的大数据秘密 第一个，简单易用。 第二个，完善的生态。 第三个，性能非常强悍。 第四个，资源使用非常弹性。 第一个特点，简单易用。MaxCompute有一个非常完整的链路，不管是从数据 开发，还是数据运维，包括数据集成，数据质量的管控，还有整个数据地图，数据安 全。当年优酷从 Hadoop 迁到 MaxCompute 之后，我们最大的体会是自己不用半夜 经常起来去维护集群了，不用去跑任务了，写一个任务，别人之前提一个需求过来， 我可能要给他排几周，而现在我可以告诉他，我给你马上跑一下，就可以出来了。包 括之前像分析师BI还要登录客户端，写脚本，自己写调度，经常会说我的数今天为 什么没出来？包括高层看的数，可能要到12点钟才能出来。而现在基本上所有重要 的数据都会在7点钟产出，包括一些基本的业务需求，其实分析师或者产品，他们自 己都可以实现了，不需要所有需求都提到数据这边。 优酷背后的大数据秘密 优酷背后的大数据秘密 第四个特点，资源使用的弹性。我们在2016年迁移之前，其实优酷的Hadoop 集群规模已经达到了一千多台，这个当时还是一个比较大的规模。当时我们遇到了很 多问题，包括像NameNode 这种内存的问题，机房没有办法再扩容的问题，当时是 非常痛苦的，包括一些运维管理上面的问题。我们不断的去问运维要资源，运维告诉 说 ， 说你们已经花了多少多少资源，花了多少多少钱。我们面临的问题是计算资源如 何按需使用，夜里的时候作业很多，到了下午之后，我的整个集群都空下来了，没有 人用，造成了浪费。其实 MaxCompute 完美的解决了这个问题。 优酷背后的大数据秘密 优酷背后的大数据秘密 数据源上，比如DB也好或者服务器的本地日志Log也好，我们通过TT ThriftHeader header = null; List messageFlush = new ArrayList(messages.size(); for (com.alibaba.middleware.jingwei.externalApi.message.Message message : messages) DbSyncMessage dbSyncMessage = (DbSyncMessage) message; DBMSRowChange dbmsRowChange = (DBMSRowChange) dbSyncMessage.getDbMessage(); try header = buildThriftHeader(dbSyncMessage); / 省去部分代码 for (Message thiftMessage : messageList) messageFlush.add(thiftMessage); catch (Throwable e) throw new JingWeiException(builder.toString(), e); try for (Message thiftMessage : messageBuilder.flush(header) messageFlush.add(thiftMessage); catch (TException e) String err = Thrift serialization error: + e.getMessage(); logger.error(err, e); throw new JingWeiException(err, e); 实时计算在阿里影业实时报表业务技术解读 109 msgSender.send(messageFlush); 代码主要是讲经过 binlog 的数据转换成 Message 对象，Message 把响应的数 据丢到 Thrift 协议中去，最核心就是把数据转成 Thrift 然后丢到 metaq。 精卫解析metaq核心代码 com.alibaba.middleware.jingwei.client.util.MetaqToJingweiMsgParser ThriftHeader thriftHeader; try thriftHeader = ThriftHelper.loadThrift(msg.getBody(), eventSet); catch (Exception e) if (DynamicConfig.isSKIP_ALL_EXCEPTION(taskName) logger.warn(SKIP_ALL_EXCEPTION is true, will skip the msg : + msg, e); continue; else throw new JingWeiException(ThriftHelper.loadThrift occur error + , msg : + msg, e); for (ThriftEvent event : eventSet) /省去部分代码 上面代码是精简出来的，解析Thrift处理过的metaq的数据，如果针对上面 ThirftEvent感兴趣可以仔细看看他们内部怎么处理，通过测试这种协议反解析出来 的速度很快，都是毫秒级别。 blink解析metaq模型 解析metaq发送过来的核心代码 public static List parseMetaQMessage(byte bytes, Class c) throws Exception List sourceList = new ArrayList(); List eventSet = new ArrayList(); ThriftHelper.loadThrift(bytes, eventSet); 110 实时计算在阿里影业实时报表业务技术解读 /协议解包 for (ThriftEvent event : eventSet) / 省去部分代码 return sourceList; 配置流程 可以参考上面整体配置流程。 精卫回溯方案 为什么不自己开发一套代码，直接把消息丢到metaq不就行了吗？ 是因为精卫 是按照任务纬度来划分，一个任务有多个表，如果自己再开发一套就需要把现有的任 务跟表的关系关联在一起，这样造成很大的工作量，并且通过查看官方文档和vone 咨询那边的开发，他们现在没有办法支持全量同步到 metaq，只能通过精卫容器模式 自己编写代码来实现。 全量发送metaq核心代码 Metaq3ApplierVO metaq3ApplierVO = new Metaq3ApplierVO(); metaq3ApplierVO.setCompressionType(NONE); BatchMetaq3Applier outerClass = new BatchMetaq3Applier(); outerClass.setMetaq3ApplierVO(metaq3ApplierVO); BatchMetaq3Applier.PartitionMessageBuilder messageBuilder = outerClass.new PartitionMessageBuilder(); ThriftHeader header = null; String topic = entryMessageData.getKey(); List messageFlush = new ArrayList(messages.size(); for (DataMessage message : entryMessageData.getValue() DBMSRowChange dbmsRowChange = null; List columns = new ArrayList(); int columnIndex = 0; / 省去部分代码 基于上面分析的协议，而现在返回DataMessage对象是精卫封装后的，为了 兼容一套Blink协议转换，需要把转换后的对象再组装成Thrift协议，在组装过程有 实时计算在阿里影业实时报表业务技术解读 实时计算在阿里影业实时报表业务技术解读 petadata技术 petadata百万查询都是毫秒级别，不过不能分页过多，因为页数过多多从多个 分区拿数据，然后再组装很耗时。 总结 精卫发送 metaq 的数据带毫秒的，格式如：2018-03-10 12:12:12.0，而回 溯全量方案获取的dataMessage是直接从数据库拿的值，没有带毫秒。格式如： 2018-03-10 12:12:12。 petadata 不支持 group by 后再 order by。 幂等顺序问题通过 LAST_VALUE 和 group by 来解决。 blink.state.ttl.ms（默认一天） 和 state.backend.rocksdb.ttl.ms（默认1一 天 半 ）， 一般是按照这个规则设置两个参数blink. state.ttl.ms = state.backend. rocksdb.ttl.ms，由于我们报表业务特殊性，是凌晨6点到第二天凌晨6点为一个周 日，所以这两个参数最少要设置为 2 天，才能保证准确性。 有 join 操作，先过滤、去重，再 join。 如果 in/outcpu 过高，则从 core、memory、parallelism，cu 几方面扩大调优。 传输数据过多，可以增大 blink.miniBatch.size，以减少在计算过程中对 IO 的 操作，但只能对 group by 生效。 精卫bug：当带上自定义查询条件，如果id是主键，且是varchar类型，精卫 拼装sql就会报错，这个已经反馈给精卫开发，正常id都是long，由于我们在弹外 的业务是字符串，所以复现这个bug，后续的表一定要按照集团规范，不然使用其他 中间件估计也会有问题。