針對上篇文章遺留問題聯邦學習之一
幾億級别的資料量架構如何設計且如何實作
要解決這個問題 那麼咱首先要會大資料處理架構的相關内容
這篇文章咱們走進大資料處理的世界
首先咱們要了解大資料相關的概念和原理 才能很好的使用這些元件和設計大資料處理架構
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使用資料倉庫模闆
- OLTP使用一般用途或事務處理模闆
資料量少，DML頻繁，并行事務處理多，但是一般都很短 - DDS 決策支援系統
典型的操作是全表掃描
長查詢，長事務
但是一般事務的個數很少
往往是一個事務獨占系統