为什么说数据仓库、数据库是每个IT架构师都要精通的技能？

互联网行业，除了数据量大之外，业务时效性要求也很高，甚至很多是要求实时的。另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线。

◆ 整体架构

如下图就是数据仓库的逻辑分层架构：

◆ 数据源

数据源，顾名思义就是数据的来源，互联网公司的数据来源随着公司的规模扩张而呈递增趋势，同时自不同的业务源，比如埋点采集，客户上报等。

◆ ODS层

数据仓库源头系统的数据表通常会原封不动地存储一份，这称为ODS层, ODS层也经常会被称为准备区，它们是后续数据仓库层加工数据的来源，同时ODS层也存储着历史的增量数据或全量数据。

◆ DW层

据仓库明细层和数据仓库汇总层是数据仓库的主题内容。DWD和DWS层的数据是ODS层经过ETL清洗、转换、加载生成的，而且它们通常都是基于Kimball的维度建模理论来构建的，并通过一致性维度和数据总线来保证各个子主题的维度一致性。

◆ DWS层

应用层汇总层主要是将DWD和DWS的明细数据在hadoop平台进行汇总，然后将产生的结果同步到DWS数据库，提供给各个应用。

◆ 数据采集

数据采集的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。

比较常见的就是用户行为数据的采集。先做sdk埋点，通过kafka实时采集到用户的访问数据，再用spark做简单的清洗，存入hdfs作为数据仓库的数据源之一。

◆ 数据存储

随着公司的规模不断扩张，产生的数据也越来越到，像一些大公司每天产生的数据量都在PB级别，传统的数据库已经不能满足存储要求，目前hdfs是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

在离线计算方面，也就是对实时性要求不高的部分，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC/PARQUET文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；而在实时计算方面，flink是最优的选择，不过目前仅支持java跟scala开发。

◆ 数据同步

数据同步是指不同数据存储系统之间要进行数据迁移，比如在hdfs上，大多业务和应用因为效率的原因不可以直接从HDFS上获取数据，因此需要将hdfs上汇总后的数据同步至其他的存储系统，比如mysql。

Sqoop可以做到这一点，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库。阿里开源的dataX是一个很好的解决方案。

◆ 维度建模

维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法。

1、 星形模式

星形模式(Star Schema)是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：

可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：

• a. 维表只和事实表关联，维表之间没有关联
• b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码
• c. 以事实表为核心，维表围绕核心呈星形分布

2、雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。

3、星座模式

星座模式也是星形模式的扩展。基于这种思想就有了星座模式：

前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

4、三种模式对比

归纳一下，星形模式/雪花模式/星座模式的关系如下图所示：

雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。

◆ 元数据管理

元数据通常定义为“描述数据的数据”,在数据仓库中是定义和描述DW/BI系统的结构，操作和内容的所有信息。

元数据贯穿了数据仓库的整个生命周期，使用元数据驱动数据仓库的开发，使数据仓库自动化，可视化。

按照不同的用途将元数据分为两类：技术元数据和业务元数据。

技术元数据指描述系统中技术细节相关的概念、关系和规则的数据，包括对数据结构、数据处理方面的描述，以及数据仓库、ETL、前端展现等技术细节方面的信息。常见的技术元数据有：

• 分布式计算存储元数据，如表、列、分区等信息。记录表的表名、分区信息、责任人信息、文件大小、表类型、生命周期、列的字段、字段类型、字段备注等。
• 分布式计算系统运行元数据，集群上所有任务的运行信息；类似hive的运行日志，包括作业类型、实例名称、输入输出、运行参数、运行时间等。
• 调度任务中的调度信息，包括输入输出字段、依赖类型、依赖关系等。
• 数据质量跟运维相关元数据，如任务监控、运维报警、数据质量、故障等。

业务元数据指从业务角度描述业务领域相关的概念、关系和规则的数据，包括业务术语和业务规则等信息。常用的技术元数据有：

如维度和属性、业务过程、指标等规范化定义，用于更好的管理和使用数据。

数据应用元数据，数据报表、数据产品等配置和运行元数据。

◆ 任务调度与监控

在数据仓库建设中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据清洗任务、数据分析任务等。这些任务除了定时调度，还存在非常复杂的任务依赖关系。

比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；这就需要一个非常完善的任务调度与监控系统，它作为数据仓库的中枢，负责调度和监控所有任务的分配与运行。

◆ 总结

数据仓库建设是一个综合性技术，而且当企业业务复杂的时候，这部分工作更是需要专门团队与业务方共同合作来完成。

因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。

另外，架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。

来源：

https://www.toutiao.com/a6971325463516398084/?log_from=d1ab3ddd9291b_1628128256833

“IT大咖说”欢迎广大技术人员投稿，投稿邮箱：aliang@itdks.com