关于金额
金额可以说是交易信息中的重中之重，而交易信息的来源渠道又大致可以分为三类，一类是互联网，包括但不仅限于淘宝，京东，自建小程序，团购等；一类是大型商超，比如家乐福，盒马等；最后一类则是线下数据，可能是来自业务人员手工记录的小门店数据，也可能是文本信息扫描后解析出来的数据。
互联网金额数据
针对来自互联网的金额数据，应该要先拆解对接的关系型数据库中的表逻辑，然后在根据自己的模型拿取对应的字段，但是需要注意，ods的数据理论上会在dwd过滤，然后再在dws关联维表，但实际上，因为互联网数据的来源也不同，无法在dws再进行关联。
所以针对这一部分数据，我们需要注意的是关联，确保关联的时候不会造成发散，比如子表有物流状态，模型不需要该状态，就需要在开窗或者分组聚合的时候确保不因为一个状态导致整条数据异常；还需要确保的是关联的逻辑是否真的正确，跟着需求文档走的同时，需要自己明确关联出来的数据大致样子，避免出现无意义的join。
线下数据
这一部分的数据质量最糟糕，不过对于他的需求也基本最简单，不会是非黑即白，基本上只要结果和预期相同，就不会有太大的问题，但是需要留意的是清理脏数据的时候，需要跟需求明确具体的清洗规则，面对商品金额里面放的某个汉字的数据是直接过滤还是单元格置空。
商超数据
商超的数据不会像互联网那么复杂，也不会像线下数据那么凌乱，却也兼备了二者所有的缺点，他需要在没有逻辑中找到合适的逻辑，可能面对关联键的缺失，比如商超退货的时候，退货单号可能就不存在，再比如溢价出售导致优惠金额是负数。
面对这种数据，需要结合互联网数据和线下数据，先摸清楚主要字段的情况，然后找需求以及对接开始拉通，同时在开发的时候尤其要着重确定数据的异常是否是真的异常，避免自己将正确的数据卡掉。
关于用户
交易的用户这一块其实也可能分为两类，一个订单号对应两个用户，以及订单的用户没有出现在用户信息中。
用户的不同
用户重复可能是因为领取优惠券的用户和使用优惠券的用户不是一个用户，面对这个情况需要先确定量级以及金额数，反馈给需求，确定后续调整方案，看是否将二者的用户选择一个，或者是将二者同时保存；当然也可能是因为线下数据等导致脏数据，这里需要让人拉通，选取较为正确的用户id。
用户的缺失
首先看调度，毕竟当你查了一圈，发现订单ods的调度比用户ods的调度要晚一个小时的时候，会是怎么样的心情，你不会想体验。
然后需要跟用户的开发确定用户的逻辑，最好将不同用户的来源拆分开，逐个排查，最好根据分区日期以及创建日期和修改日期来确定具体出现问题的日期，看一下是否是有数据源进行了调整，部分表全量推数，而部分没有。
关于商品
商品这一块只要重点放在商品id的确定以及商品名称的清洗，商品id这一块的重点不会在开发这边，商品名称的清洗会落在开发这边，先是剔除脏乱数据，比如*等无意义字符，然后是各种花里胡哨的标注，这里有人会问为什么不关联商品维表，对不起，不是每一个来源数据都有商品维表的。
关于状态和方式
订单状态，支付状态，维权状态，物流状态；我愿意称为四大流氓，五花八门的定义，在dwd用枚举值统一这四大流氓，请先老老实实将他们的枚举值转换为汉字，然后交给需求，再统一具体的逻辑，这个时候在最外面套个case when，比在里面纠结每个枚举值应该转化成什么，要方便很多。
至于说方式，比起状态来说，支付方式，配送方式，优惠方式...这些和状态是一个道理，只是他们可能无法用枚举值来替代，因为他们的方式的太多了，就单独说支付方式，从基本的现金，到支付宝，微信，银行卡，还有各种组合支付，维表是不错的选择。
