国产欧美日韩精品a在线观看-国产欧美日韩精品一区二区三区-国产欧美日韩精品综合-国产欧美中文字幕-一区二区三区精品国产-一区二区三区精品国产欧美

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

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

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

1 企業(yè)數(shù)據(jù)倉庫的體系架構(gòu)概述

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

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

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

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

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

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

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

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

DV2建模理論的價值就在于提出了跨業(yè)務主題域的鍵值的概念，提供了跟蹤和追尋多個業(yè)務范圍的數(shù)據(jù)的能力，是將數(shù)據(jù)作為可溯源的資產(chǎn)的一個重要組成部分，體現(xiàn)數(shù)據(jù)價值。其它的建模方法還包括錨建模，面向?qū)ο蠼＃谑聦嵔＃跁r間建模，完全通信建模，NOSQL建模等方法，在此不再贅述。

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

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

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

2 SAP EDW的數(shù)據(jù)建模架構(gòu)的演進和優(yōu)化

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

圖2 SAP EDW建模

利用SAP HANA數(shù)據(jù)庫可以實現(xiàn)三種方式的建模。

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

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

當EDW已經(jīng)逐漸向混合式轉(zhuǎn)變時，如何有效利用數(shù)據(jù)倉庫的已有優(yōu)勢和未來數(shù)據(jù)倉庫的靈活架構(gòu)來實現(xiàn)平穩(wěn)遷移呢？

3 基于企業(yè)數(shù)據(jù)倉庫的優(yōu)化實現(xiàn)平穩(wěn)遷移的關(guān)鍵點

（1）應用系統(tǒng)架構(gòu)的優(yōu)化實現(xiàn)EDW平穩(wěn)遷移的關(guān)鍵點之一：通過讀取優(yōu)化的操作型數(shù)據(jù)存儲模型（ADSO）實現(xiàn)平穩(wěn)的數(shù)據(jù)模型的遷移。

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

圖3 LSA++分層模型

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

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

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

圖4 BW/4數(shù)據(jù)遷移

綜上所述，基于LSA++的端對端框架，原有的數(shù)據(jù)倉庫通過遠程遷移的方式，分步驟地傳輸?shù)侥繕讼到y(tǒng)時，可以花費較小代價和資源，完成數(shù)據(jù)模型和歷史數(shù)據(jù)遷移和升級任務。

（2）應用系統(tǒng)架構(gòu)的優(yōu)化實現(xiàn)EDW平穩(wěn)遷移的關(guān)鍵點之二：多租戶的使用。

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

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

圖5 多租戶數(shù)據(jù)庫

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

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

圖6 遷移和升級場景下的多租戶

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

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

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

圖7 橫向擴展場景下的多租戶

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

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

4 結(jié)語

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

作者簡介：

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

參考文獻：

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

[2]W.H.InmonDanielLinstedt.數(shù)據(jù)架構(gòu)[M].唐富年,譯.北京:人民郵電出版社,2016.106.

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

摘自《自動化博覽》2022年9月刊