★中國海洋石油集團有限公司 王小玲

摘要：本文通過(guò)對企業(yè)數據倉庫體系架構的分析，開(kāi)展了對模型設計和數據遷移路徑的研究，發(fā)現可以通過(guò)系統架構的優(yōu)化有效地支持企業(yè)數據倉庫中數據模型和歷史數據遷移的順利完成。此架構優(yōu)化的好處也體現在保證了數據分析服務(wù)的連續性，業(yè)務(wù)不會(huì )受到企業(yè)數據倉庫升級期間模型傳輸和凍結期的影響。另一個(gè)關(guān)鍵點(diǎn)就是企業(yè)數據倉庫底層的分布式大規模并行數據庫所提供的多租戶(hù)云架構?；诖斯蚕砑軜嬎罱ǖ钠髽I(yè)數據倉庫可以靈活部署數據應用項目，在升級和遷移過(guò)程中，利用合理資源部署所需要的開(kāi)發(fā)和測試環(huán)境，不僅滿(mǎn)足了獨立性的要求，也能減輕數據冗余。多租戶(hù)的系統架構除了滿(mǎn)足遷移和升級外，也可以在資源發(fā)生瓶頸時(shí)進(jìn)行橫向擴展。不僅在系統架構和部署方面應用多租戶(hù)，通過(guò)探索簡(jiǎn)化數據冗余，更好地履行數據的單一來(lái)源的原則方面也可以探索和應用這種系統架構。從而提供用戶(hù)更好的應用效果、更低的運營(yíng)成本和最大化的資源投入。

十八大以來(lái)，黨和國家高度重視數字化發(fā)展，企業(yè)中的第一把手也要求堅持以科技創(chuàng )新為驅動(dòng)，積極推動(dòng)數字化轉型。做好數字化轉型工作，其中之一就是要求加強數據集成共享，構建一體化經(jīng)營(yíng)管理平臺。ERP時(shí)期形成的統一數據倉庫系統經(jīng)過(guò)15年的應用，全面覆蓋了主要二級單位及核心業(yè)務(wù)領(lǐng)域，成為集成、統一、共享的經(jīng)營(yíng)管理核心系統。隨著(zhù)大數據、人工智能等信息技術(shù)的發(fā)展，業(yè)務(wù)的精細化管理要求也不斷提升。ERP系統近11年來(lái)沒(méi)有進(jìn)行過(guò)升級，系統功能欠缺、運行效率低下、擴展能力不足、用戶(hù)體驗不佳，越來(lái)越難以支撐數字化轉型智能化發(fā)展需要。所以，進(jìn)行ERP系統技術(shù)更新?lián)Q代工作勢在必行。ERP系統已經(jīng)融入企業(yè)經(jīng)營(yíng)管理日常運營(yíng)流程中，企業(yè)數據倉庫通過(guò)數據建模和處理，也支撐著(zhù)經(jīng)營(yíng)管理的數據分析及報告出具。在ERP系統的升級改造過(guò)程中，要保證經(jīng)營(yíng)管理的流程不中斷，其關(guān)聯(lián)的企業(yè)數據倉庫中的歷史數據也要完成平穩遷移，這都是面臨著(zhù)必須解決的關(guān)鍵問(wèn)題。通過(guò)系統架構的優(yōu)化能有效地支持此項工作的順利完成。

1 企業(yè)數據倉庫的體系架構概述

企業(yè)數據倉庫（Enterprise Data Warehouse，EDW）的體系架構包含了從數據源系統到最終前端的多層組件，其中技術(shù)底座決定了數據倉庫運行的穩定性、高性能、可擴展性和易用性。隨著(zhù)大數據技術(shù)的發(fā)展，作為支撐企業(yè)經(jīng)營(yíng)管理的商務(wù)智能（BI）應用和報表的數據倉庫如何通過(guò)底層技術(shù)架構的優(yōu)化和完善來(lái)適應企業(yè)大數據的應用仍然是一個(gè)值得研究和探討的話(huà)題。EDW不僅與企業(yè)業(yè)務(wù)架構、數據架構、應用架構聯(lián)系緊密，更是與技術(shù)架構密不可分，它決定了其他領(lǐng)域功能的可行性。

