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