关于目前某游戏直播平台数仓建设规划的思考2_直播业务数据仓库设计方案

• 环境说明：

阿里云E-MapReduce,主要启用Hive工具作为数仓的载体，热数据存储在hdfs上，冷数据及规模数据存储在阿里云oss上。
ETL采用python编码及封装HQL、sqoop、dataX，最后由airFlow统一进行调度。

• 分层架构：

结合传统行业及移动互联网行业的不同特点，及大数据平台下数仓建设的实际，分三层进行数仓的构建，分别是操作数据存储ODS层、数据仓库层DWH、集市数据层DM。
1、ODS
数据来源：关系型数据库mysql、oracle；服务器访问日志accesslog、系统打点日志。
数据库数据，采用贴源设计的方式，根据实际需要按增量、日增量、全量进行加载；服务器访问日志accesslog解析后装载，采用hive上面的map数据类型，将访问参数尽可能多的全部装载；打点日志，根据设定的分隔符及字段定义进行装载。
命名方式：数据库表，“库名”_“原表名”；accesslog日志表，“log1”_“日志业务含义”；打点日志表，“log2”_“日志业务含义”。
这一层的作用主要是，数据同构，分表的竖向整合；大部分数据加时间戳按日存储。
2、DWH
在这里，DWH数据分两部分，一部分是贴范式的整合数据；一部分是细粒度维度指标数据。这也是与传统数据仓储的不同所在，下面具体说明。
DWH按主题进行范式和维度综合建模，划分的主题大致有用户主题、主播主题、支付主题等。贴范式的整合数据，各个主题以三范式为基准同时又有必要冗余的准则进行数据建模。数据的整合大部分是横向整合和少部分的竖向整合；数据的粒度为原始粒度，不做汇总统计；数据表的格式主要由“主键+属性+扩展属性+指标（很多没有）”这种形式构成。在数据的整合上，与传统行业如银行、证券、电信等又有所区别，不会做过深度的、严格标准的整合，会以使用方便、整合快速为目的，以适应互联网初创公司当前发展阶段的需要。贴范式的整合数据主要是为应对数据明细查询的需要，使查询更加方便快捷，并不能为维度汇总统计提供必需的支持。
细粒度维度指标数据，各个主题下按维度的方式进行数据建模，日期维的粒度最高为天，根据情况个别需要到小时。这些数据一部分来源于ODS里的数据库表数据，一部分来自于ODS的日志数据；需要对他们进行汇总和计算。这些维度事实表，大多为日期快照事实表，有一小部分的事务事实表，绝不会存在累积快照事实表；它们是DM层高度汇总维度事实表的基础。
另外，在上述贴范式的整合数据和细粒度维度指标数据之外，还存在一类代码表或维度表，它们是事实表维度及范式表枚举代码的说明。它们进行统一命名和规范，服务于DWH层的两类表及DM层的高度汇总事实表。
命名方式：“主题名”_“Inm/Kim” _“业务含义”；“CM”_“维表代码业务含义”。
这一层的作用主要是，数据整合，基础维度表建表；为明细数据查询和DM层的集市汇总表做准备。
3、DM
DM层是数据集市层，数据主要来源于DWH的细粒度维度指标数据，并对其进行更高粒度的汇总。DM集市数据按各个应用主题进行存放和管理，是下游报表数据的直接取数依据。这一层的数据，不针对具体的某一张报表，而是针对某一类报表进行数据维度建模。在这一层之后，数据根据具体报表需求，经过汇总计算，传输到存储在关系型数据库(mysql)的报表数据层。
命名方式：“应用主题” _“业务含义”。应用主题有：运营、市场、BOSS等。
这一层的作用是，将DWH中的细粒度维度指标数据进行高粒度汇总，为具体的报表应用提供基础数据。
4、数据层的其他方面
除以上提到的数仓的主要三层架构之外，可能还会有一个专门存储中间临时数据的区域，我们可以以“TMP”命名库；还会有一个存储在关系数据库的报表数据层ADS，专门针对具体报表的结果级及准结果级数据进行存放。报表展示的大部分都是DM集市层星型模型的不同层级的汇总数据，可能也会有一些极少部分的明细数据展示查询需求。

• 方法策略：

1、数据入仓的顺序，优先安排成熟的核心的业务，周边的试验性的业务数据作为次要入仓对象。
2、关于数据的整合，不严格按照Bill Inmon的企业信息工厂CIF理论，在强规范性与时效性方面做一些取舍，以适应移动互联网行业的特殊需要。
3、维度数据低维部分跟整合数据一样存储在DWH层，高维数据存储在DM集市层；这是与其他传统数据仓库的一个明显不同。