作为生意参谋联合Quick BI的初次尝试， “自助分析”面向店铺提供自助分析解决方案，支持店铺个性化数据报表制作，同时支持长周期的数据存储和分析，形成店铺专属的数据监控和分析看板，以帮助店铺提升经营效率。

“自助分析功能让店铺的数据统计与分析变得更加简单，” 厨房里的阿芬天猫旗舰店运营负责人宋福翔告诉记者，“过去需要花费1小时完成的数据统计分析工作，现在1分钟就能轻松搞定。”

生意参谋全新功能“自助分析”可自定义搭建多维数据报表

被数据拨正的参考主义 

宋福翔负责的天猫旗舰店“厨房里的阿芬”，今年六月才将目光从调味品类转向方便速食市场，目前还处于“万事开头难”阶段。

“过去，店铺一个月能有过百万的销售额，但现在一切得从0开始。”在谈到店铺转型后的销售额时，宋福翔带了些自嘲的意味，但并不是很担心现阶段的“阵痛”。

在宋福翔和团队看来，目前方便速食各品类都进入了产品重新定义、消费新一轮升级的阶段，特别是自热饭细分领域，线上市场已经初具规模，头部效应明显，“对新进入赛道的品牌来说，想要迅速起量就需要有更多不一样的抓手和推广策略。”宋福翔介绍。

然而，中式餐饮的方便熟食口味繁多，团队初期缺乏数据沉淀，只能依赖品牌定位、竞品分析和线下餐饮口味推荐来做参考，宋福翔表示，“我们将目标市场定位在一二线城市白领人群，区分现有自热米饭主流的偏重口味产品，希望以偏咸鲜口精华浓缩“捞汁”为特色的品质捞饭去细分市场，打开局面。 ”

今年天猫618消费季期间，包括迎合大众市场口味的“台式卤肉”“麻辣牛肉”，以及创新口味“鲍鱼”“花椒鸡”共四款口味捞饭商品正式上线。

第一批商品面世没多久，生意参谋就为团队带来了惊喜的商品数据反馈。宋福翔告诉记者，“数据显示，整个6月，虽然鲍鱼、花胶鸡捞饭的客单价相对比较高，但在首轮尝试过程中复购也更高，这两款产品还在多场以单口味形式的直播中被消费者要求返场。”

通过生意参谋，运营团队可以实时查看店铺整体经营数据，同时针对各个商品也能即时调用包括流量、曝光、咨询、成交、售后等整个生命周期的多维数据，依据这些数据，目前厨房里的阿芬已经开始重新梳理店铺SKU策略，并即将推出应季新品“蟹黄风味自热捞饭”，为下半年店铺的持续发力做足准备。

生意参谋数据洞察助推应季新品“蟹黄风味自热捞饭”

自助分析助力店铺经营 1分钟搞定数据分析

厨房里的阿芬天猫旗舰店的成功转型，让宋福翔更加意识到数据对于商品乃至整个店铺运营的重要性。

接触电商第七年，宋福翔其实早早就知晓如何依靠数据去调整店铺经营策略，并养成了每天通过生意参谋查看店铺数据的习惯，“从店铺流量到商品推广，再到交易端、客户体验回评……通过生意参谋的不同模块去查看统计各个端口的数据，整个一套分析下来往往需要1个多小时。”

不久前，生意参谋“自助分析”功能正式上线，作为生意参谋联手阿里云数据中台核心产品之一Quick BI的初次尝试，“自助分析”功能集结了现阶段生意参谋关于店铺的多个维度数据，店铺运营人员在可视化的操作界面，可以同步查看包括店铺流量、商品流量、跳失率等在内的100多个数据指标，并可即时调用，形成满足自身需求的数据报表。

宋福翔表示，过去需要在生意参谋不同模块进行对应数据查看和统计，但现在都能够在“自助分析”中一键选中自定义生成，“对于我们店铺运营者来说，以往需要花1小时完成的工作量，现在基本上1分钟左右就能完成，而且数据统计结果更加准确明了。”

同时针对初次接触报表搭建的店铺运营新手，“自助分析”还提供多个报表模板，可供选择使用。

在膏满堂天猫旗舰店负责人濮正阳看来，目前“自助分析”提供的两大报表类型已经能够满足店铺的大多数数据分析诉求，“生意参谋自带的数据模板侧重呈现整个店铺的核心数据，但是如果聚焦运营场景，比如商品维度、关键词维度等，其实还是需要店铺运营人员去根据自己的实际需求进行数据维度筛选和报表自主搭建，再根据最终的分析结果数据去进行商品链接推广及SKU分布的调整。”

此外，除了可自定义搭建店铺所需的报表外，“自助分析”还提供长周期数据存储能力。

“像现在对于我们店铺来说，是销售大闸蟹的旺季，今年主推的家庭分享款大闸蟹套餐，就需要去年同期相似商品的各项数据做参考，那么之后还有双11、双12、年货节等各种大促场景，自助分析模块提供的这项长周期数据存储能力，是补足了我们做同期数据比较的诉求。” 濮正阳表示。

而才组建新团队完成店铺转型的宋福翔则有更多考虑，店铺运营岗位的流动性比较大，数据交接工作通常比较复杂，“很多数据其实很难进行保存，那么自助分析现在能够为店铺存储近一年半的核心数据，这对我们整个店铺的经营来说，其实是提供了很大保障。”

而在阿里巴巴平台数据产品资深专家逸客看来，全新上线的“自助分析”功能一定程度上还能够拉平不同体量店铺间的数据分析、店铺经营能力，“体量较大的店铺往往很早就开始通过数据指导店铺经营，同时注重数据人才培养和组织建设；相对地，中小商家因为缺少专业数据岗位设置，往往不是特别能够对庞杂多维的店铺数据进行集中统计分析。我们希望通过不断丰富完善生意参谋的功能，并且引入更多专业讲师和分析人才的经验，去帮助更多店铺补齐这项能力，实现店铺经营效率的提升。”

未来，“自助分析”还将逐步上线更多维度数据，实现“一键式”全方位店铺经营数据统计与分析，普惠逾2000万累计用户。

随着DT时代互联网、智能设备及其他信息技术的发展，数据爆发式增长，如何将这些数据进行有序、有结构地分类组织和存储是我们面临的一个挑战。

如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。

数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，其阐述了数据模型的重要性。有了适合业务和基础数据存储环境的模型，那么大数据就能获得以下好处。

• 性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐。
• 成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
• 效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
• 质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

因此，毋庸置疑，大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

1．关系数据库系统和数据仓库

E .F .Codd是关系数据库的鼻祖，他首次提出了数据库系统的关系模型，开创了数据库关系方法和关系数据理论的研究。随着一大批大型关系数据库商业软件（如Oracle、Informix、DB2等）的兴起，现代企业信息系统几乎都使用关系数据库来存储、加工和处理数据。数据仓库系统也不例外，大量的数据仓库系统依托强大的关系数据库能力存储和处理数据，其采用的数据模型方法也是基于关系数据库理论的。

虽然近年来大数据的存储和计算基础设施在分布式方面有了飞速的发展，NoSQL技术也曾流行一时，但是不管是Hadoop、Spark还是阿里巴巴集团的MaxCompute系统，仍然在大规模使用SQL进行数据的加工和处理，仍然在用Table存储数据，仍然在使用关系理论描述数据之间的关系，只是在大数据领域，基于其数据存取的特点在关系数据模型的范式上有了不同的选择而已。关于范式的详细说明和定义，以及其他一些关系数据库的理论是大数据领域建模的基础，有兴趣的读者可以参考相关的经典数据库理论书籍，如《数据库系统概念》。

