苏宁数据仓库应对数据爆发式增长的技术演进

在实际大数据平台开发过程中，产生唯一代理键和生成缓慢变化为拉链表是比较困难和复杂的，在很多实际的场景中是基于计算周期，每个周期生成一份快照表，保留每个周期的快照数据，采用快照表方式维护简单使用也比较方便，弊端也很明显浪费存储，在数据量不是特别大的情况下使用此方式还是比较合适的。

层次维表

通常维度之间往往存在层次关系，关系的层级可能是固定的，也可能是不固定的

• 固定深度层级：比如苏宁采购目录层级关系，表现为固定四级层级关系，为提高查询性能，将表设置为固定四层宽表。如下图：



• 深度轻微差别层级：比如苏宁销售目录关系，表现为三到五级层级关系，层级关系不固定，但层级深度有限，可以基于最大深度和业务规则建立维度表。如下图：



• 深度可变层级：对于深度层级不确定维表，在建模和使用都相对较复杂，可以采用桥接表方式，对每个可能的路径保留一行，确保能遍历所有层次。还以销售目录举例，如下图：

由上图可见，桥接表加工处理比较复杂，且带来双算的隐患，实际模型设计中，多选择扁平化模型设计方法来解决业务问题。

事实表设计

维度模型设计过程

• 选择业务过程：业务过程由组织完成的微观活动。例如易购交易过程包含：下单、支付、发货、收货、退货等，明确了业务过程根据业务需求选择和建模有关的业务过程。
• 申明粒度：确认事实表中每一行数据的准确粒度，以交易过程举例，对应粒度为交易时间、会员、商家、商品，申请粒度和主键(单号)等价，不要以数据主键来定义数据粒度
• 确定维度：根据业务需要确认需要分析的业务维度，包含时间、地点、人物、环境等，常见包含日期、会员、商品、渠道、设备等
• 确定事实：事实也称为度量，根据业务需要和数据来源确认度量。

事务事实表

事务可以理解为业务操作最基本的动作，他可表示特定时间、空间发生的一个事件。如果某个事务发生，将在对应事实表中建立对应一行记录，它能实现对细节行为数据的分析。

如下已订单下单和支付过程具体，如下图：

在实际设计过程中，如果多个业务动作的维度和度量都基本相同，可以考虑将多个业务过程合并为一张事实表，合并可以减少数据开发工作量和方便以后业务变更。如下图：

周期快照事实

如果希望分析某个业务在某个固定的、可预测的事件间隔内的累计性能，可使用周期快照事实表，利用周期快照可对一天、一周、一个月结束时建立数据快照，存储到事实表中，周期快照事实表可用于记录事实每个周期的变化情况。

例如我们业务中通常对会员累计支付金额、积分余额、会员等级、商品库存等做周期快照，方便分析会员、商品等属性对应度量值，而不需要长期聚集事务历史。

累计快照事实表

累计快照表示具有确定的开始和结束时间以及此期间所有中间过程的步骤，累计快照适中会表示多个日期外键，表示主要时间或过程里程碑。

以交易过程举例，统计订单对应下单到支付时长、支付到发货时长、发货到收货时长、支付到收货时长等，事务事实表计算复杂，性能差，比较适合采用累积快照事实表。如下图：

离线数据处理

1)表存储格式

尽可能避免使用textfile存储格式。数据内容中时常会出现换行、tab等一些特殊字符，使用textfile容易出现数据行错位、列错位等情况，如果特殊情况不可避免使用textfile格式，尽量选择json文件格式，或者多个特殊分隔符作为行和列分隔符。

2)数据压缩

建议使用orc或rc等压缩方式存储表，以cpu换存储和时间 ，加快读写效率。

3)数据倾斜

在表数据处理过程中，多种情况会发生数据倾斜：

1. 大小表关联，走common join，由于关联key值在大表中分布不均匀，可以开启mapjoin，将小表加载到内存，大表不需要根据key做hash分布，不会出现数据分布不均情况。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!