SAP BW 學習筆記

兩年前的舊文了，而且也是半途而廢。趁著把部落格從部落格園遷到這邊，稍微整理了一下，留作紀念。原文寫於2007年8月。

 

（一）

SAP BW 全稱 Business Information Warehouse，在版本3.5之後又稱SAP Business Intelligence.

處於SAP Netweaver整體架構當中的Information Integration這一層，與之並列的還有主資料管理（Master Data Management）和知識管理（Knowledge Management），這一塊所謂的Information Integration，就是從企業的底層資料到最高表現層之間的一層分析的部分。但是它又不完全是在進行分析，因為這一層本身，也包含了資料探勘（Data Warehousing），商務智慧平臺（BI Platform），商務智慧表現（BI Suite）三個細的層次。

或許對BW的精確解釋，就是如何能讓企業的商務活動，變得高效和便捷的關鍵一步吧。

SAP Business Intelligence is an enterprise-class, complete, open and integrated solution that delivers actionable insight. 呵呵，自己解釋不清楚的時候，只能抄一句講義上的定義了。不過這個定義還是基本準確的。基本上闡述了BW的功能和應用物件。

BW的最底層，Data Warehousing。傳說中的資料倉儲，這一層裡面主要完成的任務包括，ETL流程（Extraction，Transformation，Loading），資料倉儲管理和商業建模三塊內容。其中的ETL流程，通過各種途徑和方法，把種類繁多的後設資料進行處理，清洗，從而轉化為系統所需的統一格式的資料型別，便於之後所有的需要。是BW中非常基礎非常關鍵的一步。之後的資料倉儲管理，則將這些資料根據種類，劃分成主資料，PSA，ODS Objects等不同的型別，加以管理。商業建模則是資料倉儲中比較難很快掌握的內容，這塊內容，基本上是和客戶的需求緊密聯絡，並根據需求建立合適高效的模型。這個技能，也不是一天兩天的理論學習能夠涵蓋的，需要專案經驗的積累。

第二層所謂的BI Platform，是BI中偏重邏輯處理的一塊，它把Data Warehousing的資料，按照需求進行各種計算，規劃和進一步的細緻的處理，這一層更多地是對資料進行統一的處理和基本的封裝。在這一層裡面，完成的內容有business calculations, planning and forecasts, exception scanning, alerting, query pre-calculation, caching, background printing和data mining等。主要的產品有OLAP，metadata management，data mining，Analysis process designer and BPS（Business Planning and Simulation）。

第三塊是BI Suite，這一塊其實完全是在對BI Platform裡面出來的東西的再加工了，主要的內容就是對BI Platform出來的內容加入一些商務智慧的要素，比如Query的多樣化選擇，自動報表的生成，多維度的資料分析，資訊釋出，公開的面向第三方的分析介面和具體的Web頁面體現。有了以這一塊，sap的BW才顯得更為文章，更為專業。

BW目前的市場很大，供需關係不平衡，近幾年應該都會比較火。SAP靠它產品的完備性和強大的整合功能，一方面在專案選擇上有更大餘地，接受一些較為大型的專案，另一方面這個平臺的推廣，也給它帶來了無限的商機。掌握了SAP系統軟體的一些內涵，就能在這個行業吃開來了，IBM，Accenture在這一塊也都有很大的一塊業務。不過，他們更多地是作為SAP的partner。SAP目前最大的競爭對手是Oracle，不過Oracle同時也是SAP系統的一個支援物件，所以SAP和Oracle又是合作伙伴。哎哎，好複雜。

對了，還有一點補充一下，SAP的系統之所以這麼好用，還以為它預定義了很多很多有用的模板，當實施變得輕鬆而美觀的時候，企業自然也會覺得你更加優秀。

 

（二）

今天主要看了SAP BW中的ETL Services中的Extraction部分的前面兩個引入話題的小節。做了一點筆記，其實幾乎是在翻譯了。

 

Extraction

Basic Principles

1) Classes of Data

Data在典型的像SAP一樣的ERP系統中被分為三種，主資料，事務資料和配置資料。

先說主資料，主資料通常是組織的實體，也有作為外部實體出現的，還可以是其他的事務，比如材料（@@？）。主資料在資料倉儲中的重要性就在於，它提供了多維資料分析中的那些維數。