2．从OLTP和OLAP系统的区别看模型方法论的选择

OLTP系统通常面向的主要数据操作是随机读写，主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题；而OLAP系统面向的主要数据操作是批量读写，事务处理中的一致性不是OLAP所关注的，其主要关注数据的整合，以及在一次性的复杂大数据查询和处理中的性能，因此它需要采用一些不同的数据建模方法。

3．典型的数据仓库建模方法论

• ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度设计一个3NF模型，用实体关系（Entity Relationship，ER）模型描述企业业务，在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点：

1）需要全面了解企业业务和数据；

2）实施周期非常长；

3）对建模人员的能力要求非常高；

采用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。其建模步骤分为三个阶段：

1）高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。

2）中层模型：在高层模型的基础上，细化主题的数据项。

3）物理模型（也叫底层模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

ER模型在实践中最典型的代表是Teradata公司基于金融业务发布的FS-LDM（Financial Services Logical Data Model），它通过对金融业务的高度抽象和总结，将金融业务划分为10大主题，并以设计面向金融仓库模型的核心为基础，企业基于此模型做适当调整和扩展就能快速落地实施。

• 维度模型

维度模型是数据仓库领域的Ralph Kimball大师所倡导的，他的The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling是数据仓库工程领域最流行的数据仓库建模的经典。

维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。其设计分为以下几个步骤。

选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。

1）选择粒度：在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。

2）识别维表：选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。

3）选择事实：确定分析需要衡量的指标。

• Data Vault模型

Data Vault是Dan Linstedt发起创建的一种模型，它是ER模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。Data Vault模型由以下几部分组成。

1）Hub：是企业的核心业务实体，由实体key、数据仓库序列代理键、装载时间、数据来源组成。

2）Link：代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直接描述1:1、1:n和n:n的关系，而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成。

3）Satellite：是Hub的详细描述内容，一个Hub可以有多个Satellite。它由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成。

Data Vault模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。通过Dan Linstedt的比喻更能理解Data Vault的核心思想：Hub可以想象成人的骨架，那么Link就是连接骨架的韧带，而Satellite就是骨架上面的血肉。看如下实例（来自Data Vault Modeling Guide，作者Hans Hultgren），如图所示。

Data Vault模型实例

• Anchor模型

Anchor对Data Vault模型做了进一步规范化处理，Lars. Rönnbäck的初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF，基本变成了k-v结构化模型。我们看一下Anchor模型的组成。

1）Anchors：类似于Data Vault的Hub，代表业务实体，且只有主键。

2）Attributes：功能类似于Data Vault的Satellite，但是它更加规范化，将其全部k-v结构化，一个表只有一个Anchors的属性描述。

3）Ties：就是Anchors之间的关系，单独用表来描述，类似于Data Vault的Link，可以提升整体模型关系的扩展能力。

4）Knots：代表那些可能会在多个Anchors中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。

在上述四个基本对象的基础上，又可以细划分为历史的和非历史的，其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。

Anchor模型的创建者以此方式来获取极大的可扩展性，但是也会增加非常多的查询join操作。创建者的观点是，数据仓库中的分析查询只是基于一小部分字段进行的，类似于列存储结构，可以大大减少数据扫描，从而对查询性能影响较小。一些有数据表裁剪（Table Elimination）特性的数据库如MariaDB的出现，还会大量减少join操作。但是实际情况是不是如此，还有待商榷。下面是一个Anchor模型图（来自Anchor Modeling-Agile Information Modeling in Evolving Data Environments，作者Lars. Rönnbäck），如图所示。

Anchor模型图

注：本书中出现的部分专有名词、专业术语、产品名称、软件项目名称、工具名称等，是淘宝（中国）软件有限公司内部项目的惯用词语，如与第三方名称雷同，实属巧合。

• 节选自《大数据之路：阿里巴巴大数据实践》

1
细数数仓30年发展史 

数据库与数仓的老牌产品供应商

数据工程研发的历史是可以追溯到上世纪八十年代的数据库和数据仓库理论，随后一大批的数据管理服务厂商开始崛起，其中 Oracle、Informatica 两家非常有代表性，在行业中身居统治地位。

Oracle

Oracle 的数据库在云计算逐步铺开、去IOE声浪逐步扩大的趋势中开始式微，以及各类新兴的非接口化存储，如ElasticSearch、TSDB、MongoDB 等，OLTP场景下的市场份额争夺激烈，除了老牌的数据库厂商外，一些云计算大厂也开始了数据库产品的研发,如AWS的Aurora、阿里云的PolarDB ，在云计算市场中开始成为企业云架构的基础能力。

同时，在OLAP场景下，也就是Informatica一直处于霸主地位的市场中，在12年大数据逐步进入公众视野后，越来越多的挑战者进入，几大云厂商也不例外，其中以Google、Azure和阿里云的追赶最为猛烈，Google在云计算先机失利的情况下，开始发挥巨大现金储备的优势，开始买买买，投资了 CASK、LOOKER等产品，微软则是利用自身的产品沉淀，收割着办公领域的存量客户；阿里云则是以“数据中台”架构打响了企业数字化转型的重要一枪，国内开始大量出现数据中台服务商，生态开始繁荣起来。

Informatica

在这样的大环境下，Informatica作为老牌的数据管理厂商，目前在Gartner魔力象限中依旧占有非常重要的席位，所以在众多企业选型的时候，都会考虑到使用Informatica的产品，但是国内这个产品一直是名声大市场小，对于Informatica的好奇，也为了给客户能够提供更加全面的参考，我们对Informatica进行比较细致的调研，主要从产品能力、技术支撑以及交付模式，因为商业化的企业服务产品都不便宜，希望一次采购能够带来比较长期的收益，所以产品是否能够持续使用起来也是我们关心的一个要素。

首先看Informatica的产品能力，他们提供的主要输出版本已经逐步使用B/S的模式, 相比之前的Client模式对于用户接入提供了更好的体验；对于数据仓库构建的第一步“数据集成”，Informatica以 PowerCenter 作为数据集成的产品名称，为面向不同场景的数据集成，则提供了多样不同的版本：

• PowerCenter 标准版，用于集成和提交及时、相关、可靠的数据；• PowerCenter 高级版，用于执行复杂的任务关键型数据集成方案；• PowerCenter 大数据版，通过新兴的技术和传统的数据管理基础设施集成大数据；• PowerCenter 数据虚拟版，用于提交最新的、全面的、可以信赖的业务视图；• PowerCenter 实时版，用于实时集成和预配置营运数据；• PowerCenter 云版本，用于无缝地将云中数据和本地系统上的数据进行集成

这么多版本不免让人眼花缭乱。虽然从产品管理的角度来看，是个不错的拆分方法，但是对于用户而言，就没有这么方便了，让人有种不良商家使用锚定价格来收智商税的感觉。PowerCenter的应用架构如下图：

PowerCenter 的应用组件：

1）服务端组件

• Informatica Service：PowerCenter 服务引擎• Integration Service ：数据抽取、转换、装载服务引擎

2）客户端组件

• Administrator Console:用于知识库的建立和维护• Repository Manager:知识库管理，包括安全性管理等• Designer: 设计开发环境，定义源几目标数据结构；设计转换规则，生成ETL映射；• Workflow Manager: 合理地实现复杂的ETL工作流，基于时间、事件的作业调度；• Workflow Monitor: 监控workflow和Session运行情况，生成日志和报告

简单地说就是，开发者通过Designer配置和设计数据的传输、转换和映射关系，通过workflow来首先周期性地调度和管理

2

传统数仓产业

数仓产品选型不仅是功能还有服务

