【分享】大数据数据仓库体系技术与架构
大数据领域内，数据仓库建设会面临以下问题：[*]数据时效性高
[*]业务灵活多变
[*]数据源多样性
[*]数据质量参差不齐
[*]应用场景复杂
在针对各种问题和场景，在做技术选型和低层技术架构的时候需要考虑：
[*]梳理业务和相应的应用场景
整个企业的应用场景有哪些，比如电商场景，推荐要不要做，数据化运营，广告投放需不需要做，所有的场景都需要考虑到
[*]需要处理的数据源的种类、类型、数据量
[*]对时效性要求
T+1，H，Realtime
[*]对灵活性要求
[*]对性能要求
[*]整个etl的性能
[*]对成本要求
维度建模
[*]数据仓库，不针对某一个分析主题，而是有多个分析主题，即多个事实表，维度怎么设计？
[*]即使同一个分析主题,也可能存在多个事实表,维度表如何设计?多个时间维度?
代{过}{滤}理键
维度表中必须有一个能够标识一行记录的列，通过该列维护维度表与事实表之间的关系，一般在维度表中业务主键符合条件可以当作维度主键。
是由数据仓库处理过程中产生的、与业务本身无关的、唯一标识维度表中一条记录并充当维度表主键的列,也是描述维度表与事实表关系的纽带,所以在设计有代{过}{滤}理键的维度表中,事实表中的关联键是代{过}{滤}理键而不是原有的业务主键,既业务关系是靠代{过}{滤}理键维护,这样有效避免源系统变化对数仓数据对影响
在实际业务中,代{过}{滤}理键通常是数值型、自增的值
[*]问题:传统数据库有自增id默认功能,但Hive中怎么生成自增的代{过}{滤}理键?
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'
稳定维度
部分维度表的维度是在维度表产生后,属性是稳定的、无变化的;比如时间维度、区域维度
等,针对这种维度,设计维度表的时候,仅需要完整的数据,不需要天的快照数据,因为当
前数据状态既是历史数据状态
难度好高，还在理解中
页:
[1]