針對上篇文章遺留問題聯邦學習之一

幾億級別的資料量架構如何設計且如何實現

要解決這個問題 那麼咱首先要會大資料處理框架的相關內容

這篇文章咱們走進大資料處理的世界

首先咱們要理解大資料相關的概念和原理 才能很好的使用這些元件和設計大資料處理架構

flume sqoop 資料倉庫 ETL ODS Data Mart OLTP OLAP 資料集市

咱一一分析原理

flumesqoop

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