从产品所对应的技术支持能力上看，由于是工具类产品，使用过程中的问题是否有完备的产品使用和客服支持很重要，在官方材料中没有看到过产品的客户服务支持方案，应该与具体的保障要求有关系，不知道是否会像通常的国外软件服务，仅能在工作时间电话，一般离线数据任务都是在凌晨时间运行，一旦出现问题，如何快速响应，也是需要在产品采购时关注的。

3

新时代数字化建设方案

企业数据中台的构建解决方案架构与落地路径

最后就是交付实施了，对于传统数仓交付的团队，对于Informatica应该不算是陌生的，但是在国内这一类的服务商一直没有发展起来，原因就是太依赖产品了，Informatica不是中小企业的预算可以承受的，所以比较难以规模化，尤其是在云计算的冲击下，消费互联网发展逐渐开始趋平，产业互联网开始兴起，或许企业中会有更多的资金投入到数据管理的领域，

但是，中国国内企业的现状而言，估计还是不仅仅采购一个产品这么简单，如果产品版本过于复杂，操作需要极强的专业性，那么也很难规模化；

对于企业而言，不仅仅需要一个有着丰富功能的产品，还有有支撑通过产品去实现商业成功的团队或者技术支持，所以选择一个有着完善生态交付能力的产品或许是更好的选择。

2019年云栖大会上，阿里云数据中台推出产品Dataphin，其中有个介绍对于国内企业还是参考意义的，产品具体的介绍如下：

“阿里云数据中台，基于阿里巴巴近十年的大数据建设经验，沉淀出一整套的数据采集、建设与管理的方法论体系，并产品化为Dataphin产品，形成数据的采、建、管、用 一站式全链路服务能力，在中国乃至世界企业数字化转型中，承载枢纽位置，助力企业实现数据资产化和价值化！”

Dataphin在产品能力在于数据虚拟化上，通过定义一系列的原子的概念，如维度、业务过程、原子指标、业务限定、派生指标，以及模型内的关系，如维度、属性、关联关系等等，从而实现数据生产的自动化，进而实现在开发层是面向业务逻辑的开发、在使用层面是面向主题式模型的引用，进而实现了数据的虚拟化能力。

D

总结

目前，阿里云数据中台产品矩阵正在不断地优化和发展。建议企业在选择的时候，不要盲目，适合自己的才是好的、对的！

如您对商业智能，数智化转型感兴趣，请加微信：wendy199it

随着大数据趋势的迅速增长，数据的重要性与日俱增，企业内看数据、用数据的诉求越来越强烈，其中最常见的就是各种经营报表数据：

老板早晨9点准时需要看到企业核心的经营数据，以便进行企业战略及方向决策
业务负责人不定期进行个性化的项目筹划，需要多维、及时效果数据以优化项目安排
运营需要和高层一致但粒度不同的经营分析数据，并进行活动策略调整
……
举个经营报表的例子：

这个例子并不复杂，但是对于分析师或者业务开发者，实际执行的复杂度和工作量并不小，而且类似的工作每日都在重复……业务发展越快，带来的问题就越来越多：

加工时间长、人工成本高，招再多的分析师也难以满足需求
代码可读性差，数据可维护性差，类似需求需要反复、重复开发
代码开发不规范，加工过程中难以避免的计算存储浪费
得到的数据指标，复用性差导致重复建设，数据越来越不标准规范
这种情况下，对业务的直接影响就是：决策周期长（数据需求满足慢），决策易出错（数据指标口径不一致）。

既要保证数据生产时效性——及时产出数据并满足需求，又要支持数据多样性——企业自下而上不同业务分析场景，最后还要保证数据准确性——任何时间、不同岗位的人都能用同样的数据解读经营情况，怎么才能做到呢？

企业的发展加速，离不开20世纪的文档管理转到21世纪的信息管理。同样的，如果繁复的指标代码编写工作，也可以如计算器一般，界面可视化点选，复杂的代码研发过程由计算器自行处理完成就好了。

而Dataphin的自动化建模功能，就可以很好实现这个能力。

1

选择组合条件

如下图，确定需要统计计算的值，Dataphin里称为“原子指标”——最小的数据值统计单元，比如用户数这样的统计值等，然后组合如下内容：

A. 统计计算值需要应用的分析对象，Dataphin里称为“统计粒度”——维度或维度的组合，比如用户星级、用户状态等

B. 数据统计计算的时间周期，Dataphin里称为“统计周期”——统计数据需要跨越的时间长度，比如最近1天、最近30天、自然周、自然月的等

C. 数据统计的其他个性化限定条件，Dataphin里称为“业务限定”——数据记录的筛选过滤条件，比如生鲜业务类型、PC端、女性等

2

预览指标

选择完毕组合条件后，可以预览组合出来的派生指标：
1）组合的指标，默认名取“原子指标+时间周期+业务限定”组合名，保证命名标准规范。
2）历史已生成的组合，不再生成，保证指标建设统一，无重复

3

一键自动化生成

确认需要提交的指标后，一键【提交】，分钟级指标生成：
1）自动汇聚至以“统计粒度为主题”的汇总逻辑表表下，保证管理标准规范；
2）代码和调度依赖关系，系统自动生成；
3）派生指标基于汇总逻辑表，可快速雪花模型查询使用指标、分析对象的属性信息。

①派生指标自动汇聚至汇总逻辑表

②派生指标所在汇总表节点，代码及调度关系自动生成

③汇总表及派生指标可查询消费

4
复杂需求实现

上面主要是基于简单统计指标实现，实际上，报表需求还有类似 比率型、乘积型等复合统计方式，比如“客单价=销售额/客户数”，这类也可以通过Dataphin的衍生原子指标实现：

1）衍生原子指标是基于原子指标的再组合；

2）基于衍生原子指标新建派生指标时，需要保证拆解到最细粒度的原子指标，有相同的分析维度、时间周期，允许维度的计算路径不同、设置的业务限定不同。

①新建衍生原子指标

②基于衍生原子指标新建派生指标

D
总结

上面步骤可以看到，派生指标的计算生成，离不开原子指标、业务限定、统计粒度的协助，这其中有什么奥秘呢？

其实很简单，用Dataphin高效创建派生指标，掌握这1张图就够了：

1）原子指标为核心，原子指标的来源表为中心

2）统计粒度取自来源表的关联维度，以及关联维度上的关联维度

3）业务限定基于来源表为中心的雪花模型做定义

4）统计周期可任意搭配使用

如您对商业智能，数智化转型感兴趣，请加微信：wendy199it

摘要
本文从几个常见概念入手，介绍模型设计与它们的关系，在列举当前企业模型设计的建设方法，并重点介绍“维度建模”。

1

与几个概念的关系操作型业务系统

对于这个概念大家都不陌生。企业业务赖以运转的交易系统就属于操作型业务系统。因此它是为了保障业务正常运转，能够更快的处理事务。

但是因为它是针对某一特定的意图（例如满足交易业务），它不需要承诺与其他业务系统共享公共数据。因此就出现了适合于企业中交叉应用的ERP、主数据系统。当然对于有建设业务中台的企业来说，基于微服务架构的各个服务中心，能更好的提供可复用统一的公共数据。

不管是面向业务的业务系统、经过数据统一后的主数据系统或者基于微服务架构的服务中心的数据，都是作为数据中台的数据输入源头。我们通过批量同步、归档日志采集等方式，能将数据采集进数据中台，作为ODS层原始数据的一部分。

ETL

英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。在ODS层的原始数据，需要通过加工处理后，才能进入到构建好的数据模型中。

