今天談 SAP ，幾乎繞不開 HANA ： BW/4HANA 、 S/4HANA 、 HANA Cloud ，連產品名字都把它寫在中央。
但在 HANA 出現之前， SAP 最核心的身分是企業應用軟體公司，並非資料庫廠商。當時 ERP 通常運行在 Oracle 、 IBM DB2 、 Microsoft SQL Server 等資料庫之上。
為了避免複雜分析拖慢日常交易，企業通常會把資料抽取到獨立數倉，建立索引、總計表和多層模型。這個架構穩定，卻帶來延遲：管理者看到的往往不是此刻發生的業務，而是上一次批次完成後的結果。
HANA 將記憶體運算、列式儲存、壓縮和平行處理結合起來。列存讓相同類型的資料連續存放，方便壓縮，也適合只掃描分析所需的列。在許多場景中，它還能減少額外索引和預先聚合結構。
這也是 HANA 的重要價值：不只是把硬碟換成內存，而是重新設計資料如何儲存、寫入和運算。
03 HANA 如何同時兼顧讀寫？列式儲存非常適合掃描與聚合，但壓縮後的主儲存並不適合頻繁修改。
HANA 使用 main storage 和 delta storage 配合：主要資料保存在經過壓縮、面向讀取優化的 main 中，新寫入先進入更適合更新的 delta ，再透過 delta merge 合併回 main 。
這套設計試圖把事務寫入和分析讀取放到同一個資料庫體系中。
它並不意味著所有場景都沒代價，也不意味著所有查詢都會自動變快；資料模型、 SQL 寫入法、分區和記憶體管理仍然會影響效能。
但它為 SAP 提供了一個關鍵可能性：讓 ERP 的交易和分析靠得更近。
04 “資料在記憶體裡”，斷電後會不會遺失？這是 HANA 早期最容易被誤解的問題之一。
記憶體負責運行時訪問，不等於資料只存在記憶體。 SAP HANA 仍透過資料磁碟區、日誌和 savepoint 實現持久化。
變化寫入日誌，記憶體中的資料也會週期性保存到持久化介質，以支援故障後的復原。
所以， HANA 的設計不是放棄磁碟，而是把磁碟從主要查詢路徑中移開，同時讓它繼續承擔持久化與復原職責。
05 SAP 為什麼必須自己做資料庫？如果 SAP 繼續只做應用層，它很難徹底重構 ERP 的資料模型。
因為應用仍要適配不同資料庫的共同能力，許多設計必須照顧舊有的效能限制。擁有 HANA 之後， SAP 可以讓應用程式、資料模型和資料庫共同演進。
2011 年首批客戶開始使用 HANA ； 2015 年， SAP 推出完全運作在 HANA 上的 S/4HANA 。在 S/4HANA 中，一些為傳統資料庫效能而存在的匯總和冗餘結構得以簡化， CDS 和程式碼下推也讓計算更靠近資料執行。
這才是 SAP 押注 HANA 的真正戰略意義：它不只是增加資料庫收入，而是要獲得重新設計下一代 ERP 的主動權。
06 這場押注的代價同樣明顯HANA 帶來了新的能力，也提高了系統需求。
企業需要面對硬體與記憶體規劃、 SQL 和 ABAP 程式碼適配、運作技能變化，以及從舊資料庫和舊 ERP 遷移的成本。把舊程式原樣搬到 HANA ，並不會自動獲得理想效能；一些逐行處理和不合理的資料存取方式，反而會暴露得更明顯。
HANA 也不是「所有資料永遠完整放在記憶體裡」。官方文件描述了按列載入、主動卸載，以及 Native Storage Extension 對溫資料的分頁載入。今天的 HANA 已經從單一「全記憶體」口號，發展為按熱度管理資料的完整平台。
07 HANA 真正改變了什麼？它改變了 SAP 產品路線，也改變了開發者的思考方式。
BW 從大量物化和匯總結構走向 HANA 優化； ABAP 從把資料拉到應用層循環，轉向 CDS 、 AMDP 和程式碼下推； ERP 則從 ECC 走向 S/4HANA 的簡化資料模型和嵌入式分析。
更重要的是， SAP 從依賴外部資料庫的應用廠商，變成掌握應用與資料雙重底座的平台廠商。
這條路並不輕鬆，也不是每個承諾都能無成本兌現。但如果沒有 HANA ，後來的 S/4HANA 、 BW/4HANA 以及 SAP 雲端資料路線，很難以相同方式出現。
結語SAP 押注 HANA ，表面上是在賭記憶體越來越便宜，深層是在賭企業會越來越需要即時、整合的資料處理。
這場賭局真正大膽的地方，不是做出更快的資料庫，而是敢於重寫自己最核心產品所依賴的底座。
對於 SAP 從業者而言，理解 HANA 也不應停留在「記憶體資料庫很快」。更重要的是理解列存、壓縮、 delta merge 、持久化與程式碼下推如何共同改變應用設計。
產品名字會更新，但「讓計算靠近資料、減少不必要的資料搬運」這項原則，仍然值得長期記住。
