【分享】大数据数据仓库体系技术与架构

爆炒小提莫

大数据领域内，数据仓库建设会面临以下问题：

• 数据时效性高
• 业务灵活多变
• 数据源多样性
• 数据质量参差不齐
• 应用场景复杂
  

在针对各种问题和场景，在做技术选型和低层技术架构的时候需要考虑：

• 梳理业务和相应的应用场景
  

整个企业的应用场景有哪些，比如电商场景，推荐要不要做，数据化运营，广告投放需不需要做，所有的场景都需要考虑到

• 需要处理的数据源的种类、类型、数据量
• 对时效性要求
  

T+1，H，Realtime

• 对灵活性要求
• 对性能要求
• 整个etl的性能
• 对成本要求
  

维度建模

• 数据仓库，不针对某一个分析主题，而是有多个分析主题，即多个事实表，维度怎么设计？
• 即使同一个分析主题,也可能存在多个事实表,维度表如何设计?多个时间维度?
  

代{过}{滤}理键
维度表中必须有一个能够标识一行记录的列，通过该列维护维度表与事实表之间的关系，一般在维度表中业务主键符合条件可以当作维度主键。
是由数据仓库处理过程中产生的、与业务本身无关的、唯一标识维度表中一条记录并充当维度表主键的列,也是描述维度表与事实表关系的纽带,所以在设计有代{过}{滤}理键的维度表中,事实表中的关联键是代{过}{滤}理键而不是原有的业务主键,既业务关系是靠代{过}{滤}理键维护,这样有效避免源系统变化对数仓数据对影响

在实际业务中,代{过}{滤}理键通常是数值型、自增的值

• 问题:传统数据库有自增id默认功能,但Hive中怎么生成自增的代{过}{滤}理键?
  

[SQL] 纯文本查看 复制代码

insert overwrite into_dim_goods d partition(dt=2018-06-01)
select
row_number() over (order by id)+ta. max_id as gid
from tmp_s_inc as tb
cross JoIn
(select coalesce(max (gid),0)as max_id from dim_goods d where dt='2018-05-31') ta
union all
select * from dim_goods_d where dt= '2018-05-31'

稳定维度
部分维度表的维度是在维度表产生后,属性是稳定的、无变化的;比如时间维度、区域维度
等,针对这种维度,设计维度表的时候,仅需要完整的数据,不需要天的快照数据,因为当
前数据状态既是历史数据状态




难度好高，还在理解中