该文章所有的思考都是个人理解，不一定准确，也不一定适合所有的零售行业，主要以“业务”，“建模”和“调优”三个大方向来讲述。

业务理解

目前我接触的行业还是以渠道的业务为主，消费者的整体重视程度还是很低，这就导致直接拉通业务沟通的机会很少，很多适合可能只能和开发沟通，而且就算和业务沟通，所能得到的信息也会和实际有所偏差。

因为每个业务系统的业务或者开发其实更多的只能看到自己能看到的，比如我是个以营销为主的平台，我就很少重视订单，更不要说物流或者是退款之类，甚至用户的信息都不一定重视，而是重视会员。

熟悉数据字典

这就是第一条，我们在和业务沟通前或者是沟通后，最好能够将提供的数据字典都过一遍，按照数据域和表名的矩阵来进行划分，通过数据字典来确定可能有的模型。

就拿门店信息而言，可能种种原因，源系统导致没有单独的门店表，但是在订单或者是核销券（领券）中都可能有数据，只有熟悉全部的数据字典，才能真的做到将数据放在该放的位置上，避免维度的缺失。

当然也需要结合业务来考虑，比如上面提到营销为主的平台没有用户信息，那这就代表订单中可能存的用户数据可能杂糅了一部分会员和所有的用户，这二者还是包含关系，了解会员是如何产生，这是很重要的事情。

而且最重要的是，遇到这种特殊的平台，你越应该重视你的模型不需要的表，因为他们或多或少涉及到消费者营销，比如给用户打标签，你如果理解了他们是通过什么逻辑打标签然后什么逻辑来营销客户，就是很牛逼的事情了。

营销为主

承接上文，营销客户是我理解的目前零售消费者在做的事情，无论是各种活动还是发券的核心本质都不能算是在真实盈利，重头还在渠道那边，而营销的目的应该是为了占据市场和稳定市场，当然这是集团级的猜测了，算是我瞎猜，因为零售品的种类太多了，不是所有的零售都是这样。

那我们在建模的时候就需要往这方面去偏向，避免过度设计的前提下，将模型尽可能的丰富，比如券和活动的关系，券和商品的关系，和产品的关系以及和导购和人的关系，而不应该重视券和订单的关系和活动的关系，而不重视其他地方。

营销的主体是人和物，以这两点为起点和重点，在中间不断增加连接点，这样或许能够帮助你更好的理解模型的最终形状。

同义而不是同名

上面说数据字典的看，需要留意看是细看，因为粗看可能会出现同名而不同义的情况，而应该是同义。

比如业务系统中或多或少会有品牌两个字，而商品维表中其实也会有品牌这个字段，而不同的业务系统品牌背后的行业可能是不同的，有些可能是商家，有些可能是商品品牌，有些可能是大的事业部。

避免这种事情的发生有个很简单的办法，约束每个字段的取值范围。

建模反思

当这篇文章的时候，其实整个模型的开发已经接近尾声了，其中有些许的弊端让我整理了出来。

过度设计

上面提到过度设计，我确实犯了过度设计的问题，去年双十一淘宝的订单改版，在主订单的基础上可以在子订单上添加不同的收货人和地址，我就在交易模型的订单商品中增加了收货人的相关信息，但真的有数据吗？其实并没有。

再说其他同事的一些设计，也有些不合理的地方，比如有总积分出现在订单积分中，但总积分出现在订单积分中，在没有大量业务支撑的前提下，这个设计就算是过度设计。

原因很简单，积分的产生和积分的累计不仅仅跟订单相关，存储在一个订单积分的事实表中，而且可能涉及多次关联才能出来的结果，就很奇怪。

分层不分逻辑

这是很大的弊端，分层的概念应该深入人心了，但是分层的理论不应该是不变的，按照ods直接接入，而逻辑处理在cdm中的说法。

如果是大致相同的逻辑还好，但零售行业的消费者数据来自四面八方，在cdm处理的时候就会涉及到各种清洗聚合关联，甚至ods有时候接入的是每天的全量数据，但是业务系统是在原数据上进行修改的，有些则是按照时间接的增量。

只能涉及成基本的事务类型的事实表，最难受的是关联的时候，如果两个表的ods数据处理的逻辑不同，发散问题会搞得人头大。

所以我认为应该在ods的时候能够先处理，至少要确保数据是正常的，而不应该将所有的重任都在cdm层。

雪花模型也不错

说雪花模型不错，是我们这次的建模其实是星型模型，很少涉及到维表之间的关联，更不要提支架表的设计，这就导致只能在事实表中不断冗余字段，当然这样可以更方便使用，带来的问题是事实表的开发会越来越困难。

比如将商品维表的基础上增加规格的支架表，产品的支架表等等，这样可以扩充上面提到的营销为主的关联，而不会陷入需要在不断给事实表增加退化维度的陷阱中，毕竟新建维表的成本在事实表复杂度不断增加的比较下，反而更加合适。

一起调优

看DAG

看DAG图比起纯粹靠脑子要好很多，首先我们能够看出来时间，输入和输出量，能够看出来是那个节点先完成，那个节点后完成，通过不同的任务来确定出问题的节点。

以目前的经验来说，首先肯定是全表扫描的问题，这就涉及到我上面提到的将部分逻辑放在ods处理，而不应该仅仅放在cdm中。

然后就是关联的使用，非必要不关联，如果你的关联在整个DAG中是最长的，那你就需要考虑关联是否正常，是一定要关联还是要调参。

过滤下推

很多数仓的产品其实都在底层有这种优化，但是清楚这些优化，很多时候需要大量时间的积累和对产品的理解，反而显式的去将各种过滤放在逻辑中，更好一点。

过滤的下推也不仅仅是where语句，比如函数的使用，拿最简单的，假如你是bigint格式的时间，要存入datetime中，而取值逻辑是最大的时间，拿max(from_unixtime())和from_unixtime(max())其实实现的功能是一样的，但在底层不优化的情况下，后者肯定比前者更合适点。

开窗等函数的处理也可以按照这个逻辑走。

产品的优化

理解产品的优化很重要，你需要关注产品的定期更新，增加了上面函数，提升了什么效率，比如maxcomputer六月分的时候增加了json字段，以及一批json相关的函数。

再比如说除了set外的优化器的使用，优化器这东西感兴趣的朋友可以上官网去看一下，虽然不一定所有的产品都有，但是思路却是很好的，比如获得该列最大值和最小值，这样可以提前让底层的优化方案更合适，毕竟比起整个类型的范围，还是实际数据的范围更小一点。