SAP HANA-迅捷企業之選

作者名稱：Alex Liu
原文地址：http://liualex.com/archives/1840

1. 從廢話開始
2. SAP HANA快熟介紹
3. 關於內存數據庫
4. 不一樣的架構，深入瞭解一下吧
5. 基於HANA的應用，HANA Store？
6. 期待的HANA全路線圖
7. 有待提高之處
8. 附錄

1. 從“廢話”開始

在介紹SAP HANA這個產品之前，我們來談點別的, 好嗎？行的話，請繼續看，否則大家直接跳過這節吧！

現在的企業需要什麼？時間就是金錢？效率就是生命，大家都是喊這樣的口號，讓ERP和企業的信息系統跑的更健壯，更穩定，不斷的擴大硬件投資，但是這僅僅是讓企業的信息系統以穩健的方式來提供企業管理者所需要的信息而已，而企業決策者其實想要的更多: Anywhere, Anytime, 說的簡單，做到就難了，隨時隨地，想看就看，還要看的痛“快”對吧！

一般的企業實施了ERP信息系統之後，這是企業核心的管理應用，會應用一些商務智能分析軟件（比如SAP BW）進行業務數據的抽取（從ERP, CRM, SCM, HCM，自開發系統作爲數據源），篩選，建模，重新創建出適用於企業管理的運營報表，展示給最終的用戶看的時候可能是使用（SAP Business Object）來展示，因爲比較美觀，直觀，簡單，還吸引眼球。

“白天跑業務，晚上抽數據，隔天看報表”，您那就湊合着用吧！現狀如此，如果能有所改變，您是否願意？

一般來說，目前企業信息化現在一般來說，基本這個狀態，並不是這樣不好，只是，如果企業能做到Anywhere, Anytime, Superfast… 爲什麼不呢？下面這個是比較理想的一種狀態，幾乎實時，決策時刻，無須等待。

我們賣軟件，賣服務，買升級，買各種新應用，說到底無非是2個字“價值”，到底給企業，給決策者帶來什麼好處，這是我們最關注的，到底我實施HANA能給我受益什麼東西吧？有話直說。

• 簡化企業應用平臺，而不必中斷現有的應用系統
• 向“迅捷性”邁進一步，實時工廠，實時管理，實時監控，實時分析，Anywhere, Anytime.
• 將企業的業務數據徹底的從系統中解放出來，發揮最大的價值
• 全新的基於內存計算的平臺（我是一個平臺，不是一個空盒子）

總之，最重要的一點，就是讓數據飛快，應用飛快，這應該夠了吧！當然，這是當前HANA的版本可以實現的，其實HANA還有更加宏大的遠景和計劃圖（正在完成中，每一步都讓企業和未來更近！）

什麼是迅捷企業，迅捷= 迅速+敏捷？

現在的移動應用非常發達，平板電腦/手機對於企業的信息化處理不能像過去一樣了，瞬息萬變的商業機會很快就會溜走，如果企業能在任何時間段都能對企業的信息資源可以立即瞭解，這對於商業決策的快速決策是有非常大的影響的。
怎麼樣才能迅速的抓住這些商業機會呢？首先是企業自身對信息系統中的數據，加工整理的功夫要非常厲害，這點在很多成熟的企業中都做的很好，但是僅僅是這樣還不夠，還需要什麼呢？還需要一個超快的內存數據庫和一個超級引擎來完成結果的計算，HANA正式爲此而生的。

2. SAP HANA 快“熟”介紹

根據SAP的字面意思理解，SAP HANA是硬件和和軟件組合起來一個解決方案（Appliance, 裝置），使得客戶分析海量數據，而且是以接近實時的方式來同步數據，不需要花費太多時間在數據傳輸上，目前HANA的版本是1.0.

他集成了一些SAP的組件，比如IMDB(In-Memory Database), Sybase的Replication 技術，以及SAP STR(Landscape Transformation Replicator)等等。

SAP HANA作爲一種第3方硬件合作伙伴共同合作而優化打造的應用，目前支持和認證的硬件廠商，包含HP, IBM, 思科, 富士通，戴爾5家合作伙伴，據說給聯想LENOVO做的HANA方案，是使用的聯想自己的服務器，應該也可以。但是目前不在SAP通用實施的合作伙伴範圍之內。

在官方的文檔，HP的硬件在文檔中排名第一的，列表中根本沒有提SUN 的系統什麼的，你也知道，甲骨文是SAP的競爭對手！噢耶！我就是SAP粉絲，腫麼了.

3. 關於內存數據庫(In-Memory Database)

