Flink + 强化学习搭建实时推荐系统

大家好，我叫许日花名欢伯，在2016年盒马早期的时候，我就转到了盒马的事业部作为在线数据平台的研发负责人，现在阿里云的计算平台负责DataWorks的建模引擎团队。今天的分享内容也来源于另一位嘉宾李启平（首义），他一直是盒马从初创到现在的数据研发负责人，有非常资深的数仓及数据中台建设的经验，之前也是阿里巴巴国际业务的数仓负责人。今天我给大家分享一下，盒马新零售基于DataWorks搭建数据中台的实践。

一、盒马的商业模式

大家做数据的话，首先很重要的一点就是一定要懂业务。之前有位同学问我，说数据中台很难建。在我们看来，数据是跟业务息息相关的，我们去构建整个数据中台的时候，首先要对业务有一个非常深刻的理解。盒马是近两三年阿里出现的一个新的业务，有一些同学应该体验过，包括北京、上海等中国一线二线的城市都覆盖了盒马鲜生的门店。

上图就是盒马商业模式的架构图，业务围绕主要是两点，一个是线上，一个是线下。盒马的业务虽然叫做O2O，但是比较有意思的一个点是，盒马的O2O跟早期的O2O是不一样的。以前O2O叫 Online to Offline，盒马的O2O是什么？是Offline to Online，目标要把线下的流量引入到线上，用线下的体验去让用户愿意到线上去购买，并且保证线下的品质跟线上的品质是一样的，不会出现线上是一个电商特供版，看似很便宜，但是你拿到的东西和线下是不一样的。

基于我们O2O的业务架构，同时盒马的客户群体是很有意思的。他们大部分是以家庭为单位的，就像我买盒马的时候，我的女儿、我的父母也都喜欢盒马，我是一个线上客户，可以在线上下单。那像老一辈他不会去用APP购物的时候，他就会到线下去购买，他买的东西是跟我一样的，包括我女儿，她可能不会购物，但是盒马有餐饮，她很喜欢去盒马吃海鲜，通过这种业务的闭环与传承性，来保证业务的发展与口碑。

盒马定了这种商业模式之后，需要开始构建它的业务架构，那么这个架构应该是什么样子？第一它要做线上线下的一体化，保证020的目标。同时确认了这是一个生鲜电商的业务，生鲜电商基本上跟传统的标品电商做了一个差异化的区分。第三个是多功能门店，能够融合销售展示、仓储、分拣、线上等业务形态。第四是限时配送：三公里30分钟，其实打破了之前电商平台引以为豪的当日达跟次日达这种物流，直到目前盒马这种限时配送在业界还是属于比较领先的。第五就是盒马的外卖，今天你非常想吃一个东西，但是你又不会做饭，盒马会帮你把这个东西做好，或者你会做菜，但是你不会杀鱼，或者是杀鸡之类的，盒马会帮你把这个做好，然后再帮你送过去。最后还有很重要一点，因为我们提到了门店的价值，盒马的门店不是传统的购物，它有一个仓的设置，刚才说的可以做线上和线下，你线下去看的是门店，对于线上来说他就是个仓。

二、盒马技术架构与原型

确定业务模式后，我们要做技术架构的设计。其实早期盒马有过一定的纠结，因为发现做零售，做门店，做商超，很多传统的软件厂商有一个现成的软件体系，比如说ERP、WMS。那我们是不是买一套就可以了？但是当时盒马是坚定了所有的产品技术的业务系统，包括数字化系统都要自建。因为盒马需要对很多传统业务做了一个全面的数字化，包括交易、门店、仓储、运配、采购、供应链、劳动力等等。

现在传统的ERP软件或者是物流软件，它也做了数字化，但是很重要区别是，我们做数字化不是只是为了简单的数字化，把数据结构化，更重要的是为上层策略层进行一个非常重要的支撑，我们对流量、物流履约、流程优化、财务策略进行了一个非常好的智能化的支持。在这里我可以稍微分享一下，我们之前也调研过一些线下有门店的大型零售商超企业，他们也做线上的APP，但他们的库存线上线下是隔离的，如果你总共有100条鱼，他会预先分配好，线上只卖10条，卖完之后线上就没有了，而盒马这100条是线上和线下先到先得，不会去分两拨。通过这种策略模式，基本上就把整个线下线上的数据和商品全部打通。

