前言：
对于数仓的概念非常大非常广泛，而且也并没有绝对正确的架构，只是有一定的方法论，一定的前人总结留下来的理论，所以我也不知道我这个系列会更多久，会更多少，反正我就把我现在对于数仓的想法记录下来，以后如果有更深的理解，再说吧~
1、什么是数据仓库
这个百度也能找到答案，但是我想说的是我的观点。数仓应该是一种数据整合，数据治理，将数据做成一种服务，对外提供。
什么叫数据整合，大家应该听过数据孤岛/烟囱这个概念，大概意思就是说：一家公司，数据开发各做各的，数据相互之间不能打通，数据情况掌握在不同的个人手上，往往要得到某个数据需要问一圈才能知道数据是谁在做，存在哪里，如何使用。数据整合就是想要将不同的数据整理到一起，这样有人要找数据，只要到数仓就能够找到。
什么叫数据治理，把所有数据都放到同一个地方（比如hive中），这只是把数据扔到一起了，如果没有比较清晰的分层，别人要找，他还是很麻烦，万一你一条业务线有几十张表，他根本不知道从何入手，所以数据治理就是要将数据按照一定的规范和模式存放，并且要做好元数据管理（这个非常重要），这样才可以减少数据处理人员和数据需求方的扯皮！
有了上面的思想之后，数据需求方需要找某个数据的时候，只要把相关的元数据信息（可以是一个excel字典表，甚至是个平台）给他，这样他就可以自己找到对应的数据的位置，然后去开通相应权限，获得数据结果，这样你们的数据就做成了一项服务！
2、为什么要用数据仓库/什么时候会有要做数仓的需求
我想分为2个方面说：
-1.公司想做一个数据服务部门，想把公司现有的数据做整合做一个数据平台（比如什么打标签平台啊，画像平台啊），做数仓提供给不同数据需求方做分析，或者做一些新的数据型产品
这种听起来就是Inmon理论的自上而下的需求，需要多个部门配合整理数据源，但是这种情况一般比较少。
以下纯粹是个人见解：
1、大公司数据太多部门太多，你说要所有部门来配合一个团队做数据整合，人家产品做的好好的，为什么要把数据和你们共享，放到一起，对于他们好像没有任何收益，除非是大领导强制性的安排，不然其实缓慢而且扯皮很多
2、小公司就那么点数据，做产品抢市场都来不及，还做什么规范的数仓做什么中台，只想做赶快做完先赚一波钱后续的事情后面再说
-2.公司做好产品了，稳步升级，结果发现数据量越来越大，有很多复杂的查询越来越慢，加上数据需求人员直接在生产库或者备份库上做分析，导致程序的稳定性下降，想做生产和分析的隔离
这种场景就很想Kimball提出的理论，自下而上，就是数据集市已经有了，但是想单独开辟一块空间来做分析，业务拓展后，数仓也可以不断的迭代，支持更多的维度，更多的分析需求
大多数公司都是这种场景，包括一些大厂，有很多是开拓了新的业务线，本来数据量很少，单节点玩得转（这样就算这个业务线失败了，直接砍掉也方便，成本也低），但是发现业务做的越来越好，数据量越来越大，才有做数仓分析数据帮助决策的需求
3、数仓有哪些我已知的模型
-1.自上向下（Inmon理论）
将不同的数据源，整合到一个企业级的数仓里
我认为的几个比较关键的点：
1、Inmon认为在做数据仓库的时候要遵循3NF（第三范式）来做
2、维度建模应该在数仓之后做，做在数据集市里（这样数仓的功能就比较弱，更多是数据集市里提供服务）
3、多部门数据都要写到企业数仓里（就需要多部门共同支持，这是比较麻烦的一个点）
4、Inmon的关系型建模方法，虽然他也多次强调在有了50%的需求的情况下就应该开始，先建立DW， 在细化到分部门的DataMarket上（这点就跟Kimball的想法比较接近）
因为2和3，导致自上而下的建模方式投入大，见效慢
这种模式现在用的比较少吧，毕竟很少有公司可以将公司所有数据集成到一起，特别是很多有钱做数仓的大厂，数据更是非常繁多和复杂，放到一起的操作比较少
（网上随便找的图）
-2.自下向上（Kimball理论）
1、维度建模
其实区别就在于Kimball认为数仓里就应该做维度建模，有事实表（描述实际发生的一件事情，比如下了一个订单）和维度表（描述数据的一些维度，比如订单是在哪个城市发生的，下单的具体商品是什么，是哪个用户下的，用户的基础属性又是什么？以上都是订单可以有的维度）
然后讲到维度建模，又有星型结构和雪花结构还有一个大宽表，星型和雪花区别就是，星型是把同一类的维度放到同一张表，雪花是能拆到最细粒度就一直拆，举个例子：省份和城市维度，按照星型就是一张表不同字段，雪花就是两张表，一张城市，一张省份，所以看起来雪花更遵守3NF，但是用的时候，关联表太多，sql写起来麻烦，而且性能不太好（各有优劣吧，但是大多数还是使用星型比较多）。
大宽表还是建议少用，因为很多场景下我们的维度会不断的变化（包括增加和减少和修改），做了大宽表虽然一时爽，但是在新增维度的时候，你就会有困惑，哪些维度应该写在宽表里，哪些不需要，这没有一个指导性的标准，只能全靠对于业务的理解和经验，当然如果维度基本不变的情况下，大宽表非常的爽！
2、表的先后
先有产品业务单元或部门的数据集市，之后将业务相关的数据拉一份整合到数据仓库里面，做不同维度的分析，相当于一份针对查询和分析做特别结构化的事物数据拷贝，将线上产品和分析服务做剥离互不影响
现在大多数公司都会选择这种kimball的建模方式，毕竟大多数都是先有产品，得到数据，才有分析，获得更多营销或者赚钱的策略
-3.Data Vault模型（Dan Linstedt理论）
其实这个模型我没有太多了解，大家可以自行百度下相关的文章，也可以看我分享的文章：
数据仓库建模之Data Vault模型：https://zhuanlan.zhihu.com/p/103170877
数据仓库之Data Vault模型总结：https://blog.csdn.net/junweishiwo/article/details/82838407
我大概说下他的特点：
1、不做任何的数据清洗，保留原始，这样好回溯事件
2、模型由三个结构组成：
中心表（Hub）记录事实和时间
链接表（Link）纪录事实的一些属性链接id
属性信息表（Satellite）具体属性信息
有时候可能会有附加的辅助表：Point-In-Time辅助表
通过这样的三个结构，我就可以通过链接表给中心表join上不同的维度，而且属性信息更改了，我并不需要去更改影响到中心表（嘿嘿，有没有觉得跟大宽表完全是相反的极端）
这种模型建模相对比较少见吧，或者说我见识少吧~大家如果真的有用到就去好好学习下吧
第一篇就先到这吧，不想写太长，这样大家也都看不下去，毕竟这类型文章不像解决报错一样会有突然的畅快，这类型的文章更像知识积累的过程，短时间并不会有什么大的作用（但是如果不学，很可能以后遇到书到用时方恨少的情况）
预告一些后续会写的标题，例如：如何评判一个数仓的好坏，数仓的目标，或者数仓产品应该如何迭代，数仓的分层，元数据的管理，数据质量管理等等。
渐渐的我也发现我年限到了，必须开始慢慢的有大局观，不能只关注自己手头上的事情做完，更应该知道自己做的是什么，为什么这么做，有没有更好的方法，更多的知识，更多的架构，让自己的能力形成一个闭环，能够解决一个大的框架性的问题，哎，共勉吧！
菜鸡一只吧，如果有任何疑问或者我说的不对的地方，欢迎大家留言批评！~