SAP BW4/HANA-BI與DW簡介
這一篇我們介紹以下的概念
1. SAP Business 與Data Warehousing
2. SAP HANA的歷史演變與 data layout
SAP BW(Business Warehousing)簡單來說就是SAP的Data warehousing系統，但加入了BI與Data pipeline的功能在裡面。如下圖
特點:
Consolidates data across the Enterprise
Standardized data model
Support decision making
主要作業:
Define common semantics
Harmonize data values
Establish a ‘single version of truth’
Provide a single, comprehensive source of current and historical information
Keep copy of source data to ensure independency of source and support the unknow
在現今大數據的世紀資料只會越來越多且越來越細。BI的任務就是使龐大的資料結構化並減少在分析當中減少不需要的資料最後分析成為有意義的"資訊"。但要使企業散落在各系統的資料都能讓BI分析得到就是一種挑戰，所以企業的全部資料全部集中到一個data source(Data Warehousing)就成為一種理所當然的做法。為了集中資料到同一個data source我們必須考量到企業中這些資料的metadata(business and technical attributes and descriptions of objects)。透過SAP ERP系統的資料與其他第三方的資料整併到SAP DW分析後再回饋到企業的Business strategy形成一個正向的循環是SAP BW的終極目標(流程架構如下圖)
上圖中我們可以看到資料在進入DW時第三方的資料必須清過資料清洗，而從SAP ERP來的則需要經過semantically prepared (homogenized).從這邊我們也可以看到ERP與DW的運作環境是不同的。
SAP BW的架構分為三層(如下圖一)，分別為
sourcing the data(Data Acquisition Layer)
storing data in DW( Data Layer)
Reporting on the data with reporting tools(Virtualization Layer)
這三層的主要負責的任務
Virtualization Layer: Flexible data analysis
Quality of information(flexible analysis tools)
Standardized and uniform reporting tool
Performance(ad-hoc) reporting
Analytical services(data mining, and planning)
Data Layer:
Redundant data storage(relief of source systems/ Data history/ Performance)
Reporting specific data preparation[Homogenization(data type)/Cleansing/Compression]
Data Acquisition Layer:
Data provisioning across different source systems(Integration)
當按照上圖三層式架構分析時就會有以下問題在分析過程的前中後需要回答
你需要的資料現在存放在哪裡?
你如何access這一個資料?
你如何將這個資料upload 到SAP BW?
你如何存放這個資料在SAP BW?
哪種InforProvides(store and access in DW)你會使用?
你的power users and ends如何存取他們業務上應該可以存取到的資料?
經過回答了以上問題我們就可以把圖一的三層架構在畫得更精細(如下圖)
上圖中我們可以看到DW的data source有來自SAP其他系統/flat file(例如 CSV/ excel 檔案等結構化資料)，最後一個來自其他非SAP系統的資料。而SAP與其他SAP系統之間的介面提供了一個ODP(Operational data provisioning)的功能(包含ODQ-Operational Delta Queue)，這是一個data distribution framework，透過這個ODP將資料轉移到BW中。
SAP HANA 資料的layout與演進
HANA是一套In-memory Database所以具高效能的分析，至於為什麼是如此高效能有興趣的讀者可以參考本blog其他HANA的介紹。透過如此高效能的DB我們可以處理各式各樣的資料(如下圖)
SAP HANA DB提供了完整的功能套件如下
Web application server (XS-Engine)
Components to manage planning
OLAP analytics
Predictive cases(例如: planning engine/ analytic engine / predictive engine)
如下圖
Data layout(Row and column)
我們在其他文章有提到HANA同時可以提供 Row-based and column-based的資料型態，這邊我們就在DB(在memory，因為在memory裡資料是linear sequence的)中操作面來看。
Row table的特性是:
1.資料是以 tuple-wise結構存在(就是不同資料屬性但是在同一個tuple裡)
2.對單一的tuple的 colocation of attribute 做操作
3.對資料的reconstruction代價比較低，但對單一的attribute掃描的代價很大
上圖中我們可以看到如果是要讀取A欄位其他欄位不管要不要其實都會ㄧ併讀取到(只是資料庫沒顯示給你)，這樣在讀取大量資料的同一個欄位(或幾個特定欄位)效能會很差。但若是要不同欄位的同一筆row，這樣的效率就會比較好。
哪以Cloumn-based來看的話，就與row-based的特性相反
資料是以attribute-wise存在
因為computer memory的sequence特性所以data scan的效能很高
但同一個tuple的reconstruction代價很高(意思是進到DW的資料建議沒有modify，資料如果要reconstruction不如重新在Data pipeline時這邊執行)
剛剛提及由於memory的linear 結構，我們可以看以下範例
由上圖我們就可以知道在CPU處理資料時row-based是一筆一筆處裡的(order 456 →457 →458以此)，在做交易性資料(OLTP)時這種方式最好(因為每筆資料的欄位都會用到)。但要做分析時就不好(因為分析時不是每筆資料都會用到)。而用row-based的方式來做分析我們會浪費掉CPU裡L1/L2 cache的空間。
另外使用cloumn-base的方式儲存還能得到很高的資料壓縮比，例如下圖資料，在country這邊的資料重複性很高(國家名稱在企業的business就哪幾個)，由於是cloumn-based的我們可以把國家名稱用字典的方式來替換成數字到實際的資料欄位，再針對這個欄位壓縮。這樣壓縮比就會比文字壓縮來得高，使用memory and CPU cache的效能也更好。
字典壓縮法只是其中一種，HANA還支援了以下幾種
Prefix encoding
Run length encoding (RLE)
Cluster encoding
Sparse encoding
Indirect encoding
而要選擇哪一種壓縮方式HANA會利用它的演算法幫我們找到最好的壓縮法。所以當你的SAP DB轉移到HANA時，SAP會根據已經定義好的邏輯來決定SAP system內的資料是要用row or column based，HANA裡大部分還是cloumn-based的資料。你可以在HANA studio or tcode SE13看到這個資料是row or column based。
我們前面提到row-based and column-based的資料型態的優缺點，針對cloumn-based我們要寫入資料的代價會很大(效能會非常差)。為了克服這一點SAP HANA提出了 Insert only on Delta(如下圖).
這一個部分我們在其他文章有提到過，可以參考其他文章。這種結構的重點是:
Main storage ( read-optimized, stored columns)
Delta storage (write-optimized, non-stored columns or rows)
SAP BW/4HANA概述
這邊我們會介紹SAP DW的工作台(workbench)以及它的主要功能。
資料分析師或資料科學家在SAP HANA中使用ADSO(Advanced DataSotreObject)於end-to-end的情境，這是一個for modeling persistence layer 的central object。
InfoObjects
InforObjects 是一種business analysis objects，例如sales revenue/ costs/ sold-to-parties。InfoObjects 還分為Characters 與 key figures(如下圖)
由上圖我們可以看到Characteristics提供了與它們相關的key figures的資訊。例如cost center(characteristics)與 costs(key figures)，但如果一個characteries assign 給第二個characterics，哪麼第一個characterics 會變成第二個characterics的attributes。以cost center的範例來看，若把contact person assign給cost center，哪contact person就變成cost center的attributes。Characteristic InfoObjects 能夠儲存master data，如 text/attributes/hierarchies，InfoObjects在SAP BW裡是最小的components被InfoProvides用來分析資料使用。
底下我們來比較SAP BW在InfoProviders在新舊架構之間的不同
上圖中我們可以看到舊的方式我們需要針對每種的Objects定義不同的Query Definition.
Characteristic infoObjects 儲存的是Master data，像是客戶資料/或資料等。
DataStore Object 儲存的是交易型的細部資料，例如sales order 裡的每個Item level.
Info Cube: 儲存的是經過aggregated 的交易型資料，例如公司整個sales order加總起來的銷售額
新的架構雖然ㄧ樣式三層式架構但我們可以看到大幅簡化了複雜度，所有的Objects都會在Composite Provider(InfoProviders)中處理最後送到BI工具呈現。雖然透過 Join/Union的方式處理資料了，但SAP HANA的Native features 卻可以再度增強SAP BW的分析效率(如下圖)
