資料倉庫入門知識
基本規範或優化
欄位命名規範:
語言:
命名應該使用英文單詞，避免使用拼音，最好不要使用拼音簡寫，如果使用拼音簡寫應該有規範。命名不允許使用中文或者特殊字元。
英文單詞使用用物件本身意義相對或相近的單詞。選擇最簡單或最通用的單詞。不能使用毫不相干的單詞來命名。
當一個單詞不能表達物件含義時，用片語組合，如果組合太長時，採用用簡或縮寫，縮寫要基本能表達原單詞的意義。
當出現物件名重名時，是不同型別物件時，加型別字首或字尾以示區別。
大小寫:
名稱一律小寫，以方便不同資料庫移植，以及避免程式呼叫問題。
單詞分隔：
命名的各單詞之間可以使用下劃線進行分隔。
保留字:
命名不允許使用SQL
欄位名稱:
同一個欄位名在一個數據庫中只能代表一個意思。比如telephone在一個表中代表“電話號碼”的意思，在另外一個表中就不能代表“手機號碼”的意思。
不同的表用於相同內容的欄位應該採用同樣的名稱，欄位型別定義。
Sql規範與優化相關:
1.儘量在最外層的查詢的時候使用漢字別名，在子查詢中使英文代替
錯誤示範:
Select b.id,a.`日期`
(Select date_time as `日期` from a ) a
Left join b on a.`日期`=b.date_time
改成
Select b.id,a.date_time as `日期`
(Select date_time as date_time from a ) a
Left join b on a.date_time=b.date_time
2.儘量查詢只需要的欄位
Select * 首先會去元資料中遍歷所有的列會增加資料庫的負擔
錯誤示範:
select * from b;
改正
Select id,name from b;
3.如果需要大資料量的情況下 先過濾不需要的資料再join
錯誤示範:
select a.name,b.name from
A left join b on a.id=b.id where a.dt=’2018-07-04’and b.dt=’2018-07-04’
改正：
Select a.name,b.name from
(Select name from a where dt=’2018-07-04’)a
Left join
(select name from b where dt=’2018-07-04’) b on a.id=b.id
注意:
select a.name,b.core from test a
left join test2 b on a.id= b.id
where b.core=3
select a.name,b.core from test a left join
(select id,core from test2 where core=3)b on a.id=b.id ;
以上這兩sql的結果是不一樣的 所以做優化要注意邏輯
資料庫和資料倉庫的區別
資料庫：是一種邏輯概念，用來存放資料的倉庫。傳統的關係型資料庫的主要應用OLTP（On-Line Transaction Processing 聯機事務處理），主要是基本的、日常的事務處理，,主要採取3NF的實體關係模型儲存資料。目前市面上流行的資料庫都是二維資料庫。如：Oracle、DB2、MySQL、Sybase、MS SQL Server等。
資料倉庫：是資料庫概念的升級。從邏輯上理解，資料庫和資料倉庫沒有區別，都是通過資料庫軟體實現的存放資料的地方，只不過從資料量來說，資料倉庫要比資料庫更龐大得多。資料倉庫主要用於資料探勘和資料分析，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果,輔助領導做決策。OLAP（On-Line Analytical Processing 聯機分析處理）
資料倉庫的特點
1.資料倉庫的資料是面向主題的
與傳統資料庫面向應用進行資料組織的特點相對應，資料倉庫中的資料是面向主題進行 組織的。什麼是主題呢？首先，主題是一個抽象的概念，是較高層次上企業資訊系統中的數 據綜合、歸類並進行分析利用的抽象。通俗講就是分析的物件，比如 商家，客戶，流量， 財務。
2. 資料倉庫的資料是整合的
資料倉庫的資料來源有很多方面，關係型資料庫，非關係型資料庫，日誌檔案。
3.資料倉庫的資料是不可更新的
資料倉庫的資料主要供企業決策分析之用，所涉及的資料操作主要是資料查詢，一般情況下並不進行修改操作。
4. 資料倉庫的資料是隨時間不斷變化的
資料倉庫中的資料不可更新是針對應用來說的，也就是說，資料倉庫的使用者進行分析處理時是不進行資料更新操作的。但並不是說，在從資料整合輸入資料倉庫開始到最終被刪除的整個資料生存週期中，所有的資料倉庫資料都是永遠不變的
- 資料倉庫隨時間變化不斷增加新的資料內容。
- 資料倉庫隨時間變化不斷刪去舊的資料內容
- 資料倉庫中包含有大量的綜合資料，這些綜合資料中很多跟時間有關，如資料經 常按照時間段進行綜合，或隔一定的時間片進行抽樣等等。
為什麼需要資料倉庫模型
首先我們需要了解整個資料倉庫的建設的發展史。
資料倉庫的發展大致經歷了這樣的三個過程：
- 簡單報表階段：這個階段，系統的主要目標是解決一些日常的工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的彙總資料。這個階段的大部分表現形式為資料庫和前端報表工具。
- 資料集市階段：這個階段，主要是根據某個業務部門的需要，進行一定的資料的採集，整理，按照業務人員的需要，進行多維報表的展現，能夠提供對特定業務指導的資料，並且能夠提供特定的領導決策資料。
- 資料倉庫階段：這個階段，主要是按照一定的資料模型，對整個企業的資料進行採集，整理，並且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表資料，能夠通過資料倉庫生成對對業務具有指導性的資料，同時，為領導決策提供全面的資料支援。
一般來說，資料模型的建設主要能夠幫助我們解決以下的一些問題
- 進行全面的業務梳理，改進業務流程。在業務模型建設的階段，能夠幫助我們的企業或者是管理機關對本單位的業務進行全面的梳理。通過業務模型的建設，我們應該能夠全面瞭解該單位的業務架構圖和整個業務的執行情況，能夠將業務按照特定的規律進行分門別類和程式化，同時，幫助我們進一步的改進業務的流程，提高業務效率，指導我們的業務部門的生產。
- 建立全方位的資料視角，消滅資訊孤島和資料差異。通過資料倉庫的模型建設，能夠為企業提供一個整體的資料視角，不再是各個部門只是關注自己的資料，而且通過模型的建設，勾勒出了部門之間內在的聯絡，幫助消滅各個部門之間的資訊孤島的問題，更為重要的是，通過資料模型的建設，能夠保證整個企業的資料的一致性，各個部門之間資料的差異將會得到有效解決。
資料倉庫建模的好處：
效能和效率:良好的資料模型可以幫助我們快速的查詢所需要的資料,減少資料的減少資料的I/O吞吐，可以改善使用者使用資料的體驗,提高使用資料的效率(比如 儘量好的維度表 儘量少的join 操作，寬表,彙總表)
成本:良好的資料模型能極大的減少不必要的資料冗餘,也可以計算成本複用,降低儲存和計算成本
質量:良好的資料模型能夠改善資料統計口徑的不一致,減少資料計算錯誤的可能性
資料倉庫的架構分層：
資料倉庫標準上可以分為四層：ODS（臨時儲存層 Operational Data Store）、DWD（資料明細層 Data Warehouse Detail ）、DWS（資料彙總層 Data Warehouse Summary）、APP（應用層 Application Data Store）。
DJ資料倉庫說明
Dj層級介紹
TMP層:臨時層,資料處理的輔助層
ODS層:原始層,資料、表結構跟原始層保持一致,資料來源於源表或者臨時層
DWD層:維表層,主要存放維度表資料
DWF層:基礎資料層,資料清洗後的ODS層資料或者關聯後的明細資料,資料來源於ODS層,DWF層
DWA層:資料彙總層,資料來源於DWF或者DWA
Dj命名說明
庫名:
xx_yy_zz
xx:業務縮寫如dj(到家縮寫)jz(家政縮寫)
yy:資料型別如dw(資料倉庫),ods(原始層)
zz:業務層級如 d(維表),f(基礎資料層),a(資料彙總層)
表名:
Xx_yy_zz
Xx:資料所屬層級o(原始層),d(維表),f(明細層),a(彙總層)
Yy:業務範圍:pty(使用者商家企業),fin(財務),agt(協議訂單),mar(營銷),flow(流量)
Zz:業務具體含義
資料倉庫建模方法
1.正規化建模法
正規化建模法其實是我們在構建資料模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關係型資料庫得資料儲存，利用的一種技術層面上的方法。目前，我們在關係型資料庫中的建模方法，大部分採用的是三正規化建模法。
1NF:欄位不可分;
2NF:有主鍵，非主鍵欄位依賴主鍵;
3NF:非主鍵欄位不能相互依賴;
解釋:
1NF:原子性 欄位不可再分
2NF:唯一性 一個表只說明一個事物;
3NF:每列都與主鍵有直接關係，不存在傳遞依賴;
一個符合第三正規化的關係必須具有以下三個條件 :
1NF(第一正規化)：
資料庫表中的欄位都是單一屬性的，不可再分，資料庫表中的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。
比如 電話欄位 包括手機電話和家庭電話的組合 或者一個欄位再不同的情況下 內容含義不同。
我們先來看一張不符合1NF的表1-1
飯卡充值收費表：
|
card_no |
student_no |
student_name |
sex |
department |
money |
|
001 |
021101 |
小明 |
男 |
教育學院，心理系，1班 |
100 |
修改後：
|
card_no |
student_no |
student_name |
sex |
department |
major |
class |
money |
|
001 |
021101 |
小明 |
男 |
教育學院 |
心理系 |
1 |
100 |
2NF(第二正規化):
第二正規化(2NF)是在第一正規化(1NF)的基礎上建立起來的，即滿足第二正規化(2NF)必須先滿足第一正規化(1NF),每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分
|
card_no |
student_no |
student_name |
sex |
department |
major |
class |
money |
|
001 |
021101 |
小明 |
男 |
教育學院 |
心理系 |
1 |
100 |
修改後:
|
card_no |
money |
|
001 |
100 |
|
student_no |
student_name |
sex |
department |
major |
class |
card_no |
|
021101 |
小明 |
男 |
教育學院 |
心理系 |
1 |
001 |
3NF(第三正規化)
每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去
第二正規化（2NF）和第三正規化（3NF）的概念很容易混淆，區分它們的關鍵點在於，2NF：非主鍵列是否完全依賴於主鍵，還是依賴於主鍵的一部分；3NF：非主鍵列是直接依賴於主鍵，還是直接依賴於非主鍵列。
Inmon 的正規化建模法的最大優點就是從關係型資料庫的角度出發，結合了業務系統的資料模型，能夠比較方便的實現資料倉庫的建模。但其缺點也是明顯的，由於建模方法限定在關係型資料庫之上，在某些時候反而限制了整個資料倉庫模型的靈活性，效能等，特別是考慮到資料倉庫的底層資料向資料集市的資料進行彙總時，需要進行一定的變通才能滿足相應的需求。
2.維度建模法
維度建模法，Kimball 最先提出這一概念。其最簡單的描述就是，按照事實表，維表來構建資料倉庫，資料集市。
根據事實表和維度表的關係，又可將常見的模型分為星型模型和雪花型模型。
星型架構是一種非正規化的結構，多維資料集的每一個維度都直接與事實表相連線，不存在漸變維度，所以資料有一定的冗餘，如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那麼國家 A 和省 B 的資訊分別儲存了兩次，即存在冗餘。
圖1. 銷售資料倉庫中的星型模型
圖 2. 銷售資料倉庫中的雪花型模型
比較：
1.資料優化
雪花模型使用的是規範化資料，也就是說資料在資料庫內部是組織好的，以便消除冗餘，因此它能夠有效地減少資料量。通過引用完整性，其業務層級和維度都將儲存在資料模型之中。
相比較而言，星形模型實用的是反規範化資料。在星形模型中，維度直接指的是事實表，業務層級不會通過維度之間的參照完整性來部署。
2.效能
雪花模型在維度表、事實表之間的連線很多，因此效能方面會比較低。
3.ETL
雪花模型載入資料集市，因此ETL操作在設計上更加複雜，而且由於附屬模型的限制，不能並行化。
星形模型載入維度表，不需要再維度之間新增附屬模型，因此ETL就相對簡單，而且可以實現高度的並行化
星型模型因為資料的冗餘所以很多統計查詢不需要做外部的連線，因此一般情況下效率比雪花型模型要高。星型結構不用考慮很多正規化的因素，設計與實現都比較簡單。雪花型模型由於去除了冗餘，有些統計就需要通過表的聯接才能產生，所以效率不一定有星型模型高。正規化也是一種比較複雜的過程，相應的資料庫結構設計、資料的 ETL、以及後期的維護都要複雜一些。因此在冗餘可以接受的前提下，實際運用中星型模型使用更多，也更有效率。
維度建模:
基本概念：
事實表:事實是各個維度的的交點,是對某個特定事件的度量。若干個一致的事實能夠被組合到一個公共的結構中就是事實表。
維度表:維表是使用者分析決策的角度。
四步維度建模方法:
第一步:選擇業務過程
業務過程通常使用行為動詞表示業務執行的活動,通俗講就是確定要分析的業務流程
第二步:宣告粒度
粒度的宣告是事實表建模非常重要的一步，意味著精確定義事實表的每一行所表示的業務含義，粒度傳遞的是與事實表度量有關的細節層次。明確的粒度能確保對事實表中行的意思的理解不會產生混淆，保證所有的事實按照同樣的細節層次記錄。
應該儘量選擇最細級別的原子粒度，以確保事實表的應用具有最大的靈活性。
第三步:確定維度
完成粒度宣告以後，也就意味著確定了主鍵，對應的維度組合以及相關的維度欄位就可以確定了，應該選擇能夠描述清楚業務過程所處的環境的維度資訊。
維度提供圍繞某一業務過程所涉及的“誰、什麼、何處、何時、為什麼、如何”等背景。維度表包含BI應用所需要的用於過濾及分類事實的描述屬性。
第四步:確定事實
事實可以通過回答“過程的度量是什麼”來確定。事實涉及來自業務過程時間的度量，基本上都是以數量值表示。應該選擇與業務過程有關的所有事實，且
事實的粒度要與所宣告的事實表的粒度一致
事實表基礎:
若干個一致的事實能夠被組合到一個公共的結構中就是事實表。
發生在現實世界中的操作型事件,其所產生的可度量值，儲存在事實表中。除了數字度量外，事實表總是包含外來鍵,用於關聯與之相關的維度。
事實表中的一條記錄所表達的業務細節程度稱為粒度。通常粒度可以聽過兩種方式來表達:一種是維度屬性組合所表示的細節程度；一種是所表示的具體業務含義。
事實的型別:可加、半可加、不可加事實
事實表中的數值數字度量可劃分為三類。
可加事實:可以按照與事實表關聯的任意維度進行彙總。
半可加事實:只能按照特定的維度彙總，比如庫存可以按照地點和商品進行彙總，而按照時間維度把一年中每個月的庫存累加起來則毫無意義。
不可加事實:比如比率
事實表型別：
事物事實表：事務事實表用來描述業務過程，眼蹤空間或時間上某點的度量事件，儲存的是最原子的資料 比如下單,發貨,退款,提供最明細的資料，用來定義業務過程的原子粒度的行為。通俗的講,比如就是訂單表的每一行記錄。
週期快照事實表：週期快照事實表中的每行彙總了發生在某一標準時間，如某一天，某一週，某一月的度量時間。粒度是週期性的，不是個體的事務。
比如:商家彙總表,指標有如,距離今天一共服務多少單,距離今天一共賺多少錢，截止一共服務多少客戶
累積快照事實表: 累積快照事實表的行彙總了發生在過程開始和結束之間可預測步驟內的度量時間。如訂單服務為例,可以有這幾個欄位 訂單id,下單時間,支付時間,服務時間,完成時間,取消時間
維度表：
維度是維度建模的基礎和靈魂。在維度建模中。將度量稱為’事實’，將環境描述’維度’，
維度是用於分析事實所需要的多樣環境。
第一步：選擇維度或者新建維度。作為維度建模的核心，在企業及資料倉庫中必須保證維度的唯一性。
第二步:確定主維表，一般是ods表，與業務系統直接同步
第三步：確定相關相關維表。資料倉庫是業務源系統的資料整合，不同業務系統或者同一月系統中的表之前存在關聯性。根據對業務的梳理，確定哪些表和主維表存在關聯關係，並選擇其中的某些表用於生維度屬性。
第四步：確定維度屬性。分兩個階段：一個階段從主維度表中選擇維度屬性或者生成新的維度屬性。第二個階段從相關維表中選擇維度屬性或者生成新的維度屬性
無事實的事實表：
比如 瀏覽日誌表 或者 記錄 維度和維度的關係表
資料治理：
元資料管理：
技術元資料：
1、建表對每個欄位必須有註釋。
2、庫名，表名，資料載入策略，資料更新週期，源表，欄位名，欄位型別，欄位含義
3、碼值類：有可供查詢的碼值集合，用來整理歸納，所有表的所有字典欄位的型別和描述資訊。
4、資料表新建，變更，刪除等。
5、Mapping文件
（業務->BI）
系統名，表名，資料載入策略，資料更新週期，介面實現方式，源表清單，欄位名，欄位型別，主鍵，
非空，預設值，舉例，ETL 計算口徑，備註（資料字典相關定義等，比如列舉值，取值範圍，業務說明等）
業務元資料：
1.業務知識整理
業務系統相關業務知識庫整理，按照系統業務域整理，業務系統說明，操作流程說明等。
比如:資料來源 清洗的 生命週期
比如:SDK埋點規範
比如:各個型別日誌的含義，開發流程
比如:業務線具體業務含義
2、業務表的指標含義，統計的口徑，業務的含義，維度的說明
3、資料開發規範
資料開發流程 業務評審 研發設計評審 開發 測試