在BW中，主資料通常又是由三種表現方式呈現的，屬性，層級和文字。屬性就是描述實體屬性的那些域，層次則大多數是一些獨立的表，它們表述的通常是主資料之間的父子關係。而文字表則是包含了主資料的一些文字表述，它們通常也被分別儲存在獨立的表中，因為它們通常都是依賴於語言的。

 

主資料的關鍵鍵值，通常因為應用而異，所以有時候即使是相類似的概念，也會根據業務的需求制定複合的資訊物件（Compound InfoObjects），以適應於不同的業務型別。

 

層次表相對屬性表來說更復雜。首先，層次中主資料的相互聯絡可以很複雜，第二，儲存這些層級關係的技術也因應用而異，許多應用模組只有唯一的層次表達方式，

 

事務資料用來表述一個商業事件，或者商業過程的結果。比如一個交易請求或者一個產品的當前庫存。事務資料也被分為兩個種類，文件事務資料和總結性事務資料。

就文件事務資料來說，通常可以從三個部分來描述，一個是開篇部分，一個是內容，一個是時間表的內容，開頭部分主要是文件相關的資訊，比如作者和建立時間，內容部分是文件的詳細描述，時間表則是在文件需要被劃分為若干個階段釋出時候文件釋出的時間表。通常最適合資料抽取的往往是最低階別的顆粒資料，因為它們的資訊量也是最大的。動態的總結性資料表則多是一些冗餘的對錶述內容的總結。SAP BW穩定的將SAP R/3中的總結性資料的部分孤立開來。

 

在SAP R/3 的HR系統中，主資料和事務資料的差別不是很大的。（只是舉個例子）

 

配置資料是整個ERP的邏輯驅動者，在許許多多的ERP軟體中都能找到配置資料表，如此多的應用程式的邏輯被放置到配置資料表中，是的企業級別的軟體解決方案趨於高度使用者化。配置資料雖然本意是用來定義業務過程的細節的，但是它在資料倉儲中也常常得到應用，舉例省略。備註：在SAP BW系統中，配置資料被模組化為特徵，並且可能包含有主資料的屬性，文字或者層次，所以在SAP BW中，主資料和配置資料是不作區分的。

 

主資料，事務資料和配置資料就組成了BW系統中所有的資料型別，包括報表相關的和不相關的（那些專業性很強的部分資料，可以忽略，對業務的分析和彙報沒有實際意義）。一些報表相關的資料需要在轉化過程（Transformation）之前就要做一些改動（意即在Extraction過程中開始做一些conversion——原作沒有在這裡用transformation，可見轉化的區別）。

 

2) Data Flow and Integration

SAP R/3是個包含了各種各樣擁有獨自的資料模型特性的系統，隨著R/3的發展，不同的系統之間經常發生分歧和合並的矛盾，知道現在將R/3分為四個大塊, mySAP Financials, mySAP Human Capital Management,  mySAP Logistics and mySAP Product Lifecycle Management.每塊由著自己不同於其他塊的特性，特別是從資訊系統的角度來看。當然，如果從更大的角度出發，就會發現其實他們之間還是有著千絲萬縷的聯絡。

熟悉和了解過程流對於跨不同應用型別的建模和辨別相當重要，特別是對於關鍵項來源究竟在哪裡如何確定。P209，P210講述了兩個具體的例子進行了具體分析。講述了資料流和整合的重要性。

 

（三）

繼續寫ETL部分的學習體會，今天是Extraction的第三部分

        

Dimensions of Data Extraction (資料抽取的維數)

資料抽取的過程通常可以由四種不同的維度來進行描述和分類。

 

首先是抽取模式，抽取模式通常分為完全抽取和動態抽取。兩者意思很明確，完全抽取是每次抽取的時候講資料來源可用的所有資料都抽取過來，而動態抽取則是每次抽取的時候只抽取更新和增加了的新的資料。

其次是按照抽取的情景作為抽取的維度，分為推式抽取和拉式抽取，推式抽取時，資料抽取和傳輸過程的發起者是操作的系統，反之在拉式抽取時，發起者變成了資料倉儲。推式和拉式抽取的共存也暗含了一個領導角色的概念，因為在實際生活中，資訊後臺更多地是在和發起者進行交易。另外一種更好的解釋方法是將推式抽取和拉式抽取分別比擬為資訊的釋出與預定和請求與反應的情形。

