现在行业里，谈起技术都要提下“大数据”、“云计算”等关键词，好像不提都显得技术不够档次似的。然而要“玩”好大数据，数据仓库建模尤其重要。这里从概念、必要性、理论与实践3个方面娓娓道来，和可爱的你一起“懂“点数仓建模～
概念篇
数据库（database）与数据仓库（data warehouse）
数据库大家比较熟悉了，这里不再赘述。主要来看数据仓库。
数据仓库是面向主题的（Subject-Oriented ）、集成的（Integrated）、非易失的
（Non-Volatile）和时变的（Time-Variant ）数据集合，用以支持管理决策，具体来看四个特性。
（1）面向主题
面向整个抽象的分析主题，比如交易、营销、广告域等。
（2）集成性
异构数据的集成，比如数据库数据、业务日志、埋点数据等都会集成其中。
（3）非易失性
数据仓库里的数据通常只需要两种操作：初始化载入和数据访问，因此其数据相对稳定，极少或根本不更新。
（4）时变性
数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。
OLTP与OLAP
联机事务处理OLTP（on-line transaction processing），是传统关系型数据库的主要应用；
联机分析处理OLAP（On-Line Analytical Processing），是数据仓库系统的主要应用。
通过表格看下二种应用差异，对数据库和仓库的概念以及二种方式差异理解会更清晰。
上面表格的前面几项对比都很好理解，但是3NF设计是什么概念呢？这就涉及到下一个概念了。
3NF模型与维度建模
3NF建模：采用符合3NF的实体关系模型存储数据。
维度建模：从分析决策的需求出发构建模型，为分析需求服务。
具体来看3NF具体指什么？
1NF：字段原子性——比较好理解，不赘述
2NF:：符合1NF，有主键，且非主键完全依赖于主键
举个例子，订单详情表中单价（UnitPrice）部分依赖于主键ItemID，非完全依赖。要想符合2NF，要拆成如图2张表。
3NF：符合2NF，且非主键字段不能相互依赖
举个例子，下表中客户名称和客户城市依赖于非主键客户ID，所以需将表拆分成订单表和客户信息表才符合3NF。
OLTP系统大多采用3NF存储数据，避免数据冗余导致的事务处理的不一致；
OLAP关注数据整合和查询性能，需要冗余更多的数据换取更好的查询性能。
维表和事实表
维表：包含维度属性，用于分析时分组和筛选。
事实表：包含实际业务过程，是数据仓库维度建模的核心。
如上图，
事实表作为核心，一个或多个维表直接和事实表连接的模式则成为星型模式，星型模式是维度建模的典型代表。与之相对应的是雪花模式，顾名思义，是维表和事实表按照❄️的形状间接连接。
必要性
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。不建模则会造成二种后果：源头百花齐放，产出处处烟囱。
源头百花齐放
使用方会按照自己的技术面选择开源的flume、sqoop等各种开源，甚至未做过开源调研的，自己现造轮子同步贴源层数据。导致数据以各种形态方式导入，数据冗余，管理混乱。
产出处处烟囱
而在产出层，则会造成下面尴尬的局面：
1）常用业务指标都从基础层（源头）开始重新计算，不可复用！
2）同一名称指标，开发者自行取数，口径各异，导致睡觉不一致引发数据问题！
比如，简单的“累计支付金额”统计，会涉及到排风控吗、排退款、买家渠道限制等口径细节问题，不同的使用方都从同步过来的订单表算，同一指标会被重复计算。
所以，数仓建模能从性能、成本、效率、质量四个方面带来收益。
性能 :良好的数据模型能帮助我们快速查询所需要的数据，减少 数据的 110吞吐。
成本 : 良好的数据模型能极大地减少不必要的数据冗余，也能实 现计算结果复用，极大地降低大数据系统中的存储和计算成本。
效率 :良好的数据模型能极大地改善用户使用数据的体验，提高 使用数据的效率。
质量 : 良好的数据模型能改善数据统计口径的不一致性，减少数 据计算错误的可能性。
理论与实践
未完待续，持续更新，请关注～