數據倉庫系統架構包括了技術(shù)架構和數據架構，除了強調其中包括的組件及組件之間的關(guān)系外，它應該還強調反映和調整其自身系統內各個(gè)功能組件元素及其演化狀態(tài)的能力，以及這些能力的獲得是否容易，也就是架構的擴展性和兼容性。如果將EDW看做一個(gè)有機體的話(huà)，架構就是在整體系統設計視角下，其內部各個(gè)細胞體的新陳代謝的過(guò)程。

數據倉庫中的經(jīng)典數據模型有：

關(guān)系建模（也叫范式建模），側重效率的數據倉庫用第一范式建模，側重規范的數據倉庫用第三范式建模，關(guān)系模型設計的主要目的是可以準確表達業(yè)務(wù)數據，且存儲一個(gè)消除冗余的事實(shí)。這種建模方式中常見(jiàn)的就是事實(shí)表通過(guò)兩個(gè)或兩個(gè)以上的外鍵鏈接多個(gè)維度或屬性表，強調通過(guò)ERD實(shí)體—關(guān)系設計和建模。此類(lèi)型的建模方式主要來(lái)自于Inmon在上世紀80年代提出的企業(yè)信息工廠(chǎng)理論，早期的基于關(guān)系型數據庫的數據倉庫大多基于此種方式建模。強調面向主題的、集成的、與時(shí)間相關(guān)的、不可修改的數據集合。此建模理論與其他數據庫應用不同的是，數據倉庫更像一種過(guò)程，對分布在企業(yè)內部各處的業(yè)務(wù)數據的整合、加工和分析的過(guò)程。而不是一種可以購買(mǎi)的產(chǎn)品。

維度建模，數據被重構優(yōu)化，用于滿(mǎn)足數據的查詢(xún)和分析的需要。維度建模側重大量數據分析。構建指標數據分析的系統一般標準用的是維度建模?！氨M管維度模型通常應用在關(guān)系數據庫管理系統之上，但并不要求維度模型必須滿(mǎn)足第三范式”^[1]。此種類(lèi)型的建模是由數據倉庫領(lǐng)域的Kimball倡導的，維度建模的興起解決了數據模型過(guò)于復雜的問(wèn)題，通過(guò)多維所產(chǎn)生的點(diǎn)和度量相結合，可以實(shí)現業(yè)務(wù)上的指標分析。適用于對不太成熟、快速變化的業(yè)務(wù)進(jìn)行建模。

數據拱頂（Data Vault）建模。隨著(zhù)大數據技術(shù)的發(fā)展，Inmon和Daniel提出了此種建模方式。Data Vault 2.0（DV2）是一個(gè)商業(yè)智能系統，包括模型、架構、方法論和實(shí)施這四個(gè)方面的最佳實(shí)踐^[2]。如圖1所示。

圖1 商業(yè)智能Data Vault系統

DV2建模主要引入了散列鍵和鏈接表的概念，實(shí)現跨業(yè)務(wù)主題的數據集的融合，它們通過(guò)業(yè)務(wù)流程中的鍵值結合數據集與業(yè)務(wù)過(guò)程，采用第三范式和維度建模方法混合而成，同時(shí)滿(mǎn)足NoSQL和RDBMS，往往也稱(chēng)為混合建模。

DV2建模理論的價(jià)值就在于提出了跨業(yè)務(wù)主題域的鍵值的概念，提供了跟蹤和追尋多個(gè)業(yè)務(wù)范圍的數據的能力，是將數據作為可溯源的資產(chǎn)的一個(gè)重要組成部分，體現數據價(jià)值。其它的建模方法還包括錨建模，面向對象建模，基于事實(shí)建模，基于時(shí)間建模，完全通信建模，NOSQL建模等方法，在此不再贅述。

大數據系統可以基于企業(yè)數據倉庫進(jìn)行擴展建設。通過(guò)擴展主數據系統、元數據管理系統，并建成全域數據資產(chǎn)，為企業(yè)的數據流入提供了一條新的途徑^[3]。

從以上數據倉庫建模的幾種經(jīng)典方法可以看出，每一種理論的提出和廣泛使用都與當時(shí)的數據庫與大數據技術(shù)密不可分。技術(shù)的進(jìn)步所支持的業(yè)務(wù)需求的快速迭代和實(shí)施對數據倉庫的系統架構提出相應的要求，這便有了從關(guān)系建模到維度建模再到Data Vault建模的整個(gè)理論體系的發(fā)展。