在模型设计时，需要考虑ETL加工流程，根据逻辑判断，做模型的合理设计。同样对于下游使用数据模型的ETL元数据，也是作为模型设计的输入，可基于下游应用方式做模型的横向和纵向的拆分设计，这就是“元数据驱动模型设计”的理论来源。

因此，无法理解数据开发的模型设计师是不合格的。

数据应用

数据中台提供多种数据应用的形式，包括数据报表、智能数据产品等。将统一汇总加工后的数据或者明细原子数据提供给数据应用，为业务提供数据支撑。

更加合理的数据模型设计，能够给更宽泛的应用提供数据支撑，也能够让业务方更准确无疑义的使用好数据。

2

几种企业常见的建设现状烟囱式

也许大家都不愿意承认，但是绝大部分的企业当前是没有统一、标准、公共、全局的模型设计的，而仅仅是把数据同步上来，然后基于业务需求做烟囱式的数据开发。这种方式也许从短期来看是效率最高的，但是从长期看，不仅仅造成计算存储资源的极大浪费、没有统一可用的数据、大量的重复性的工作。企业的数据就像一团乱麻，根本无法管理。

三范式+数据集市

一些传统大型企业，由于历史原因，原子数仓中以三范式的模型设计方式构建，在各个应用的数据集市中以维度建模方式构建。通过这种方式，在原子数据设计过程中，需要投入较大的资源。

对于业务来说，三范式模型太复杂，用户难以理解和检索。并且对于业务频繁变化的企业，模型的维护成本极高。

企业级维度模型

基于企业全局的角度去构建业务总线矩阵，在此基础上完成维度模型的设计，是当前众多企业选择的方向。从众多互联网企业的数据中台实践经验来看，这也是一个绝佳的各因素平衡后的选择。

后面，我们将从各个角度来思考如何基于维度模型构建企业级数据中台。

3

维度建模初探优势

在数据中台建设经验中，企业级维度模型设计从理解性、扩展性、高性能上都是更适应当前的技术和业务环境的。

首先由于计算和存储成本逐步下降，模型更重要的变成了易于理解，当易用性放在模型设计的重要位置时，维度模型可理解的优势就显现出来了，维度建模一直就是以业务的视角来描述数据。

另外，当新的业务出现时，新的模型不会对已有模型形成冲击，可以无影响的产出新的模型数据。

维度建模会设计部分数据的冗余，通过冗余换来数据检索的高性能。对于数据量极具膨胀的今天，高性能给用户带来了高价值。

事实表

所谓的事实表，就是企业的业务过程事件的度量信息。例如对于支付这个业务过程来说，需要度量支付的商品数、金额等度量。因此，企业的业务过程数据以事实表的形式在模型中呈现出来。

事实表每行都对应了一个度量事件，每行数据是一个特定级别的细节数据。事实表中每个度量都必须是相同的粒度级别。

事实表中的度量的可加性也至关重要，因为业务方往往需要将事实表的数据基于某些维度进行汇总，在度量上需要能够做汇总累加。

事实表还是稀疏的，它仅仅会将发生的业务过程数据放入其中。

维度表

维度表是事实表不可或缺的组成成分，它描述了事实表业务过程度量的环境。用于描述“谁、什么、哪里、何时、如何、为什么”有关的事件。

维度属性是作为查询约束、分组、标识的主要来源，因此它的好坏直接决定了数据的可分析性的差异。维度属性需要是可理解的，因此需要尽量避免“0,1”之类的代码，将代码翻译成更易理解的字符避免业务的误解。

同样，会有一些数值型的可作为维度属性。例如：也许有人会问商品标价适合在事实表还是维度表中？

当用于计算度量时，它应该存在于事实表中；但是当它用于做约束、分组、标识分析时，则需要存在于维度表中。在维度表中，我们往往会把连续的数据换成离散的数值存储，例如：将标价变为价格区间段。这是要根据对业务的理解做进一步设计的。

雪花模型与星型模型

所谓的雪花模型，是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

而星型模型则是所有维表都直接连接到事实表上，整个图解就像星星一样，故将该模型称为星型模型。

雪花模型是对星型模型的扩展。

星型模型是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连，不存在渐变维度，所以数据有一定冗余。因为有冗余，所以很多统计不需要做外部的关联查询，因此一般情况下效率比雪花模型高。

但是从可理解性上看，雪花模型是更容易让业务理解的。因为业务可以从模型上看出维度与维度之间的关系。

因此如何平衡查询效率和业务理解？我们在后面的文章中再细细道来。

总线矩阵

总线矩阵，维护的是企业的各个业务过程与一致性维度的关系。是以企业的高度实现的顶层设计。它的存在对于数据中台项目至关重要。

如果数据中台的模型设计就是一本书，那么总线矩阵就是这本书的目录，能从整体上对每个模型有统一的定义。

从项目协调上看，总线矩阵在大型项目中起到举足轻重的地位，整个项目组都能基于这个目录清晰的明白自己在做什么，别人已经做了什么，极大程度上的避免了信息沟通不畅导致的重复定义。

从项目管理上看，也可以基于总线矩阵对模型设计和开发进行有效的优先级排期。

最后，总线矩阵是共同业务人员和技术人员的桥梁，通过总线矩阵在项目沟通中达成一致的语言。

D

结语
通过这篇文章，初浅的对数据中台模型设计发表了一些观点。

在后面的章节中，我们将继续围绕模型设计的技术细节、结合行业的模型设计案例，和数据同仁们做进一步的分享和交流 。

如您想加入199IT商业智能群，请加微信wendy199it

欢迎关注公众号：数智化转型俱乐部

7月30日，在杭州召开的数据中台高峰论坛上，阿里云宣布正式推出金融级数据中台，助力金融机构构建全方位数据资产化的整体方案，从数据和组织变革的层面加速数字化转型升级。

据介绍，阿里云金融数据中台是集方法论、工具、组织于一体的智能大数据体系，能够帮助银行、保险、证券等金融机构把数据智能等能力嵌入到业务流程之中，赋能组织和员工，进而实现金融业务增长和创新，让数据以资产化的方式为业务的增长而赋能，从而加速整体数智化转型进程。

在具体实践中，阿里云金融数据中台通过联动蚂蚁集团的生态，帮助金融机构实现业务增长；通过丰富的工具和产品，实现金融机构数据仓库、大数据平台的迁移与融合，在搭建底层数据处理技术能力的同时叠加数据应用和数据研发以及数据智能的能力，让数据处理技术和数据应用技术融为一体；通过专属的安全和加密技术，保障金融机构内部合规、安全地在授权范围内使用数据。

“金融数据中台打破了金融机构的部门墙、数据墙，让数据真正变成全局性资产，并让所有员工都能在工作中基于数据智能进行分析，预测以及决策。”阿里云新金融事业部总经理刘伟光表示，金融数据中台将触动金融机构自顶向下的组织变革，它将扮演“航空母舰”的角色，为业务和科技的融合创新提供强大的动力和支撑。

据了解，以往银行、保险等金融机构的科技部门为支撑各业务部门运营，构建了数据仓库、数据集市、大数据平台等技术体系，在当时的技术条件和业务发展情况下，对金融业务发展提供了有力的支撑，但是在面临金融互联网时代到来和开放金融的巨变环境下，这些系统建设的短板也逐渐显露，出现数据割裂、难复用，使用难等问题，不能在今天发挥对业务更大的价值，无法让数据向水和电一样唾手可得以及在安全环境下的自由流动。

鉴于此，2015 年阿里巴巴在国内率先提出数据中台概念，历经内部复杂场景的实践后，阿里巴巴于2018 年正式通过阿里云全面对外开放数据中台能力，加速企业实现数智化转型，迄今已在金融、零售、政务、互联网等行业成功落地。

