如何理解数据仓库
从事数据开发后,再回头来看一看数据仓库的定义:数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。那么如何理解这几个关键词:
- 面向主题的:主题(topic),即分类,专题分析。这里引入了主题模型的思想,实际操作中将数据按照业务线、业务模块层层细分。比如先划分大的业务域,每个业务域再按照业务过程划分数据域(一级、二级、三级数据域)。
- 集成的:数仓系统和生产系统通常是隔离的,把跨源的、分散的多个业务DB的数据同步到数仓系统,按照一系列模型打成宽表的过程就是集成。
- 相对稳定的:每天/每小时分区内数据不频繁更新,即一个任务正常每天只会向一个分区写入一次(回刷数据的时候除外),可以看作这部分数据是一个相对稳定的快照。
- 反映历史变化的:每个周期(天/小时)的快照形成了历史全量数据,即拉多个分区进行聚合(dws)等操作便可以看到历史趋势。
如何设计数据仓库
这个问题可以从几个方面来看:
数据技术:
- 数据采集:常见的有流量埋点日志的采集、数据库的binlog采集等。
- 数据同步:采集的数据同步至数仓系统,数据量小可直连数据库平抽,数量大可通过消息队列传输日志。考虑的主要问题是如何数据延迟、数据飘逸(0点数据落到错误的分区)、删除(删历史数据、删最后一条数据)、遗漏(更新,补数)。
- 数据开发:离线数据开发采用hive、spark sql、odps等,实时数据开发采用flink;存储采用hdfs、hbase、adb、doris、holo等。这里主要是开发技术深度和广度的积累。
- 数据服务:加工好的数据可通过结果表、数据接口、分析看板等形式对外提供。服务以产品化的形式提供,主要考虑的是接口参数的约定,更新频次,qps、命名约定等。
- 数据挖掘:基于加工好的数据训练模型,主要用到一些常见的机器学习算法和统计学知识。
数据模型:
- 关系模型:Inmon提出,用实体和关系(E-R)来描述业务,符合3范式。站在企业角度自上而下的进行抽象、整合和主题建模。但是不适用于业务快速迭代的互联网数仓系统,因为实施周期长。
- 维度建模:Kimboll提出,和Inmon相反的是维度建模自底向上的,面向需求/分析的进行建模。烟囱式的开发,开发周期快。常见的星型模型、雪花模型、星座模型等,实际操作中都是宽表化处理+生命周期,如淘系的大宽表,冗余维度和事实,通常都是几百个字段/标签,这也是目前的主要建模方法论。
- 领域建模:宽表后期的维护很痛苦,后期演化出了一种面向