大型數據倉庫項目ODS 層的系統設計

韓慶安 珠海世紀鼎利科技股份有限公司

關鍵字：大數據 ODS

一、什么是ODS

ODS（Operational Data Store），可操作的數據存儲。是數據倉庫體系結構中的不可缺少的一個部分，是存儲整個數據倉庫的數據的地方，是元數據經過ETL 抽取，再到OLAP 分析庫的中轉樞紐。可以這樣通俗的理解：ODS 就是把一線的生產數據經過抽取、整理、清洗等一系列操作，歸納成一個相對完整、相對封閉的數據存儲倉庫。ODS 的構成并不是一個數據庫或者一個文件服務器，應該是一系列數據庫以及文件服務器的總稱。

二、如何設計一個具體的ODS 層

對于系統架構設計師來說，任何一個系統的設計工作，都要建立在對業務需求的親身調查的基礎上，傳統的應用軟件如此，大型的數據倉庫項目也應如此。俗話說：沒有調查，就沒有發言權。這種調查應該是方方面面的，甚至在一些問題上要精確到具體的業務場景的，比如元數據的特點、數據抽取的頻率，上層OLAP 系統對ODS 層數據結構的要求等等。

結合實際調查具體項目特點的基礎上，ODS 層的設計，可以總結為以下幾個方面：

1.數據庫的選取

ODS 層的數據來源可以定義為上層的生產數據，也就是整個系統的元數據。生產數據比較原始，數據的結構、數據的類型以及數據的產生頻率都是由現場生產的特點決定的。比如電力系統的發電數據，主汽溫度、汽輪機轉速、二次風出口溫度等，這樣的數據在第一手生產數據系統里，通常是有實時數據庫或者內存數據庫完成采集，數據的組織比較雜亂，必須經過ETL 工具經過抽取、清洗等操作，才能進入數據倉庫，也就是ODS 層。那么根據不同行業不同領域的元數據的特點，應該切合實際情況選取ODS 層的數據庫模型。其中包括：關系型數據庫的選擇、表的結構的設計、存儲空間的分配等。上述電力系統的ODS 層，結合實際情況，應選擇oracle RAC 作為核心存儲。一方面，oracle RAC 的性能比較好，在眾多的關系型數據庫產品中，性能是經過考驗的；oracle RAC 提供了一系列主從復制、雙機熱備、DG 等措施保證數據的安全和完整，同時，也可以利用上述特點隨時為ODS 層存儲的數據抽象出一套業務數據庫，方便一些周邊業務功能的數據查詢工作，而不應該整個數據倉庫的性能。最主要的是，像這樣的生產制造型企業，元數據以結構化數據為主，并不會出現圖片、聲音等非結構化數據，所以，像這樣的生產制造型企業，選用oracle RAC 作為存儲，是比較恰當的。

幾年來，hadoop 比較流行，hadoop 的特點是以HDFS 為基礎，建立在hbase 數據庫上的。hadoop 的特點是可以很好地處理非結構化數據，并且采用了分布式的架構，可以進行MapReduce 計算。針對這樣的特點，交通運輸類項目的ods層選擇可以使用hadoop作為存儲，比如某市地鐵項目。地鐵項目包含站務系統、票務系統和乘務系統等，這樣的系統產生的元數據，一定會包含大量的非結構化的數據，針對此種情形，hadoop 可以非常完美地解決這個問題，并且，hadoop 采用了分布式文件系統存儲數據，可以一式多份，對數據的備份也提供了方便。

2.數據庫參數的設計

就上文中提到的電力系統發電部的模型，數據庫選擇了oracle RAC，接下來就是一系列參數的設置。

ODS 層的關系型數據庫，和傳統的OLTP 型數據庫，在設計思路上有本質上的區別，關心的“點”，也截然不同。就Oracle 數據庫為例，對于OLTP 數據庫，由于事務型數據庫的DML 行為非常頻繁，所以關心的點是內存使用率、各種指標的命中率、綁定變量和并發操作。對于一個OLTP 系統來說，數據庫內存設計顯得很重要，如果數據都可以在內存中處理，那么數據庫的性能無疑會提高很多。

內存的設計通常是通過調整Oracle 和內存相關的初始化參數來實現的，比較重要的幾個是內存相關的參數，包括SGA 的大小（Data Buffer，Shared Pool），PGA 大小（排序區，Hash 區等）等，這些參數在一個OLTP 系統里顯得至關重要，OLTP 系統是一個數據塊變化非常頻繁，SQL 語句提交非常頻繁的一個系統。對于數據塊來說，應盡可能讓數據塊保存在內存當中，對于SQL 來說，盡可能使用變量綁定技術來達到SQL 的重用，減少物理I/O 和重復的SQL 解析，能極大的改善數據庫的性能。

如果說OLTP 型數據庫的評測指標是相應時間，那么OLAP 型數據庫的指標應該是吞吐量。聯機分析系統的DML 操作非常少，而且時間比較集中，即使是數據導入，也很少使用直接insert 的方式，要么是SqlLoad 加載進來的，要么是通過Kettle 等工具加載進來的。對于用戶來說：它更像一個只讀的數據庫。這樣的數據庫，設計的時候內存的因素考慮的很少，應該考慮的是以下幾個方面：

分區：由于數據量太過龐大，你必須設計的時候就考慮好分區處理。

索引：并不是說ODS 中的數據庫就不重視相應時間，那么建立索引是提高查詢效率最好的途徑，但是由于每張業務表的數據量都非常龐大，你必須考慮到每次加載數據的時候刪除索引，加載完畢之后再重建索引的問題，否則索引反而會給數據導入帶來麻煩。

物理參數：鑒于數據在盤陣上的存儲比較穩定，不會發生頻繁的DML 操作。修改一些物理參數以改善數據庫性能。可以考慮建立一些Bigfile Tablespace，并且將這些大文件表空間設置成Automatic Storage Management，自動存儲管理。使用大文件表空間可以更好地發揮Oracle 在64 位操作系統下的存儲能力。另外，將ASM 的塊大小調整為16M(默認為1M)。這也是提高Oracle 存儲能力的一種手段。

3.文件組設計

這里的文件組指的也是對結構化數據的存儲，并非非結構化數據。

文件組的規劃在ODS 層也是相當重要的一個環節，在某項目中，涉及到23 個省級系統的、各分成9 種業務類型的、分成不同的時間區段的文件組數據。這樣，需要對磁盤組進行詳細再詳細的規劃，并且對“周期”問題的考慮一定要細致、慎重，因為ETL 加載的時候，“本周期”沒有加載完，“下一周期”的數據又來了。

4.數據備份

任何一個技術管理者，都明白數據備份的重要性，數據丟了，應用程序寫的再花俏都功虧一簣。

目前比較流行6+1、 4+7 的備份策略。什么是6+1 和4+7 呢？就是星期日做一個全量備份，之后每天做一個增量備份，每七天為一個周期，每個月有四個周期。保留歷史備份記錄的話，一般保留最近一個月的，也就是最近四次的全量備份。如果配合歸檔數據，這樣可以保證數據庫在任何時間點宕機，都不丟數據。ODS 層作為數據倉庫系統的一個重要組成部分，存儲了整個倉庫幾乎全部的數據，項目開始時對你的數據做一份詳細的備份計劃，可以讓你在數據安全的問題上，高枕無憂。