如您对商业智能，数智化转型感兴趣，请加微信：wendy199it

数据中台自14年至今，已然成为了2B、2G业务最热门的话题，政府机构、企事业单位、互联网公司等进行着数字化、数据化、智能化转型。市场普遍认为，阿里巴巴将自身数据中台建设能力对外赋能是拉起本轮数据中台浪潮的根本所在。

本文将带你全面了解阿里巴巴做数据中台的历史。

1

缘起

在2014年以前，阿里巴巴有很多条业务线，都有自己的ETL团队，每个ETL团队建设和维护自己的数据体系。当时许多人认为，这种自下而上的自给自足能够最高效地满足业务需求。也因此，各个ETL团队之间缺乏相互信任，也缺乏最大化互通的可能性。

即便在2020年的很多公司，这种现象也普通存在。不同部门、不同业务、不同系统之间都有自己单独的ETL处理体系，每个ETL体系只关注与自己垂直业务相关的需求，并从底向上完整支撑业务体系。这种情况的出现，大多是由于业务发展迅速，为了快速低成本的满足业务数据需求，单独拉出数据支撑团队造成的。

对于当时的阿里巴巴而言，这种分散数据处理体系带来了很多问题。以日志采集数据为例，就同时存在若干份数据：淘宝数据基础层、广告数据基础层、搜索数据基础层各有一份日志数据，不仅直接耗费了非常多的存储资源，更重要的是扼杀了数据中间层和数据应用层等复用的可能性。

图2014年以前阿里巴巴分业务自建数据体系的抽象图

下图展示的是2014年以前，阿里巴巴各个数据团队建设的数据任务关系图。每个圆形代表着一条业务线的数据任务集合，任意两个圆形之间的连线代表着两者的关系。由此可见：数据处理流向是混乱的、无方向性的；数据管理是无序的，基本处于失控状态；除了浪费研发资源和存储资源，也必然满足不了业务需求。

图阿里巴巴数据公共层建设之初计算环境1上的数据任务关系图

业务猛烈发展与数据支撑能力不匹配产生了巨大的矛盾，也促使阿里巴巴内部开始进行数据公共层的建设，数据公共层旨在可持续地建设阿里巴巴智能大数据体系。

2

发展

从零散的数据到统一的数据

从2014年起，阿里巴巴启动数据公共层建设项目，以OneData体系特别是方法论为指导。

数据公共层建设初期是为了消除因”烟囱式”开发给业务带来的困扰和技术上的浪费。而OneData体系是保障和推进项目建设的关键。OneData体系一方面致力于数据标准的统一，另一方面追求让数据变为资产而非成本。OneData体系除了方法论，还包含工具型产品、规范等，具体体现为：数据规范定义、数据模型定义、模型智能化设计、规范ETL开发、落实数据规范和模型定义的研发工具、对于整个体系的自动化调优和监控。

通过建设统一的ODS数据基础层，建设基于业务应用或需求来源端的抽象数据逻辑层来丰富数据中间层，允许数据应用层的百花齐放来打造阿里巴巴数据公共层。从而将零散的数据变为统一的数据。

从数据孤岛到数据融通

在业务突飞猛进发展过程中，不同的事业部、业务条线会为了快速实现需求，数据单独定义、存储、使用，从客观性来讲，每个发展壮大的企事业单位都避免不了数据孤岛的产生。数据孤岛不仅包含物理孤岛（独立存储、维护、使用），而且包含逻辑孤岛（定义不一致、计算逻辑不一致）。

阿里巴巴创新性的创建OneID体系，将所有业务范围（电商、金融、广告、物流、文化、教育、娱乐、设备、社交等）中的人、货、场、物、钱等实体打通，解决体系内逻辑性数据孤岛问题。在阿里云的强力支撑下，集团内所有隔离数据进行统一的存储和管理，解决体系内物理孤岛问题。

从数据孤岛到数据融通，使得数据拥有创造价值的可能性。

从授人以鱼到授人以渔

从以定制化开发的方式将数据交付到业务人员，到基于数据规范但需要配置，再到全链路数据打通，直到主题式服务，阿里巴巴一次次努力追求的正式从授人以鱼到授人以渔。

2012年前后，服务于1688有超过300多个API，梳理后发现这些API之间无法整合，因为每个API只服务于一个业务应用而不能被共享，API应用的数据应用层数据表也不能被共享。

从2012年至2016年，阿里巴巴通过OneService体系将API数据服务从物理表SQL模式升级至面向主体查询逻辑模型的SQL模型，大大提升了系统的可用性，也使得数据中台面向业务人员使用变成了现实，达到了授人以渔的目标。

3
从数据成本到数据价值

对于大部分企业来说，业务系统创造的数据不仅需要占据大部分的存储空间，而且还需要技术人员持续维护，是一笔不小的成本开支。

阿里巴巴致力于将数据从成本中心变为资产中心，在业务数据化与数据业务化两大方向，数据赋能业务、驱动创新四大业务场景上取得了丰硕的成功。

数据中台赋能业务、驱动创新的四大典型场景包含：全局数据监控、数据化运营、数据植入业务、数据业务化。

全局数据监控，如战略决策的智能方案：最大限度降低数据分析的难度，最大程度提高数据分析效果，同时不动声色中传递品牌价值，以高效优质地辅助战略决策和数据化运营。

图双十一数据大屏&银泰互动大屏

数据化运营，如用户管理的智能方案：基于全链路全渠道的数据构建、数据连接与萃取管理体系，对用户进行全生命周期的精细化管理（如智能CRM）。

2017年热播的一部电视剧，该电视剧在优酷土豆独家播放十天，播放量就突破了60亿次，属于”现象级IP”。但这样的”现象级IP”并不是偶然产生的，除资本投入因素外，数据化运营在其中发挥了巨大的作用。

事前通过舆情分析锁定IP，及时独立采购IP；事中实时监控流量变化、播放情况，及时调整流量入口，有针对性的推送用户；事后，及时总结和复盘，进行用户沉淀，挖掘相似内容，形成闭环。

数据植入业务：智能图像鉴别，智能客服。

通过数据模型算法，将图像鉴别从手工变为自动化，节省95%以上工作量。

图数据智能植入业务系统

数据业务化，如零售管理的智能方案：规避传统零售的松散式管理，将库存、定价、补货、销售等统一协同，整体提升线上线下零售体验和效果（如生意参谋）。

4

集大成

到今天为止，阿里云数据中台体系（Dataphin、QuickBI、QuickAudience）经历了阿里几乎所有业务的考验，包含新零售、金融、物流、营销、旅游、健康、大文娱、社交领域。在此过程中，云上数据中台除了形成自己的内核能力外，更向上”赋能业务前台”、向下与”统一计算后台”连接并与之融为一体，形成云上数据中台业务模式。

同时，阿里巴巴从2018开始，将自身的数据中台能力向外输出赋能，对社会创造更多价值。

如您对商业智能，数智化转型感兴趣，请加微信：wendy199it

几个月前，还没多少国人了解美国炸鸡品牌Popeyes，但现在，Popeyes却成为上海滩最火爆的网红店：5月在上海市淮海中路开出首家门店当天，早上7点半，第一条队伍就已排出了半条街。

面对良好的开局，Popeyes却丝毫不敢放慢脚步。

Popeyes 中国区CEO Raphael Coelho在接受媒体采访时表示，外来品牌在中国市场迅速站稳脚跟并实现盈利的关键在于快速达到规模，“从第1家店快速扩展到400家店，没有达到这一规模是很难生存下来的；而成功的品牌在跨过这个槛以后，会迅速进入盈利期。”

