共计 3656 个字符，预计需要花费 10 分钟才能阅读完成。
这一篇整顿下订单域的数仓设计。目前市场上的企业都有很多销售渠道，线下门店以及各个电商平台，那么要想及时理解销售状况，获取、整合数据以及进行剖析就显得尤为重要，订单模型就是一套依照迷信零碎的办法设计的整合所有渠道订单数据的、省去人力反复加工数据过程的分析模型，所以订单模型对于大部分企业来讲还是很有价值的。我做过三个我的项目的订单模型设计，接下来就依照这个分类说说订单模型设计的那些事儿：
- 订单模型设计指标
- 订单模型组成
- 数据获取和传输
- 业务梳理
- 数据源探查
- 订单模型设计
- 订单模型利用
一、订单模型设计指标
1. 统一口径，增强数据可解释性
如果一家销售美妆的企业，有多家线下门店，电商平台有淘宝、京东、微商城，那么如果想查看最近一个月的销售额，则须要手机各方数据再进行汇总，期间可能会因为工夫统计周期不同或者销售额口径不统一（例如线下门店是营收额，电商平台是减了退款的不含税的销售额）导致最初的后果失去准确性和可解释性，进而失去剖析的意义。订单模型在设计之初就会对立销售渠道的数据口径，确保数据对齐。
2. 缩短数据获取周期和老本
以上统一口径中提到的例子中，数据获取可能还绝对容易些，因为各门店和电商平台都有本人的销售额看板，然而想剖析明细数据的话，就须要自行导出各个平台的明细订单数据，期间可能会因为各个平台的商品编码、订单状态不对立，须要对商品编码、订单状态进行 mapping 转换，在进行真正的剖析之前就减少了很多前置预处理工作。那么订单模型就承当了这个工作，对立各渠道数据，独特应用一套数据字典，并且应用数据工具定时拉取个平台的数据进行整合计算，极大地升高了剖析数据的老本。
3. 便于数据分析
当订单模型上线之后，数据分析人员就能够持续订单模型进行不同维度的剖析探查，缩小了数据获取和剖析的老本，更具时效性；若指标探查后具备剖析意义，可落地成标签或者报表指标，由平台主动计算。
二、订单模型组成
订单模型个别由“订单父表”和“订单子表”组成，搭配“维度模型”一起应用。
1. 订单父子表
订单父表是基于订单维度的一张表，个别蕴含订单的编号、工夫、状态、渠道，消费者信息，收货人信息，数量金额信息以及门店信息等；而订单子表是订单明细表，除了记录订单的根本信息外，还会记录商品明细的一些信息，例如商品编码、商品价格等。
2. 退单父子表
退单父子表和订单父子表是一一对应的，退单次要记录退货商品的数量、金额以及正向单据的一些信息，用于正负单关联，得出减退款退件口径的指标。
3. 维度模型
订单模型个别搭配维度模型应用，维度模型常见有“商品维度模型”，存储商品的详细信息如编码、生产日期、容量、分量等，个别商品信息繁多，全副存储在订单模型会显得十分冗余，而且剖析场景不是特地频繁的状况下，能够只在“订单模型”保留商品编码，须要剖析商品其它维度信息的时候，能够用“订单模型”关联“商品维度模型”进行其它粒度的剖析。
三、数据获取和传输
个别数据仓库是一个独立于各平台的企业级的数据库，各个销售渠道个别有独自的数据库，那通常获取源数据的形式有三种：
- API 获取：须要开发 API 接口，有开发成本，而且 API 提供方可能因为各种因素会限度数据的返回数量；然而对于数据提供方来说，这种形式更平安更灵便；
- 应用 ETL 工具：从源数据库通过脚本和工作加载到指标数据库，对应用方来说比拟不便；然而对于数据提供方来说有安全隐患，数据权限和调用频率也不好管制，个别也是抽取源的备份数据库；
-
文件传输：也能够应用 excel、csv 或者 txt，上传 SFTP 服务器。
个别数据传输周期是 T+1，当然也有实时传输的场景，可用 kafka 等音讯队列进行传输。四、业务梳理
1. 明确数据的业务含意
这一步尤其重要，要先明确各渠道订单数据字段的含意和口径，能力确保数据的真实性和可解释性，例如“销售额”须要明确：是否含税、是否减退款、是否减折扣、是商品总金额还是付款金额，“订单工夫”须要明确：是下单工夫还是付款工夫还是发货工夫等。
另外对于用户信息也须要分外留神，明确手机号、openid 之类的数据是明文还是密文，因为后续触达的话须要保障身份信息可用。2. 明确业务规定
- 数据更新场景
因为波及到指标数据库的数据更新，所以要理解哪些状况下订单数据会更新。常见的有订单状态、订单 工夫的更新，以及退款之后金额字段的更新，那么一笔订单从创立到关单的周期是多长也须要理解。 -
业务规定
常见的业务规定比方淘宝店铺积分是如何产生的、积分有效期如何计算、店铺会员是什么折扣、套装折扣产品的成本价如何计算等等，这些须要依据具体业务场景细细理解，才便于发展后续的建模以及剖析工作。五、数据源探查
1. 主键确认
这一步对于订单数据更新也很重要，个别订单表的主键是“订单编号”或者“数据库自增 id”，订单明细表的主键是“订单编号”+“商品编码”或者“数据库自增 id”，然而通常状况下可能不会这么简略，因为很多订单零碎设计的不太正当，这时候能够做一些解决，以下是我碰到的几种状况：
- 订单明细表一笔订单存在多行雷同商品编码的订单明细，产生多行的起因是一些商品加入了套装流动，价格产生了折扣即不同于单品的价格，当用户独自购买了该单品和含该单品的套装时，该商品因为价格不同就会被拆成 2 行，那么在订单明细表没有其它主键标识的状况下，如何标识主键进行后续的数据更新呢？
– 最间接的方法还是从源头解决，革新源订单零碎，减少主键标识；然而在源订单零碎没方法革新的状况下，也能够用一个笨办法，即指标订单表用“订单编号”+ 自生成的“订单明细序列号”作为主键，当源表订单中任一明细产生扭转的状况下，抽取该订单的全副订单明细更新该订单的所有明细。 -
订单父表主键为“订单编号”+“门店编码”，且主键存在反复，那第一步须要查看反复订单的信息是否雷同，若全副雷同的话，则可间接疏忽；若主键雷同订单的订单信息不同，则须要查看起因，是否订单源零碎的问题，是否修复，若是极少产生的事件，则能够手动更改历史订单的主键信息；若是常常产生的状况，则须要源订单零碎做数据上的修改。
2. 身份 id 探查
在业务梳理的时候理解到的身份 id 例如手机号、openid 等，须要探查数据的可用性和填充率：
例如手机号是否非法、是否为虚构号，openid 是否非法、字符串是否含空格等；如有空格之类的可解决的须要荡涤掉，不非法的身份 id 须要从源头思考怎么能获取实在可用的数据，或者有没有其它的 id mapping 关系能够关联获取，进步身份 id 的填充率；3. 数据字典
搞清楚字段的含意之后，就须要对立各渠道的数据字典，便于后续剖析。
- 例如淘宝的订单状态为：
已下单
已付款
已发货
已收货
京东的订单状态为：
未付款
已付款
期待发货
已发货
确认收货
那么从业务流程来讲，京东的”未付款”、“已付款”、“已发货”、“确认收货”和淘宝的“已下单”、“已付款”、“已发货”、“已收货”是一个含意，须要对立名称；京东的“期待发货”较淘宝是多进去的一个中间状态，能够保留，相当于看不到淘宝订单已付款未发货的订单，只能看到京东这个状态的订单； - 再例如商品编码对立，我之前碰到企业各渠道的商品编码不对立，例如 一款洗发水，A 零碎存的是“S001 450ml”，B 零碎存的是“S001_450ml”，这个时候就须要进行对立荡涤解决；
-
另外还有其它字段：领取形式、退款状态等都需一一对照对立，可依据理论业务而定。
4. 异样值解决
订单中可能还会呈现一些异样值，例如超过字典范畴的枚举值，需确认是否新的枚举或是异样，异样是否能够置空或者转换成其它枚举值；例如日期字段存储成了数值，是否能够将该日期间接置空，或者用其它日期字段赋值。
5. 确认数据类型
除了以上步骤，最重要的就是确认数据字段类型了，这会影响到后续指标的计算，例如日期是什么格局、数值类型的是 int 还是 decimal，数值类型是否有空值（计算过程中需将 null 转 0），字符串长度是否超过存储要求等等，非凡状况能够根据理论状况来调整。
六、订单模型设计
1. 字段对齐
通过之前的业务梳理以及数据源探查之后，数据能够说是荡涤洁净了，那么就到了订单模型设计阶段，其实比较简单，只需将各个源业务零碎的字段分类，而后对应起来即可，如果对应不起来的，独自存在即可，另外也可依据字段信息重要成都酌情删减；常见的订单父表分类如下：
订单子表除了订单根底信息模块和订单主表不同，还多了商品信息模块：
2. 数据荡涤加工
设计好之后就能够进行数据 ETL 的解决，个别将源零碎的订单数据分表存储在 ods 层，在 dwd 整合成“订单主表”和“订单子表”，在 dm 层进行个性化指标的计算；当然这个分层也不是相对的，也要依据具体实施我的项目的产品和条件来定。
七、订单模型利用
整合好的“订单主表”和“订单子表”能够作为“数据集”放在数据分析平台，供 Marketing 共事 或者 数据分析人员进行剖析，dm 层的数据能够作为报表展现，或者能够创立标签。个别 dm 和 标签的数据周期都是 T+1，当这套模型落地并投入使用后，能够节俭重复劳动，极大的升高数据的剖析老本，更好的辅助输入销售策略。