★中國海洋石油集團有限公司 王小玲
摘要:本文通過對企業數據倉庫體系架構的分析,開展了對模型設計和數據遷移路徑的研究,發現可以通過系統架構的優化有效地支持企業數據倉庫中數據模型和歷史數據遷移的順利完成。此架構優化的好處也體現在保證了數據分析服務的連續性,業務不會受到企業數據倉庫升級期間模型傳輸和凍結期的影響。另一個關鍵點就是企業數據倉庫底層的分布式大規模并行數據庫所提供的多租戶云架構。基于此共享架構所搭建的企業數據倉庫可以靈活部署數據應用項目,在升級和遷移過程中,利用合理資源部署所需要的開發和測試環境,不僅滿足了獨立性的要求,也能減輕數據冗余。多租戶的系統架構除了滿足遷移和升級外,也可以在資源發生瓶頸時進行橫向擴展。不僅在系統架構和部署方面應用多租戶,通過探索簡化數據冗余,更好地履行數據的單一來源的原則方面也可以探索和應用這種系統架構。從而提供用戶更好的應用效果、更低的運營成本和最大化的資源投入。
十八大以來,黨和國家高度重視數字化發展,企業中的第一把手也要求堅持以科技創新為驅動,積極推動數字化轉型。做好數字化轉型工作,其中之一就是要求加強數據集成共享,構建一體化經營管理平臺。ERP時期形成的統一數據倉庫系統經過15年的應用,全面覆蓋了主要二級單位及核心業務領域,成為集成、統一、共享的經營管理核心系統。隨著大數據、人工智能等信息技術的發展,業務的精細化管理要求也不斷提升。ERP系統近11年來沒有進行過升級,系統功能欠缺、運行效率低下、擴展能力不足、用戶體驗不佳,越來越難以支撐數字化轉型智能化發展需要。所以,進行ERP系統技術更新換代工作勢在必行。ERP系統已經融入企業經營管理日常運營流程中,企業數據倉庫通過數據建模和處理,也支撐著經營管理的數據分析及報告出具。在ERP系統的升級改造過程中,要保證經營管理的流程不中斷,其關聯的企業數據倉庫中的歷史數據也要完成平穩遷移,這都是面臨著必須解決的關鍵問題。通過系統架構的優化能有效地支持此項工作的順利完成。
1 企業數據倉庫的體系架構概述
企業數據倉庫(Enterprise Data Warehouse,EDW)的體系架構包含了從數據源系統到最終前端的多層組件,其中技術底座決定了數據倉庫運行的穩定性、高性能、可擴展性和易用性。隨著大數據技術的發展,作為支撐企業經營管理的商務智能(BI)應用和報表的數據倉庫如何通過底層技術架構的優化和完善來適應企業大數據的應用仍然是一個值得研究和探討的話題。EDW不僅與企業業務架構、數據架構、應用架構聯系緊密,更是與技術架構密不可分,它決定了其他領域功能的可行性。
數據倉庫系統架構包括了技術架構和數據架構,除了強調其中包括的組件及組件之間的關系外,它應該還強調反映和調整其自身系統內各個功能組件元素及其演化狀態的能力,以及這些能力的獲得是否容易,也就是架構的擴展性和兼容性。如果將EDW看做一個有機體的話,架構就是在整體系統設計視角下,其內部各個細胞體的新陳代謝的過程。
數據倉庫中的經典數據模型有:
關系建模(也叫范式建模),側重效率的數據倉庫用第一范式建模,側重規范的數據倉庫用第三范式建模,關系模型設計的主要目的是可以準確表達業務數據,且存儲一個消除冗余的事實。這種建模方式中常見的就是事實表通過兩個或兩個以上的外鍵鏈接多個維度或屬性表,強調通過ERD實體—關系設計和建模。此類型的建模方式主要來自于Inmon在上世紀80年代提出的企業信息工廠理論,早期的基于關系型數據庫的數據倉庫大多基于此種方式建模。強調面向主題的、集成的、與時間相關的、不可修改的數據集合。此建模理論與其他數據庫應用不同的是,數據倉庫更像一種過程,對分布在企業內部各處的業務數據的整合、加工和分析的過程。而不是一種可以購買的產品。
維度建模,數據被重構優化,用于滿足數據的查詢和分析的需要。維度建模側重大量數據分析。構建指標數據分析的系統一般標準用的是維度建模。“盡管維度模型通常應用在關系數據庫管理系統之上,但并不要求維度模型必須滿足第三范式”[1]。此種類型的建模是由數據倉庫領域的Kimball倡導的,維度建模的興起解決了數據模型過于復雜的問題,通過多維所產生的點和度量相結合,可以實現業務上的指標分析。適用于對不太成熟、快速變化的業務進行建模。
數據拱頂(Data Vault)建模。隨著大數據技術的發展,Inmon和Daniel提出了此種建模方式。Data Vault 2.0(DV2)是一個商業智能系統,包括模型、架構、方法論和實施這四個方面的最佳實踐[2]。如圖1所示。
圖1 商業智能Data Vault系統
DV2建模主要引入了散列鍵和鏈接表的概念,實現跨業務主題的數據集的融合,它們通過業務流程中的鍵值結合數據集與業務過程,采用第三范式和維度建模方法混合而成,同時滿足NoSQL和RDBMS,往往也稱為混合建模。
DV2建模理論的價值就在于提出了跨業務主題域的鍵值的概念,提供了跟蹤和追尋多個業務范圍的數據的能力,是將數據作為可溯源的資產的一個重要組成部分,體現數據價值。其它的建模方法還包括錨建模,面向對象建模,基于事實建模,基于時間建模,完全通信建模,NOSQL建模等方法,在此不再贅述。
大數據系統可以基于企業數據倉庫進行擴展建設。通過擴展主數據系統、元數據管理系統,并建成全域數據資產,為企業的數據流入提供了一條新的途徑[3]。
從以上數據倉庫建模的幾種經典方法可以看出,每一種理論的提出和廣泛使用都與當時的數據庫與大數據技術密不可分。技術的進步所支持的業務需求的快速迭代和實施對數據倉庫的系統架構提出相應的要求,這便有了從關系建模到維度建模再到Data Vault建模的整個理論體系的發展。
那么,如何利用已經建成的EDW的系統架構來完成歷史數據遷移和改造升級呢?本文主要以SAP EDW為例進行論述。
2 SAP EDW的數據建模架構的演進和優化
基于SAP數據倉庫建模先期主要通過關系建模的方式進行建設,采用Oracle的結構化數據庫搭建邏輯上的維度、屬性和星型模型。這種建模方式與所匹配的ERP流程系統契合度較好,所以能支持前端用戶的商務智能和報表需求。隨著SAP自有的高性能內存數據庫HANA的問世,以及大數據技術的發展,原有嚴謹的外鍵對事實表和維表進行關聯的界限變得模糊,在內存數據庫中也可以實現維度的建模。如圖2所示。
圖2 SAP EDW建模
利用SAP HANA數據庫可以實現三種方式的建模。
第一種,基于SQL的建模,客戶的數據源大多是非SAP的系統,可以通過基于SQL的數據倉庫工具,在HANA數據之上進行模型搭建。這種情況下可以利用HANA里面的計算視圖進行實施,大部分第三方數據倉庫產品可以提取HANA的計算視圖數據。第二種,混合模式,如果客戶本身已經具有了SAP BW和其他品牌的數據倉庫,可以同時利用這兩種系統環境進行模型搭建。BW數據模型中的大部分對象也可以映射成對應的視圖與外部SQL數據倉庫進行融合。第三種,SAP EDW建模方式。這種方式的體系架構比較清晰,中央元數據存儲庫能有效支持端到端的基于架構的數據倉庫中的數據管理。
參考以上模式的數據倉庫實施方法,傳統的BW建模變成輕量級,復雜的層層加載的數據鏈除了處理復雜邏輯打包的SAP事務端標準數據源的抽取、傳輸和上載外,大部分的數據處理任務通過底層的HANA數據庫建模,通過虛擬化封裝,以數據服務的形式提供最終商務智能消費端,包括報表出具與移動應用。
當EDW已經逐漸向混合式轉變時,如何有效利用數據倉庫的已有優勢和未來數據倉庫的靈活架構來實現平穩遷移呢?
3 基于企業數據倉庫的優化實現平穩遷移的關鍵點
(1)應用系統架構的優化實現EDW平穩遷移的關鍵點之一:通過讀取優化的操作型數據存儲模型(ADSO)實現平穩的數據模型的遷移。
(2)EDW中的數據是分層匯聚并處理的。這種分層和匯聚按照分層可伸縮架構(Layered Scalable Architecture,LSA)來實現。LSA代表了可靠的管理數據和元數據生命周期的數據倉庫框架體系。隨著HANA的不斷應用,LSA框架擴展到LSA++整體框架,以滿足高效運營和敏捷BI的需求。如圖3所示。
圖3 LSA++分層模型
LSA++的重要部分包括EDW部分,其中緩沖/企業內存部分包括了源模型與EDW模型之間的鏈接,企業內存持久層。開放的操作數據層(ODSO)加快了模型中數據的激活時間,一個模型至少加速10%。在進行對SAP BW 7.30 SP 10遷移到BW/4過程中,所有標準數據存儲對象執行SAP HANA優化激活,而無需進行任何設置,也無需進行任何手動轉換或遷移活動,節省了遷移過程中的工作量消耗。除了激活,SID(主數據ID)生成也經過HANA優化。因此,如果在數據激活期間設置SID生成,則幾乎不會對正在進行生產系統運行的數據倉庫性能產生任何影響。
除此之外,如圖3中的箭頭所示,查詢不僅可以在虛擬的體系結構數據集市之上運行,也可以跨層直接從開放的操作數據層(ODS)以及傳播層DSO上運行查詢,其性能與EDW之上的信息立方體多維模型(Info Cube)上運行類似。
EDW升級和遷移過程中,并行實施項目及已上線的應用往往是受影響最大的,特別是在并行實施過程中用到EDW中企業內存持久層的內容或者標準數據源時。現實中往往發生這樣的情況,如果EDW升級和遷移的A項目的凍結期安排在3月初至6月底,而業務單位將EDW的標準數據源作為貼源層,實施6月底上線的B項目,如何實現兩個項目的并行運行并保證相互不受影響?基于以上的系統架構能保證A、B項目同時進行,相互不會產生影響。如圖4所示。所以,關鍵點就在實施B項目時,將貼源層的數據模型搭建在DSO之上,通過BW/4的升級轉換,這些DSO自動轉換為ADSO,成為HANA工作區可以識別的視圖(通過路徑③),不需要再到BW/4工作區進行模型調整,也不必等待BW/4應用工作區遷移完成才開始工作。而其他的BW模型及與BW Infocube等相關的HANA View同樣需要通過路徑①、②和④進行轉換和遷移,受到凍結期和BW/4模型調整的影響。
圖4 BW/4數據遷移
綜上所述,基于LSA++的端對端框架,原有的數據倉庫通過遠程遷移的方式,分步驟地傳輸到目標系統時,可以花費較小代價和資源,完成數據模型和歷史數據遷移和升級任務。
(2)應用系統架構的優化實現EDW平穩遷移的關鍵點之二:多租戶的使用。
由于SAP HANA是一種分布式大規模并行分析數據庫(Analytical Massively Parallel Processing(MPP)Databases),不僅能通過列式存儲方式對數據進行壓縮,同時能平衡和配置大數據分析工作的負載,這種體系結構使復雜的分析查詢可以更快、更有效地處理。
SAP HANA租戶數據庫是SAP HANA中多租戶的基礎。能夠在一個SAP HANA系統中運行和管理多租戶數據庫,有助于降低資本支出、簡化數據庫管理并構建多租戶云應用程序。從HANA2.0以后自動轉換成多租戶(Multi-tenant Database Container,MDC)模式。如圖5所示。
圖5 多租戶數據庫
一個系統始終只有一個用于中央系統管理的系統數據庫,以及任意數量的租戶數據庫(包括零個),多個應用程序在不同的租戶數據庫中運行。SAP HANA系統有單個系統ID(SID,請區分此SID與前面所述的主數據SID的不同)標識。數據庫由SID和數據庫名稱標識。
從管理的角度來看,在系統級執行的任務和在數據庫級執行的任務之間存在區別。在多租戶的情況下,可以共享相同的數據庫系統、軟件安裝、相同的計算資源和相同的系統管理。但是,每個DB Schema都是獨立的。這種多租戶的MPP架構使得其上的數據應用項目部署更加靈活。在進行EDW遷移和升級過程中,就利用了多租戶系統架構,從而節省了遷移和升級過程中所需要耗費的數據庫和硬件資源。系統架構如圖6所示。
圖6 遷移和升級場景下的多租戶
在節點3上,有3套系統,系統DB、開發環境和測試環境。System DB安裝時默認SID為D12,建立開發環境租戶時,這個環境的SID為D12@D12,后期又根據需求增加了測試環境的租戶,SID為Q12@D12。這種方式,保證了同一節點下繼續增加租戶時每個租戶系統的獨立性。
除此之外,其他基于多租戶數據倉庫系統架構還可以適用橫向擴展(Scale Out)場景,應用于集團公司及下屬需要獨立性的上市公司的系統架構。
一般來說,企業集團統建系統會先實施SAP HANA系統,如下示例,統建系統形成了6個節點,每個節點容量為2TB的EDW系統。除Standby節點的2TB外,其他5個節點中的4個節點有8TB內存容量可用。所以Tenant DB1.1~1.4可以分布在集團公司的4個主要節點上,減輕主節點上的數據壓力。下屬公司可以在Host5(節點5)下面建立自己獨立的數據應用環境,保證了2TB的內存容量。由主節點共同管理底層系統資源,實現成本效益最大化。如圖7所示。
圖7 橫向擴展場景下的多租戶
以上模式的優勢:使用HANA多租戶MDC特性,可以實現跨租戶的數據查詢訪問。一臺Standby節點可待命兩套系統。租戶的拓展縮減方便,比如可以再增加或者刪除租戶3而不影響其他租戶的使用。劣勢:如果租戶1和租戶2同時出現故障時,Standby節點無法同時兼顧。另外,停機維護時,租戶1和租戶2的應用同時受影響。
以上兩種都是常用的多租戶數據倉庫的應用場景。目前我們也在繼續探索其他應用場景,比如用于業務上關聯緊密,貼源層共享的兩個獨立DB Schema系統。這種類型的場景往往發生在不同的兩個應用系統需要向同一個數據倉庫系統提取數據,并且這些數據具有高度的一致性。如果單獨建立兩個數據庫系統,分別存放一份數據,必然引起數據冗余,而且這些冗余數據極易導致數據的不一致。另外,考慮到多一份數據庫系統將耗費更多的運維資源,所以采用多租戶是一種各方面評估后均合適的方案。
4 結語
綜上論述,EDW系統作為是集團數據平臺的一部分,發揮著支撐企業數據分析和輔助決策的作用。特別是底層的體系架構的能力以及其變化發展對EDW所構建及支撐的數據平臺滿足最終用戶需求的能力起著決定性的作用。利用虛擬化的高級操作型數據模型對象ADSO可以盡可能減少EDW遷移和升級對并行數據平臺實施項目的影響;利用多租戶的MPP架構可以擴展數據倉庫的能力,使得更多的系統環境經濟高效實現。
作者簡介:
王小玲 (1972-),女,四川宜賓人,高級工程師,碩士,現就職于中國海洋石油集團有限公司信息技術中心,研究方向為大數據及商務智能應用。
參考文獻:
[1]RalphKimball.數據倉庫工具箱:維度建模權威指南[M].王念濱,周連科,韋正現,譯.北京:清華大學出版社,2015.38.
[2]W.H.InmonDanielLinstedt.數據架構[M].唐富年,譯.北京:人民郵電出版社,2016.106.
[3]DAMA國際:DAMA數據管理知識體系指南[M].DAMA中國分會翻譯組,譯.北京:機械工業出版社,2020.297.
摘自《自動化博覽》2022年9月刊