在Raphael Coelho看来，想要实现这一目标，离不开数字化运营， “数字化是生意标配，是在行业生存的基本技能。”

正是基于对数字化的高度重视，Popeyes早早地就为自己挑选好了最为合适的数据建设解决方案——阿里云数据中台。

Raphael Coelho认为：阿里云在零售行业中的实践，已经证明了他们能够在短时间内为企业搭建起完整、可靠的数字化能力。

不止精准营销，数据还能指导门店选址

目前，Popeyes拥有会员、供应链、支付三大数据体系。其中供应链、支付数据体系已经实现基础打通，可以满足现阶段财务场景的数据分析和使用，但会员数据体系建设却还只是出具规模。

过去两个月，Popeyes在上海陆续开出三家门店，其注册会员数突破20万，“但目前主要还只是把会员信息沉淀下来并进行一些基础分析，”Popeyes CIO 张天介绍，“我们希望能够借助数据中台的能力，实现更为智能的消费者资产管理和运营，更好地为顾客提供服务。”

现阶段Popeyes的会员数据大多积累在自身CRM系统当中，分析维度还较为常规，离数据驱动的运营和有效洞察还有一段距离。正因如此，尽管在短时间内Popeyes在上海连开三店，且把新的市场增长机会瞄准毗邻上海的杭州，可在消费者精准洞察与营销方面，Popeyes却还一直处于准备阶段。

张天透露，Popeyes会员数据体系的建设会着重依靠数据中台来做。在他看来，企业的基础数据建设和处理，就应该交给成熟的产品化解决方案来进行，而不是投入大量人力成本去重新创造前进的“轮子”，“像数据中台核心产品之一Dataphin，能够减少企业在数据处理和管理方面的工作量，让企业的精力能更多地放在对业务及消费者的分析上面，从而让企业更快更好地实现数据驱动下的运营和营销“。

据了解，Dataphin能够将会员信息集中管理并形成符合前端业务场景使用逻辑的标签体系，并通Quick BI实现可视化展现——值得一提的是，Quick BI目前正在深化在钉钉端的集成应用，未来可以支持企业在移动端的数据处理操作；此外，已经规范且符合前端业务使用场景的消费者资产，还能通过数据中台另一核心产品Quick Audience进行全域洞察和营销，并将相关效果数据回流反哺。

通过这一完整的数据流通闭环，Popeyes能够实现面向会员人群的数字化精准营销。

但在张天看来，数据中台在会员数据体系搭建方面能带来的价值，远不止于此。

“与其他行业不同，餐饮是个更加注重门店选址的行业。”张天介绍，目前Popeyes在上海的三家门店已经能够覆盖休闲、办公、社区等多个消费场景，且在9月前还将陆续在上海和杭州开出新的门店。

如何根据会员信息及消费大数据进行有效门店选址，是包括Popeyes在内等餐饮企业的一大重要课题。

张天举例，核心商圈的门店凭借周边客流能够吸引大量消费者，但这类人群一般都是“一次性消费”；设立在办公楼间的门店，能够吸引周边办公人群的消费，且消费高峰期较为稳定，一般集中在午餐和晚餐时间段；而围绕住宅社区打造的门店，能够吸引到的消费者则相对更为稳定，除了午餐晚餐之外，夜宵时间段也会是一大消费高峰期。

以前这些信息大多靠经验所得，但在使用数据中台之后，包括各门店成交信息、会员信息都将以数据的形式加以沉淀打通，并在后期同城店铺选址时作为重要参考依据， “有了这些直观的数据，企业就能知道在这座城市里，自己已经覆盖了哪些消费场景和人群，以及现阶段的场景、人群短板在哪里，这些都将是它的新机会。”

数据中台在店铺选址层面的运用，其实就是帮助企业去找到消费者， “这样我才可以做到，消费者在哪，我的门店就跟进到哪。”张天补充。

从迟疑观望到积极推进，Popeyes要借势开出1500家新店

早在Popeyes之前，国内知名餐饮品牌海底捞就依托阿里云数据中台的数智赋能，在9个月内使得APP会员数量增长近50%，同时拓展极致服务边界。

而将目光跨越行业界限，阿里云数据中台还帮助蓝光地产充分打通全国60多个城市400多项业务数据和100多万业主信息，帮助运营部门一年节省90多万元运营费用。

除此之外，福建移动、良渚古城遗址、良品铺子等数十家企业都积极搭建数据中台，并获得实效。

回到Popeyes，张天在两年前第一次听说数据中台的时候，并没想到自己会在后来成为一名践行者。

他解释，这是因为那时候数据中台这个新概念刚刚兴起，大多数人并不清楚这是什么，“包括我自己，当时对数据中台也存有一种怀疑，这种怀疑不是说觉得这个新概念不好，而在于对其能否真正落地心存疑虑”，在张天的理解中，数据中台的架构需要对企业的核心业务能力进行沉淀和抽象化，这就导致它的实施和投入要比通常的一个业务应用项目工作量大得多，“这些企业是不是真的在做数据中台，还是只是把一个业务项目微服务化了，对于这一点我心存疑虑。”

但随着对Popeyes数字化进程的战略规划逐步推进及对数据中台的理解加深，张天发现，“公司决策层都认为数据中台的方法论是最合理且有战略远见的”，只是认知转变之后，又有了新的难题，“那会儿但凡是个公司都在说自己能提供中台解决方案，市场上的声音非常多，容易让人混淆。”

但好在Popeyes有自己的一套数据中台标准。

对Popeyes来说，相对大型的企业来提数据中台概念会更加有信服力，因为大型企业的数据系统及场景更为多样复杂，会更加懂数据中台的重要性和必要性；另外更重要的一方面是数据中台的提出者必须将全套方法论及解决方案在自身内部进行实践，只有自己真正使用过了才最有发言权——而阿里云数据中台，恰好满足了Popeyes的两大标准。

但彼时，却还是有不同声音传来：Popeyes未来一段时间内在数据层面可能遇到的问题，其实可以另寻单点工具进行解决——为什么要花几倍甚至几十倍的成本去搭建数据中台，这会不会有点“大材小用”？

但张天却有自己的看法：从长远来看，数据中台一定是最高效的解决方案。他说， “虽然现在建设中台，看似成本比较高，但是一旦建设完成，在未来就不需要一而再再三地对数据进行整合，所以长线来看，能够避免很多重复建设，降低运维复杂性，从而最大限度实现成本的优化。”

也正是有所经历，张天现在对数据中台才更有发言权。

他认为，数据中台能够为企业带来的价值，除了是一项解决方案之外，更重要的其实是整套核心方法论，即数据在线且打通。

虽然不同企业由于体量不同，所遇到的数据问题也不尽相同，但是它们都能够在数据中台的方法论里去找寻到适合自己的解决方案，“在阿里云数据中台的方法论框架下，企业可以像搭积木一样去挑选对应的产品，搭建出满足自身需求的数据中台。”

而在阿里云数据中台高级专家列文看来，数据中台的搭建也一定是为了满足企业的自身实际诉求，在这个基础上，数据中台所能带来的价值将不再局限于单纯的数据治理，而是对企业的整个数字化全链路的赋能，“这个过程贯穿供应链改造、新品研发、多系统数据打通治理、前端业务数字化营销等等，帮助企业构建强力高效的数智化闭环。”

也正是看到了数据中台所能带来的业务爆发潜力，目前Popeyes已经在积极布局上海以外的发展。

据了解，今年9月Popeyes会在杭州开出3家门店，10年内还将在全国开设1500家门店，“我们也将继续运用数据中台深钻消费者资产运营，去了解我们的消费者到底喜欢什么，不同城市之间的消费者会有什么差异，以此来不断提升我们的服务。”张天说。

