洛龙区网站制作建设费用,二手书网站建设的意义,同学录网站建设,做代码和网站维度建模 数仓建模方法1. 范式建模法#xff08;Third Normal Form#xff0c;3NF#xff09;2. 维度建模法#xff08;Dimensional Modeling#xff09;3. 实体建模法#xff08;Entity Modeling#xff09; 维度建模1. 事实表事实表种类事务事实表周期快照事实表累计快… 维度建模 数仓建模方法1. 范式建模法Third Normal Form3NF2. 维度建模法Dimensional Modeling3. 实体建模法Entity Modeling 维度建模1. 事实表事实表种类事务事实表周期快照事实表累计快照事实表 2维度表2. 维度建模三种模式3. 维度建模过程维度表设计步骤维度设计要点规范化与反规范化维度变化 数据仓库建模的意义 如果把数据看作图书馆里的书我们希望看到它们在书架上分门别类地放置如果把数据看作城市的建筑我们希望城市规划布局合理如果把数据看作电脑文件和文件夹我们希望按照自己的习惯有很好的文件夹组织方式而不是糟糕混乱的桌面经常为找一个文件而不知所措。 数据模型就是数据组织和存储方法它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后数据才能得到高性能、低成本、高效率、高质量的使用。 高性能良好的数据模型能够帮助我们快速查询所需要的数据。 低成本良好的数据模型能减少重复计算实现计算结果的复用降低计算成本。 高效率良好的数据模型能极大的改善用户使用数据的体验提高使用数据的效率。 高质量良好的数据模型能改善数据统计口径的混乱减少计算错误的可能性。 数仓建模方法
数仓建模在哪层建设呢我们以维度建模为例建模是在数据源层的下一层进行建设在上节的分层架构中就是在DW层进行数仓建模所以DW层是数仓建设的核心层。 那数仓建模怎么建呢其实数据仓库的建模方法有很多种每一种建模方法代表了哲学上的一个观点代表了一种归纳、概括世界的一种方法。常见的有 范式建模法、维度建模法、实体建模法等每种方法从本质上将是从不同的角度看待业务中的问题。
1. 范式建模法Third Normal Form3NF
这种建模方法的出发点是整合数据其目的是将整个企业的数据进行组合和合并并进行规范处理减少数据冗余性保证数据的一致性。这种模型并不适合直接用于分析统计。 范式建模法其实是我们在构建数据模型常用的一个方法该方法的主要由 Inmon 所提倡主要解决关系型数据库的数据存储利用的一种技术层面上的方法。目前我们在关系型数据库中的建模方法大部分采用的是三范式建模法。 范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则而在关系型数据库中这种规则就是范式这一过程也被称为规范化。目前关系数据库有六种范式第一范式1NF、第二范式2NF、第三范式3NF、Boyce-Codd范式BCNF、第四范式4NF和第五范式5NF。 在数据仓库的模型设计中一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 : ● 每个属性值唯一不具有多义性 ; ● 每个非主属性必须完全依赖于整个主键而非主键的一部分 ; ● 每个非主属性不能依赖于其他关系中的属性因为这样的话这种属性应该归到其他关系中去。 根据 Inmon 的观点数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中企业数据模型决定了数据的来源而企业数据模型也分为两个层次即主题域模型和逻辑模型。同样主题域模型可以看成是业务模型的概念模型而逻辑模型则是域模型在关系型数据库上的实例化。
2. 维度建模法Dimensional Modeling
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型构建的数据模型为分析需求服务因此它重点解决用户如何更快速完成分析需求同时还有较好的大规模复杂查询的响应性能。 典型的代表是我们比较熟知的星形模型Star-schema以及在一些特殊场景下适用的雪花模型Snow-schema。 维度建模中比较重要的概念就是 事实表Fact table和维度表Dimension table。其最简单的描述就是按照事实表、维度表来构建数据仓库、数据集市。
3. 实体建模法Entity Modeling
实体建模法并不是数据仓库建模中常见的一个方法它来源于哲学的一个流派。从哲学的意义上说客观世界应该是可以细分的客观世界应该可以分成由一个个实体以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法将整个业务也可以划分成一个个的实体而每个实体之间的关系以及针对这些关系的说明就是我们数据建模需要做的工作。 虽然实体法粗看起来好像有一些抽象其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分实体事件说明如下图所示 上图表述的是一个抽象的含义如果我们描述一个简单的事实“小明开车去学校上学”。以这个业务事实为例我们可以把“小明”“学校”看成是一个实体“上学”描述的是一个业务过程我们在这里可以抽象为一个具体“事件”而“开车去”则可以看成是事件“上学”的一个说明。
维度建模
维度建模是专门应用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种小型数据仓库。 先来了解下维度建模中表的类型和维度建模的模式之后再开始建模。
维度建模中表的类型 维度建模分为两种表事实表和维度表事实表必然存在的一些数据像采集的日志文件订单表都可以作为事实表 。 特征是一堆主键的集合每个主键对应维度表中的一条记录客观存在的根据主题确定出需要使用的数据维度表维度就是所分析的数据的一个量维度表就是以合适的角度来创建的表分析问题的一个角度时间、地域、终端、用户等角度
1. 事实表
发生在现实世界中的操作型事件其所产生的可度量数值存储在事实表中。从最低的粒度级别来看事实表行对应一个度量事件反之亦然。事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。 图中的订单表就是一个事实表你可以理解他就是在现实中发生的一次操作型事件我们每完成一个订单就会在订单中增加一条记录。 事实表的特征表里没有存放实际的内容他是一堆主键的集合这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键可与维度表关联。事实表的度量通常是数值类型且记录数会不断增加表数据规模迅速增长。 明细表宽表 事实表的数据中有些属性共同组成了一个字段糅合在一起比如年月日时分秒构成了时间,当需要根据某一属性进行分组统计的时候需要截取拼接之类的操作效率极低。如 为了分析方便可以事实表中的一个字段切割提取多个属性出来构成新的字段因为字段变多了所以称为宽表原来的成为窄表。将上述的local_time字段扩展为如下6个字段 又因为宽表的信息更加清晰明细所以也可以称之为明细表。
事实表种类
事实表分为以下6类
事务事实表周期快照事实表累积快照事实表无事实的事实表聚集事实表合并事实表
事务事实表
表中的一行对应空间或时间上某点的度量事件。就是一行数据中必须有度量字段什么是度量就是指标比如说销售金额销售数量等这些可加的或者半可加就是度量值。另一点就是事务事实表都包含一个与维度表关联的外键。并且度量值必须和事务粒度保持一致。 事务型事实表用来记录各业务过程它保存的是各业务过程的原子操作事件即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。事务型事实表可用于分析与各业务过程相关的各项统计指标由于其保存了最细粒度的记录可以提供最大限度的灵活性可以支持无法预期的各种细节层次的统计需求。 设计事务事实表时一般可遵循以下四个步骤选择业务过程→声明粒度→确认维度→确认事实 1选择业务过程 在业务系统中挑选我们感兴趣的业务过程业务过程可以概括为一个个不可拆分的行为事件例如电商交易中的下单取消订单付款退单等都是业务过程。通常情况下一个业务过程对应一张事务型事实表。 2声明粒度 业务过程确定后需要为每个业务过程声明粒度。即精确定义每张事务型事实表的每行数据表示什么应该尽可能选择最细粒度以此来应各种细节程度的需求。 典型的粒度声明如下订单事实表中一行数据表示的是一个订单中的一个商品项。 3确定维度 确定维度具体是指确定与每张事务型事实表相关的维度有哪些。 确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度。 4确定事实 此处的“事实”一词指的是每个业务过程的度量值通常是可累加的数字类型的值例如次数、个数、件数、金额等。 经过上述四个步骤事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表第二步可以确定每张事务型事实表的每行数据是什么第三步可以确定每张事务型事实表的维度外键第四步可以确定每张事务型事实表的度量值字段。
事务事实表的不足 事务型事实表可以保存所有业务过程的最细粒度的操作事件故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求其逻辑可能会比较复杂或者效率会比较低下。例如 1存量型指标 例如商品库存账户余额等。此处以电商中的虚拟货币为例虚拟货币业务包含的业务过程主要包括获取货币和使用货币两个业务过程各自对应一张事务型事实表一张存储所有的获取货币的原子操作事件另一张存储所有使用货币的原子操作事件。 假定现有一个需求要求统计截至当日的各用户虚拟货币余额。由于获取货币和使用货币均会影响到余额故需要对两张事务型事实表进行聚合且需要区分两者对余额的影响加或减另外需要对两张表的全表数据聚合才能得到统计结果。 可以看到不论是从逻辑上还是效率上考虑这都不是一个好的方案。 2多事务关联统计 例如现需要统计最近30天用户下单到支付的时间间隔的平均值。统计思路应该是找到下单事务事实表和支付事务事实表过滤出最近30天的记录然后按照订单id对两张事实表进行关联之后用支付时间减去下单时间然后再求平均值。 逻辑上虽然并不复杂但是其效率较低应为下单事务事实表和支付事务事实表均为大表大表join大表的操作应尽量避免。 可以看到在上述两种场景下事务型事实表的表现并不理想。下面要介绍的另外两种类型的事实表就是为了弥补事务型事实表的不足的。
周期快照事实表
顾名思义周期事实表就是每行都带有时间值字段代表周期通常时间值都是标准周期如某一天某周某月等。粒度是周期而不是个体的事务也就是说一个周期快照事实表中数据可以是多个事实但是它们都属于某个周期内。 周期快照事实表以具有规律性的、可预见的时间间隔来记录事实主要用于分析一些存量型例如商品库存账户余额或者状态型空气温度行驶速度指标。 1.对于商品库存、账户余额这些存量型指标业务系统中通常就会计算并保存最新结果所以定期同步一份全量数据到数据仓库构建周期型快照事实表就能轻松应对此类统计需求而无需再对事务型事实表中大量的历史记录进行聚合了。 2.对于空气温度、行驶速度这些状态型指标由于它们的值往往是连续的我们无法捕获其变动的原子事务操作所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样构建周期型快照事实表。 设计流程 1确定粒度 周期型快照事实表的粒度可由采样周期和维度描述故确定采样周期和维度后即可确定粒度。采样周期通常选择每日。 维度可根据统计指标决定例如指标为统计每个仓库中每种商品的库存则可确定维度为仓库和商品。 确定完采样周期和维度后即可确定该表粒度为每日-仓库-商品。 2确认事实 事实也可根据统计指标决定例如指标为统计每个仓库中每种商品的库存则事实为商品库存。 事实类型此处的事实类型是指度量值的类型而非事实表的类型。事实度量值共分为三类分别是可加事实半可加事实和不可加事实。 1可加事实可加事实是指可以按照与事实表相关的所有维度进行累加例如事务型事实表中的事实。 2半可加事实半可加事实是指只能按照与事实表相关的一部分维度进行累加例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例这张表中的库存事实可以按照仓库或者商品维度进行累加但是不能按照时间维度进行累加因为将每天的库存累加起来是没有任何意义的。 3不可加事实不可加事实是指完全不具备可加性例如比率型事实。不可加事实通常需要转化为可加事实例如比率可转化为分子和分母。
累计快照事实表
周期快照事实表是单个周期内数据而累计快照事实表是由多个周期数据组成每行汇总了过程开始到结束之间的度量。每行数据相当于管道或工作流有事件的起点过程终点并且每个关键步骤都包含日期字段。如订单数据累计快照事实表的一行就是一个订单当订单产生时插入一行当订单发生变化时这行就被修改。 累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表如交易流程中的下单、支付、发货、确认收货业务过程。 累积型快照事实表通常具有多个日期字段每个日期对应业务流程中的一个关键业务过程里程碑。 累积型快照事实表主要用于分析业务过程里程碑之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔使用累积型快照事实表进行统计就能避免两个事务事实表的关联操作从而变得十分简单高效。
设计流程 累积型快照事实表的设计流程同事务型事实表类似也可采用以下四个步骤下面重点描述与事务型事实表的不同之处。 选择业务过程→声明粒度→确认维度→确认事实。 1选择业务过程选择一个业务流程中需要关联分析的多个关键业务过程多个业务过程对应一张累积型快照事实表。 2声明粒度精确定义每行数据表示的是什么尽量选择最小粒度。 3确认维度选择与各业务过程相关的维度需要注意的是每各业务过程均需要一个日期维度。 4确认事实选择各业务过程的度量值。
● 无事实的事实表 我们以上讨论的事实表度量都是数字化的当然实际应用中绝大多数都是数字化的度量但是也可能会有少量的没有数字化的值但是还很有价值的字段无事实的事实表就是为这种数据准备的利用这种事实表可以分析发生了什么。
● 聚集事实表 聚集就是对原子粒度的数据进行简单的聚合操作目的就是为了提高查询性能。如我们需求是查询全国所有门店的总销售额我们原子粒度的事实表中每行是每个分店每个商品的销售额聚集事实表就可以先聚合每个分店的总销售额这样汇总所有门店的销售额时计算的数据量就会小很多。
● 合并事实表 这种事实表遵循一个原则就是相同粒度数据可以来自多个过程但是只要它们属于相同粒度就可以合并为一个事实表这类事实表特别适合经常需要共同分析的多过程度量。
2维度表
维度表是维度建模的基础和灵魂。前文提到事实表紧紧围绕业务过程进行设计而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段维度字段称为维度属性。 每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键当然维度表行的描述环境应与事实表行完全对应。维度表通常比较宽是扁平型非规范表包含大量的低粒度的文本属性。
维度表示你要对数据进行分析时所用的一个量比如你要分析产品销售情况 你可以选择按类别来进行分析或按区域来分析。每个类别就构成一个维度。上图中的用户表、商家表、时间表这些都属于维度表这些表都有一个唯一的主键然后在表中存放了详细的数据信息。
总的说来在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析以查询为主不涉及数据更新操作。事实表的设计是以能够正确记录历史信息为准则维度表的设计是以能够以合适的角度来聚合主题内容为准则。
● 维度表结构 维度表谨记一条原则包含单一主键列但有时因业务复杂也可能出现联合主键请尽量避免如果无法避免也要确保必须是单一的这很重要如果维表主键不是单一和事实表关联时会出现数据发散导致最后结果可能出现错误。 维度表通常比较宽包含大量的低粒度的文本属性。
● 跨表钻取 跨表钻取意思是当每个查询的行头都包含相同的一致性属性时使不同的查询能够针对两个或更多的事实表进行查询 钻取可以改变维的层次变换分析的粒度。它包括上钻/下钻 上钻roll-up上卷是沿着维的层次向上聚集汇总数据。例如对产品销售数据沿着时间维上卷可以求出所有产品在所有地区每月或季度或年或全部的销售额。 下钻drill-down下钻是上钻的逆操作它是沿着维的层次向下查看更详细的数据。
● 退化维度 退化维度就是将维度退回到事实表中。因为有时维度除了主键没有其他内容虽然也是合法维度键但是一般都会退回到事实表中减少关联次数提高查询性能
● 多层次维度 多数维度包含不止一个自然层次如日期维度可以从天的层次到周到月到年的层次。所以在有些情况下在同一维度中存在不同的层次。
● 维度表空值属性 当给定维度行没有被全部填充时或者当存在属性没有被应用到所有维度行时将产生空值维度属性。上述两种情况推荐采用描述性字符串代替空值如使用 unknown 或 not applicable 替换空值。
● 日历日期维度 在日期维度表中主键的设置不要使用顺序生成的id来表示可以使用更有意义的数据表示比如将年月日合并起来表示即YYYYMMDD或者更加详细的精度。
2. 维度建模三种模式 星型模式 星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心所有的维度表直接连接在事实表上像星星一样。 星形模式的维度建模由一个事实表和一组维表成且具有以下特点 a. 维表只和事实表关联维表之间没有关联 b. 每个维表主键为单列且该主键放置在事实表中作为两边连接的外键 c. 以事实表为核心维表围绕核心呈星形分布 雪花模式 雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的虽然这种模型相比星型更规范一些但是由于这种模型不太容易理解维护成本比较高而且性能方面需要关联多层维表性能也比星型模型要低。所以一般不是很常用
3星座模式 星座模式是星型模式延伸而来星型模式是基于一张事实表的而星座模式是基于多张事实表的而且共享维度信息。 前面介绍的两种维度建模方法都是多维表对应单事实表但在很多时候维度空间内的事实表不止一个而一个维表也可能被多个事实表用到。在业务发展后期绝大部分维度建模都采用的是星座模式。
3. 维度建模过程
我们知道维度建模的表类型有事实表维度表模式有星形模型雪花模型星座模型这些概念了但是实际业务中给了我们一堆数据我们怎么拿这些数据进行数仓建设呢数仓工具箱作者根据自身60多年的实际业务经验给我们总结了如下四步请务必记住 数仓工具箱中的维度建模四步走 请牢记以上四步不管什么业务就按照这个步骤来顺序不要搞乱因为这四步是环环相扣步步相连。下面详细拆解下每个步骤怎么做 1、选择业务过程 维度建模是紧贴业务的所以必须以业务为根基进行建模那么选择业务过程顾名思义就是在整个业务流程中选取我们需要建模的业务根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城整个商城流程分为商家端用户端平台端运营需求是总订单量订单人数及用户的购买情况等我们选择业务过程就选择用户端的数据商家及平台端暂不考虑。业务选择非常重要因为后面所有的步骤都是基于此业务数据展开的。
2、声明粒度 先举个例子对于用户来说一个用户有一个身份证号一个户籍地址多个手机号多张银行卡那么与用户粒度相同的粒度属性有身份证粒度户籍地址粒度比用户粒度更细的粒度有手机号粒度银行卡粒度存在一对一的关系就是相同粒度。为什么要提相同粒度呢因为维度建模中要求我们在同一事实表中必须具有相同的粒度同一事实表中不要混用多种不同的粒度不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时强烈建议从关注原子粒度开始设计也就是从最细粒度开始因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的所以对于有明确需求的数据我们建立针对需求的上卷汇总粒度对需求不明朗的数据我们建立原子粒度。
3、确认维度 维度表是作为业务分析的入口和描述性标识所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢如果该列是对具体值的描述是一个文本或常量某一约束和行标识的参与者此时该属性往往是维度属性数仓工具箱中告诉我们牢牢掌握事实表的粒度就能将所有可能存在的维度区分开并且要确保维度表中不能出现重复数据应使维度主键唯一
4、确认事实 事实表是用来度量的基本上都以数量值表示事实表中的每行对应一个度量每行中的数据是一个特定级别的细节数据称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量这种情况下该列往往是事实。
维度表设计步骤
1确定维度表 在设计事实表时已经确定了与每个事实表相关的维度理论上每个相关维度均需对应一张维度表。需要注意到可能存在多个事实表与同一个维度都相关的情况这种情况需保证维度的唯一性即只创建一张维度表。另外如果某些维度表的维度属性很少例如只有一个**名称则可不创建该维度表而把该表的维度属性直接增加到与之相关的事实表中这个操作称为维度退化。 2确定主维表和相关维表 此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_infospu_infobase_trademarkbase_category3base_category2base_category1等其中sku_info就称为商品维度的主维表其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。 3确定维度属性 确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择也可通过进一步加工得到。 确定维度属性时需要遵循以下要求 1尽可能生成丰富的维度属性 维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。 2尽量不使用编码而使用明确的文字说明一般可以编码和文字共存。 3尽量沉淀出通用的维度属性 有些维度属性的获取需要进行比较复杂的逻辑处理例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理可将这些维度属性沉淀到维度表中。
维度设计要点
规范化与反规范化
规范化是指使用一系列范式设计数据库的过程其目的是减少数据冗余增强数据的一致性。通常情况下规范化之后一张表的字段会拆分到多张表。 反规范化是指将多张表的数据冗余到一张表其目的是减少join操作提高查询性能。 在设计维度表时如果对其进行规范化得到的维度模型称为雪花模型如果对其进行反规范化得到的模型称为星型模型。 数据仓库系统的主要目的是用于数据分析和统计所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型用户在统计分析的过程中需要大量的关联操作使用复杂度高同时查询性能很差而采用星型模型则方便、易用且性能好。所以出于易用性和性能的考虑维度表一般是很不规范化的。
维度变化
维度属性通常不是静态的而是会随时间变化的数据仓库的一个重要特点就是反映历史的变化所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态通常有以下两种做法分别是全量快照表和拉链表。 1全量快照表 离线数据仓库的计算周期通常为每天一次所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。 优点是简单而有效开发和维护成本低且方便理解和使用。 缺点是浪费存储空间尤其是当数据的变化比例比较低时。 2拉链表 拉链表的意义就在于能够更加高效的保存维度信息的历史状态。 1什么是拉链表 2为什么要做拉链表 3如何使用拉链表 多值维度 如果事实表中一条记录在某个维度表中有多条记录与之对应称为多值维度。例如下单事实表中的一条记录为一个订单一个订单可能包含多个商品所会商品维度表中就可能有多条数据与之对应。 针对这种情况通常采用以下两种方案解决。 第一种降低事实表的粒度例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。 第二种在事实表中采用多字段保存多个维度值每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。 建议尽量采用第一种方案解决多值维度问题。 多值属性 维表中的某个属性同时有多个值称之为“多值属性”例如商品维度的平台属性和销售属性每个商品均有多个属性值。 针对这种情况通常有可以采用以下两种方案。 第一种将多值属性放到一个字段该字段内容为key1:value1key2:value2的形式例如一个手机商品的平台属性值为“品牌:华为系统:鸿蒙CPU:麒麟990”。 第二种将多值属性放到多个字段每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。