那么，如何利用已經(jīng)建成的EDW的系統架構來(lái)完成歷史數據遷移和改造升級呢？本文主要以SAP EDW為例進(jìn)行論述。

2 SAP EDW的數據建模架構的演進(jìn)和優(yōu)化

基于SAP數據倉庫建模先期主要通過(guò)關(guān)系建模的方式進(jìn)行建設，采用Oracle的結構化數據庫搭建邏輯上的維度、屬性和星型模型。這種建模方式與所匹配的ERP流程系統契合度較好，所以能支持前端用戶(hù)的商務(wù)智能和報表需求。隨著(zhù)SAP自有的高性能內存數據庫HANA的問(wèn)世，以及大數據技術(shù)的發(fā)展，原有嚴謹的外鍵對事實(shí)表和維表進(jìn)行關(guān)聯(lián)的界限變得模糊，在內存數據庫中也可以實(shí)現維度的建模。如圖2所示。

圖2 SAP EDW建模

利用SAP HANA數據庫可以實(shí)現三種方式的建模。

第一種，基于SQL的建模，客戶(hù)的數據源大多是非SAP的系統，可以通過(guò)基于SQL的數據倉庫工具，在HANA數據之上進(jìn)行模型搭建。這種情況下可以利用HANA里面的計算視圖進(jìn)行實(shí)施，大部分第三方數據倉庫產(chǎn)品可以提取HANA的計算視圖數據。第二種，混合模式，如果客戶(hù)本身已經(jīng)具有了SAP BW和其他品牌的數據倉庫，可以同時(shí)利用這兩種系統環(huán)境進(jìn)行模型搭建。BW數據模型中的大部分對象也可以映射成對應的視圖與外部SQL數據倉庫進(jìn)行融合。第三種，SAP EDW建模方式。這種方式的體系架構比較清晰，中央元數據存儲庫能有效支持端到端的基于架構的數據倉庫中的數據管理。

參考以上模式的數據倉庫實(shí)施方法，傳統的BW建模變成輕量級，復雜的層層加載的數據鏈除了處理復雜邏輯打包的SAP事務(wù)端標準數據源的抽取、傳輸和上載外，大部分的數據處理任務(wù)通過(guò)底層的HANA數據庫建模，通過(guò)虛擬化封裝，以數據服務(wù)的形式提供最終商務(wù)智能消費端，包括報表出具與移動(dòng)應用。

當EDW已經(jīng)逐漸向混合式轉變時(shí)，如何有效利用數據倉庫的已有優(yōu)勢和未來(lái)數據倉庫的靈活架構來(lái)實(shí)現平穩遷移呢？

3 基于企業(yè)數據倉庫的優(yōu)化實(shí)現平穩遷移的關(guān)鍵點(diǎn)

（1）應用系統架構的優(yōu)化實(shí)現EDW平穩遷移的關(guān)鍵點(diǎn)之一：通過(guò)讀取優(yōu)化的操作型數據存儲模型（ADSO）實(shí)現平穩的數據模型的遷移。

（2）EDW中的數據是分層匯聚并處理的。這種分層和匯聚按照分層可伸縮架構（Layered Scalable Architecture，LSA）來(lái)實(shí)現。LSA代表了可靠的管理數據和元數據生命周期的數據倉庫框架體系。隨著(zhù)HANA的不斷應用，LSA框架擴展到LSA++整體框架，以滿(mǎn)足高效運營(yíng)和敏捷BI的需求。如圖3所示。

圖3 LSA++分層模型

LSA++的重要部分包括EDW部分，其中緩沖/企業(yè)內存部分包括了源模型與EDW模型之間的鏈接，企業(yè)內存持久層。開(kāi)放的操作數據層（ODSO）加快了模型中數據的激活時(shí)間，一個(gè)模型至少加速10%。在進(jìn)行對SAP BW 7.30 SP 10遷移到BW/4過(guò)程中，所有標準數據存儲對象執行SAP HANA優(yōu)化激活，而無(wú)需進(jìn)行任何設置，也無(wú)需進(jìn)行任何手動(dòng)轉換或遷移活動(dòng)，節省了遷移過(guò)程中的工作量消耗。除了激活，SID（主數據ID）生成也經(jīng)過(guò)HANA優(yōu)化。因此，如果在數據激活期間設置SID生成，則幾乎不會(huì )對正在進(jìn)行生產(chǎn)系統運行的數據倉庫性能產(chǎn)生任何影響。