摘要

当前，整个社会都处在产业升级和数字化转型的大浪潮中，如何在新的商业环境下，运用设计的方式，发挥设计的驱动力，助力整个数据产业的创新升级，是数据设计师们最核心的课题下图是我们在阿里云上可以看到的当前“阿里云数据中台”核心矩阵中的数据产品。这些数据产品分别通过输出阿里巴巴的数据智能能力，面向云上企业、用户，破解数据采集、建设、管理及应用等课题。

在对这些体系化矩阵类数据产品的设计构思中，来自阿里的数据设计师的都会遇到哪些设计难题，又如何解题呢？

1
体验架构构建：数据管理

阿里巴巴通过数据服务上云，目标是帮助政府、企业等用户合理便捷地管理数据，让数据为企业创造商业价值。

这类产品拥有海量的功能模块，错综复杂的交互流程，以及普通用户无法理解的强数据技术背景，用户体验正是其最佳的定义方式。

从商业竞争研究、业务链路梳理、场景化体验架构构建，再到产品的落地与售卖传播，设计师在这一环扮演着“商业规划师”的角色。

这里提到的“体验架构=体验流程+信息架构”，如何去构建产品的体验架构呢？

体验链路构建：根据产品战略、行业竞争力优势及业务目标，全链路的定义产品分模块及体验关键触点。

信息框架设定：运用场景化及结构化解构思维，根据多角色需求，抽离用户多角色使用场景、提炼使用行为链路，设计师要真正站在用户的视角看问题，运用同理心，层层递进的剥丝抽茧，逐层架构产品信息框架。

信息过载解构：出现产品级、页面级、功能级信息冗余时，为了减少对用户造成误导的情况，可以从场景层、信息层、逻辑层进行解构。

（Dataphin 体验架构构建案例）

2
可视化呈现：数据演绎

传统的数据表呈现方式无法跟上数据时代的脚步。

我们期望让数据开口说话，用最直观简洁的可视化语言展现商业背后的故事。从构建业务目标，设计故事版，抽离符号，典型用户分析，用户需求收集，到最后的可视化设计呈现，设计师为用户规划了洞察业务、经营决策的分析动线和场景化体验。

Dataphin中，为满足企业主看企业数据、技术看业务关联及数据资产情况。“数据资产全景”以可视化的方式进行呈现，根据用户关注点及场景，设计师定义了从“全局>流程>结构”三种视图，从全局到细节，满足用户多维监控探索的需求。

3
从数据智能到商业智能：数据增值

1.工具化设计

BI工具可以满足用户从数据处理，数据查看，数据分析到数据洞察的全链路分析需求，并用最直观的可视化方式进行商业的探索。

设计中，可视化图表的丰富、易搭建，工具的易操作，产品的多维分析能力都非常重要。设计师需要从可视化分析、工具化体验等不同维度进行方法体系深耕，用专业性说话，让产品具有丰富的工具配置能力、深度的工具洞察能力，才能帮助产品更稳定成熟的迭代，建立行业竞争力。

（Quick BI 可视化组件模型及工具框架搭建）

2.智能化设计

如果说BI工具的工具化能力是产品的基础能力，智能化能力则是产品加在行业竞争力上的砝码。Gartner 2019发布的魔力象限报告中指出，通过人工智能、机器学习等技术实现的增强分析已是BI产品发展的最重要、也是最显著的趋势之一。

如何用体验赋能数据智能，如何以全链路的视角打造闭环的用户体验？

行业竞争研究：了解行业产品布局，挖掘竞争力优势。

可行性挖掘：与技术共建，多思维碰撞，了解知识图谱，自然语言理解，意图识别等最前沿的人工智能算法技术，全流程思考，不断挖掘设计可行性，设计赋能业务。

专业规则定义：辅助定义用户分析意图，可视化匹配规则、NLP交互规则，多轮对话逻辑，兜底问答逻辑等，做专业性定义。

设计师运用自己的专业能力，赋能打造低使用成本、轻松问、精准答的数据智能小助理，驱动产品从数据智能到商业智能的进程。

4
度量标准：软性评估
从2018年初始至今，云上产品矩阵生态初步形成，当前整个云上产品矩阵处在成长期-初创期及成熟期之间。该阶段产品小步快跑，快速迭代，不停歇的补齐有竞争力的产品功能。我们尚无法拿到成熟的使用数据指标，那如何度量产品是否健康的进行着商业化呢？

生命周期评估：产品上线后，记录功能的生命周期，不容易被更新或被替代，代表生命周期长，反之短。生命周期短会造成大把的研发投入被荒废，设计结果不尽人意。- 评估可用性

用户反馈评估：新功能上线后，收集用户已有功能建议及无法满足的需求，记录反哺产品需求，辅助产品迭代。-辅助迭

续签率评估：随着用户对产品的熟识，商业化营收续签率增长，说明用户对产品接受度较高，对产品产生正向影响。- 评估商业化健康度

我们暂时把这几种度量方法定义为软性评估，更适用于B端成长期的产品，帮助产品节省研发成本的同时进行稳定迭代。

小结在大数据时代，数据服务的产品化上云步伐不停继续，前路任重而道远。作为数据设计师们，需要不断突破设计师的限制，从多角度思考，运用设计的专业能力在产品中发挥更多的主观能动性，打造强有力的行业竞争力，同时定义可传承可复制的数据产品设计模式，长远赋能整个数据行业。

如您想加入199IT商业智能群，请加微信wendy199it

摘要：

Quick BI和Power BI分别是阿里云和微软云上的官方BI产品，两款产品都是比较好的自助式商业智能软件，都具备云BI的优势，既能够像SaaS运行在阿里云或者Azure云上，又能快速部署到本地的服务器中运行。但是，两款产品还是有非常大的区别的；比如Power BI微软主打的是组合策略，需要Power BI Desktop、Power Query、Excel等多个产品的各自使用；Quick BI崇尚“高效数据分析与展现”，是基于网页版能实现数据建模、可视化报表以及类Excel分析、数据门户分享等一站式数据分析链路。那么两款产品比较起来到底哪个更好用？下面我们对这两款商业智能软件做个对比评测。

一、Quick BI对比Power BI：数据源连接

从数据引擎的对接能力来看，两者差不多，比如Power BI支持连接文件、Azure、联机服务、SQL Server、MySQL、Oracle等多种关系数据库；Quick BI 支持连接文件、阿里云多种数据库、SQL Server等多种数据库。

不同点在于一是两个产品集中在于对各自的云数据库的支持，二是Quick BI在支持常见数据库的基础上，还支持跨数据源查询，以及对常见数据库支持上传本地文件。

Quick BI如下所示：

Power BI如下所示：

二、Quick BI对比Power BI：数据处理和建模

Quick BI支持自助式建模，和SQL建模两种方式，通过网页版连接到数据库，映射成逻辑表，可以直接对大数据量的数据表做数据集管理和处理，并支持对特定数据库的加速；Quick BI图示如下：

Power BI网页版无数据建模功能，需要安装Power BI Desktop版连接本地数据库，在本机上对数据表的行列进行灵活的处理和相关的数据集操作，但其中对于数据量会有限制和要求，而且Desktop版仅支持Windows系统，不支持Mac电脑；Power BI desktop版实例如下：

三、Quick BI对比Power BI：可视化展现和报表制作

Quick BI网页版支持可视化数据报表搭建和电子表格的两种数据分析分析方式，其中可视化报表支持40+种图表组件的展示，以及复杂的查询控件的设置来方便预览者动态查询数据，电子表格除包含本地Excel的基础功能以外，优势在于能直接联系加工好的数据集，并支持数据动态更新。Quick BI图示如下：

