阿里巴巴大数据及AI实战.pdf

2020 年我们如果问企业 IT 最大的趋势是什么，我觉得云计算必然会排在前列。今天，上云是 IT 基础设施继续向企业提供能力升级的必然趋势，通过稳定、快捷、高性能和高弹性的底座，帮助企业迅速实现已有业务的数字化，以及推动现有数字信息的实现业务价值。IT 的基础设施上云只是一个开始。云的最大价值，用一句话来说，就是“数据让应用智能化”。从阿里巴巴经济体的角度来说，未来数据智能技术发展的两大方向，一是实时化的大数据能力，二是人工智能技术。云时代的数据智能，可以真正处理海量的数据，可以真正实时地进行数据的分析，也可以真正把人工智能和大数据完美结合，提炼数据的内在规律。在阿里云提供的统一技术平台上，阿里巴巴的各个业务部门沉淀了很多优秀的方法论。我们非常高兴用这一本实践手册作为给开发者社区和企业用户的献礼。通过这些最佳实践的分享，我们希望能够和企业，和开发者一起探索，进一步推动数据智能领域的创新和落地。序言贾扬清阿里云智能计算平台事业部总裁 解密淘宝推荐实战，打造“比你还懂你”的个性化 APP 5优酷背后的大数据秘密 18阿里集团风控大脑关于大数据应用的探索与实践 29可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践 44MaxCompute 在高德大数据上的应用 59MaxCompute 在阿里妈妈数据字化营销解决方案上的典型应用 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&Datahub存储到 MaxCompute 上面做分析。当然现在非常火的 Flink 实时计算，其实是作为一个实时处理的链路。包括 DB 的同步，除了实时的链路，DB 也会去通过按天/按小时，把数据同步到 MaxCompute，数据计算结果也可以同步到 Hbase、Mysql 这种 DB 上面。再通过统一的服务层对应用提供服务。下面这个是机器学习 Pai 做的一些算法训练，再把训练的结果通过 OSS 传到一个算法的应用上面去。这张图可能也是业界比较流行的一个数仓分层的图，因为我们这边是数据中台，所有的数据都是统一从 ods 层 cdm 层，然后 ads 层，去一层一层的往上去做精细，再到最上面，通过接口服务、文件服务、SQL 服务，去提供多样化的服务。再往上面，提供对内的一些数据产品，对高管、对小二，可能还有一些对外的，比如说像优酷的播放数，包括热度这些对应用的数据。优酷背后的大数据秘密优酷背后的大数据秘密这张图大部分互联网公司不太会涉及到，就是关于反作弊的问题。这个是我们在 MaxCompute 做的一个反作弊的架构，通过原始的数据去提取它的特征，然后再通过算法模型，包括机器学习、深度学习、图模型去支持流量反作弊、渠道反作弊等等。再通过业务场景上反作弊的监控工具，把监控到的作弊信息去打一个黑白样本，再把这个黑白样本跟特征一起来不断的迭代优化算法模型。同时针对算法模型，做一个模型的评价，不断来完善反作弊体系。最后一点，其实还是跟成本相关，在日常使用中，一定是有小白用户或者一些新来的用户去错误的使用或者不在乎的使用一些资源，比如经常会有一些实习生或者是非技术的同学，如分析师，一个 SQL 消费比较高，这个其实是非常浪费资源，而且可能他一个任务，让其他所有人的任务都在这儿等着排队，实际上我们会去对整个的资源做一个治理。从节点的粒度上，通过大数据来治理大数据，我们可以算出哪些表产出来之后，多少天没有被读取的，包括它的访问跨度可能没有那么大的，我们会去做下线或者去做治理，有一些业务场景可能并不是非常的重要或者它的时间要求没有那么高，比如一些算法训练，可以去做一些错峰的调度，保证水位不要太高。从 MaxCompute 任务的角度，可以算出哪些任务有数据倾斜、哪些数据可能会有相似计算，哪些任务需要去做 MapJoin，哪些任务需要去做一些裁剪，然后来节省它的 IO。还有哪些任务会去做暴力扫描，扫一个月、扫一年的数据，哪些数据可能会有这样一个数据膨胀，比如说它做了 CUBE 之类的这种复杂计算，一些算法模型的迭代；我们通过数据计算出来的这些迹象，去反推用户，来去提高它的这样一个数据的质量分，来去达到我们降低整个计算资源的目的。在计算平台的角度，我们也持续的在使用 MaxCompute 推出的一些非常高级的用法，比如我们这边的 HBO、Hash Cluster、Aliorc；优酷背后的大数据秘密优酷背后的大数据秘密最后一页是存储的优化，因为像一些关键的原始数据或者是需要审计的数据是不能删的，永久不能删的。实际上就会造成我们数据存储的趋势是一直往上不减的，计算会在某一个时间点达到一个平衡。当前用这么多的计算资源，再往后，其实应该也不会再大涨了，比如说旧的业务逻辑下掉了，会换新的业务逻辑，这样会保持在一个相对平稳的波动上面。但是储存，因为它有一些历史的数据是永远不能删的，可能会出现一直在增长，而且是指数级的。所以我们也会持续关注存储的情况，还是通过大数据来治大数据，去看哪些表的访问跨度比较小，来去做生命周期的优化，来去控制它的增速。还有刚才提到的 Aliorc，实际上也是做压缩的。我们会去做一些大字段的拆分，来提高压缩的比例。OK，这个是优酷在 MaxCompute 中的一些应用场景，感谢大家的聆听。阿里集团风控大脑关于大数据应用的探索与实践作者：丁明峰(山蜂)阿里集团 新零售技术事业群 高级数据技术专家简介：2019 年双 11 阿里风控保护了约 388 亿消费者的操作行为，同时挡住了约 22 亿次恶意攻击。在首席技术官大数据专享会，阿里巴巴新零售技术事业群高级数据技术专家丁明峰为大家介绍了阿里风控大脑关于大数据应用的探索与实践，即风控领域如何应用大数据来构建风控体系？并详细介绍风控架构以及链路。本次分享主要围绕以下三个方面：一、阿里风控大脑整体介绍二、近线引擎三、离线引擎一、阿里风控大脑整体介绍1.阿里风控大脑是什么？阿里的风控主要分为两大块。一块是金融领域，主要业务是支付宝，另一块是非金融领域，如新零售、高德、大文娱等，我们负责的主要是非金融领域。阿里风控大脑的含义较为丰富，可以有不同的解读，但基本上代表了几个方向。首先，阿里风控大脑是“大中台小前台”战略，由于阿里风控管的风险业务很多，领域非常杂，所以允许不同的领域、不同的风控场景可以有自己独特的交互，有自己的 console，但是用到的底层引擎必须是中心化的，由风控引擎做统一计算和处理。第二，阿里风控大脑代表高智能，后续会有深度学习和无监督学习模型大量上线，防控策略及防控方式都会更加智能化。如下图所示，右侧是目前阿里风控覆盖的主要业务和防控的风控场30阿里集团风控大脑关于大数据应用的探索与实践景，如黑客攻击、消费者保护、商家保护等。左侧是阿里风控 2019 年双 11 的部分数据，保护了约 388 亿消费者的操作行为，同时挡住了约 22 亿次恶意攻击。2.典型防控链路用户通过阿里的 APP 或网站访问阿里的业务会产生大量操作。这些操作进来之后大概会经过如下图所示的七层防控环节。首先会是端上防控，主要在应用层，比如应用的加固，应用的代码混淆等。然后是端上安全策略。第二层是在网络层，在网络层做流量清洗和流量保护。基础安全防控：网络层之后会有人机判断。人机部分在风控领域占比非常大，网络层+人机的防控方式和下面几层差异比较大，主要针对基础流量做防控，不会加入具体的业务逻辑，所以称其为基础安全防控。实施安全防控：人机比较复杂，一部分与流量相关，另一部分偏业务。其中偏业务的部分与下面几层称为业务防控范围。人机之后，在业务防控侧做白/黑判断，主要是出于成本考虑。如果能先判定用户行为的白/黑，后面则不需要做太多进一步判定，可以节约大量成本。然后是比较复杂的灰的判定，需要从多个维度来识别风险。阿里集团风控大脑关于大数据应用的探索与实践阿里集团风控大脑关于大数据应用的探索与实践其中最复杂的是风险识别环节。风险识别会用到前端的业务系统，比如淘宝APP、天猫 APP 传过来的各种业务数据。但是仅仅通过这些业务数据做风险防控是远远不够的，所以阿里会做很多大数据的应用，比如名单库、关键词库、还有很多的指标以及实时图、IP 库等。这些数据会通过元数据中心做统一定义和管理，最终通过统一数据服务来给风险识别做数据增强。另外，通过事件中心、策略工厂、模型平台，构建了策略/模型快速实验和上线的过程。事件中心把实时引擎或者近线引擎的数据补全完整后写入 MaxCompute，然后在策略工厂中，会和 PAI 打通，由策略工厂准备数据后，再通过 PAI 做模型训练。最终在策略工厂里面将新的策略、新的模型部署到线上，如此便形成了快速的数据+训练+上线的链路。阿里集团风控大脑关于大数据应用的探索与实践阿里集团风控大脑关于大数据应用的探索与实践2.近线引擎的定位基于阿里场景，要求近线引擎至少满足三个要求，如下图所示，第一时效性不能太差，即允许有延时，但不能太久，因为如果延时太久，没有返回风险结果，业务侧就会认为这种行为是正常的，容易造成漏防。第二要支持多事件综合处理的能力，在流计算中称为支持多流的 join 处理。并且需要非常灵活的数据处理能力，大部分算法里面会有很多非常灵活的数据加工，需要算法同学自己实现。第三希望近线引擎能和阿里现有的风控体系无缝融合，因为阿里本身原本的风控体系非常庞大，上下游环节非常多，如果近线引擎孤立在外，可能需要做很多重复造轮子的事情。3.WhyBlink？流计算的快速发展，让阿里选择了流计算平台作为近线引擎的底层核心。在对比了市面上几个比较受欢迎的流计算平台之后，最终选择了 Blink。选择 Blink 有几点原因，如下图所示。首先 Blink 是阿里内部定制版的 Flink，在公司内部已经搭建了性能非常好的流计算平台，平台开放性、扩展性非常不错，兼容成本也非常低。另外Blink 有一套完整的 SQL 语义支持，这一点非常重要。因为阿里希望业务方尽量使用 SQL，SQL 使用成本较低，上手速度也会非常快。Blink 团队会持续优化 SQL 性阿里集团风控大脑关于大数据应用的探索与实践阿里集团风控大脑关于大数据应用的探索与实践理实现，阿里希望用户不需要关注这些实现细节，而只关注业务逻辑，所以设计了S-SQL。语法转义：将 S-SQL 翻译成 Blink SQL。Blink 任务管理：包括任务的上下限、安全生产相关的，做灰度、做测试等。5.阿里在近线引擎为同学提供的两种模式算法同学模式开放式 SQL：算法同学模式是开放式 SQL。因为算法同学具备较强的数据能力和开发能力，并且经常会针对一些业务场景写个性化很强的算法，如果将其限制的太死反而不方便，所以支持完全用 S-SQL 来写业务逻辑。下图所示案例是从数据源取出一个字段。左侧是对过程中需要用到的业务组件的封装，中间是S-SQL。可以看到 S-SQL 写法跟 Blink SQL 完全不一样，只需要写 event.odl_event_ugc。event 是数据源的特殊名词，即一个系统保留关键字。用 S-SQL 来写根本不用关注 event 是怎么来的等影响研发效率的信息，因为在系统、业务组件里有一套约定告知 event 从哪里来。阿里集团风控大脑关于大数据应用的探索与实践阿里集团风控大脑关于大数据应用的探索与实践另外，任务之间基本通过两种方式进行数据传递。第一种是 MetaQ，上游任务会通过 MetaQ 分发到下游。第二种是通过 HBase，因为 HBase 的多列加上 HLog可以很方便地把多条消息整合到一条消息里面，所以数据合并基本是用 HBase 来做。6.业务效果目前近线引擎用了约 2000CU 资源，日均处理事件量约 300 亿，主要覆盖的场景有商品、内容、直播、拉新等多个领域，风险识别在风控领域占比约 10%。相信随着模型和算法的进一步发展，产品的进一步完善，比重也会大幅上升。三、离线引擎1.为何需要离线引擎离线引擎基本是和近线引擎同一时间考虑的，起初是发现有很多离线数据会批量导入到实时引擎中处理，非常不利于实时引擎的稳定。随着深入探索和研究，发现很多场景确实需要批处理能力进行风险识别。离线引擎起初是为了解决以下几个问题。第一是新业务的接入，阿里集团规模最近几年发展越来越快，覆盖了非常多的业务领阿里集团风控大脑关于大数据应用的探索与实践阿里集团风控大脑关于大数据应用的探索与实践仿真模拟离线引擎的独特之处是需要对历史数据进行全面处理。一个很大的问题是新特征不能通过事件中心对历史数据进行补全，所以做了仿真模拟，即尽可能在离线上复现风控在实时引擎中用到的特征。按照如何去做将仿真分为三类。业务原始数据：业务原始数据即业务发过来的数据，按照目前策略，业务原始数据会通过事件中心全量写到 MaxCompute 中。事件中心使用 DataHub 中间件，事件数据会通过 DataHub 写到 MaxCompute。这类数据默认全部都有，不需再做过多操作。不可模拟的增强数据：第二类是不可模拟的增强数据。比如调用了一个第三方的服务，完全不清楚第三方服务的逻辑是什么，只知道第三方服务给出的数据。因为调用的第三方服务比较多，所以不可能逐一去看，这类数据基本暂时是不可模拟的。目前对于这种数据要预先配置在事件中心里面去做补全，其缺点是如果要在新的事件上做补全，已经属于事后的事情了，那么历史的那部分数据是没办法获取的。所以不可模拟的增强数据目前还有缺陷。可模拟的增强数据：第三类是可模拟的增强数据，按照模拟方式的不同又分为三阿里集团风控大脑关于大数据应用的探索与实践阿里集团风控大脑关于大数据应用的探索与实践任务调度Blink 无需太多任务调度，流量来了就处理，但离线批处理需要有任务调度。离线引擎的任务调度很大一部分是用 DataWorks 本身的调度，但也有一些场景没办法使用。目前离线引擎的任务分为两种。周期性任务：用户需要周期性的对一些增量或者全量的历史数据进行风险识别。周期性任务借助 DataWorks 的周期任务，因为它的周期任务管理已经做得很好，首先有完善的上下游依赖和调度，其次有丰富的调度参数配置，可以通过很多参数来控制调度。DataWorks 周期性任务的缺点是任务结构不建议经常刷新，如果经常刷新任务的上下游结构，可能导致任务调度出问题。比如昨天的任务今天还未调度，如果把调度链路改了，任务就可能有问题甚至报错。但在离线引擎中，为了让一次风控计算任务性能更好，需要将一个任务拆成多个任务，即多个 DataWorks 周期性任务来处理。比如会先用一个任务做预处理，然后多个任务并行做各种数据增强，之后再进行合并，最后做策略执行，如此一来时效性会很好，执行速度会更快。但是周期任务中这种任务链会在策略变更时需要经常去刷新，为了避免刷新带来的问题，现在将增强数据固定分成了几类，比如无论这一次离线任务里是否使用名单，先将名单增强任务生成好，将任务节点永远保留在任务链中，那么无论怎么刷新，最多是刷新其中的逻辑，而不刷新任务结构，从而让离线引擎任务可以随时更新。一次性任务：需要对历史数据做一次性回捞，不需要跑多次。一次性任务是利用DataWorks 中的触发式任务。触发式任务最大的问题是只支持单个任务做调度。因为一次性任务时效性很重要，用户做一次回捞不可能等几个小时，所以需要对任务进行更细致的分拆，分拆完成后在离线引擎里面自己实现调度，通过周期性轮询任务状态，自己完成任务依赖、任务调度等工作。阿里集团风控大脑关于大数据应用的探索与实践43四、总结阿里目前有三个引擎，实时引擎、近线引擎和离线引擎，其好处是用户能做的事情变得更多，能力变得更强，坏处是引擎增多，概念增多，用户理解和使用成本会变得更高。所以阿里在引擎设计之初坚持的原则是用同一套元数据，即引擎的元数据都是一样的，可以在最大层面上避免用户对引擎理解的不一致。其次，在很长时间甚至到现在，一直在做的事情都是尽量让引擎用到的是同一套数据。未来希望所有引擎有同一套风控语言，例如 S-SQL 或比 S-SQL 更成熟、更抽象的一种语言。这种语言可用于解释风控场景中的各种语义。如果有这样一套风控语言，风控用户对风险的描述、风险场景的落地会更加直观清楚。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践作者：林鸣晖友盟+首席产品官简介：对于所有企业来说，数据决定了基于算力、算法等能做出哪些场景和应用。在本次首席技术官大数据专享会上，友盟+首席产品官林鸣晖围绕业务数据化，数据资产化、资产应用化、应用价值化构建属于企业的可闭环、可沉淀、可持续的数据赋能体系进行分享，基于智能数据采集（U-SDC），用户数据平台（U-CDP），数据开放平台（U-DOP）探讨如何建立企业的数据银行。本次分享主要围绕以下两个方面：一、构建可闭环、可沉淀、可持续的企业级数据赋能体系的背景二、开发者数据银行一、构建可闭环、可沉淀、可持续的企业级数据赋能体系的背景1.数据“四化”如何让属于企业自己的不同触点的数据快速形成一个闭环，沉淀串联这些零散的数据能够快速应用去赋能业务？这涉及到四个关键词，一是业务数据化，企业所有触点是否为真，是否被打通。第二是数据资产化，能否可以像管理资产一样很好地管理数据。第三是资产应用化，企业的资产能否有效应用？如何借助数据资产赋能业务，最后是应用价值化。所有的应用最终一定是为增长、为获客而服务，必须要有价值。在这背后最重要的是场景必须可闭环，数据必须可沉淀，最终数据中台、数据能源才是可持续的。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践关广告的内容。二、开发者数据银行每一家公司都需要构建属于自己的数据银行。比如在阿里巴巴的生态体系内，阿里在双 11 当天有上百万商家卖货，很多品牌商家都在阿里构建数据银行。同样，友盟+在数据智能服务领域已深耕九年，凭借服务百万家互联网企业的经验，面向开发者推出开发者数据银行，与 MaxCompute 形成一套核心解决方案服务用户。数据银行需要解决几个问题：第一，数据银行解决数据资产的管理和应用的问题，可以用采、建、管、用四个字来表达。首先是业务数据化和数据资产化，如何采集数据，并快速将端的数据形成数据资产。其次是资产应用，形成多种消息的推送，营销的拉新，包括 App 的推送，各种运营推荐，都是在数据银行上能够提供的服务。数据银行包括三类产品，从三个角度帮助用户解决问题。如下图所示，第一个产品是智能数据采集（U-SDC），第二个用户数据平台（U-CDP），帮助企业沉淀数据资产，高效服务业务部门、运营团队、市场等团队。第三个是数据开放平台（U-DOP），将采集到的数据通过友盟云之上与业务数据进行融合、分析，更全面的洞察用户，更场景化的应用数据。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践埋点智能方案推荐：某家视频行业领域的公司的有两个团队，分别负责直播不同频道的业务，两个团队都会定义一些公司的埋点规范。但是数据规范性在两个团队不一致，如视频播放开始，A 团队定义埋点全局参数叫 Play，代表播放开始事件，B 团队将其定义为 Start。两个团队并不知道两个数据定义都不一致。案例中的问题看似不严重，但后续会发现公司数据不可持续，此时不论利用什么工具都不能解决问题。对于公司数据的管理一定要基于对业务场景的深刻理解，对业务场景进行标准、规范的定义。友盟+通过更多标准化的场景，包括为不同行业提供标准的埋点方案推荐来解决用户问题。友盟+聚合了非常多比较优秀的企业的实践，告诉用户如何埋点，埋点后能够解决哪些场景问题，同时会提供各种各样埋点智能推荐，针对技术团队沉淀公司基于场景的埋点解决方案的知识图谱。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践埋点健康度一键体检：当埋点全部完成，公司要做埋点健康度的验证，检查埋点是否符合规范，是否有异常点。埋点健康度是公司数据采集准确性的底座保证。数据团队和做客户端的开发团队经常会因为埋点问题产生矛盾。数据团队觉得数据有问题时一般归责为埋点问题，开发团队也会认为是数据团队配合问题。埋点的 KPI 就是先让埋点可视化，看到是由谁埋了哪个点，运行情况是否出现问题，是否按照规范埋点。如果埋点的规范度没有达到一定程度，团队是否应该承担责任？因此需要从管理角度、从组织层面以及产品能力层面解决公司埋点和采集的核心问题。数据银行采集平台（U-SDC）会重点解决以上几个核心问题，使用户埋点可见、可控、可管，为用户埋点推荐合适的优秀方案，使用户埋点能够智能调试和验证，大幅降低埋点采集的成本，从而最终达成数据质量的根本性提升，使最终保存的数据资产有价值有质量。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践是否清楚自己的用户资产：用户数据平台（U-CDP）支持多源数据如何在很短时间一键接入平台，如移动客户端、服务端、客户端等源头。U-CDP 保证可信识别和多端归一，通过全域数据识别，帮助用户做数据归一和提纯，过滤垃圾，反作弊。识别打通后最终形成用户资产可视化，清楚公司触点来源，了解多少私域用户被沉淀下来。清楚上述问题再分析需要建哪些触点，需要增强哪些触点。最终沉淀下来的才真正是自己的私域数据资产。沉淀私域用户资产的一个前提是可运营，若不可运营、不可见，那么数据是无用的。用户的标签管理库，配置即生产：业务团队总是对技术团队不满意，当运营团队要做一个活动，需要按照业务场景准备物料，准备活动的页面，还要再按照规则圈到一群想要触达的内存，然后对其进行运营。上述需求需要先和产品经理提需求，产品经理再去和算法、技术团队沟通然后写 PRD，再等待几天将活动开发上线。往往流程特别长，完全无法满足运营团队快速迭代、快速试错、快速运营客户的诉求。而运营团队的需求并没有那么复杂，如运营团队只是想给最近 30 天访问过 APP、看过小程序，同时这两天被广告命中的那部分人一个红包，但是很多企业面临技术排期。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践多种组合模式，找到想找的人：如某装修建材公司，有一个 Web 网站，起初是通过 Web 网站以及 QQ 与客户联络。后面该公司又发展了 APP 和小程序的团队。客户可能同时出现在三处，问题时数据不互通，并且组织是分开运营的。其实本质问题是能否在 APP 端快速发现小程序的客户，再去客户端做投放，运营和回流。友盟+结合多种模式，无需等排期，帮助运营能找到合适的人。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践一键数据包订阅返还：如下图所示，友盟云采集帮助客户快速采集移动客户端、服务端、客户端不同的平台等数据。如果客户自行加工单一的上述事情，处理时间会非常就且最终质量难以保证。基于 UMID 打通能力，多账号归一，多端归一，支持不同的终端数据打通，友盟+帮助客户做好加工，生成不同的数据包，只要客户使用 SDK，数据包自动生成，自动将数据传送到 MaxCompute 中。然后可以借助DataWorks、DataV、QuickBI 与客户的数据做数据融合，极大地降低成本。客户使用的不再是原始数据，而是经过友盟+加工处理过的数据。之后，用户就可以专注于业务产品的开发，业务场景的赋能，把精力放到业务创新而非原始的加工工作上。可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践可闭环、可沉淀、可持续的企业级数据赋能体系友盟云数据中台产品实践总结：无论企业有多么强大的容器、数据库和算法，或者要做多么智能的场景应用，一定要先回到四个关键词：第一是业务数据化，管理好采集和数据质量。第二是数据资产化，让管理层清楚的看到用户资产的具体情况，涉及多少个端，多少个触点，每天产生的数据，沉淀下多少用户。第三是资产应用化，沉淀下来的数据能够快速变成哪些应用去服务业务团队，使业务团队认为技术、数据是在促进帮助业务团队做创新，而不是业务团队等待资源去赋能。其中最根本的一套理念是必须让所有的触点和业务行为的环节能够产生场景和数据的闭环，让场景和闭环能够沉淀数据资产，只有这样才能使一个企业的数据中台可持续，数据赋能可持续，数据能源才会越用越厚，越用越好。MaxCompute 在高德大数据上的应用作者：苗翌辰(喵鹿)阿里集团 高德事业群 数据技术专家摘要：2019 年 1 月 18 日，由阿里巴巴 MaxCompute 开发者社区和阿里云栖社区联合主办的“阿里云栖开发者沙龙大数据技术专场”走近北京联合大学，本次技术沙龙上，高德数据技术专家苗翌辰为大家分享了高德如何应用 MaxCompute 来管理数据架构，开发易用、高效以及弹性的高德应用，为用户提供更优质的出行服务。一、高德的业务和数据地图描绘需要很多支撑数据，包括现实中的道路信息、路形以及路况等。下面的轨迹热力图展示了高德地图显示的北京联合大学的周边路况，描绘了点、线和面三种信息。通过地图信息和轨迹数据叠加形成区域热力。其中，不同颜色的轨迹展示了该区域一天内不同时间段的路况。60MaxCompute 在高德大数据上的应用下面展示了高德的一些业务场景。第一个场景是大家日常使用的高德 APP。高德地图是苹果中国的战略合作伙伴，第二个场景展示了高德为苹果提供的出行服务。高德向整个互联网行业开放了其生态能力，第三个场景是高德为 APP 应用开放者提供的位置服务接口，目前使用该接口进行开发的移动应用包括手机淘宝、今日头条和小米运动等。另外，第四个场景是高德为车载设备提供的完善的位置服务方案。高德地图的业务架构可以用“442 阵型”来形容，即分为客户端、中间层、服务引擎以及基础地理信息等 4 层，同时包含 AppleMaps、高