第三種抽取的維度是時間的滯後性，這裡常用的有三種時間滯後尺度：同步的（就是實時的），不同步的（儲存和轉發）和不同步批處理（按需或者事件觸發或者排程式的）。

第四種維度則是抽取的範疇，抽取範疇對我們抽取資料方法角度的一種描述，是從對映的角度，還是從選擇的角度，還是從聚合的角度，來進行這麼一次抽取。

 

每一次資料抽取的過程都可以拿這四種維度來衡量，SAP BW中首先符合SAP 3/R資料抽取需求的抽取器就主要是非同步批處理拉式完全抽取模式。現在主流的資料抽取還都是集中在拉式抽取這一塊內容，不過隨著業務的需求變化，現在的資料抽取已經穩步地由動態總結表變成業務表，動態抽取的捕捉機制更加複雜化了。

 

動態抽取的難點在於，如果和識別那些動態變化了的部分，這裡通常也有兩種不同的方法，一種是用增量佇列的方法，一種是時間戳判斷法。時間戳判斷方法比較常用，也因為它比較容易實現，所以常用。但是時間戳法有缺憾就是在時間戳被記錄的時間和抽取實際開始的時間之間有段無法彌補的空白，這段時間內的檔案更新將會丟失。不過也有對付這個的“安全增量”法，那就是將使用者的時間戳調後幾小時，這樣便能避免了。

 

另外一種代價不菲但是質量有保證的方法就是增量佇列法了，這個類似於對每次的更新和新加入元素進行記錄，形成log，就是所謂的增量佇列了，增量佇列關鍵就表現為一些記錄了主要鍵值發生變化的抓拍過程。

 

和時間戳法相對比來說，增量佇列法不需要更多的安全方面的顧慮，它完全與資料的更新頻率沒有了關係，另外兩者還有一個不同之處就在於，時間戳技術只能獲取在抽取時間內出現的版本序列，而不是全部，相比之下，增量佇列法會有一個完備的版本連續性。

 

不管使用哪種方法，動態抽取一個比較複雜的地方都在於，如何在互相緊密依靠的表之間的微小改變。除此之外，動態抽取的另一個挑戰在與它要隨時隨地地面對多個不同的資料來源的不同資料表的不同時間的資料更新。它卻需要提供一個統一的東東，來統一這一切。

當前來講，同步的推式抽取還不能被SAP BW完全支援，同時對於拉式的對事務資訊立方體的實時更新卻能夠實現。這種更新總是直接性的繞開了正規的分段運輸過程，它們也絲毫沒有運用傳輸或者是更新法則，它們甚至不在SAP/BW的監控範圍內。

 

推式抽取技術通常和增量更新脫不開干係，而拉式抽取則可以同時用於完全和增量抽取模型。現在BW中為開發報表最普遍深入的技術還是通過使用遠端的資訊塊，實現抽取技術。這一進步的帶來的最相關的就是效能了，通過使用多個提供者的模式，則會使得效能減低。然而，當需要實時的顆粒狀資料時，非同步抽取依然是可取的方法。

 

當對R/3可用的抽取器滿足了選則的動態規範和對映規範時，只有一小部分是滿足對集合層面的規範，對非同步抽取來說，你通常可以通過直接在SAP BW中聚合資料而不是在資料來源中聚合，來彌補這個不足，對同步抽取來說，這個就是無法實現的了。

 

（四）

 

OLTP(On Line Transaction Process) Technology Considerations 聯機事務處理的技術考慮事項

 

這一部分主要講述了聯機事務處理的系統中涉及到的資料儲存方式（包括寫入和讀取資料庫）。

 

物理更新，資料在R/3系統中進行更新的時候通常有兩種形式，同步和不同步的。同步更新都有程式執行，使用者需要等待確認完成。而不同步更新則通常是接近實時地完成，使用者無需等待業務操作執行結束。按照週期的長短，不同步更新又被分為了V1和V2兩種更新方式。V1是時間要求相對嚴格的更新，它的更新進度完全取決於交易表所限定的進度。而V2則是時間要求不嚴格的，它通常用來更新一些不需要經常變化的和交易相關的統計資料。一般來說，任務佇列越長，更新的速度就越慢，這個基本上是要取決於系統負荷的。

 

從資料倉儲的角度出發，在運作系統中資料的寫入有兩種基本方法，使用增量變化捕獲機制和不使用這一機制的。目前，SAP BW中的增量捕獲機制正在發展中，R/3中已經實現了增量捕獲機制。

 

