淺析數倉分層:DB+ODS+DW+DM
本期將從結構層面瞭解資料倉儲分層的幾個名詞和簡單理解。
文章目錄
1 理想的資料分層總體結構
如圖可看出理想的資料分層分為四層:
- 源資料層DB,包括關係型資料庫、非關係型資料庫、以及未採集到資料庫直接以檔案形式存在的資料;
- 運算元據儲存層ODS,包括企業級操作型系統資料OLTP以及及時分析型系統資料OLAP;
- 資料倉儲DW/EDW層,包括資料明細層DWD,輕度彙總層MID/DWB,主題層/資料服務層DWS… (資料倉儲分層並不是如上圖那般簡單明確,每一層分層的取捨都由架構師對業務難度、業務適用範圍和現有資源的多少來決定,在文末筆者將提出生產環境較複雜的資料倉儲案例模型,以供參考。)
- 資料集市層/應用層DM。
為什麼要對資料分層?
- 清晰資料結構:對資料和表以及此層的作用域有清晰的定位和理解。
- 方便進行資料血緣追蹤:簡單來講可以這樣理解,我們最終給業務誠信的是一能直接使用的張業務表,但是它的來源有很多,如果有一張來源表出問題了,我們希望能夠快速準確地定位到問題,並清楚它的危害範圍。關於資料血緣關係可檢視筆者往期文章:資料治理:資料血緣關係分析。
- 減少重複開發:規範資料分層,開發一些通用的中間層資料,能夠減少極大的重複計算。
- 把複雜問題簡單化:講一個複雜的任務分解成多個步驟來完成,每一層只處理單一的步驟,比較簡單和容易理解。而且便於維護資料的準確性,當資料出現問題之後,可以不用修復所有的資料,只需要從有問題的步驟開始修復。
- 遮蔽原始資料的異常。
- 遮蔽業務的影響,不必改一次業務就需要重新接入資料。
2 DB層:關係型資料庫和非關係型資料庫
資料庫(
Database,DB
):常見的資料庫分為關係型資料庫和非關係層資料庫。
2.1 關係型資料庫RDB
關聯式資料庫(Relational Database,RDB)就是基於關係模型的資料庫,也叫關係型資料庫。詳見關係型資料庫
**關係模型(Relational Model):**可理解為是一個二維資料表格模型,所有資訊都表現為關係中的資料值。詳見關係模型
**關係型資料庫事務必須具備ACID
特性,ACID
分別是Atomic
原子性,Consistency
一致性,
Isolation
隔離性,Durability
永續性。**詳見資料庫系統中事務的ACID原則
常用的關係型資料庫有:
Oracle,Microsoft SQL Server,MySQL/MariaDB,PostgreSQL,DB2/Informix,
Microsoft Access, SQLite,Teradata,SAP
2.2 非關係型資料庫NoSQL
NoSQL最常見的解釋是“non-relational”, “Not Only SQL”也被很多人接受。NoSQL僅僅是一個概念,泛指非關係型的資料庫,區別於關聯式資料庫,它們不保證關係資料的ACID特性。詳見NoSQL
NoSQL的基本需求就是支援分散式儲存,嚴格一致性與可用性需要互相取捨。
NoSQL的CAP理論:**一個分散式系統不可能同時滿足C(一致性)、A(可用性)、P(分割槽容錯性)**三個基本需求,並且最多隻能滿足其中的兩項。對於一個分散式系統來說,分割槽容錯是基本需求,否則不能稱之為分散式系統,因此需要在C和A之間尋求平衡。詳見CAP原則
常用的NoSQL有以下幾大類:
1 面向高效能併發讀寫的key-value資料庫
Redis, Amazon DynamoDB, Memcached,
Microsoft Azure Cosmos DB和Hazelcast
2 面向海量資料訪問的面向文件資料庫
MongoDB,Amazon DynamoDB,Couchbase,
Microsoft Azure Cosmos DB和CouchDB
3 面向搜尋資料內容的搜尋引擎
Elasticsearch,Splunk,Solr,MarkLogic和Sphinx
4 面向可擴充套件性的分散式資料庫
Cassandra,HBase,Microsoft Azure Cosmos DB,
Datastax Enterprise和Accumulo
3 ODS層:運算元據儲存層
很多時候,提起數倉,有一些人會直接想到DB到DW這兩層,或者有部分人會把DW中的DWD當作是ODS層,然而,實際生產環境中,我們還需要一個概念明確且和DWD界限清晰的中間資料層,那就是ODS。
參考連結:https://www.cnblogs.com/liuwchao/articles/10423647.html (ODS層簡介和ODS設計)
3.1 ODS產生背景
人們對資料的處理行為可以劃分為操作型資料處理和分析型資料處理(詳見操作型資料庫和分析型資料庫的區別 、OLAP、OLTP的介紹和比較),操作型資料處理一般放在傳統的DB中進行,分析型資料處理則需要在DW(Data Warehouse, 資料倉儲)中進行。但是並不是所有的資料處理都可以這樣劃分,換句話說,人們對資料的處理需求並不只有這兩類,比如,有些操作型處理並不適合放在傳統的資料庫上完成,也有些分析型處理不適合在資料倉儲中進行。這時候就需要第三種資料儲存體系,運算元據儲存(Operational Data Store,ODS
)系統就因此產生。它的出現,也將DB~DW
兩層資料架構轉變成DB~ODS~DW
三層資料架構。
3.2 ODS在企業資料架構中擔任的角色
企業資料架構需要建立在統一的資料模型的基礎上,由生產系統自有資料庫(DB)、運算元據儲存(ODS)、企業資料倉儲(EDW)三個層面組成。
其中,ODS層儲存的是:按業務主題分類的、面向運營的準實時資料,提供統一的企業資料檢視。
生產系統自有資料庫(DB)儲存的是:該生產系統內部運算元據和基礎資訊資料。
EDW儲存面向經營決策分析的歷史資料和綜合資料。
ODS對生產系統產生的資料進行清洗、過濾、轉換、整合(詳見資料ETL),是提供給EDW高質量資料的重要來源之一,同時為各個生產系統提供準實時的運營報表等跨系統共享資料服務。另外,在企業運營層,對於需要同時利用跨系統的操作型資料和相關分析結果資料的協作性應用需求,ODS也起到關鍵支撐作用。
ODS系統是一個跨系統的資料共享平臺,承接操作環境和分析環境。
3.3 ODS層的特徵
ODS中的資料具有以下4個基本特徵:
- **面向主題的:**進入ODS的資料是來源於各個操作型資料庫以及其他外部資料來源,資料進入ODS前必須經過
ETL
過程(抽取、清洗、轉換、載入等)。 - **整合的:**ODS的資料來源於各個操作型資料庫,同時也會在資料清理加工後進行一定程度的綜合。
- **可更新的:**可以聯機修改。這一點區別於資料倉儲。
- 當前或接近當前的:“當前”是指資料在存取時刻是最新的,“接近當前”是指存取的資料是最近一段時間得到的。
3.4 ODS層的功能
(1)實現企業級的OLTP操作:
傳統的操作型資料庫往往只存放企業某一類業務或者某一個部門的資料,因此無法面向企業全域性資料的OLTP,而ODS可以實現。因為ODS的資料是面向整個企業進行整合彙總的,克服了原來面向應用的操作型資料庫資料分散的缺陷。
(2)實現即時的OLAP操作:
在資料倉儲上進行OALP,往往由於資料量十分龐大而需要較長的時間。而在企業實際應用中,對於一些較低層次的決策,往往並不需要太多的歷史資料,可能只需要參考當前的或者接近當前的資料就可以完成,並且要求具有較快的響應時間,因此資料倉儲顯然無法滿足這樣的要求,但是ODS可以實現。ODS中不僅有面向企業全域性的細節資料和彙總資料,而且規模比資料倉儲小,具有較強的實時響應能力。
4 DW層:資料倉儲
未完待續…
相關文章
- 數倉 - [04] 數倉分層
- 數倉建模分層理論
- 資料倉儲(6)數倉分層設計
- pyspark底層淺析Spark
- ArrayList底層原理淺析
- 從ODS到ADS,詳解數倉分層!
- 淺析skynet底層框架下篇框架
- 淺談分層圖
- 數倉開發之ODS層
- 【Camera專題】Qcom-Camera驅動框架淺析(Hal層->Driver層)框架
- 股票虧損怎麼辦——淺析鎖倉的好處
- 資料倉儲分層你清楚了嗎
- 資料倉儲架構分層設計架構
- 資料倉儲分層概念之我見
- iOS Block淺淺析iOSBloC
- iOS底層原理 MVC、MVP、MVVM、分層設計淺談 — (13)iOSMVCMVPMVVM
- 數倉公共層,還有存在的必要嗎?
- 由淺入深 docker 系列: (6) 映象分層Docker
- 淺析RedisRedis
- Jvm 淺析JVM
- CGLib淺析CGLib
- 淺析XMLXML
- MongoDB淺析MongoDB
- 淺析 JWTJWT
- 淺析 DDD
- RunLoop 淺析OOP
- 淺析 ReentrantLockReentrantLock
- Unstated淺析
- 淺析SharedPreferences
- Nginx淺析Nginx
- 淺析PromisePromise
- ejs 淺析JS
- 淺析KubernetesStatefulSet
- AIDL淺析AI
- ArrayList淺析
- [譯] 淺析深度學習神經網路的卷積層深度學習神經網路卷積
- 分層架構在資料倉儲的應用架構
- 淺析Oracle(rownum)和Mysql(limit)分頁的區別OracleMySqlMIT