市場上基於內存計算的數據庫產品有一些，這裏就不多介紹，爲什麼呢？可否讓企業的信息化的架構簡單一點？怎麼樣簡單呢？我希望基因相同，血統純正，不要讓一個“簡單”的信息化架構變成異常複雜和異構的那種大架構。

因爲，把複雜的東西變“簡單”，那纔是真的不簡單，IPhone/IPad爲什麼這麼受追捧，是有道理的，HANA也是一樣，通俗一點說，就是“空間換時間”，以前數據放磁盤保存讀取，現在放內存，你說能不快嗎？

SAP IMDB(In-Memory Database)是一個內存數據庫的混血兒，不僅包含行存儲，也包含列存儲，而且還有基於對象存儲的數據數據庫技術，這麼設計的主要目的是用來充分挖掘和使用現代多核CPU架構設計所帶來的併發處理能力，毫無疑問，SAP的這種應用能從中受益頗多。

IMDB是SAP HANA的核心，用來幫助客戶提升運營效率，敏捷而且靈活，下圖來自SAP HANA的Technology of Manual中圖片。

IMDB支持多種數據源，目前支持3中數據replication方法，並且提供了一個管理界面，這邊叫admin studio，一般的監控和新modeling都可以在這裏實現。

然後支持2種客戶端，用來生成基於內存存儲而產生的報表等，當然這些外圍的工具是不斷的擴充的。

3.1 SAP HANA Replication Technologies-數據複製技術

SAP IMDB所產生報告和分析所需要的業務數據是需要從源系統複製到SAP 的IMDB. 具體怎麼複製這裏現在提供了3中方法，在看具體有那3中方式之前，先看這個IMDB的核心中有哪些會參與到數據Replication的場景：

• SAP HANA由IMDB和IMDB Admin Studio組成，UI主要用來管理HANA的應用裝置，有點類似BO的儀表盤界面
• Source System，例如ERP ,BW, CRM等
• 當然還有用於支持數據複製的軟件組件

1. Trigger-Based Replication

這裏暫且稱呼爲實時模式，雖然也需要一個Landscape Transformation Replicator，實時撲捉SAP ERP的數據庫系統的修改變化，然後幾乎是是實時的就同步到HANA中，這個Replicator可以直接安裝在ERP上，比較方便，也可以獨立的安裝在一個服務器中，也用於撲捉實時ERP的數據庫修改變化。

2. ETL Based Replication

這裏暫時稱呼爲BO模式，需要用到BO的Data Service組件，意味着需要有BO，優點是可以對抽取的數據做合併和加工處理，支持多數據源和多目標系統, ETL也就是一個數據抽取然後傳輸（可以再加工）的組件

3. Log Based Replication

這裏暫時稱呼DB LOG模式，因爲這種模式對於數據的要求是有依賴的，而前2種都是獨立於任何任何數據庫的，我一般不推薦使用，除非客戶制定使用這種方式。

所以一看數據複製技術的排序方式，就知道了，肯定是重要和好的放在前面，這就像在支持硬件中,HP惠普排名第一一樣，總不能以上來就直接吧LOG BASED 複製技術，放在第一，然後跟着說這種方式不推薦吧！所以拍大腿也知道，前面兩種是重點對象。

詳細對比，SAP HANA TOM上有詳細描述，3中方式各有千秋，看你的的業務需要什麼樣的模式了，這裏不談好壞，只談差異！

4. SAP HANA, 不一樣的架構

不想了解大致架構和組件的同學，請直接忽略本章

也是剛剛開始學習HANA的一些知識，一邊看書一遍做筆記，說到底無非是用自己的語言來理解標準幫組文檔所講解的意思，肯定有理解失誤的地方，畢竟沒有參加過標準培訓，即使有培訓，從老師那邊來的知識也不可能是完整的傳授過來，中間多少的知識遺漏是正常的，所以多看看HELP的文檔，應該可以原汁原味的理解作者的意思。

這張圖片是從SAP HANA的PPT上剪輯下來的，主要包含了SAP HANA的應用架構和在應用中會涉及到一些周邊軟件環境。

4.1 HANA架構下的親戚關係

SAP HANA的實施需要遠親，近親，朋友，兄弟等等幫忙

• IMCE Studio
  用於HANA的系統管理，以及信息建模（各種維度，KPI等），是一個客戶端的工具，基於Eclipse平臺開發
• ERP
  這裏指的是一般的數據源，會從ERP過來過來的業務數據，好吧，我們就是SAP ERP
• BO BI4
  BO的BI 4.0平臺，主要提供ETL的核心功能，源系統數據導入，刪選/合併/格式化數據，再導入目標系統
• Other Source System
  其他的數據源, Sybase, DB2, Oracle, SQL-Server等主流的數據庫都支持，當然，還可以文本XML, CSV,EXCEL都可以。