再一个很重要的一点，刚才讲的一些业务，你会发现在阿里的很多业务团队是分开的，比如菜鸟只负责物流，淘宝只负责营销和交易，目前整个经济体的业务都在走向融合。但是盒马为了去完成自己的业务闭环，所有的系统从交易门店、仓储运费、采购供应链、劳动力全部是自建，并且能让他们通过一个协同层把所有的业务打通，我们有生意计划、供应链管理、协同管理、全渠道多业态，并且提供了一个闭环的解决方案。

闭环中非常重要的一点是最右侧的一个数据层，如果没有我们统一的数据中台建设，是很难去支撑整个企业工程的，这也是我今天会重点跟大家介绍的这部分。

我们说到数据中台，其实在阿里巴巴，数据中台不仅是一个解决方案，它也是一个团队的职能，在盒马是有一个独立的数据中台团队去支持这块业务的。我们是把数据作为一种资产，跟盒马的商品、会员，包括设备是同样重要的。盒马数据中台的同学，他们是资产的建设者、管理者和运营者，并且要通过这些资产去驱动整个零售供应链全链路、智能化的升级。其中最主要的是我们会去采集、管理、建设这份数据，并且能让这份数据在业务上能更好的使用起来。

上图是盒马的数据平台的一个整体架构，这部分会有一定的特殊性，也有一些通用性。

首先说一下通用性，我们整个基础设施是跟阿里巴巴集团所有的部门是一样的，采用的是阿里云的基础设施，并且在整个数据分层这边，我们有源数据，源数据基本上都是来自于业务系统。接入层这边相对来说盒马会比较复杂一点，刚才说的盒马是全渠道，我们有APP，有线下，还有我们配送员的电动车，还有盒马内部的一些悬挂链、iot、APP、人力资源等，所以这里面就会出现很多结构化和非结构化的数据，我们通过数据加工层去把我们非结构化的数据进行一定的加工，最终会形成非常重要的数据资产层。

数据资产层构建之后就会有一定的业务含义，这部分数据是可以直接被业务去使用的。但是我们在这个数据资产层上又会去定一层数据服务，让数据使用起来会更方便，就是开箱即用。还有一块，到了服务这一层，他可能还是个无形的，之前有同学也问我，说今天我们希望业务用户能直接去用数据，而不是说去到很多表里面去查数据，这方面盒马用的是数据应用层，我们会建立很多数据产品，通过产品化的方式给业务去提供真正的数据使用。最后我们盒马这边产品形式会特别多，我们在不同的端通过PC、钉钉、掌中宝，还有很多iot的小设备，深圳可能就是一个小的黑白的屏幕，都会有数据的透传。并且在最右侧我们有一套管理体系，通过这种管理体系，让我们整个运营和运维可以有效地执行起来。那么这种架构图，就是盒马理解的一个偏业务型的数据中台分层架构图。

那么基于这种业务型的数据中台分层架构，我们又设计了一套数据中台技术架构。其实大家做过大数据的话，在数据采集的时候经常会碰到，我同时有离线和在线的计算，那么离线计算我们基于MaxCompute，阿里巴巴几乎所有的离线数据都放在MaxCompute上，2020年双11 MaxCompute每日数据处理量超过1000PB，达到EB级。实时计算我们是基于Flink，计算的性能也非常强大。还有一块是我们要去做数据的存储，存储里面其实盒马这边会比较重地依赖在线存储，譬如说Lindorm就是kv，还有MMaxCompute交互式分析（Hologres）以及在线搜索Elasticsearch，并且我们会把这些存储变成一个个数据服务。数据服务的话就会有指标明细，还有特征、标签等等，这些数据我们会推广到运营最常使用的一些设备、运营平台、钉钉移动办公、智能化管理等，这些更多是runtime层面的。我们在整个集市运营层面，有元数据、数据质量、容灾管控、数据治理等等。这个技术架构图，我们更多的是当成一个技术需求架构图，是我们技术团队在做数据中台的时候需要去做的一些事情。

三、盒马基于DataWorks的数据中台方案

