在阿里做过几年电商业务，越发认识到，做电商的，怎么都绕不过商品，
最近几年特别火的千人千面，商品知识图谱，都离不开商品数据的支持。
在展开分析之前，先来思考一个问题，追根溯源，什么是商品？
理解一个概念，不能离开上下文。
为了更加真实和准确的反映实物，我们通过创建不同的模型，组合不同的属性去描述商品。也就是说，商品可以理解为线下实物商品的数字化。
商品连接交易，电商时代的特点是一切皆可交易，所以商品的概念也越来越宽泛。
实物商品在线下是如何流通的？
那么到了线上，商品如何流转？
既然是流转，那就会有一个链路，围绕商品领域，可以把整个电商上下游分为供应链路和销售链路。
大家都学习过计算机网络原理，我们在学习网络协议的时候，信息的传输是需要网络协议来管理，网络协议定义了编码和解码的规范。
类似的，商品信息在线上的流转，需要一个模型去承载，也就是商品模型。
通用的电商商品模型包括商品、SPU以及SKU，以及在这个基础上发展出来CSPU的概念，形成了下面的结构。
在业务中，通过SPU和CSPU对商家发布商品进行强管控，同时对商家对SPU和CSPU属性的填充，又扩充了基础属性和基础属性值库，在运营审核的过程中，这些基础属性添加到标准属性和对应的类目属性下。
商品特指与商家有关的商品，商品通过SKU和库存，来对应到线下的实物商品。每个商品会对应一个商家，每个商品下面有多个颜色，款式，可以有多个SKU。
例如，Iphone12是一款产品，但是当平台上很多商家在出售这个产品的时候，我们就把Iphone12称为一个商品。
SKU的英文是stockkeepingunit(库存单位)，SKU即库存进出计量的单位，可以是以件、盒、托盘等为单位。在服装、鞋类商品中使用最多最普遍。
在谈到SPU之前，先来思考一下，有了类目和SKU，为什么要定义一个SPU？
SPU概念的出现，是为了满足在叶子类目下对商品进行进一步抽象的需求。
还是用手机举例子，一般来说，手机就是叶子类目，那么我能不能添加几个苹果手机/华为手机的类目呢？
当然可以，但是这样类目树就会变得非常庞大，所以，SPU是在「对商品约束进一步细化的需求」中各方平衡的结果。
SPU(StandardProductUnit)标准产品单元，是对某一类标准产品的共同特征属性的描述，是商品信息共有属性的一种抽取，在淘系商品中，SPU是由后台类目+一组关键类目属性唯一确定。
SPU是一个介于叶子类目和商品之间的概念,是对类目的细化，是商品标准化运营的基础。
SPU有哪些应用呢？
举几个简单的例子，淘宝购物车的找相似功能，就是通过SPU去关联商品。
还记得多年之前轰轰烈烈的比价网站吗，比价网站的核心业务就是围绕SPU。
CSPU是淘宝特色的一个商品模型，这里的C是Child的意思，也就是子标准化产品单元，即SPU的细分，更细粒度的标识产品。
“类目+关键属性+销售属性”唯一确定一个的细粒度产品CSPU。
比如手机类型下，品牌和型号这两个属性可以确定一个SPU，但还不能标示一个CSPU，需要额外的销售属性来确定；
以苹果手机为例，品牌是IPhone，型号是12，颜色为深灰色，存储卡256G，两个关键属性是品牌和型号，两个销售属性为颜色和存储卡。
类目属性体系和商品领域相辅相成，打个不恰当的比方，类目树是坐标轴，类目属性是坐标，商品就是其中的点。
类目是商品所属的分类，类目决定了商品的归属。
类目是有层次的，分为一级类目、二级类目等，之间有继承关系，通常是通过类目树来展现。
比如厨房电器这个一级类目下，有电磁炉，冰箱等二级类目，电磁炉下面还会有细分的三级类目，类目树的最下面一层类目是叶子类目，一般来说，只有叶子类目才可以下挂商品。
通常来说，电商业务里有两大类型的类目体系，一种类型是后台类目，主要用于商家发布商品；另外一种类型是前台类目，主要用于前台商品导购。
后台类目是商品的实际归属类目，卖家在发布商品时，将商品发布到指定的后台类目下。淘系定义的类目最多四层，类目层级太深会影响商家商品发布的体验。
前台类目用于在前台进行导航，展现，搜索定位用，前台类目中保存的，实际上是对后台类目/属性的筛选条件，即映射条件。
用户通过前台类目搜索到该类目所映射的后台类目下挂靠的商品，但是商品只归属于一个后台类目。
前台类目主要用来导购，导购路径过长会导致转化率下降，一般来说，前台类目不会超过3层。
类目属性是类目下的商品所具有的共同特征定义，关联叶子类目和属性，比如手机类目具有品牌、型号、颜色、网络等属性。
和类目属性对应的是类目属性值，表示类目下的商品所具有的某一个特征的值。
属性是用来描述商品的，为了更好的对商品进行描述，对类目属性进行一层抽象，也就是类目属性分类。
一般的，类目属性可以进一步分为关键属性，绑定属性，销售属性，商品属性。
属性用于描述商品具有的特性，比如颜色、尺码，只靠属性不能描述商品，需要说明属性值才可以。
读到这里你肯定也意识到了，属性库其实类似元数据的概念，也就是「描述商品数据的数据」。
属性库既然是元数据，就要支持大部分的商品描述，目前主流电商平台的属性库数量都是在百亿级别。
现在思考一个问题，那么这么多属性，都是靠运营手工录入的吗？
另外大部分数据，来自商家和平台的共建，也就是通过商家来输入。
这里又有一个问题，如果商家在发布商品时创建一个根本不存在的属性，比如上架一部手机，内存选择100TB，平台如何解决这种问题呢？
典型的解决方案，就是淘宝的商品审核机制。
以淘系为例，属性库分为标准属性库和基础属性库，其实就是对应两套数据表。
基础属性库和属性值来自商家发布商品时录入，类目运营通过人工审核、算法审核等方式，会把部分属性添加到标准属性库。
标准属性库维护的是经过审核的，类目上直接可用的属性，而基础属性库，来自商家在发布商品和spu过程中直接录入的数据。
经过运营审核、机器审核、数据清洗等流程，基础属性数据会流入到标准属性，作为整个平台属性库的扩充，在其他商家录入商品时，可以直接依赖，实现属性的复用。
属性库不只有K-V结构这么简单，还需要一些别的规则来约束。
属性有一个概念叫输入类型，因为不同的属性有的可以枚举，有的只能文本输入。
比如商品的产地，是固定的行政区域，但是如果是重量，就没办法通过枚举表示完全。
一般来说，属性可以分为枚举，枚举可输入，可输入三种，另外某些复杂类目下还有属性模板的定义，用于某些无法提前枚举的子属性填充。
特别的，部分属性有子属性的概念，比如阿迪达斯的三叶草系列，就是隶属于阿迪达斯这个品牌属性值下边的。
如果没有子属性的概念，单纯通过笛卡尔积来表示，在发布商品时就会出现太多的属性值并列，导致无法筛选，并且出现很多不存在的属性组合，而多级属性，就可以解决这个问题。
上面的商品模型，都是偏向销售链路，在供应链路，商品模型又会有一切不同，简单列举几点。
刚才说到，标准的电商类目体系会分为前台类目和后台类目，其实在商品模型中，也会分成前端商品和后端商品。
为什么要分前端商品和后端商品呢？
前端商品可以理解为分销商品，后端商品可以理解为供销商品。
举个例子，你在网上购买一个空调，实际上呢，这个空调分为室内主机和外机，内机和外机在仓储上和可能是分开的。
为了解决这种情况，就可以通过前后端商品模型，将前端的空调商品，与后端的空调内机和外机关联起来，最终计算库存时，是使用内机商品和外机商品的库存。
还记得啤酒与尿不湿的故事吗？
埃隆马斯克有个特别推崇的第一性原理，第一性原理要求我们回归本质，找寻最基本的要素，建立更简洁完整的架构体系。
商品模型的变化，都是为了更好的描述现实世界的实物商品，满足业务要求。
从这个角度看，电商业务中，商品模型就具有第一性，熟悉了底层商品模型，在面对上层的各种业务变化，就可以游刃有余。