数据仓库总结

项目上线了，结合数据仓库实战视频，复盘总结下。

历史的浪潮

一文搞懂企业级数据仓库实战

1、数仓痛点

一文搞懂企业级数据仓库实战

感受到疼痛的点

烟囱式开发形成的数据孤岛和重复计算：–建模规范和开发规范

各业务系统都存在汇率、证券信息等公开市场信息的重复计算，重复做；
客户信息表是全量，更新很少，但需要某个历史时刻的客户状态，重复做；

指标口径不一致导致数据可信度下降： --指标字典

同样的股基交易量，要和另一部门的数据保持一致；

产出形式单一： --数据产品和服务化

离线的报表。

数据模型

一文搞懂企业级数据仓库实战

实际项目中，完善了DWD明细层，未衍生DWS、DWM；但根据需要设计了指标中心，服务于应用层；
实际应用中会遇到数仓的两个架构，kimball维度建模和Inmon模式；
Inmon都是以数据源头为导向。首先，需要探索性地去获取尽量符合预期的数据，尝试将数据按照预期划分为不同的表需求。其次，明确数据的清洗规则后将各个任务通过ETL由Stage层转化到DW层，这里DW层通常涉及到较多的UDF开发，将数据抽象为实体-关系模型。接着，在完成DW的数据治理之后，可以将数据输出到数据集市中做基本的数据组合。最后，将数据集市中的数据输出到BI系统中去辅助具体业务。很关注数据的清洗工作，从中抽取实体-关系
Kimball都是以最终任务为导向。首先，在得到数据后需要先做数据的探索，尝试将数据按照目标先拆分出不同的表需求。其次，在明确数据依赖后将各个任务再通过ETL由Stage层转化到DM层。这里DM层数据则由若干个事实表和维度表组成。接着，在完成DM层的事实表维度表拆分后，数据集市一方面可以直接向BI环节输出数据了，另一方面可以先DW层输出数据，方便后续的多维分析。
Kimball往往意味着快速交付、敏捷迭代，不会对数据仓库架构做过多复杂的设计，在变换莫测的互联网行业，这种架构方式逐渐成为一种主流范式。实际案例可两数仓架构的对比

一文搞懂企业级数据仓库实战

实体表、维度表、事实表的关系：
事实表是多个维度表的一个交点。而维度表是分析事实的一个窗口，数据库结构中的星型结构，该结构在位于结构中心的单个事实数据表中维护数据，其它维度数据存储在维度表中。每个维度表与事实数据表直接相关，且通常通过一个键联接到事实数据表中。
星型架构是数据仓库比较流行的一种架构。
事实表是数据仓库结构中的*表，它包含联系事实与维度表的数字度量值和键。事实数据表包含描述业务（例如产品销售）内特定事件的数据。
维度表是维度属性的集合。是分析问题的一个窗口。是人们观察数据的特定角度，是考虑问题时的一类属性，属性的集合构成一个维。
聚合表一种中间表。数据是按照最详细的格式存储在事实表中，各种报表可以充分利用这些数据。一般的查询语句在查询事实表时，一次操作经常涉及成千上万条记录，但是通过使用汇总、平均、极值等聚合技术可以大大降低数据的查询数量。因此，来自事实表中的底层数据应该事先经过聚合存储在中间表中。中间表存储了聚合信息，所以被称为聚合表，这种处理过程被称为聚合过程。
实体表就是一个实际对象的表，实体表它放的数据一定是一条条客观存在的事物数据，比如说设备，它就是客观存在的，所以可以将其设计一个实体表；