如果從傳統(tǒng)數(shù)據(jù)庫(kù)中讀取海量數(shù)據(jù)需要數(shù)十分鐘的時(shí)間，那么從SAP HANA中讀取同樣的數(shù)據(jù)只需要不到一秒鐘的時(shí)間。
 
        電力信息化用戶參考：內(nèi)存計(jì)算技術(shù)的存儲(chǔ)模式有哪些特點(diǎn)？


        潘明惠：內(nèi)存計(jì)算技術(shù)采取行存儲(chǔ)和列存儲(chǔ)的混合模式。傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)是按照行的方式存儲(chǔ)數(shù)據(jù)的，能夠?yàn)榻灰紫到y(tǒng)即OLTP應(yīng)用提供高效的支持。例如一個(gè)零售商每當(dāng)客戶購(gòu)買產(chǎn)品時(shí)，需要在業(yè)務(wù)系統(tǒng)中創(chuàng)建一條數(shù)據(jù)記錄銷售的時(shí)間、地點(diǎn)、客戶、金額、地址等字段數(shù)據(jù)，當(dāng)前端完成數(shù)據(jù)的錄入并提交后臺(tái)系統(tǒng)后，在數(shù)據(jù)庫(kù)中會(huì)在數(shù)據(jù)表中插入一行記錄，這條記錄中會(huì)包含本次銷售業(yè)務(wù)操作相關(guān)的數(shù)據(jù)。然而，基于行存儲(chǔ)的數(shù)據(jù)庫(kù)在支持?jǐn)?shù)據(jù)分析應(yīng)用即OLAP應(yīng)用時(shí)則顯得低效和力不從心。 同樣的例子，假設(shè)這家零售公司在傳統(tǒng)數(shù)據(jù)庫(kù)中保存了3億條記錄，并且需要基于這些銷售記錄分析單筆銷售的平均金額，則需要首先讀取所有這3億條記錄，并取出其中的銷售金額這一個(gè)字段，然后再進(jìn)行平均值計(jì)算。這意味著實(shí)際進(jìn)行分析的數(shù)據(jù)（消費(fèi)金額字段）只占總體數(shù)據(jù)的5%（假設(shè)每條數(shù)據(jù)20個(gè)字段）。顯然這是非常低效的方式。而在基于列存儲(chǔ)的機(jī)制中，這3億條記錄實(shí)際上是按照列進(jìn)行存儲(chǔ)，即總共只有20條記錄（20個(gè)字段，每個(gè)字段一條記錄）。在進(jìn)行同樣的分析時(shí)，只需要取出銷售金額這一列的記錄并計(jì)算平均值即可，與基于行存儲(chǔ)的機(jī)制相比，在這個(gè)示例的應(yīng)用場(chǎng)景下，數(shù)據(jù)處理的效率提高了50倍。
 
        電力信息化用戶參考：在近年，硬件服務(wù)器的處理器主頻提升并不明顯，但是單臺(tái)服務(wù)器配置更多的CPU，并且每個(gè)CPU包含更多的內(nèi)核。提升并行處理的能力，才能夠在新的硬件發(fā)展趨勢(shì)下保證系統(tǒng)的性能能夠持續(xù)的提升。內(nèi)存計(jì)算在這一點(diǎn)上有何建樹？


        潘明惠：SAP HANA支持多服務(wù)器、多處理器的高效并行處理，能夠最高效、充分的利用多處理器的并發(fā)能力。能夠拆解數(shù)據(jù)模型，分成可以并行執(zhí)行的步驟，也能夠?qū)?shù)據(jù)處理和運(yùn)算拆分并部署到多個(gè)處理器。例如計(jì)算引擎可以將數(shù)據(jù)模型拆解，將一些SQL腳本拆分成可以并行執(zhí)行的步驟。這些操作將遞交給數(shù)據(jù)庫(kù)優(yōu)化器來(lái)決定最佳的訪問(wèn)行存儲(chǔ)和列存儲(chǔ)的方案。


        除此外，SAP HANA的基本機(jī)制是將數(shù)據(jù)全部存儲(chǔ)到內(nèi)存中，以進(jìn)行高效的數(shù)據(jù)訪問(wèn)和運(yùn)算。雖然硬件包括內(nèi)存的價(jià)格日趨低廉，但相比磁盤而言，內(nèi)存仍是較貴的存儲(chǔ)設(shè)備。而在企業(yè)系統(tǒng)中數(shù)據(jù)增長(zhǎng)迅速，達(dá)到數(shù)TB甚至數(shù)十TB的情況下，將所有數(shù)據(jù)原封不動(dòng)的導(dǎo)入內(nèi)存仍將帶來(lái)較大的硬件投資。為了幫助企業(yè)節(jié)省這一部分投資，SAP HANA中采取了基于智能數(shù)據(jù)字典等高效的數(shù)據(jù)壓縮機(jī)制，能夠?qū)?shù)據(jù)壓縮5-20倍，從而充分節(jié)約硬件投資。


        在SAP HANA中，將源數(shù)據(jù)導(dǎo)入內(nèi)存后，在HANA中的虛擬建模，一個(gè)屬性視圖可以被看作為一個(gè)數(shù)據(jù)立方體，屬性視圖不存儲(chǔ)任何數(shù)據(jù)，數(shù)據(jù)存儲(chǔ)在列存儲(chǔ)表中 ，系統(tǒng)只保存這些數(shù)據(jù)模型內(nèi)表的構(gòu)際關(guān)系以及數(shù)據(jù)的運(yùn)算邏輯，當(dāng)前端提交分析請(qǐng)求時(shí)，HANA會(huì)根據(jù)虛擬數(shù)據(jù)模型進(jìn)行數(shù)據(jù)的計(jì)算并將結(jié)果提交給前段。這意味著HANA中不會(huì)存在冗余的數(shù)據(jù)，從而大大節(jié)約的硬件的投資和維護(hù)成本。


        另外，虛擬模型可以進(jìn)行靈活的創(chuàng)建、修改、刪除，從而滿足業(yè)務(wù)的需求變化，而無(wú)需擔(dān)心對(duì)整體數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)結(jié)構(gòu)的影響。在傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)中，通過(guò)ETL方式抽取數(shù)據(jù)并加載到數(shù)據(jù)模型中往往需要數(shù)小時(shí)甚至更長(zhǎng)的時(shí)間，而在HANA的架構(gòu)下，后端數(shù)據(jù)處理和加載的時(shí)間將大大縮短，從而減少IT部門運(yùn)維系統(tǒng)投入的時(shí)間和精力，并為前端數(shù)據(jù)處理提供更長(zhǎng)的時(shí)間窗口，減少數(shù)據(jù)不一致性發(fā)生的可能。
 
        電力信息化用戶參考：在數(shù)據(jù)庫(kù)層面進(jìn)行數(shù)據(jù)密集型運(yùn)算，似乎也是內(nèi)存計(jì)算所特有的優(yōu)勢(shì)？
        潘明惠：是的。SAP HANA 除了提供完善的數(shù)據(jù)庫(kù)功能外，其內(nèi)置的計(jì)算引擎可以將原本在應(yīng)用層進(jìn)行的運(yùn)算轉(zhuǎn)移到數(shù)據(jù)庫(kù)層面進(jìn)行處理，這在數(shù)據(jù)密集型運(yùn)算的場(chǎng)景，能夠優(yōu)化應(yīng)用層和數(shù)據(jù)庫(kù)層之間的數(shù)據(jù)交互，從而從整體上提升系統(tǒng)的效率。傳統(tǒng)上，數(shù)據(jù)密集型運(yùn)算包括計(jì)劃、預(yù)測(cè)、模擬等，在HANA中首先將計(jì)劃（Planning）