当我们盒马的商业模式，业务产品技术架构，以及数据中台的技术需求整理之后，我们要开始做一个数据中台的技术选型，或者是做一个技术调研，什么样的产品什么样的系统可以去支撑我们整套技术架构。之前说到我们的业务系统是自研的，但我们整个数据中台的技术盒马最终选择是不自研，因为阿里云上已经有非常成熟的产品体系让我们去构建盒马自己的数据中台。大数据计算引擎我们使用的是集团一直在使用的MaxCompute，那么构建数据中台的数据开发与治理工具我们做了调研，最终选择了DataWorks，下面就是DataWorks的整体架构图：

DataWorks对外提供了数据集成，它有很多这种批量、增量、实时、整库的数据集成，能够支持盒马这么多且复杂的数据源，目前DataWorks数据集成离线支持50+种数据源，实时支持10+种数据源，无论数据源在公网、IDC、VPC内等环境，都可以做到安全、稳定。灵活、快速的数据集成。DataWorks还有一套元数据统一管理服务，支持统一的任务调度、同时提供了非常丰富的一站式的数据开发工具，覆盖了数据开发的整个生命周期表，极大地提高了我们的数据开发效率。上层还包括了数据治理、数据服务等，并且它提供了很重要的开放平台。因为之前说到盒马是一个非常独立、丰富的业务，很多业务系统都是自研的，有自己的研发团队，我们需要通过DataWorks OpenAPI对很多功能做一个二次的加工以及和各种自研系统、项目系统的集成，目前DataWorks提供的100多个OpenAPI可以让我们非常简单地去实现这个需求。

那么我们再看一下这个数据中台技术需求图，我们去跟DataWorks做一个比对，数据采集部分对应了DataWorks提供的数据集成，基本上我们左边的这些数据同步的需求DataWorks都可以满足。

还有我们做数据开发，在数据开发层，DataWorks通过它的DataStudio、HoloStudio和StreamStudio可以同时完成我们的流、批、实时的开发，并且它还提供了数据服务跟开放接口的功能，可以通过OpenAPI的方式跟我们现有的系统和产品做一个集成，还有很关键的一点，DataWorks提供了数据地图和数据治理的能力，这两个功能看似是边缘功能，但是在我们盒马甚至在阿里巴巴起到了一个非常关键的作用，这块我们后面会继续展开。

前面我们更多地可以看成是数据中台的准备过程，我们了解了业务，做了设计，并且做了一个技术选型，那么接下来在阿里做事情很重要一点就是做之前要确定一个明确的目标，目标不代表KPI，他也有可能是一个使命或者初衷。盒马数据中台的目标是什么？盒马的数据中台是要建立一个数据丰富，全链路多维度，质量可靠（就是口径要标准，结果要准确），并且要运行稳定，产出及时无故障的一个中间层，很多人会说这是个数据集市，没关系，它就是个中间层。还有很重要一点是我们要为上层业务提供可靠的数据服务，数据产品及业务应用，其实这就限定了它不是一个简单的数仓，也不是一个简单的数据集市，而是一个数据中台，是可被业务去不断使用的数据中台。如果我们只是把数据同步加工，放到MaxCompute或者开源的Hadoop或者一个数据库里面，那他还只是个仓。数据中台我们定义是可被业务直接去使用的，甚至是要给业务带来业务价值的，才叫数据中台。

定义这样一个目标之后，我们要开始做一个分步拆解，我们主要做什么？首先要做一个指标体系的设计，因为业务去使用不是一个表的字段，需要有一个数据模型设计的支撑，让我们去把数据变得更标准，并且我们还要去做数据处理任务的开发。今天我们有一些智能化构建数仓的方式，但这可能更多的是一个未来，现在我们不得不面临一个问题，我们还是靠人工靠人肉去做数据开发。并且我们要把这些数据通过数据服务的方式开放出去，让业务去使用，数据服务的形式不限于 Table、API和Report，甚至是一个产品或者其他的任何一个东西。

