前言：
對於數倉的概念非常大非常廣泛，而且也並沒有絕對正確的架構，只是有一定的方法論，一定的前人總結留下來的理論，所以我也不知道我這個系列會更多久，會更多少，反正我就把我現在對於數倉的想法記錄下來，以後如果有更深的理解，再說吧~
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上不同的維度，而且屬性信息更改了，我並不需要去更改影響到中心表（嘿嘿，有沒有覺得跟大寬表完全是相反的極端）
這種模型建模相對比較少見吧，或者說我見識少吧~大家如果真的有用到就去好好學習下吧
第一篇就先到這吧，不想寫太長，這樣大家也都看不下去，畢竟這類型文章不像解決報錯一樣會有突然的暢快，這類型的文章更像知識積累的過程，短時間並不會有什麼大的作用（但是如果不學，很可能以後遇到書到用時方恨少的情況）
預告一些後續會寫的標題，例如：如何評判一個數倉的好壞，數倉的目標，或者數倉產品應該如何迭代，數倉的分層，元數據的管理，數據質量管理等等。
漸漸的我也發現我年限到了，必須開始慢慢的有大局觀，不能只關注自己手頭上的事情做完，更應該知道自己做的是什麼，爲什麼這麼做，有沒有更好的方法，更多的知識，更多的架構，讓自己的能力形成一個閉環，能夠解決一個大的框架性的問題，哎，共勉吧！
菜雞一隻吧，如果有任何疑問或者我說的不對的地方，歡迎大家留言批評！~