最近在做資料倉儲的一些事情，想著寫一篇部落格來談一下我認識的資料倉儲，個中錯誤之處，還請指正。（20170918更新）
先說一下個人專案大概：
我做的是乙個資料集市，面向分析師和營銷部。將底層源資料通過表與表之間關聯整合成乙個乙個主題，各個主題表之間又通過關鍵字進行關聯，滿足業務多場景、多維度的分析。
關於數倉個人的一些看法：要能深入業務，也能跳出業務。跳出的目的是為了別讓業務牽著鼻子走，你要盡可能的預見業務的潛在需求點，避免後期不斷地修改維護風險。當然這靈活性很大，仁者見仁的事。關於這個點雖然一開始就知道，但是也沒能做好。後期不斷接受別人修改和維護。建設數倉的困難再有就是版本控制和展現也很重要。版本控制不多說，你更新了你的數倉，結果別人還在用舊的字典或表那就很尷尬了。至於展現，就像花了好多錢造了個飛機，大家卻還在用自行車。我要是老闆，就把你開除掉！
介紹
資料倉儲當前有兩個牛逼的人，乙個是inmon，另乙個是kimball。兩個人有著不同的主張，inmon主張資料集市是資料倉儲的子集，先設計底層資料並滿足第三正規化要求，在此基礎之上構建資料集市。這樣的好處，就是資料倉儲易於維護並高度整合，缺點則是周期長，結構相對死板。kimball則認為資料倉儲是一系列資料集市的集合，底層建設成最低粒度的維度模型，對不同業務條線進行構建資料集市。優點就是：靈活方便，周期短見效快；缺點則是後期維護和資料整合困難。目前大多傾向於kimball方式（擴充套件閱讀：同樣我們這裡也更多的是說kimball的模型。
事實表與維度表
kimball在描述他的維度模型時，是面向企業資料的。乙個主題或乙個業務條線雖然更多的從部門角度出發，但從企業角度強調一致性。舉個例子來說明一下事實表和維度表。我們去食堂吃飯，有消費事實（點幾個數、付款等可加性事實）、也有維度（菜的**、分量、冷熱等文字描述；食堂的地理位置、名稱、大小、消費模式等）。當我們建立乙個消費主題時，就需要乙個事實表和業務關心的維度進行有機結合。具體來說，維度表包含了對業務的文字描述。維度屬性是查詢的約束條件、分組與報表標籤生成的基本**。不同的維度交叉就會有事實，事實表承載事務資料。事實表根據粒度的角色劃分不同，可分為事務事實表、週期快照事實包和累積快照事實表（少見）。對於週期和累積事實表，一般的粒度都比較高依賴滿足對應的業務需求。
星型模型和雪花模型
顧名思義，星型模型是以乙個事實表為中心，多個維度表進行關聯的模型。而雪花模型在維度表之下還會有一層或多層維度。在kimball看來，星型模型較雪花模型更具有可取型。雪花模型實現了規範化的儲存（3nf）減少資料儲存空間，同時以更小的維度表在查詢時效率可能會更高。但實際場景下，事實表往往佔據儲存的90%，對維度表的規範化並不具有顯著效果（往往也就是幾十m資料的區別）反而將邏輯複雜化，導致後期維護的艱難和使用的繁瑣。
資料構建邏輯
建設數倉時，都是面向企業來做，實現為各個部門和管理層建設資料的提取、分析的資料中心平台。數倉建設90%的工作，其實都在做維度表選擇（如何保障多個業務條線能夠統一使用同一維度是乙個挑戰性工作，一般企業都會有：日期維度表、產品維度表、客戶維度表。以日期維度表來說，雖然事務級有日期資料，但是日期維度錶可實現更多的日期屬性，一般都是存留5-10年的資料）。方式為匯流排結構，以事實-維度矩陣作為概覽，指導各個主題進行分別設計。說的很簡單，誰做誰知道！
關於分層
面試經驗之談
這裡是2017年11月7日，鄙人不才，17年應屆畢業，經驗不足，十一之後來到上海找工作，目前一無所獲。無奈，今天又逛了一趟培訓機構，看著和自己年齡相仿同學在前台焦急等待的時候感觸頗深，為什麼總是接到培訓機構的邀請，而不見想象之中offer也看不見期待的公司的回覆。剛好有哥哥姐姐在上海這邊，所以借住在...
Oracle insert大量資料經驗之談
在很多時候，我們會需要對乙個表進行插入大量的資料，並且希望在盡可能短的時間內完成該工作，這裡，和大家分享下我平時在做大量資料insert的一些經驗。前提 在做insert資料之前，如果是非生產環境，請將表的索引和約束去掉，待insert完成後再建索引和約束。1.insert into tab1 se...
Oracle insert大量資料經驗之談
在很多時候，我們會需要對乙個表進行插入大量的資料，並且希望在盡可能短的時間內完成該工作，這裡，和大家分享下我平時在做大量資料insert的一些經驗。前提 在做insert資料之前，如果是非生產環境，請將表的索引和約束去掉，待insert完成後再建索引和約束。1.insert into tab1 se...