上图可能是大家在网上看到最多的关于数据模型或者数据集市构建的分层图，那就是老生常谈，ODS、DWD、DWS和ADS。其实虽然有很多概念和理念，但是每个人对这层的理解是不一样的，盒马有一套自己非常严格清晰的定义，每一层要有每层自己的一个特点和职责。简单概述的话，ADS一定要是面向业务的，不是面向开发的，你这部分数据让业务能最短的时间去理解，甚至直接使用，还有DWS必须是指标，也是我刚才前面讲的指标体系的一个承载体，都由DWS去做，DWS汇总基本上就是ADS的支撑。还有一层是DWD，就是我们经常说的明细层，明细层怎么建呢？我们采用的是维度建模的方式，我们有维表，有事实表，那维表也有很多层级维度，比如枚举维度，事实表我们有周期快照。当然在这里有一个很重要的点，DWD的字段必须是可被直接理解的，不要有二义性，一旦有二义性的时候，DWS使用的时候会有问题，会导致整个上游应用都有问题。ODS基本上大家理解应该都保持一致，就是业务数据直接同步过来。但是现在有一些架构的演变，大家喜欢在ODS做一个初步的ETL处理，这样会导致ODS的数据跟我们业务的数据不一致。其实在盒马是不允许这样做的，原因很简单，我们要保证我们的ODS跟业务库是保持一致的，这样当我们出现问题的时候，我们能很快定位到问题的原因。一旦做了ETL，有可能ETL的过程是有bug的，会导致两边数据不一致。所以盒马是严格要求从业务库的数据到ODS是不允许做任何的逻辑的处理。如果出现问题，只能是中间件或者是其他的任何存储出了问题导致的，不应该是业务逻辑导致的。

四、盒马基于DataWorks构建数据中台

前面更多的是讲盒马这边的一些数据中台建设的思想、设计、架构和一些目标及要求，接下来我会去讲盒马如何使用DataWorks构建数据中台以及在使用DataWorks平台的一些心得。DataWorks这个平台不仅仅是给盒马用的，还有阿里巴巴集团几乎所有的业务部门，每天集团内部有数万名运营小二/产品经理/数据工程师/算法工程师/研发等在使用DataWorks，同时DataWorks还服务大量阿里云上的用户。所以它的设计很多是偏向于开放的、通用的、灵活的。这个时候我们在使用的时会导致一些过于灵活或者是没有标准出现等一系列的问题，后面的内容就会针盒马的一些经验和大家分享当时的一些心得。

首先数据同步是建数据中台的第一步，如果数据进不了仓，那么数据中台就没办法构建。盒马在做数据同步的时候，会有几个要求，比如盒马的所有业务数据都是统一同步到一个项目，并且只同步一份，不允许重复同步，这样的话方便我们管理，减少成本，同时保证了数据不要有二义性。数据源出问题了，那后边数据就都有错，所以我们一定要保证数据源100%正确。然后从数据回溯与审计考虑，数据生命周期设置的是一个永久保存，哪怕业务系统因为一些线上库的流量问题，会有一些归档、删除，但当他们想再使用历史数据的时候，可以通过ODS这层原封不动地再还原回去。

第二块就是数据开发，数据开发这部分基本上是很考验个人能力的，基本上大家都是使用SQL。我们对于数据开发这部分是有一定的心得，简单来说就是数据处理过程是业务逻辑的实现，既要保证业务逻辑的正确性，也要保证数据产出的稳定性、时效性和合理性。DataWorks进行数据开发的编辑器，除了提供了比较好的coding能力以外，也提供了一些处理流程的可视化的方式，帮助我们去做一些code review，甚至一些校验，这个功能在我们日常使用中是非常有帮助的。

整个数据开发的过程，因为我本身也是做 Java的同学，我们知道每一种编程都有一定的编程范式，我们在整个数据开发的过程中也去抽象了几个步骤，首先是一个代码转换，这个代码转换主要是干什么用的？刚才讲过业务系统很多是为了完成一个业务流程，它有很多这种个性化的处理，尤其是大家做互联网，为了解决一些性能问题或者是filter的问题，会做一些Json字段，媒体字段、分隔符等等，这样的内容会出现二义性。我们在开发中会有个代码转换，比如说把一些枚举的东西转成一个实际会看得懂的东西，譬如说0到底是什么？2是什么？或者a是什么？我们会做代码转换。还有个格式转换，我们有一些业务系统，它很难标准，譬如说时间，有的是用的是timestamp，有的是存字符串，有的是存yymm这些，虽然它们都代表时间，但是格式不一样，在数据集市的构建过程中，它一定要求里面的数据格式必须是一致的，我们会去把非标准的数据格式通过格式转换的方式变成一个标准的格式。