Power BI网页版支持可视化数据报表的搭建，并提供多种图表的配置和展现；同时本地支持Excel支持复杂的报表分析和制作，示例如下:

四、Quick BI对比Power BI：用户分享及数据

Power BI本地服务器用户能共享报表，但不能编辑仪表板，并缺少在Power BI SaaS上的机器学习功能。 用户还报告了不同数据支持方面的不一致之处。微软没有灵活性的提供对Azure以外的云服务器同样好的性能支持。

Quick BI 为网页版，网页版可以编辑和通过URL分享给企业小伙伴，开发者并一键发布即访问者可实时观测到报表的变化，同时Quick BI的本地服务器版(豪华版）支持的功能为云上SaaS版的功能集合；同时从Quick BI的权限架构体系中可以看出Quick BI更适合中国国情，是面向企业IT部门、业务人员，提供企业级管控下的业务人员自助式数据分析，从而实现上游IT部分做好数据管控，下游业务部分充分利用加工好的底层数据来自助式分析，支撑前台业务的快速发展。

五、Quick BI对比Power BI：移动端

Quick BI以HTML5形式集成钉钉微应用中，还支持对接企业的账号系统，嵌入到自有的APP系统中。Quick BI用移动端打造了以访问者为中心的报表搜索、查看、收藏、分享等一站式移动端服务；提供企业级的数据报表目录以方便用户快速找到相应的报表，支持快捷查看报表、权限审批流等，并支持通过应用内消息、钉钉、微信等渠道将报表分享给其他同事。

Power BI移动端为安装独立的APP，其中可视化图表是PC端做的简单适配，但和PC端相比，和其它系统无法进行互动和分享联系；

总体看来，两款产品各有优势，Quick BI在数据处理和建模、移动端及用户数据分享方面更胜一筹，大家可以根据自己的需要选择使用哪款产品哦～

阿里巴巴数据中台团队，致力于输出阿里云数据智能的最佳实践，助力每个企业建设自己的数据中台，进而共同实现新时代下的智能商业！

阿里巴巴数据中台解决方案，核心产品：

• Dataphin，以阿里巴巴大数据核心方法论OneData为内核驱动，提供一站式数据构建与管理能力；

• Quick BI，集阿里巴巴数据分析经验沉淀，提供一站式数据分析与展现能力；

• Quick Audience，集阿里巴巴消费者洞察及营销经验，提供一站式人群圈选、洞察及营销投放能力，连接阿里巴巴商业，实现用户增长。

查看更多：https://yq.aliyun.com/articles/745039?utm_content=g_1000104749

摘要
今年618，借助阿里云零售数据中台，上百家零售品牌实现了逆势增长。昨天（7月22日）俱乐部开启了618回顾直播活动，细致介绍了阿里云零售数据中台如何帮助品牌实现消费者极速增长。今明两日，我们将推送两场课程的直播课件。今日推荐——课程1《阿里云零售数据中台创新场景介绍》
今年6月，阿里云数据中台正式对外发布了零售、金融、政务、互联网企业等行业数据中台。其中，零售行业数据中台主要提供多维的全方位洞察、全域自动化营销等服务,并通过与阿里巴巴生态联动,帮助更多零售企业实现数智化增长。

1

场景1：赋能IP运营站内爆发

什么是IP:定义升级

传统IP：IP，英文为“intellectual property”，其原意为“知识产权”， 是一 种 无形财产或者精神财富，是创造性的智力劳动所创造的劳动成果。IP有两大类，一类是著作权(即版权)，一类是工业产权。

升级IP：随着新文创、网红、品牌 IP 等不断兴起，为更聚焦相关产业和数据服务 的标准化，我们升级了 IP 的概念:IP 是文化积累到一定量级后输出的精华，不断推出创新的作品，构建了 完整 的世界观、价值观，吸引了成千上万的粉丝，进而产生了巨大的商 业价值和文化价值。

阿里经济体IP：在阿里经济体内，用户通过UC资讯，阿里读书、优酷、大麦、淘票票、 虾米，以及淘宝、天猫、盒马等平台，可以完成影/视/综/音乐/戏剧/读 书及衍生品消费。

IP运营数字化解决方案

【案例】某家电品牌：精准引流引爆IP货品

2

场景2：跨端运营，联动轻店/支付宝/饿了么

品牌营销已升维进入多端连接新时代，亟需多端联动以“人”为本，助 力品牌直连用户

营销1.0—以[店]为链接

营销2.0——以[跨端触点]直连用户 会员X 线上售券 X 支付 X 外卖 X 门店

【案例】某服饰品牌：通过轻店拉新入会

【案例】某食品品牌：实现跨端拉新和提频

3

场景3：全域人群赋能直播间转化

门店营销已升维进入以“人”直连时代，直播营销实现从看“热闹”到“粉丝-兴趣-购买”转变。

【案例】某服饰品牌：见证聚合力量

直播视频，扫码下方二维码，申请入群收看

如您想加入199IT数智化群或对199IT有任何建议，请加微信：wendy199it

摘要
7月22日，俱乐部开启了618回顾直播活动，细致介绍了阿里云零售数据中台如何帮助品牌实现消费者极速增长。今日推荐——课程2《全域GROW解决方案 赋能企业运营落地 》今年6月，阿里云数据中台正式对外发布了零售、金融、政务、互联网企业等行业数据中台。其中，零售行业数据中台主要提供多维的全方位洞察、全域自动化营销等服务,并通过与阿里巴巴生态联动,帮助更多零售企业实现数智化增长。在今年的618中，阿里云零售数据中台通过帮助企业建设一方数据中台，联动阿里生态，为百家品牌实现了全域赋能。昨天我们推送了618直播课程课《阿里云零售数据中台创新场景介绍》欢迎点击回看今天我们来深度介绍一个通过全域GROW解决方案帮助品牌实现品类增长的干货。

01

GROW品类增长方法论介绍

品牌营销已从流量至上，转变为以人群运营为核心的数字化增长阶段:

过去: GMV = 流量 * 转化率 * 客单价

现在: 以人群运营为核心，驱动数字化增长

02

全域GROW解决方案-场景案例-G

跨品类渗透

基于品牌一方人群+淘系数据， 寻找高相关品类，精准挖解决跨品类消费活跃人群

特色货品供给提升

一方IP人群上传算法放大，精准引流引爆IP货品

价格分层渗透

基于一方人群及价格带偏好/折扣敏感偏好，实现人群 分层运营，提升有效行动转化率

多渠道联动渗透

基于品牌一方用户及其行为，打通多端潜在受众资源池， 并 通过全域媒体矩阵进行全域触达和引流。

营销活动渗透

一方沉淀营销人群持续运营，提升品牌营销效率。

平台能力加速渗透

联动一方人群，探索平台直播趋势场景，精准渗透， 全面放大平台能力价值

03

全域GROW解决方案-场景案例-R

类目老客召回

品牌线下流失会员上翻，线上精准触达， 增强品牌黏着度

老客消费场景拓展

基于一方老客，通过挖掘细分场景需求以及培养新的消 费习惯，促进购买。

04

全域GROW解决方案-场景案例-O

商品溢价挖掘

基于品牌一方粉丝人群，挖掘偏好趋势，构建专属商品 孵化方案，提升品牌价值

未来:联动品牌一方数据资产，共建全域GROW由“人”及“品”场 景落地，加速品牌生意新增量

直播视频，扫码下方二维码，申请入群收看

如您想加入199IT数智化群或对199IT有任何建议，请加微信：wendy199it