除此之外，如圖3中的箭頭所示，查詢(xún)不僅可以在虛擬的體系結構數據集市之上運行，也可以跨層直接從開(kāi)放的操作數據層（ODS）以及傳播層DSO上運行查詢(xún)，其性能與EDW之上的信息立方體多維模型（Info Cube）上運行類(lèi)似。

EDW升級和遷移過(guò)程中，并行實(shí)施項目及已上線(xiàn)的應用往往是受影響最大的，特別是在并行實(shí)施過(guò)程中用到EDW中企業(yè)內存持久層的內容或者標準數據源時(shí)?，F實(shí)中往往發(fā)生這樣的情況，如果EDW升級和遷移的A項目的凍結期安排在3月初至6月底，而業(yè)務(wù)單位將EDW的標準數據源作為貼源層，實(shí)施6月底上線(xiàn)的B項目，如何實(shí)現兩個(gè)項目的并行運行并保證相互不受影響？基于以上的系統架構能保證A、B項目同時(shí)進(jìn)行，相互不會(huì )產(chǎn)生影響。如圖4所示。所以，關(guān)鍵點(diǎn)就在實(shí)施B項目時(shí)，將貼源層的數據模型搭建在DSO之上，通過(guò)BW/4的升級轉換，這些DSO自動(dòng)轉換為ADSO，成為HANA工作區可以識別的視圖（通過(guò)路徑③），不需要再到BW/4工作區進(jìn)行模型調整，也不必等待BW/4應用工作區遷移完成才開(kāi)始工作。而其他的BW模型及與BW Infocube等相關(guān)的HANA View同樣需要通過(guò)路徑①、②和④進(jìn)行轉換和遷移，受到凍結期和BW/4模型調整的影響。

圖4 BW/4數據遷移

綜上所述，基于LSA++的端對端框架，原有的數據倉庫通過(guò)遠程遷移的方式，分步驟地傳輸到目標系統時(shí)，可以花費較小代價(jià)和資源，完成數據模型和歷史數據遷移和升級任務(wù)。

（2）應用系統架構的優(yōu)化實(shí)現EDW平穩遷移的關(guān)鍵點(diǎn)之二：多租戶(hù)的使用。

由于SAP HANA是一種分布式大規模并行分析數據庫（Analytical Massively Parallel Processing（MPP）Databases），不僅能通過(guò)列式存儲方式對數據進(jìn)行壓縮，同時(shí)能平衡和配置大數據分析工作的負載，這種體系結構使復雜的分析查詢(xún)可以更快、更有效地處理。

SAP HANA租戶(hù)數據庫是SAP HANA中多租戶(hù)的基礎。能夠在一個(gè)SAP HANA系統中運行和管理多租戶(hù)數據庫，有助于降低資本支出、簡(jiǎn)化數據庫管理并構建多租戶(hù)云應用程序。從HANA2.0以后自動(dòng)轉換成多租戶(hù)（Multi-tenant Database Container，MDC）模式。如圖5所示。

圖5 多租戶(hù)數據庫

一個(gè)系統始終只有一個(gè)用于中央系統管理的系統數據庫，以及任意數量的租戶(hù)數據庫（包括零個(gè)），多個(gè)應用程序在不同的租戶(hù)數據庫中運行。SAP HANA系統有單個(gè)系統ID（SID，請區分此SID與前面所述的主數據SID的不同）標識。數據庫由SID和數據庫名稱(chēng)標識。

從管理的角度來(lái)看，在系統級執行的任務(wù)和在數據庫級執行的任務(wù)之間存在區別。在多租戶(hù)的情況下，可以共享相同的數據庫系統、軟件安裝、相同的計算資源和相同的系統管理。但是，每個(gè)DB Schema都是獨立的。這種多租戶(hù)的MPP架構使得其上的數據應用項目部署更加靈活。在進(jìn)行EDW遷移和升級過(guò)程中，就利用了多租戶(hù)系統架構，從而節省了遷移和升級過(guò)程中所需要耗費的數據庫和硬件資源。系統架構如圖6所示。

圖6 遷移和升級場(chǎng)景下的多租戶(hù)