还有一个是业务判断，业务判断这里边基本上就是通过条件的方式得出一个业务结果。举个例子，年轻人在业务系统里面肯定不会算一个叫“年轻人”这样的字段或业务逻辑，如果有年龄数据，那么我们在梳理的时候会说小于30岁的我们叫年轻人等等，这个就是我们说的业务判断。数据连接这块，基本上很简单，就是一个表关联去补数据。另外一个数据聚合，我们在做DWS的时候会大量用到数据聚合的这部分。还有数据过滤，我们经常会碰到一些无效的数据，我们通过数据库这个方式把这些无效的数据给处理掉。再一个是条件选择，这个条件选择基本上也就是一些when的东西，跟数据过滤稍微有点相似。最后是业务解析，其实业务解析是我们最经常用到的，因为现在NoSQL或者是MySQL也支持了，甚至有一些业务团队用了Mongo，那一个大字段里边有很多业务表示，我们这几年在数据集市做DWD的时候，一定要把这种Json字段或者map字段的格式全部解析成固定的列字段。因为刚才我们说过它的内容必须要一致的，让用户直接可以看到。在这里面分享个心得，就是业务逻辑会尽量收口在数据明细层，目的是保证数据的一致性，简化下游使用。源头上的变化，也可以通过代码或格式等转换，保证明细层结构的稳定性，避免给下游带来更多的变化。好的模型也需要上游业务系统协同开发，一要业务系统有合理的设计，二要变更能及时的感知，就是说数据中台的建设不是数据团队一个团队的事情，也要跟业务团队去做一个联动和共创。

刚才讲的这些部分更多的是开发阶段，如果DataWorks只完成这些的话，我们认为它就是一个IDE，但是DataWorks是一个一站式大数据开发治理平台，开发平台很重要一点是它要去保证它的运行，如何去保证我们做数据开发的代码能运行起来？就是通过DataWorks的任务调度。盒马的业务是非常复杂的，有30分钟送达，还有次日达、三日达，还有一些预售预购等等。这些如果是简单的调度系统可能就支持不了，DataWorks这边比较好的一点是，它提供了非常灵活的任务调度的周期选择，比如说月、周、日。盒马的业务是一个闭环，他每个业务是有相关性的，那么反过来盒马的数据任务也是有相关性的，这个时候整个盒马的任务调度链路是非常复杂的。

在整个过程里面，盒马也有很多尝试、创新，也踩过了很多坑，这边就给大家分享一下，就是DataWorks任务节点未起调或者在错误的时间起调都可能出现数据缺失或者是错误。这里就要保证我们数据开发对于每个线上任务的任何问题都要及时处理，因为每个问题都会造成一个数据的问题。合理的调度策略既可以保障数据产出的正确性，也可以保障数据产出的及时性。我们希望他一天产出，那就不要把它变成一小时，我们就按一天就可以了，如果三天就是三天。

通过这几步，正常情况下，就是我们一个项目或者一个需求，按照这种方式去完成，我们认为一个数据开发工程师的任务就结束了。但是一般情况下不是这个样子的，因为数据中台是一个偏商业化的事情，所以说它一旦出问题，在阿里的话，影响是特别大的。业务线它有核心系统、非核心系统，部门核心系统、集团核心系统，通过这种方式有不同的保障，还有业务团队有p1、p2、p3、p4的方式去定义故障总级。数据业务跟正常业务系统不太一样，我们这边是依托了DataWorks来去做整个线上大数据业务任务的稳定性保障。其中DataWorks这边提供了很重要的一个模块，就是数据质量监控。数据质量监控其实我们更多的是能及时去发现一些问题，保证当业务有影响的时候，我们第一时间就知道。因为有的时候业务使用还是有一定的延迟性的。这里面提供了很多能力，比如说数据质量的一些监控，数据质量监控的目的是保障数据产出的正确性，并且监控范围一定要比较全，不仅限于表大小的变化，函数的变化，字段枚举值和一些主键的冲突，甚至一些非法格式，并且很重要一点就是异常值会触发报警或中断数据处理过程，然后值班人员要第一时间介入。