在SAP BW出現之前，就有趨勢將R/3分為幾個分開的例項，並在其間仍然進行資料流通，這個時候業務框架的概念得以發展，而原先版本的應用程式漸漸淡化，並讓它們都通過ALE進行互動。工作流包括在供應鏈中的預警和通知等，也漸漸的從中清除。在ALE出現之前，其實也已經有一種用於審計的變化日誌的存在來實現類似的功能。也有部分主資料增量抽取器使用ALE作為更新檢查工具過，不過最近來講，最牛的還是增量佇列法。

 

另外還有一種增量檢驗機制的方法，是由BADI提供的。在此不做贅述。

 

不穩定文件，SAP BW中的每一項事務，都有一個過程——生命週期，它也有兩種不同的狀態，活動和不活動狀態。屬於活動狀態的事務，相關的描述文件可以是連續更新的，比較常見的就是一個交易（order）追蹤文件的狀態有好多種，它本身的內容，就包括了它的當前狀態，而且這也是非常重要的。

 

相似地，一些後發的資料流。也會跟隨這商務的進行而與之聯絡在一起。

 

理解資料的不穩定性，對於理解BW的資訊模型是大有好處的，在R/3當中何時需要更新和重新獲取資料，在一個商務文件變得不再活動的時候把它放到另外一種型別的文件中去。在BW中，有關不活動文件的資料通常只需要載入一次即可。因為它們不會發生變化。（這句是廢話-。-）

 

讀取資料，經常會發生第三方的產品想要連線到SAP BW中進行資料讀取而脫離開SAP的應用層的事例，儘管SAP R/3中的許多資料都是直接可呼叫的，但是仍然有一些複雜的地方，首先，需要過濾掉商業邏輯後將這些資料表全部得到，其次，你可能會遇到技術上的困難，比如應用伺服器緩衝的資料和鎖定的資料等等。處理這些問題需要對業務邏輯的技術細節極其熟悉才行。即使當資料提交給資料庫的時候，它也未必在一個很容易讀取訪問的地方。SAP將它的資料表們分成了幾種不同的型別，以進行技術上的區別。

 

它們分別是：

 

簡單表（Transparent Tables）：簡單表就是簡單表，你最開始接觸的那種表就是了。

資料庫檢視：就是你知道的那種檢視的定義，呵呵，這個沒有做進一步的細分。

池狀表（Pooled Tables）這個在SAP發展R/3的初期出現，早期的時候，資料表的數量有限，這個時候隨著SAP BW中對資料量的增加，人們開始將許多的表放到一個表裡面，這個原先的作為母體的表，就被稱為Pooled Table.這些表把子表的表明作為主鍵，資料則以一種很長的row string 來表示。

群狀表，和Pooled Tables差不多吧，主要區別就是Cluster tables裡面會有一些複雜的存在於程式記憶體中的資料物件可以直接存在其中而不需要任何其他的操作。

邏輯資料庫，這一層次可以表現實際上的表，也可以不表示，它流行於報表製作的階段，因為使用者無需考試實際資料的問題而進行報表的構思。

 

（五）

 

這段時間沒怎麼看書，都在BW的系統裡面摸索，今天繼續看了 Mastering SAP BW… 一點小小心得，流於此，但願後面能多看看…

 

SAP Source System

後設資料流

後設資料在BW系統中，貫穿了整個資料傳輸的過程，在這其中，後設資料流的作用就是基本上用來決定了資料從各種後設資料到達BW的資料來源系統的過程中的傳輸規則的制定。 它是一個域的集合，包括了進行上述第一步無損失的資料傳輸的過程中需要進行域的選擇，哪些資料要對映到資料來源系統中，哪些不用，哪些需要選擇，哪些不需要，都由它決定。

        

之所以要進行這樣的處理，是為了提高資料載入的效率，節約資料抽取佔用的資源。

        

按照習慣來講，資料域的聚合，是應該在進行資料查詢的執行過程中執行的，而不是在資料抽取的過程中。但是我們注意到，通常資料的聚合必然帶來的就是資料資訊的丟失，而如果在執行資料查詢的過程中就會帶來資料的丟失，顯然是會影響到整體的資料完整性的。只要遠端資訊立方體是由源系統抽取器直接生成的，這個抽取器就得支援抽取時間的因為效能要求而聚合。