針對上篇文章遺留問題聯邦學習之一
幾億級別的資料量架構如何設計且如何實現
要解決這個問題 那麼我們首先要會大資料處理框架的相關內容
這篇文章我們們走進大資料處理的世界
首先我們們要理解大資料相關的概念和原理 才能很好的使用這些元件和設計大資料處理架構
flume sqoop 資料倉儲 ETL ODS Data Mart OLTP OLAP 資料集市
我們一一分析原理
flume
sqoop
Hadoop和關聯式資料庫伺服器之間傳送資料
資料倉儲
`資料倉儲是供戰略決策使用的資料`
`基本不更新的反應歷史變化的資料`
`DW:Data Warehouse`
`一個很大的資料儲存集合`
`出於企業的分析性報告和決策支援目的而建立`
`對多樣的業務資料進行篩選與整合`
`它為企業提供一定的BI（商業智慧）能力`
`指導業務流程改進、監視時間、成本、質量以及控制`
`資料倉儲的輸入方是各種各樣的資料來源`
`最終的輸出用於企業的資料分析、資料探勘、資料包表等方向`
特點
- 主題性
`不同於傳統資料庫對應於某一個或多個專案`
`資料倉儲根據使用者實際需求`
`將不同資料來源的資料在一個較高的抽象層次上做整合`
`所有資料都圍繞某一主題來組織`
`比如對於滴滴出行"司機行為分析"就是一個主題`
`對於鏈家網"成交分析"就是一個主題`
- 整合性
`資料倉儲中儲存的資料是來源於多個資料來源的整合`
`原始資料來自不同的資料來源，儲存方式各不相同`
`要整合成為最終的資料集合，需要從資料來源經過一系列抽取、清洗、轉換的過程`
- 穩定性
`資料倉儲中儲存的資料是一系列歷史快照，不允許被修改`
`使用者只能通過分析工具進行查詢和分析`
- 時變性
`資料倉儲會定期接收新的整合資料 反應出最新的資料變化`
ETL
`ETL是將業務系統的資料經過抽取、清洗轉換之後載入到資料倉儲的過程`
`目的是將企業中的分散、零亂、標準不統一的資料整合到一起`
`為企業的決策提供分析依據`
`ETL是BI專案重要的一個環節`
`通常情況下，在BI專案中ETL會花掉整個專案至少1/3的時間`
`ETL設計的好壞直接關接到BI專案的成敗`
ODS
`短期的實時的資料 供產品或者運營人員日常使用`
`可以更新的資料`
`操作型資料儲存`
`儲存的是當前的資料情況`
`給使用者提供當前的狀態`
`提供即時性的、操作性的、整合的全體資訊的需求`
`ODS作為資料庫到資料倉儲的一種過渡形式`
`與資料倉儲在物理結構上不同，能提供高效能的響應時間,ODS設計採用混合設計方式`
`ODS中的資料是"實時值",而資料倉儲的資料卻是"歷史值"`
`一般ODS中儲存的資料不超過一個月，而資料倉儲為10年或更多`
DSS(decision-support system)決策支援系統
`用於支援管理決策的系統`
`通常，DSS對大量的資料單元進行的分析`
`通常不涉及資料更新`
Data Mart
`為了特定的應用目的或應用範圍，而從資料倉儲中獨立出來的一部分資料`
`也可稱為部門資料或主題資料（subjectarea）`
`在資料倉儲的實施過程中往往可以從一個部門的資料集市著手`
`以後再用幾個資料集市組成一個完整的資料倉儲`
`需要注意的就是在實施不同的資料集市時，同一含義的欄位定義一定要相容，這樣再以後實施資料倉儲時才不會造成大麻煩`
工作中實際案例分析
資料部門工作流程
- 刪除分析資料庫的歷史訂單資料
- 全量更新訂單資料到分析資料庫
- 將資料簡單清洗，並生成資料集市層
- 分析處理，產出報表
問題分析
- 業務變化很快
`業務資料表經常變化欄位含義、增加各種邏輯資料等`
- 業務資料來源越來越多
`隨著品類越來越多，新部門逐步成立，資料來源也就越來越多樣化`
- 需求越來越多，越來越複雜
`所有的產品和運營都向我們要各種各樣的使用者行為資料、訂單分析資料和競對優勢資料`
- 資料的實時行要求越來越高
`早晨提出個新業務資料需求，晚上就要`
分析資料特點
`此時的資料集合不是資料倉儲 因為不符合相對穩定的和反應歷史變化的兩個條件`
`因為類似訂單類資料，每天全量更新`
`（原因是同一個訂單狀態隨著時間會變化，比如今天買了，明天退貨了）`
`而是一個ODS`
解決方案
業務資料 － ODS － 資料倉儲
優勢
- ODS的資料與資料倉儲的資料高度統一
- 開發成本低，開發一次並應用到ODS即可
- 可見ODS是發揮承上啟下的作用
劣勢
- 資料倉儲需要的所有資料都需要走ODS
- 擴充套件、系統的靈活性差
OB-ODS
優勢
- 結構簡單 初創資料分析團隊都是類似的結構
劣勢
- 所有資料都歸結到ODS
- 長期資料決策分析能力差，軟硬體成本高，模組劃分不清晰，通用性差
資料倉儲和ODS並行
優勢
- 便於擴充套件，ODS和資料倉儲各做各的，形成優勢互補
ODS和DW區別
資料的當前性
`ODS包括的是當前或接近當前的資料`
`ODS反映的是當前業務條件的狀態`
`ODS的設計與使用者或業務的需要是有關聯的`
`而DW則是更多的反映業務條件的歷史資料`
資料的更新或載入
`ODS中的資料是可以進行修改的`
`而DW中的資料一般是不進行更新的`
`ODS的更新是根據業務的需要進行操作的，而沒有必要立即更新`
`因此它需要一種實時或近實時的更新機制`
`DW中的資料是按照正常的或預先指定的時間進行資料的收集和載入的`
資料的彙總性
`ODS主要是包括一些細節資料`
`但是由於效能的需要，可能還包括一些彙總資料`
`如果包括彙總資料，可能很難保證資料的當前性和準確性`
`ODS中的彙總資料生命週期比較短，所以可稱作為動態彙總資料`
`如果細節資料經過了修改，則彙總資料同樣需要修改`
`而DW中的資料可稱為靜態的彙總資料`
資料建模
`ODS是站在記錄層面訪問的角度而設計的`
`DW或DM則是站在結果集層面訪問的角度而設計的`
`ODS支援快速的資料更新，DW作為一個整體是面向查詢的`
查詢的事務
`ODS中的事務操作比較多`
`可能一天中會不斷的執行相同的事務`
`而DW中事務的到達是可以預測的`
用途
`ODS用於每一天的操作型決策 是一種短期的`
`DW可以獲取一種長期的合作廣泛的決策`
`ODS是策略型的，DW是戰略型的。`
使用者
`ODS主要用於策略型的使用者 比如保險公司每天與客戶交流的客服`
`DW主要用於戰略型的使用者，比如公司的高層管理人員`
資料量（主要區別之一）
`ODS只是包括當前資料`
`DW儲存的是每一個主題的歷史快照`
OLTP與OLAP
- 資料處理分類
`聯機事務處理OLTP（on-line transaction processing）`
`聯機分析處理OLAP（On-Line Analytical Processing）`
`OLTP是傳統的關係型資料庫的主要應用`
`主要是基本的、日常的事務處理`
`例如銀行交易`
`OLAP是資料倉儲系統的主要應用`
`支援複雜的分析操作，側重決策支援`
`並且提供直觀易懂的查詢結果`
`OLTP 系統強調資料庫記憶體效率`
`強調記憶體各種指標的命令率，強調繫結變數，強調併發操作`
`OLAP 系統則強調資料分析`
`強調SQL執行市場，強調磁碟I/O，強調分割槽等`
- OLTP與OLAP之間的比較
OLTP
`事務性非常高的系統`
`一般都是高可用的線上系統`
`以小的事務以及小的查詢為主`
`評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量`
`單個資料庫每秒處理的Transaction往往超過幾百個，或者是幾千個`
`Select 語句的執行量每秒幾千甚至幾萬個`
`典型的OLTP系統有電子商務系統、銀行、證券等，如美國eBay的業務資料庫`
OLTP 瓶頸
CPU與磁碟子系統
CPU
表現在邏輯讀總量與計算性函式
- 邏輯讀總量
`邏輯讀總量等於單個語句的邏輯讀乘以執行次數`
`如果單個語句執行速度雖然很快，但是執行次數非常多，也可能會導致很大的邏輯讀總量`
- 計算型的函式
`如自定義函式、decode等的頻繁使用`
`也會消耗大量的CPU時間，造成系統的負載升高`
`儘量避免計算過程，如儲存計算結果到統計表`
磁碟子系統
`承載能力一般取決於它的IOPS處理能力`
`磁碟物理讀一般都是db file sequential read(單塊讀)`
`讀的次數非常頻繁`
`如果頻繁到磁碟子系統都不能承載其IOPS的時候，就會出現大的效能問題`
OLTP設計和優化
Cache技術與B-tree索引技術
Cache技術
`Cache決定了很多語句不需要從磁碟子系統獲得資料`
`Web cache與Oracle data buffer對OLTP系統是很重要的`
索引
`語句越簡單越好 這樣執行計劃也穩定`
`一定要使用繫結變數，減少語句解析，儘量減少表關聯、儘量減少分散式事務`
`基本不使用分割槽技術、MV技術、並行技術及點陣圖索引`
`因為併發量很高，批量更新時要分批快速提交，以避免阻塞的發生`
在OLTP環境中使用點陣圖索引很容易造成阻塞與死鎖
* 繫結變數
使用者併發數很大，使用者的請求十分密集並且這些請求的SQL 大多數是可以重複使用的
`OLTP 系統是一個資料塊變化非常頻繁，SQL 語句提交非常頻繁的系統`
##### 資料塊
應儘可能讓資料塊儲存在記憶體當中
##### SQL
儘可能使用變數繫結技術來達到SQL重用減少物理I/O 和重複的SQL 解析從而極大的改善資料庫的效能
`影響效能的因素`
##### 熱快（hot block）
當一個塊被多個使用者同時讀取時Oracle 為了維護資料的一致性需要使用Latch來序列化使用者的操作當一個使用者獲得了latch後，其他使用者就只能等待獲取這個資料塊的使用者越多，等待就越明顯這就是熱塊的問題這種熱快可能是資料塊 也可能是回滾段塊
* 資料塊
通常是資料庫的資料分佈不均勻導致如果是索引的資料塊，可以考慮建立反向索引來達到重新分佈資料的目的
* 回滾段資料塊
可以適當多增加幾個回滾段來避免這種爭用
### OLAP
`即DSS決策支援系統或資料倉儲`
要對幾億條或者幾十億條資料進行聚合處理這種海量的資料，全部放在記憶體中操作是很難的同時也沒有必要，因為這些資料快很少重用快取起來也沒有實際意義，而且還會造成物理I/O相當大所以這種系統的瓶頸往往是磁碟I/O上面的。對於OLAP系統，SQL 的優化非常重要因為它的資料量很大，做全表掃描和索引對效能上來說差異是非常大的
* 考核標準
考核標準是磁碟子系統的吞吐量（頻寬）如能達到多少MB/s的流量不看一條語句的執行時間可能會非常長，讀取的資料也非常多
* 磁碟吞吐量
磁碟子系統的吞吐量則往往取決於磁碟的個數Cache基本是沒有效果的資料庫的讀寫型別基本上是db file scattered read與direct path read/write應儘量採用個數比較多的磁碟以及比較大的頻寬，如4Gb的光纖介面
#### 分割槽技術
`體現在資料庫管理的方便性 並不能絕對保證查詢效能的提高`
* 通過分割槽交換的方式實現資料庫載入
* 通過備份分割槽表空間實現備份
* 通過分割槽進行刪除資料
`分割槽對效能的影響`
* 使得一些大表的掃描變得很快（只掃描單個分割槽
* 分割槽結合並行可以使得整個表的掃描會變得很快
`優化器模式`
* all\_rows
絕大多數時候資料庫上執行著的是報表作業執行基本上是聚合類的SQL 操作，比如group by
* first\_rows
對於一些分頁操作比較多的網站類資料庫
`注意`
`不是大範圍地使用分割槽關鍵字，而採用其它的欄位作為where條件`
* 本地索引，將不得不掃描多個索引，而效能變得更為低下
* 全域性索引，又失去分割槽的意義
#### 並行技術
在Oracle 10g中 可把一個任務，如select的全表掃描平均地分派到多個RAC的節點上去
`不需要使用繫結（BIND）變數`
整個系統的執行量很小分析時間對於執行時間來說，可以忽略而且可避免出現錯誤的執行計劃OLAP中可以大量使用點陣圖索引，物化檢視對於大的事務，儘量尋求速度上的優化沒有必要像OLTP要求快速提交，甚至要刻意減慢執行的速度
`一般在完成大型任務時才使用`
如在實際生活中，翻譯一本書，可以先安排多個人，每個人翻譯不同的章節，這樣可以提高翻譯速度如果只是翻譯一頁書，也去分配不同的人翻譯不同的行，再組合起來，就沒必要了，因為在分配工作的時間裡，一個人或許早就翻譯完了
資料集市
----
資料倉儲是企業級的，能為整個企業各個部門的執行提供決策支援手段資料集市則是一種微型的資料倉儲,它通常有更少的資料,更少的主題區域,以及更少的歷史資料因此是部門級的，一般只能為某個區域性範圍內的管理人員服務，因此也稱之為部門級資料倉儲資料倉儲向各個資料集市提供資料幾個部門的資料集市組成一個資料倉儲資料倉儲中資料結構採用規範化模式資料集市中的資料結構採用星型模式通常倉庫中資料粒度比集市的粒度要細
建庫模版
----
* OLAP使用資料倉儲模板
資料量大，DML少
* OLTP使用一般用途或事務處理模板
資料量少，DML頻繁，並行事務處理多，但是一般都很短
* DDS 決策支援系統
典型的操作是全表掃描長查詢，長事務但是一般事務的個數很少往往是一個事務獨佔系統
參考資料
----
https://blog.csdn.net/weixin_39935887/article/details/83902522