• In-Memory Computing Engine
  IMCE的核心組件部分，用於計算數據和緯度
• Clients
  客戶端的工具，用什麼方式瀏覽工具（查看報表或者查詢），或者用什麼工具來展現數據（報表設計工具，是用Explorer還是用Web Intelligence, 或者用Crystal Report也是可以的，這裏不多加描述）

以上這些都是在實施SAP HANA的時候，所涉及到到一些組件和設備等，然後下面就這些不同的工具來做一個詳細的解釋和分類。

4.2 和數據導入相關的

• Modeling 工具中可以創建數據庫表
• Replication Agent（這裏可能是使用SLT實時同步的情況下），可以安裝在ERP中作爲一個但單獨的組件，監控應用層的數據庫修改，然後可以同步到HANA的數據庫
• Data Service Designer用來創建數據的source，以及target， 可以做mapping，作爲ETL的工具，比如創建定時的作業，這樣可以定期的從source system抽數據，然後導入到HANA的數據庫中
• Data Service是服務器端（雖然使用DS作爲ETL的工具，然後DS依然需要一個數據庫來支持，注意！不是用來存儲從ERP來的數據，然後傳輸到HANA中，是用來保存一些mapping關係的資源庫）

4.3 和數據建模相關的

• 同樣，Modeling工具（就是HANA的Admin Studio），用來創建數據模型，Attribute View，Analytical View，Calculation View，在Modeling工具中可以直接查看HANA中數據庫表，也可以創建表等。
• Meta Data Manager
• SBO Information Design Tool, 比如創建一些Business Layer，然後發佈成Universe，這樣其他的BO的報表設計工具就可以使用這個基於Universe的數據模型了，然後開發出查詢報表，等等。
• Data Service Designer，除了幫助load 數據之外，它提供了Job導入，篩選數據等，重新合併數據源等等。

4.4 和報表計算相關的

• MS Excel – BI Analysis for MS-Office Edition, 是個插件用來瀏覽報表用的
• BI4 – Web Intelligence 可以用來做基於Universe發佈的報表，稍微比Explorer靈活點

4.5 和HANA管理相關的

例如備份和恢復都是在IMCE Studio裏面做的，和Information Modeling同一個界面，只是切換到管理視圖的話，就可以看到用戶，角色，schema等，以及HANA的服務的一些系統狀態。

Persistence Layer持久層

HANA的服務器中用於儲存數據的非閃存空間, HANA中的數據都是保存在內存中的，一拉閘停電，數據就沒有了，雖然服務器掉電的情況發生很少，但是這裏還是解決了這個問題，當然不是專門爲停電而解決的，比如數據庫休克了或者HANA服務器死機了，必須重啓的情況。
它有以下的功能 記錄Log信息，包含last save point和因爲停電而沒有寫入數據庫中的那些log信息。

這裏可以看到從HANA的內存寫到Persistence Layer的數據，包含了2個部分：Data和Log，這個過程是持續不斷的過程，當然中間有一定的時間間隔，其實Persistence Layer就是HANA的內存數據庫的某個時點的一個完整的鏡像拷貝，以及這個拷貝之後所所有發生的數據庫更新的Log信息（在停電前成功執行完畢的）

爲什麼不直接寫入磁盤保存呢？

因爲HANA基於內存數據庫(new DB)，這種實時數據同步操作或者實時數據的更新是很快的，但是磁盤的讀寫速度往往和內存的速度有差異，爲了解決這個問題，在硬件層面提供了一個閃存（即使斷電，還有數據，有點像快速緩存，這個閃存有2~4 TB左右）用來同步保存內存數據庫中的log信息，並且生成Save Point，然後寫入真正的持久的磁盤存儲。

硬盤/固態存儲, 閃存硬盤？

Disk Storage用於保存和備份HANA的數據庫，因爲Persistence Layer的容積是有限的，所以HANA的備份都是放在外部的物理存儲的，比如高速率的硬盤或者其他的設備。在備份數據和恢復數據的時候會用到，比如重啓服務器。

備份是從Persistence Layer到Disk，原因上面已經解釋了，爲了不影響HANA的運行，以及讀寫速率差異的問題。備份可以設定時間，比如每天一次，還是一週一次等。

注意：

文中特別之處，當前的版本1.0（SP12）不支持Log的備份以及Configuration文件的備份，這些必須手動的拷貝出來備份，下個一個版本應該會解決這些問題。

4.6 和備份恢複相關的

• 數據備份，從Persistence Layer備份到外部的存儲系統，自動化處理
  工具：IM Computing Studio 中有備份和恢復的功能可以使用
• log備份, 暫時沒有自動化，需要手工，不是體力活哦
• Configuration 備份，沒有自動化，需要手工