上面讲的是监控的问题，但是一旦监控很多就会导致监控泛滥，会有很多预警报警出来，那么DataWorks也提供了另一种能力，就是任务基线的管理。我刚才讲过业务有分级，我们线上业务也有一些重要性和非重要性的任务，我们通过这种基线的方式去把这些任务进行一个隔离。基线这边盒马的经验就是：基线是保障数据资产的及时产出，优先级决定了系统硬件资源的保障力度，也决定了运营人员值班的保障力度，最重要的业务一定要放8级基线，这样会保证你的最重要的任务第一时间产出。并且DataWorks有一个很好的功能，DataWorks提供了一些回刷工具，当我的基线出问题或者破线的时候，可以通过回刷工具快速地把数据回刷出来，并且DataWorks智能监控功能会通过一些基线下的任务状态和历史的运行时长等，去帮你提前预估出是否存在破线的风险，这种智能化地监控与风险的预估还是非常有用的。

那么做好数据质量的监控跟基线，基本上就保证了我们的大数据任务和业务的稳定、正常地运行，但是还有很重要的一点就是数据资产的治理。阿里巴巴是提倡数据的公司，它做转变的一个非常大的里程碑就是阿里巴巴在数据方面的存储和计算的硬件成本超过了业务系统的硬件成本。这也导致了阿里巴巴的CTO会去把数据资产治理作为它的一个非常核心的任务。DataWorks是整个阿里巴巴集团数据使用的体量最大的平台，甚至是一个唯一的平台，而且也提供了数据资产的模块叫UDAP，这里面基本上是可以通过多方面多维度，从项目到表甚至到个人，全局查看今天整个资源使用情况是什么样的，并且很重要的一点是给你提供了一个健康分的概念。这个健康分可以综合地看到每个业务部门内每个个人的排名情况。做治理最简单的方式就是先把头部打掉，阿里是这么做的，先治理头部健康分最低的，然后把健康分拉上来，整个水平就下来了。并且它提供了很多数据可视化的工具，可以让你很快的看到治理的效果。盒马在这方面做的一些心得：主要目标是优化存储与计算，降低成本，提升资源使用率；技术团队会建很多项目空间，我们需要与技术团队共建，一起去完成数据治理。盒马一些比较好用的手段就是无用的应用要下线、表生命周期管理、重复计算治理、还有很重要的是计算资源暴力扫描，我们是严格禁止暴力扫描的。UDAP里面的一些功能我们现在在DataWorks的资源优化模块也能够实现，比如一些重复表、重复数据开发与数据集成任务等。

做完以上这些，我们认为数据中台该做的事情就差不多了，最后还有很重要的一点就是数据安全管理。随着互联网的发展，中国应该是持续基本上每一年都会出一个相关的网络法，比如说电子商务法，然后还有网络安全法等等，然后最近应该是草拟数据安全法。作为一家企业，对法律的遵守是特别重要的。DataWorks作为阿里大数据最统一的一个数据入口和出口，做了很多这种数据安全管理的手段，它可以从引擎层面进行一个管控，并且通过项目层面进行管控，同时可以到表层面，甚至到字段层面，在字段层面，每个字段它有等级，比如说有一些字段的等级是必须要到部门负责人或者是总裁层面才可以审批通过的，再比如说有一些我们认为即使审批通过了，它也有一定的风险的时候，比如说身份证号码，手机号码等，我们会提供一种技术叫数据脱敏，这个数据被拿走是被脱敏过的，不影响你的统计或者分析，但是你不可见。

盒马在数据安全治理这边基本上跟集团是比较类似的，阿里巴巴集团有一套统一的数据管理方法，它是跟组织架构打通的，我们员工离职或者转岗，他的权限会自动收回。在任何企业包括阿里，他的人员变动是非常频繁的，通过这样的功能与体系，我们在保证数据安全的前提下去更好地应用数据。

五、盒马基于DataWorks构建数据中台的价值

之前讲的都是基于DataWorks来构建盒马的数据中台，最早提到数据中台一定要是服务业务的，我现在也介绍一下盒马的数据中台是如何为业务服务。很有幸我跟首义是见证了盒马从0到1再到N家店快速发展的一个过程，一家企业它用数据的过程也是这样由浅而深的过程。首先大家都一样，最开始我只是看数据，我有什么数据，然后通过数据去看一些问题，做一些人工的辅助和决策，但是盒马它的扩张是特别快的，最多的时候一年开了100家店，当它的业务形态发生变化，通过简单的数据报表和数据可视化，是无法再支撑这个业务了。所以说我们也做了很多精细化的管控，比如说品类诊断、库存健康，告诉这个业务你现在有哪些问题，而不是让他们用报表去做再去发现问题。