在節點(diǎn)3上，有3套系統，系統DB、開(kāi)發(fā)環(huán)境和測試環(huán)境。System DB安裝時(shí)默認SID為D12，建立開(kāi)發(fā)環(huán)境租戶(hù)時(shí)，這個(gè)環(huán)境的SID為D12@D12，后期又根據需求增加了測試環(huán)境的租戶(hù)，SID為Q12@D12。這種方式，保證了同一節點(diǎn)下繼續增加租戶(hù)時(shí)每個(gè)租戶(hù)系統的獨立性。

除此之外，其他基于多租戶(hù)數據倉庫系統架構還可以適用橫向擴展（Scale Out）場(chǎng)景，應用于集團公司及下屬需要獨立性的上市公司的系統架構。

一般來(lái)說(shuō)，企業(yè)集團統建系統會(huì )先實(shí)施SAP HANA系統，如下示例，統建系統形成了6個(gè)節點(diǎn)，每個(gè)節點(diǎn)容量為2TB的EDW系統。除Standby節點(diǎn)的2TB外，其他5個(gè)節點(diǎn)中的4個(gè)節點(diǎn)有8TB內存容量可用。所以Tenant DB1.1~1.4可以分布在集團公司的4個(gè)主要節點(diǎn)上，減輕主節點(diǎn)上的數據壓力。下屬公司可以在Host5（節點(diǎn)5）下面建立自己獨立的數據應用環(huán)境，保證了2TB的內存容量。由主節點(diǎn)共同管理底層系統資源，實(shí)現成本效益最大化。如圖7所示。

圖7 橫向擴展場(chǎng)景下的多租戶(hù)

以上模式的優(yōu)勢：使用HANA多租戶(hù)MDC特性，可以實(shí)現跨租戶(hù)的數據查詢(xún)訪(fǎng)問(wèn)。一臺Standby節點(diǎn)可待命兩套系統。租戶(hù)的拓展縮減方便，比如可以再增加或者刪除租戶(hù)3而不影響其他租戶(hù)的使用。劣勢：如果租戶(hù)1和租戶(hù)2同時(shí)出現故障時(shí)，Standby節點(diǎn)無(wú)法同時(shí)兼顧。另外，停機維護時(shí)，租戶(hù)1和租戶(hù)2的應用同時(shí)受影響。

以上兩種都是常用的多租戶(hù)數據倉庫的應用場(chǎng)景。目前我們也在繼續探索其他應用場(chǎng)景，比如用于業(yè)務(wù)上關(guān)聯(lián)緊密，貼源層共享的兩個(gè)獨立DB Schema系統。這種類(lèi)型的場(chǎng)景往往發(fā)生在不同的兩個(gè)應用系統需要向同一個(gè)數據倉庫系統提取數據，并且這些數據具有高度的一致性。如果單獨建立兩個(gè)數據庫系統，分別存放一份數據，必然引起數據冗余，而且這些冗余數據極易導致數據的不一致。另外，考慮到多一份數據庫系統將耗費更多的運維資源，所以采用多租戶(hù)是一種各方面評估后均合適的方案。

4 結語(yǔ)

綜上論述，EDW系統作為是集團數據平臺的一部分，發(fā)揮著(zhù)支撐企業(yè)數據分析和輔助決策的作用。特別是底層的體系架構的能力以及其變化發(fā)展對EDW所構建及支撐的數據平臺滿(mǎn)足最終用戶(hù)需求的能力起著(zhù)決定性的作用。利用虛擬化的高級操作型數據模型對象ADSO可以盡可能減少EDW遷移和升級對并行數據平臺實(shí)施項目的影響；利用多租戶(hù)的MPP架構可以擴展數據倉庫的能力，使得更多的系統環(huán)境經(jīng)濟高效實(shí)現。

作者簡(jiǎn)介：

王小玲 （1972-），女，四川宜賓人，高級工程師，碩士，現就職于中國海洋石油集團有限公司信息技術(shù)中心，研究方向為大數據及商務(wù)智能應用。

參考文獻：

[1]RalphKimball.數據倉庫工具箱:維度建模權威指南[M].王念濱,周連科,韋正現,譯.北京:清華大學(xué)出版社,2015.38.

[2]W.H.InmonDanielLinstedt.數據架構[M].唐富年,譯.北京:人民郵電出版社,2016.106.

[3]DAMA國際:DAMA數據管理知識體系指南[M].DAMA中國分會(huì )翻譯組,譯.北京:機械工業(yè)出版社,2020.297.

摘自《自動(dòng)化博覽》2022年9月刊