系統恢復的話，需要：

• 最後一個SAVE POINT
• 以及發生在這個save point之後成功被寫入持久層的關於DB更新的log（不可以是損壞的文件）
  

恢復到什麼地方到，看上面圖片，紅線之前的數據庫的狀態能全部還原。

5. 基於SAP HANA的應用，HANA App Store？

基於SAP HANA的第一個應用是SAP Business Objects - Strategic Workforce Planning, 目前基於HANA的應用還不是很豐富，當然這也是SAP目前正在全力以赴在做的事情，我理想中的狀態是，SAP可以發佈基於HANA的應用然後，客戶可以下載，然後在HANA中直接應用，這不是很好嗎？

HANA的發佈很突然，像個祕密武器一樣，橫空出世，保密工作做的好啊！但是至少我們現在知道，HANA的後續應用開發會越來越多，當然企業可以自己基於HANA開發自己的應用，也可以使用SAP標準發佈的HANA應用。

5.1 SAP官方HANA應用

SAP官方目前加大了HANA Based的業務應用開發，企業財務，銷售預測，庫存管理等等方面都會有新的應用出來，應該是立即部署，就可以立即使用的，如果做的像Apple Store的那樣，或者直接就延續現在的SAP Service Marketplace方式，在上面發佈HANA的應用，也挺好。

5.2 SAP相關的ISV的參與

SAP 的生態圈是做的比較好的，無論是在Portal上應用開發，還是圍繞SAP核心的ERP的上的一些開發，都有很多很多的第三方的公司參與，而且很多都是非常優秀的產品。

同樣，基於HANA的應用，ISV也可以參與開發，發佈到SAP的HANA App Store.

5.3 客戶自定義開發

之前有幸參與了HANA的一個項目實施，也是很受啓發，也蠻震撼的，速度之快，以及開發部署的方便性，都非常讓客戶滿意。

相比之下，BW的流程，創建創建Data Source, Cube, Key Figure, Characteristics, Transformation Structure, Load / Delta Load, 然後創建Query還是蠻漫長的。

HANA基本上就是3步驟：

• 導入表，需要幾個就導入幾個，可以不
• 基於表，拖拽關聯關係，建模型，這個過程非常短，因爲所有的數據都有了，沒有BW中的Information Structure這麼一層
• BO出最終用戶的報表，效果還是非常不錯的.

6. 期待的HANA全路線圖

HANA是基於內存數據庫（In-Memory Database）的一種應用，而這個內存數據庫（newDB）是可以在任何的業務平臺上使用的，這是毫無疑問的，也是SAP正在努力做的事情，到今年的年底，SAP的BW的數據庫(不管目前是DB2, Oracle，還是SQL-Server)就能切換能到內存數據庫（newDB），當然以前BW的上的業務模型該怎麼弄還是怎麼弄，應該沒變化。

類似以前的BW Accelerator（BW加速器）一樣，它也是基於內存數據庫的一種應用，也是最早的基於內存計算的一種SAP應用。

如果ERP的數據庫也能基於HANA的，那是比較爽的，數據的讀寫，以及整個SAP ERP系統的執行效率都應該會有很大的飛躍，BW系統的數據庫據說年內會替換成內存數據庫。

HANA沒有直接從SAP ERP開始，不是因爲現在技術做不到，而是讓客戶接受和推廣市場的時候需要一個循序漸進的過程，選擇從BW-加速器作爲HANA應用的第一塊磚，是因爲BW只是基於數據做分析，基本上沒有業務數據的修改等問題，對客戶來說比較保險和安全。

然後是替換BW的數據庫，然後將ERP的底層數據庫替換成HANA，這樣一步一步的走，是個不錯的路線圖！

7. 有待提高之處

HANA目前的版本是1.0 SP3的版本，貌似，不過版本好像更新的很快，升級非常容易，比ERP容易多了，呵呵！但是我還是有些意見要說：

• HANA的管理工具中有一些小Bug，需要修復
• HANA的權限說明配置文檔，需要再詳細一點
• Calculation View（圖形模式時候）中的Script步驟好像不work，沒有找到相關的文檔說明，頭疼
• Analytical View的時候如果能支持更加高級的過濾就好了，比如可以設定只顯示某列的最大值的那一行記錄.

當然，對於新的產品我們要有耐心和信心，畢竟SAP出品，品質還是有保障的。

附錄

本文中的部分圖片引用自來SAP的官方的HANA文檔, 如果需要詳細的瞭解,可以參考一下的一些站點.

• 我的個人站點 http://www.LiuAlex.com
• SAP官方標準幫助文檔 http://help.sap.com/hana
• SAP官方介紹 http://www.sap.com/hana/index.epx