那么还有一块是盒马跟电商非常不一样的点，它是属于新零售，零售受自然因素的影响特别大，譬如说天气或者是节假日，甚至一个交通的事故都会影响到盒马的业务。我们针对这种情况，有很多这种预测类的应用，比如销量预测。盒马的销量预测是要求到小时，每个小时都要做迭代，还有一些仿真系统，当我出现什么问题的时候，我通过仿真系统预测到或者感知到有什么样的风险。最后还有很重要的一点就是说预测完，盒马的业务刚才讲过，它有限时预约30分钟送达，以及因为大家买过盒马的日日鲜商品，就是商品当天就要卖出，这些情况靠人是绝对没有办法去感知的。盒马的CTO提过，他要求我们把几百张报表全部干掉，把这些所有通过人看数据发现问题的场景，全部集中到业务系统里面。譬如说日日鲜，当我们发现商品已经卖不出去了，只有三个小时了，需要一个打折，不需要人参与，通过我们的数据的预测，跟这个算法自动去触发打折，把这个商品卖出去。我在阿里接近10年，盒马这些应用其实应该是为数不多真正地把BI跟AI结合在一起的数据中台的应用。

以上就是本次分享的全部内容，谢谢大家。

原文链接
本文为阿里云原创内容，未经允许不得转载。

Flink + 强化学习搭建实时推荐系统相关推荐

《强化学习周刊》第6期：强化学习应用之推荐系统
No.06 智源社区强化学习组强化学习研究观点资源活动关于周刊强化学习作为人工智能领域研究热点之一,它在推荐系统领域中的应用的研究进展与成果也引发了众多关注.为帮助研究与工程人 ...
基于深度强化学习的长期推荐系统
A deep reinforcement learning based long-term recommender system 基于深度强化学习的长期推荐系统 ABSTRACT 推荐系统旨在最大化长 ...
乔治亚理工提出基于GAN的强化学习算法用于推荐系统
Generative Adversarial User Model for Reinforcement Learning Based Recommendation System Xinshi Chen ...
DRN——强化学习与推荐系统结合
强化学习是近年来机器学习领域非常热门的研究话题,它的研究起源于机器人领域,针对智能体在不断变化的环境中决策和学习的过程进行建模.在智能体的学习过程中,会完成收集外部反馈,改变自身状态,再根据自身状态 ...
推荐系统强化学习DRN
文章目录强化学习的基本概念强化学习推荐系统框架强化学习推荐模型的特点深度强化学习推荐模型中的DQN DRN的学习过程 DRN竞争梯度下降算法强化学习的基本概念强化学习的基本概念就是一个智能 ...
强化学习在推荐系统中的环境模拟器构建
文章目录 1.背景 2.<Toward Simulating Environments in Reinforcement Learning Based Recommendations> 2 ...
推荐系统中的前沿技术研究与落地：深度学习、AutoML与强化学习 | AI ProCon 2019...
整理 | 夕颜出品 | AI科技大本营(ID:rgznai100) 个性化推荐算法滥觞于互联网的急速发展,随着国内外互联网公司,如 Netflix 在电影领域,亚马逊.淘宝.京东等在电商领域,今日头 ...
推荐系统遇上深度学习(十五)--强化学习在京东推荐中的探索
强化学习在各个公司的推荐系统中已经有过探索,包括阿里.京东等.之前在美团做过的一个引导语推荐项目,背后也是基于强化学习算法.本文,我们先来看一下强化学习是如何在京东推荐中进行探索的. 本文来自于pap ...
强化学习算法在京东广告序列推荐场景的应用实践
猜你喜欢 0.淘宝首页猜你喜欢推荐建模实践 1.[免费下载]2022年3月份热门报告 2.[实践]小红书推荐中台实践 3.微信视频号实时推荐技术架构分享 4.对比学习在宽狩推荐系统中的应用实践 5.微 ...

Flink + 强化学习搭建实时推荐系统

Flink + 强化学习搭建实时推荐系统相关推荐

最新文章

热门文章