订单仓库建设实践

背景

某OTA门票的数据源分布在业务线的各个组内，订单系统、景区系统、产品系统、供应商后台系统、点评管理系统等。订单仓库涉及到的数据包括订单基础数据，景区基础数据，产品和票种数据，供应商基础信息等。门票订单基础订单包含以上数据的主键，在仓库建设中需要将门票的完整订单数据拼接到一起。例如订单基础信息表中有产品的id，但是没有产品的创建时间，使用期限等信息，同理也没有供应商对应的地域等信息。

订单仓库要尽可能将订单涉及到的、大家普遍关注的数据汇总到一起，方便大量查询。

订单仓库

订单仓库的架构图简单可以用下图来描述。

数据源

最上层是由业务线只读数据库同步过来的同构的数据表，在门票订单仓库中，包含的数据源主要包含订单、景区、产品、供应商等数据。订单数据包含订单流水表，订单基础表，订单分账表，订单扩展表等。景区数据包含景区基础表，景区标签表，景区聚合表等。产品数据是最复杂的，包含产品的基础信息、货架信息、票种信息，产品分类信息等等。这些数据同步到数据侧作为订单仓库的ods层。

数据仓库

订单的数据仓库主要包含三张表：流水事实表、订单事实表、订单宽表。

流水事实表

这里的流水事实表是指的聚合事实表，主要关注订单的资金变化，将每天有资金变动的订单多条几录做聚合，得到订单在当天的事实数据。例如在一天之内，一个订单从成单到退款，那么订单至少包含两条流水记录，一条支付的流水，一条退款的流水，对于分账信息也会含有同样的两条记录，那么对于这个订单在当天的资金事实数据就是0。流水事实表主要承担的是财务口径的各种统计数据，可以得到业务线在当天的绝对利润数据。

订单事实表

和流水事实表一样，订单事实表也是聚合的数据表。订单事实表是将当天有变动的订单信息更新到数据仓库，对订单基础信息做轻度补充，例如将景区数据、供应商数据等部分信息补充到事实表中。订单事实表在仓库中过多承担的是宽表的过渡表，只包含部分通过表关联得到的订单数据，相当于是数据丰富后的订单基础信息表。

订单宽表

订单宽表依赖于订单事实表，以及其他维度表。基于事实表对订单进行分类，得到订单的归属，例如订单是测试单、黄牛单、刷单等等。用户维度表部分是将用户的基础信息补充到订单中，得到下单用户的完整信息。订单宽表综合以上数据，得到一个订单需要关注的各方面信息，宽表的作用是承担业务线在订单方向上方方面面的应用，理论上所有的订单上层数据分析和查询都要依赖宽表。所以宽表不是一层不变的，是随着业务的变动和发展方向不停扩充的。

数据集市

宽表是为了使用的方便，宽表之上是数据集市层。这一层需要什么维度的数据是一个问题，目前的建设主要来自两个方向：第一，数据开发组根据以往的使用情况将常用的指标进行统计汇总；第二，运营数据等的需求驱动；第一类相对来说统计的更宽泛，尽可能将更多的维度假如到统计表中，例如对于地域销量数据的统计，会按照城市取汇总，但同时会将省份一级国家信息放进去，以便后续统计省份粒度的销量。第二类的统计会更偏重于定制化，C端产品看的数据和B端产品关注数据的角度不一样，那么就会按照他们不同的需求出不同的数据汇总，但也不是完全定制化，数据开发需要做一步分抽象处理，尽可能的将共同的数据放在一起。

数据应用

数据应用层是距离用户最近的，一般会的方式有三种：1. 邮件报表，一般会将每天最核心的数据放在邮件中，例如每天的GMV，利润，销量等数据，发送给业务线的主要负责人。2. 自助查询，自助查询是相对通用灵活的手段，在数据平台提供给每个人写sql的权限，通过一些小的trick将最常用的查询条件外置，生成查询之后可以提供给有权限的人使用。需要注意的是不是每一个使用者都是数据开发，所以sql写的也都参差不齐，需要注意一下sql的执行性能问题。3. api应用，完整的数据应该是闭环的，业务产生数据，反过来数据要回归到业务上，统计数据的汇总，通过api再将汇总的统计数据开放出来，提供给各方调用；可以开发api平台，加快接口的开发效率；