文章作者：许日（欢伯），在2016年盒马早期的时候，转到盒马事业部作为在线数据平台的研发负责人，现任阿里云计算平台DataWorks建模引擎团队负责人。
文章简介：本篇文章向大家分享新零售企业如何基于DataWorks搭建数据中台，从商业模式及业务的设计，到数据中台的架构设计与产品选型，再到数据中台搭建的最佳实践，最后利用数据中台去反哺业务，辅助人工与智能的决策。
内容贡献：李启平（首义），盒马从初创至今的数据研发负责人，有非常资深的数仓及数据中台建设的经验，原阿里巴巴国际业务数仓负责人。
一、新零售的商业模式
一家新零售企业如果要做数据中台的话，首先很重要的一点就是一定要懂业务。之前有位同学问过我，说数据中台很难建。在我看来，数据跟业务是息息相关的，在构建整个数据中台的时候，首先要对业务有一个非常深刻的理解。
新零售企业会有各种各样的业务形态，例如线上电商平台、线下门店、官方APP、分销渠道、供应链等等，我们没必要在一开始就要求把所有渠道的数据都收集起来，做大一统，就是做数据中台了。我们在最开始需要了解的是整个企业的商业模式是什么，基于商业模式，我们再来定义需要做的业务形态，最后的事情才是开始规划企业新零售数据中台的建设。在这里可以给大家举个例子。
例如比较多的新零售企业原先是以线下门店为主的，现在会做一些线上APP或者电商业务，但是它线上的库存和线下的库存是不同步，或者电商的款式和线下的款式是不一样的。那他的商业模式其实还是传统的零售业务，只不过开了另外一条线上的业务。数据中台首先需要的是打破企业原先的商业模式，设计一个真正线上线下融合的业务形态，所以我们经常说数据中台是企业一把手工程。
确定了商业模式之后，新零售企业的业务形态也有很多，大家都在做不同的尝试，例如一些生鲜业务会有XX分钟限时达、有线下门店的企业会把线下流量导入到线上，同时把线下门店当做线上入口的一个仓、也有企业线上购买后可以到线下门店提货，保证线上线下同款同价等等。当确定了这些业务形态后，我们再来聊数据中台如何去支撑这些业务，通过数据的打通来完成整个商业模式的闭环。
二、新零售企业产品技术架构设计
确定业务模式后，接下来需要做纯产品技术架构的设计。这时候许多零售的企业会比较纠结，因为发现做零售、门店、商超，很多传统的软件厂商有一个现成的软件体系，比如说ERP、WMS，对于企业来说是不是买一套就可以了？
现在传统的ERP软件或者是物流软件，有一些也做了数字化，但是很重要区别是，数据中台做的数字化不只是为了简单的数字化、把数据结构化，更重要的是为上层策略层做一个非常重要的支撑，让数据中台对流量、物流履约、流程优化、财务策略做一个非常好的智能化的支持。在这里可以稍微分享一个例子，我们之前也调研过一些线下有门店的大型零售商超企业，他们也做线上的APP，但他们的库存线上线下是隔离的，如果总共有100条鱼，APP内会预先分配好，线上只卖10条，卖完之后线上就没有了，而拥有数据数据中台之后，这100条鱼线上和线下先到先得，同时可以通过算法预测做库存预警、做折扣、做交叉销售、做供应链调整等等，比起粗暴地分成两拨，数据中台通过这种策略模式，基本上就把整个线下线上的数据和商品全部打通，也重构了一些业务形态，所以我们说数据中台不是简单地把数据结构化。
企业如果有一定技术能力的话，建议所有核心业务系统都采用自研的形式，因为新零售企业需要对很多传统业务做一个全面的数字化，包括交易、门店、仓储、运配、采购、供应链、劳动力等等。如果外部采购的话，基于商业模式出发，一定要让系统形成闭环，从交易门店、仓储运费、采购供应链、劳动力等等，不要APP、门店、电商都不同的系统，那样你做数据中台的时候，数据本身的壁垒就已经很高了。
完成整个闭环中非常重要的一点就是最右侧的数据层，除了业务系统的设计，如果没有统一的数据中台建设，是很难去支撑整个企业工程的，这也是今天会重点跟大家介绍的部分。
在我们看来，数据中台不仅是一种解决方案，也是一个团队的职能。企业应该建设一个独立的数据中台团队来支持业务。对于企业来说，数据和商品、会员以及设备一样，是非常重要的资产。企业数据中台团队的同学，是资产的建设者、管理者和运营者，通过这些资产去驱动整个零售供应链全链路、智能化的升级。通过采集、管理、建设数据，让数据更好地运用到业务上。
上图是比较通用的数据中台的整体架构，这部分会有一定的特殊性，也有一些通用性。
首先介绍一下通用性，整个基础设施的建设基本采用的是阿里云的基础设施，阿里云上的DataWorks+MaxCompute十一年来一直支持阿里巴巴集团数据中台的建设。在整个数据分层这边，源数据层基本上来自于业务系统，接入层相对来说会比较复杂一点，很多企业现在讲全渠道覆盖，包含APP，线下，甚至一些企业还有自己的配送员、电动车，以及门店的一些IOT设备数据，人力资源等，所以这里面就会出现很多结构化和非结构化的数据。通过数据加工层把非结构化的数据进行一定的加工，最终会形成非常重要的数据资产层。
数据资产层构建之后就会有一定的业务含义，这部分数据是可以直接被业务使用的。但是在数据资产层上我们会定一层数据服务层，让数据使用起来更方便，开箱即用。到了服务这一层，可能还是无形的，从业务方来看，肯定希望业务用户能直接去用数据，而不是去到很多表里面查数据。所以在数据服务层之上的数据应用层，数据中台团队可以建立很多数据产品，通过产品化的方式给到业务，提供真正的数据使用。产品形式也会比较多，在不同的端，包括PC、钉钉、掌中宝，还有很多IOT的小设备，可能就是一个小的黑白屏幕，都会有数据的透传。并且在最右侧数据中台会有一套管理体系，通过这种管理体系，让企业整个运营和运维可以有效地执行起来。这个架构图，就是我们理解的一个偏业务型的数据中台分层架构图。
基于刚才提到这种业务型的数据中台分层架构，我们需要继续设计一套数据中台的技术架构。大家如果做过大数据的话，在数据采集的时候经常会碰到，同时有离线和实时的计算该怎么办？离线计算我们推荐阿里云上的MaxCompute，阿里巴巴几乎所有的离线数据都放在MaxCompute上，2020年双11 MaxCompute每日数据处理量达到1.7EB级。实时计算我们推荐Flink，峰值每秒处理消息规模达到40亿条，计算的性能也非常强大。除了计算，还要去做数据的存储，比如实时计算Flink的数据汇总加工后，可以存储到MaxCompute交互式分析（Hologres），来构建我们的实时数据仓库，MaxCompute交互式分析（Hologres）可支持的峰值写入速度达到5.96亿条，同时支持PB级数据的亚秒级查询，以及在线搜索Elasticsearch，并且这些存储都会变成一个个数据服务。数据服务会有指标明细，还有特征、标签等等，这些数据可以推广到运营最常使用的一些设备、运营平台、钉钉移动办公、智能化管理等，这些更多是runtime层面的。在整个数据集市运营层面，还有元数据、数据质量、容灾管控、数据治理等等。这个技术架构图，更多的是当成一个技术需求架构图，是新零售企业技术团队在做数据中台的时候需要去做的一些事情。
三、基于DataWorks的新零售数据中台解决方案
当企业的商业模式，业务产品技术架构，以及数据中台的技术需求整理之后，我们就要开始做一个数据中台的技术选型与技术调研，什么样的产品什么样的系统可以去支撑新零售企业整套的技术架构。之前说到企业的业务系统我们建议是自研，但整个数据中台的技术其实是可以不自研的，因为阿里云上已经有非常成熟的产品体系让我们的新零售企业去构建自己的数据中台。刚才我们说到了大数据计算引擎的选型，离线数仓可以选择MaxCompute，实时数仓可以选择实时计算Flink+MaxCompute交互式分析（Hologres），这三个产品同时可以无缝组合构建一套完整的实时离线一体化数据仓库，构建数据中台的数据开发与治理工具可以选择DataWorks，DataWorks服务了阿里巴巴集团几乎所有的业务部门，每天集团内部有数万名运营小二/产品经理/数据工程师/算法工程师/研发等都在使用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这个平台不仅仅服务阿里云上的客户，从2009年开始就同时服务阿里巴巴集团几乎所有的业务部门。所以它的整体产品设计很多是偏向于开放的、通用的、灵活的。这个时候企业在使用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比较好的一点是，它提供了非常灵活的任务调度周期选择，比如说月、周、日，并且能够支持双11每日1500万任务的稳定调度，从调度周期灵活性和稳定性来看都非常好。最开始我们设计企业的新零售业务是一个闭环，它每个业务是有相关性的，反过来说企业的数据任务也是有相关性的，这个时候整个的任务调度链路是非常复杂的。
在整个过程里面，我们也有很多尝试、创新，也踩过了很多坑，这边就跟大家分享一下。DataWorks任务节点未起调或者在错误的时间起调都可能出现数据缺失或者是错误，这里就要保证企业数据开发对于每个线上任务的任何问题都要及时处理，因为每个问题都会造成一个数据的问题。合理的调度策略既可以保障数据产出的正确性，也可以保障数据产出的及时性，我们希望一天产出，那就不要把它变成每小时产出，产生12次，就按一天就可以了，如果是三天我们就设置三天的调度。
通过这几步，正常情况下，我们的一个项目或者一个需求，按照这种方式去完成，我们就认为一个数据开发工程师的任务结束了。但是一般情况下不是这个样子，因为数据中台是一个偏商业化的事情，所以说它一旦出问题，影响是特别大的。如果说集团有集团核心系统，部门核心系统，业务线有核心系统、非核心系统，不同的核心系统需要有不同的保障，还有p1、p2、p3、p4的方式去定义故障等级，数据业务也同理。数据业务跟正常业务系统不太一样的是，数据中台团队是依托了DataWorks来做整个线上大数据业务任务的稳定性保障。其中DataWorks这边提供了很重要的一个模块，就是数据质量监控。数据质量监控可以让企业更及时地去发现一些问题，当业务有影响的时候，保证我们第一时间就知道（因为有的时候业务使用还是有一定的延迟性的，数据团队经常遇到的就是业务出现问题过来找你才知道）。数据质量的监控，目的是保障数据产出的正确性，并且监控范围一定要比较全，不仅限于表大小的变化，函数的变化，字段枚举值和一些主键的冲突，甚至一些非法格式，并且异常值会触发报警或中断数据处理过程，这时候值班人员要第一时间介入。
上面讲的是监控的问题，但是一旦监控多了就会导致监控泛滥，会有很多预警报警出来，DataWorks也提供了另一种能力，就是任务基线的管理。我刚才讲过业务有分级，企业的数据业务也有一些重要和非重要的任务，我们通过这种基线的方式去把这些任务进行一个隔离。基线这块我们的经验就是：基线是保障数据资产的及时产出，优先级决定了系统硬件资源的保障力度，也决定了运营人员值班的保障力度，最重要的业务一定要放8级基线，这样会保证你的最重要的任务第一时间产出。另外DataWorks有一个很好的功能——回刷工具，当我的基线出问题或者破线的时候，可以通过回刷工具快速地把数据回刷出来。并且如果你设置了DataWorks的智能监控，这个功能会通过一些基线下目前的任务状态和历史的运行时长等，通过算法的形式去帮你提前预估出是否存在破线的风险，比如一个数据正常是晚上12点产出的，在这之前有个数据应该是晚上6点产出，设置完智能监控之后，如果之前晚上6点产出数据的任务在今晚7点都未产出，并且系统通过算法判断晚上12点依旧无法正常产出，智能监控在7点的时候就会发出一个告警，让技术同学进行提前干预，不用等到晚上12点数据真正产出延时时才开始干预，这种智能化的监控与风险的预估对于企业业务的稳定性来说是非常有用的。
做好数据质量的监控与基线，基本上就保证了企业的大数据任务和业务的稳定、正常地运行，还有就是数据资产的治理。阿里巴巴是提倡数据的公司，它做转变的一个非常大的里程碑就是阿里巴巴在数据方面存储和计算的硬件成本超过了业务系统的硬件成本。这也导致了阿里巴巴的CTO会去把数据资产治理作为非常核心的任务。DataWorks是整个阿里巴巴集团数据使用的体量最大的平台，甚至是一个唯一的平台，也提供了数据资产的模块叫UDAP，这里面基本上是可以通过多方面多维度，从项目到表甚至到个人，全局查看今天整体资源使用情况是什么样的，并且给使用者提供了一个健康分的概念。这个健康分可以综合地看到每个业务部门内每个个人的排名情况。做治理最简单的方式就是先把头部打掉，我们先治理头部健康分最低的，然后把健康分拉上来，整个水平就下来了。同时UDAP提供了很多数据可视化的工具，可以让你很快地看到治理的效果，在这方面我也有一些心得分享给大家。
首先主要目标是优化存储与计算，降低成本，提升资源使用率；技术团队会自己建很多项目空间，数据中台团队需要与技术团队共建，一起去完成数据治理。一些比较好用的手段就是无用的应用要下线、表生命周期管理、重复计算治理、还有很重要的是计算资源暴力扫描，是需要被严格禁止的。UDAP里面的一些功能目前在DataWorks的资源优化模块也能够实现，比如一些重复表、重复数据开发与数据集成任务的治理等等。
做完以上这些，我们认为数据中台该做的事情就差不多了，最后还有一点就是数据安全管理。随着互联网的发展，中国基本持续每一年都会出一个相关的网络法，比如说电子商务法、网络安全法等等，最近应该是草拟数据安全法。作为一家企业，对法律的遵守是特别重要的。DataWorks作为阿里大数据最统一的数据入口和出口，做了很多数据安全管理的手段。它可以从引擎层面进行一个管控、也可以通过项目层面进行管控，同时可以到表层面，甚至到字段层面。在字段层面，每个字段有等级，比如说有一些高等级字段的权限必须部门负责人或者是总裁层面审批才可以使用的，再比如说有一些即使审批通过了，但还是有一定风险的数据，像身份证号码，手机号码等，DataWorks数据保护伞会提供一种技术叫数据脱敏，这些敏感、具有风险的数据被拿走是被脱敏过的，不影响使用者的统计或者分析，但是使用者是不可见的。
阿里巴巴集团有一套统一的数据管理方法，它跟组织架构是打通的，员工离职或者转岗，他的权限会自动收回。在任何企业包括阿里，人员变动是非常频繁的，通过这样的功能与体系，企业能保证在数据安全的前提下更好地应用数据。
五、基于DataWorks构建数据中台的价值
之前讲的都是基于DataWorks来构建新零售数据中台，最早我们提到数据中台一定要服务业务，现在我也介绍一下数据中台服务业务的一些方式。一家企业它用数据的过程是由浅而深的过程，首先大家都一样，最开始我们只是看数据，我有什么数据，然后通过数据去看一些问题，做一些人工的辅助和决策，但是新零售的很多业务的扩张是特别快的，一年开100多家店，覆盖全国200多个城市等等，当它的业务形态发生这样的变化后，通过简单的数据报表和数据可视化，是无法再支撑这个一年开100多家店的业务了。所以说企业这时候也可以做很多精细化的管控，比如说品类诊断、库存健康，告诉这个业务你现在有哪些问题，而不是让他们用报表去发现问题。
再到后面比如一些生鲜业务跟电商业务有一个非常不一样的点，生鲜这种新零售业务受自然因素的影响特别大，譬如说天气或者是节假日，甚至一个交通事故都会影响到生鲜的业务，因为库存问题导致货损。针对这种情况，企业基于数据中台可以做很多预测类的应用，比如销量预测。生鲜的销量预测可以要求到小时，每个小时都要做迭代，甚至还可以做一些仿真系统，当出现比如天气突然发生变化的时候，通过仿真系统预测到或者感知到有什么样的风险，并做出一定调整。再到后面生鲜会有日日鲜的一些商品（商品当天就要卖出），每个运营人员、销售人员每天有很多事情要做，这么多门店的这么多种日日鲜商品，靠人是绝对没有办法高效感知并做出调整的。如果我们把几百张报表全部干掉，把这些所有通过人看数据发现问题的场景，全部集中到业务系统里面。当数据中台发现日日鲜的商品已经卖不出去了，距离关门只有三个小时了，需要一个打折，这时候不需要人参与，通过数据中台的数据的预测与算法自动触发打折，把这个商品卖出去。这些BI跟AI结合在一起的应用是可以让数据中台真正产生价值，企业也可以根据目前不同的数据应用阶段，设计不同的数据应用产品，让数据真正赋能业务。
本文为阿里云原创内容，未经允许不得转载。