一、贴源区（ODS）：存放从业务系统获取的最原始的数据，是其他上层数据的源数据，数据与业务系统数据保持一致，一旦修改、重新同步则其他层的数据也要修改。相关数据表如下：
会员域：商户表、部门表、销售小组表、渠道人员关系表、人员表
商品域：品牌表、分类表、商品表、商品表(渠道)、渠道表、ebay和amazon卖家信息表、订单表、订单明细表、退货订单、自发货配送费、订单退款收款表
仓库域：仓库表、头程池、库存明细表、销售运费池明细
公共域：币别表、国家表
二、逻辑区：从贴源区同步过来并经过处理的数据
1、基础数据：数据字典表、币种表、币种符号表
2、维度表：时间表、商户表、部门表、销售小组表、人员表、品牌表、分类表、商品表、
商品表（渠道）、平台表、国家表、销售渠道表、仓库表
3、事实表：订单表、订单明细表、结算表、结算明细表、销售运费池表、SP广告日报表、
SB广告日报表、SD广告日报表、月仓储费表、长期仓储费表、库存超量表表 、移除订单、费用表
三、集市区：直接提供给前台接口查询的数据
1、日报表
2、月报表
数据库使用华为云PgSQL，采用分区、分布存储（考虑到数据量过大），分区键使用时间字段分区
报表系统页面：页面有多个维度展示数据报表，时间、sku、渠道sku、asin、父asin、平台、国家、部门、渠道，时间维度，从时间上又有日维度、周维度、月维度、季维度、半年维度、年维度
日维度、周维度查询日报表，月、季、半年、年查询月报表。
出现的问题及解决方案
1、当选择月、季、半年、年维度时，时间上又选择了头尾不足一个月的，如选择了时间范围2021-01-15~2021-03-15,查询时2021-01-15~2021-01-31和2021-03-01~2021-01-15查询日报表，再查询月报表的2021年2月份数据，进行union all。发现性能过慢，则前台进行限制，选择月、季、半年、年时，只能选择整个月的时间，日、周只查日报表，其他时间维度只查月报表。
2、上线生产以后，发现当数据量大了一些以后，性能还是过慢，每个页面的接口基本都要7、8秒才能出现数据，慢的接口甚至要半分钟才出来数据。
a.集市区的表设计采用的是标准的微服务表设计，即一个表只存另一个表字段的id（代理id、主键），当需要另一个表数据时再关联表查询，没有对需要的数据做冗余，比如汇总表的商品名称只存对应的id，当需要时关联本地商品表查询，除此之外还有分类、品牌、渠道等等，页面查询时只使用一条sql需要关联太多的表导致性能过慢----->对于页面需要的信息做一定的冗余，不仅仅只存id，尽量减少表关联,尤其是大维度的表，如本地商品表、渠道商品表等，这种都是百万级别的表。
b.页面要显示的数据是根据维度汇总的，所以sql要group by和sum等一系列计算-----无法解决
c.页面要显示不止一种币种金额，随页面选择原币种（后面取消）、人民币、美元，为了应对多币种金额，开始每个金额字段设计的是数组类型，分别存储原币种、人民币、美元对应的金额----->每种币种存储一条数据，不再使用数组存储，尽量减少sql中的运算。
d.因为页面进来时最先显示的是时间维度（除了时间、币种外没有其他查询条件），所以为了给用户一个系统良好的印象，在表里生成时间维度的数据，这样可以以最快的数据查询数据。