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

数据仓库总结

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

历史的浪潮

1、数仓痛点

• 感受到疼痛的点

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

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

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

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

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

• 离线的报表。

数据模型

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

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

数仓规范

离线处理：对一段时延的数据要求；比如用户作弊判断、日周月交易量横纵向比对
实时数仓：实时的交易量，一般在小时级别下；Flink、flume、kafka等架构

外围系统建设

调度：AirFlow、Oozie、Azkaban
离线计算：HiveSQL优化：数据倾斜问题，小表关联大表、大表关联大表、排序等情况下的MapReduce原理【埋个坑】
数据质量监控DQC：

发展方向展望

数据化思维：1、全局的想法：任务拆分成那些指标，指标如何落地；事后如何去评估；工具化实现；