文 · 元年科技高級副總裁 李彤

一、問題的提出

在數(shù)字化轉(zhuǎn)型的大潮推動下，企業(yè)信息化架構(gòu)正在進(jìn)行互聯(lián)網(wǎng)化的轉(zhuǎn)型升級。在新一代企業(yè)信息化架構(gòu)下，各種系統(tǒng)產(chǎn)生的數(shù)據(jù)類型和數(shù)據(jù)量快速激增，如何利用數(shù)據(jù)進(jìn)行科學(xué)有效決策、如何充分挖掘數(shù)據(jù)的價值，成為眾多企業(yè)的重要訴求。

企業(yè)的數(shù)據(jù)應(yīng)用主要有兩個大的方向。一是面向業(yè)務(wù)運(yùn)營的數(shù)據(jù)支撐。它包括：①通過對消費(fèi)者數(shù)據(jù)的洞察，改變銷售和交易模式，提高獲客和成交效率。目前大多數(shù)企業(yè)的數(shù)據(jù)應(yīng)用聚焦在改變市場銷售模式方面。②通過數(shù)據(jù)模型為供應(yīng)鏈管理提供支撐，提高生產(chǎn)經(jīng)營過程的效率，如排產(chǎn)和計劃優(yōu)化、物流的優(yōu)化。③大數(shù)據(jù)+算法成為業(yè)務(wù)運(yùn)營的數(shù)據(jù)賦能主要技術(shù)手段。二是面向戰(zhàn)略規(guī)劃和執(zhí)行的管理決策分析。它包括：①在戰(zhàn)略指引下對財務(wù)結(jié)果進(jìn)行持續(xù)規(guī)劃和分析是管理過程的核心。②管理會計的預(yù)算管理、成本盈利分析、管理報告等工具是戰(zhàn)略執(zhí)行的重要管理工具。③管理會計的核心是基于對企業(yè)全方位數(shù)據(jù)的加工、分析，發(fā)現(xiàn)問題，制定戰(zhàn)略和相關(guān)決策，并對結(jié)果進(jìn)行預(yù)測和監(jiān)控。④規(guī)模越大的企業(yè)對管理會計的需求越強(qiáng)，支持管理決策的數(shù)據(jù)模型越復(fù)雜。

本文主要探討在管理決策分析中多維內(nèi)存分析技術(shù)及其計算應(yīng)用的幾個問題，重點(diǎn)闡述元年方舟多維數(shù)據(jù)庫（ArkCube）架構(gòu)及其主要應(yīng)用場景。

二、數(shù)字化時代決策分析技術(shù)的發(fā)展歷程與全新要求

面向戰(zhàn)略規(guī)劃和執(zhí)行的管理決策應(yīng)用，無疑包括了管理會計體系的幾項(xiàng)核心內(nèi)容，如戰(zhàn)略規(guī)劃和測算、全面預(yù)算管理、成本管理、管理分析報告體系。這些決策類應(yīng)用的主要目標(biāo)是幫助管理者應(yīng)對企業(yè)各種不確定性。這就需要管理會計體系具備敏捷反應(yīng)，順應(yīng)前端業(yè)務(wù)變化的能力，能夠?qū)崟r獲取第一手的業(yè)務(wù)端信息并及時捕捉到變化中的管理需求，建立業(yè)務(wù)模型來對可能的變化進(jìn)行預(yù)測、管理和分析。

不同的應(yīng)用場景對數(shù)據(jù)技術(shù)的需求不同，面向運(yùn)營支撐的數(shù)據(jù)應(yīng)用主要依賴大數(shù)據(jù)+算法。而面向戰(zhàn)略規(guī)劃和執(zhí)行的決策場景主要依賴的是利用多維數(shù)據(jù)技術(shù)建立復(fù)雜業(yè)務(wù)財務(wù)模型的能力，以及對模型中的數(shù)據(jù)進(jìn)行快速、靈活分析的能力。雖然算法在戰(zhàn)略決策方面也有重要價值，但是管理決策體系的數(shù)據(jù)模型中更多的是顯式、復(fù)雜的計算規(guī)則。

數(shù)據(jù)建模和計算是管理會計應(yīng)用的關(guān)鍵技術(shù)基礎(chǔ)。管理會計系統(tǒng)的功能滿足度、可擴(kuò)展性，都依賴系統(tǒng)的建模計算能力。以計劃預(yù)測和成本分?jǐn)偰Ｐ蜑槔?，管理決策數(shù)據(jù)模型具有以下特點(diǎn)。①數(shù)據(jù)模型通常具有從業(yè)務(wù)到財務(wù)的轉(zhuǎn)換邏輯，計算規(guī)則成鏈狀、網(wǎng)狀。②數(shù)據(jù)來源既包含從業(yè)務(wù)系統(tǒng)導(dǎo)入的歷史數(shù)據(jù)，又包含人工輸入和計算生成的預(yù)測和計劃數(shù)據(jù)。③存在大數(shù)據(jù)量的分?jǐn)傆嬎銏鼍?，分?jǐn)偰Ｐ托枰粩嗾{(diào)整，需要較低的時間開銷，以保障分析效率。④預(yù)測和分?jǐn)偰Ｐ陀蓸I(yè)務(wù)驅(qū)動，需要根據(jù)業(yè)務(wù)變化頻繁快速調(diào)整，業(yè)務(wù)人員需要獨(dú)立進(jìn)行建模和維護(hù)。

在這種面向分析的管理系統(tǒng)中，數(shù)據(jù)是由多個維度（角度）描述的。例如銷售收入的數(shù)據(jù)是由產(chǎn)品、時間、渠道、客戶、區(qū)域、部門、人員等多個角度進(jìn)行定義的，在對銷售收入的預(yù)算或?qū)嶋H發(fā)生數(shù)據(jù)進(jìn)行分析的時候，分析人員可能會關(guān)心按產(chǎn)品、渠道、客戶等各維度匯總的銷售收入，或者按照不同的維度組合進(jìn)行數(shù)據(jù)查詢。這些都要求管理會計應(yīng)用系統(tǒng)建立在一個多維度的數(shù)據(jù)模型上。

在全球軟件市場，企業(yè)績效管理（Enterprise Performance Management，EPM）是指支撐戰(zhàn)略執(zhí)行過程的一系列管理過程與管理軟件。類似于Oracle Hyperion、SAP BPC、IBM T M1等領(lǐng)先產(chǎn)品的數(shù)據(jù)模型，都是構(gòu)建在OLAP（Online Analytical Processing，聯(lián)機(jī)分析處理）多維數(shù)據(jù)庫之上的。

多維數(shù)據(jù)庫從設(shè)計理念上與面向交易的管理信息系統(tǒng)有著本質(zhì)的區(qū)別?；贠LAP的多維數(shù)據(jù)庫技術(shù)不同于關(guān)系型數(shù)據(jù)庫（OLTP，聯(lián)機(jī)事務(wù)處理），主要面向業(yè)務(wù)分析人員。多維數(shù)據(jù)庫用戶的多角度思考模式，預(yù)先為用戶組建多維的數(shù)據(jù)模型。維度指的是用戶的分析角度，例如對銷售數(shù)據(jù)的分析，會計期間、產(chǎn)品類別、渠道、區(qū)域、客戶都是維度。多維數(shù)據(jù)庫用維度對數(shù)據(jù)進(jìn)行描述和存儲，一旦多維數(shù)據(jù)模型建立完成，用戶可以快速地從各個分析角度獲取數(shù)據(jù)，也能動態(tài)地在各個角度之間切換或者進(jìn)行多角度綜合分析，具有極大的分析靈活性。

（一）OLAP分析技術(shù)在數(shù)字化決策領(lǐng)域面臨的挑戰(zhàn)

從數(shù)據(jù)庫產(chǎn)生以來，數(shù)據(jù)分析和決策支持的需求就始終存在，為了解決這一需求，IT領(lǐng)域已經(jīng)為之付出了50余年的努力。OLAP就是這一領(lǐng)域的技術(shù)門類的代表。OLAP是關(guān)系數(shù)據(jù)庫之父Edgar F.Codd在1993年提出的，作為與OLTP（Online Transactional Processing,聯(lián)機(jī)事務(wù)處理）所對應(yīng)的另一類數(shù)據(jù)處理能力。這個概念主要用于多維數(shù)據(jù)分析(MDA)領(lǐng)域，是商業(yè)智能（BI）技術(shù)的核心。

如前所述，企業(yè)決策分析需求長期以來就是由OLAP技術(shù)進(jìn)行支撐的。OLAP按數(shù)據(jù)存儲組織的模式分為MOLAP、ROLAP和HOLAP。其中MOLAP（Multi-dimensional OLAP）是以多維數(shù)組存儲模型的OLAP，是OLAP發(fā)源最初的形態(tài)。它的特點(diǎn)是數(shù)據(jù)需要預(yù)計算（Pre-computaion），然后把預(yù)計算之后的結(jié)果（Cube）存在多維數(shù)組里。ROLAP（Relational OLAP）是基于關(guān)系模型存放數(shù)據(jù)，一般以事實(shí)表（Fact Table）和維度表（Dimensition Table）的結(jié)構(gòu)來存儲數(shù)據(jù)，不需要預(yù)計算，使用標(biāo)準(zhǔn)SQL就可以根據(jù)需要即時查詢不同維度數(shù)據(jù)。HOLAP是MOLAP和ROLAP類型的混合運(yùn)用，細(xì)節(jié)的數(shù)據(jù)以ROLAP的形式存放，更加方便靈活。而高度聚合的數(shù)據(jù)以MOLAP的形式展現(xiàn)，更適合高效的分析處理。HOLAP的目的是根據(jù)不同場景來利用不同OLAP的特性。

從發(fā)展歷程分析，其包括兩個大階段。

（1）獨(dú)立OLAP數(shù)據(jù)庫階段。1992年Arbor公司發(fā)布Essbase產(chǎn)品。這是一個獨(dú)立的OLAP數(shù)據(jù)庫產(chǎn)品，在服務(wù)器端通過跟業(yè)務(wù)系統(tǒng)和數(shù)據(jù)倉庫的集成，面向業(yè)務(wù)人員提供數(shù)據(jù)建模和決策分析。1998年，Hyperion公司與Arbor公司合并，之后，憑借在管理會計（預(yù)算、合并、成本）和BI領(lǐng)域的應(yīng)用產(chǎn)品與Essbase的集成，一躍成為OLAP市場的領(lǐng)頭羊，并持續(xù)保持領(lǐng)先位置。2004年Hyperion進(jìn)入中國市場，成為管理會計和BI領(lǐng)域應(yīng)用系統(tǒng)的領(lǐng)導(dǎo)者。2007年Hyperion被Oracle收購，借助Oracle的力量在國內(nèi)大型企業(yè)管理會計和BI市場形成了幾乎壟斷的優(yōu)勢。Essbase作為底層的核心能力，一直延續(xù)到今天。

Essbase是一個MOLAP產(chǎn)品，主要優(yōu)點(diǎn)有：面向業(yè)務(wù)人員設(shè)計，業(yè)務(wù)人員可以獨(dú)立完成數(shù)據(jù)分析建模，實(shí)現(xiàn)計算規(guī)則，對IT人員依賴較低，Oracle Hyperion基于Essbase的應(yīng)用產(chǎn)品深受CFO和財務(wù)人員的認(rèn)可；支持?jǐn)?shù)據(jù)回寫和更新，大并發(fā)的查詢和數(shù)據(jù)回寫的性能優(yōu)異；采用預(yù)計算的方式來提高查詢性能；計算的執(zhí)行效率遠(yuǎn)高于關(guān)系數(shù)據(jù)庫。但是，Essbase有以下缺點(diǎn)：Cube的維度需要提前規(guī)劃，增加新的維度需要對數(shù)據(jù)進(jìn)行重構(gòu)；數(shù)據(jù)規(guī)模大的時候，計算的時間開銷較大；TB級數(shù)據(jù)量時，預(yù)計算和Cube重構(gòu)的時間開銷巨大。

（2）大數(shù)據(jù)OLAP階段。21世紀(jì)初，隨著互聯(lián)網(wǎng)的快速發(fā)展，非結(jié)構(gòu)化數(shù)據(jù)大量出現(xiàn)，傳統(tǒng)的數(shù)據(jù)庫難以處理。2008年《自然》雜志?？岢隽薆igData（大數(shù)據(jù)）概念。2009年谷歌公開論文提出分布式文件系統(tǒng)GFS、分布式計算系統(tǒng)框架MapReduce、分布式鎖Chubby及分布式數(shù)據(jù)庫Big Table，催生了開源的Hadoop平臺，成為大數(shù)據(jù)蓬勃發(fā)展的基礎(chǔ)。

Hadoop的本質(zhì)是一個處理非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)的分布式系統(tǒng)，要做數(shù)據(jù)分析需要將數(shù)據(jù)轉(zhuǎn)換為結(jié)構(gòu)化數(shù)據(jù)。Hadoop本身并不具備結(jié)構(gòu)化數(shù)據(jù)處理的能力，于是MPP(Massively Parallel Processing)即大規(guī)模并行處理技術(shù)開始與Hadoop一起提供大數(shù)據(jù)量下的新型OLAP能力。簡單來說，MPP是將任務(wù)并行地分散到多個服務(wù)器和節(jié)點(diǎn)上，在每個節(jié)點(diǎn)上計算完成后，將各自部分的結(jié)果匯總在一起得到最終的結(jié)果。

大數(shù)據(jù)OLAP階段的應(yīng)用主要集中在互聯(lián)網(wǎng)行業(yè)，開源的OLAP產(chǎn)品以其低成本開放性優(yōu)勢占據(jù)主流。這類產(chǎn)品以SQL為主要開發(fā)語言，主要面向研發(fā)技術(shù)人員。在應(yīng)用場景上以PB級海量數(shù)據(jù)的分布式聚合分析為主，面向互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)運(yùn)營分析場景。對于決策支持和管理會計領(lǐng)域應(yīng)用場景，這類OLAP產(chǎn)品在數(shù)據(jù)實(shí)時回寫、復(fù)雜規(guī)則計算方面存在較大局限性。

由以上分析可見，傳統(tǒng)OL AP技術(shù)對大數(shù)據(jù)環(huán)境下的管理決策分析存在一定的計算能力局限性，而新興的大數(shù)據(jù)OLAP由于原理和設(shè)計場景的差異，主要用于運(yùn)營分析支持，也不能很好地支持管理決策分析場景。

（二）數(shù)字化時代對決策分析技術(shù)的全新要求

管理會計系統(tǒng)的應(yīng)用與實(shí)施的成功，不僅要看系統(tǒng)能否成功上線，而且要考慮系統(tǒng)上線后對管理模型變化的適應(yīng)性和可擴(kuò)展性。因此優(yōu)秀的多維數(shù)據(jù)庫產(chǎn)品都把系統(tǒng)用戶定義為業(yè)務(wù)背景的分析人員，可以由分析人員用簡單易懂的多維表達(dá)式，編寫計算公式和計算腳本來完成數(shù)據(jù)建模和維護(hù)。

隨著數(shù)字化時代來臨，企業(yè)擁有的數(shù)據(jù)量在快速增長，數(shù)據(jù)更精細(xì)更全面，對實(shí)時性要求越來越高。以某地產(chǎn)企業(yè)為例，2008年的經(jīng)營分析系統(tǒng)的數(shù)據(jù)量級在GB級，到2017年業(yè)務(wù)規(guī)模增長近10倍，數(shù)據(jù)精細(xì)化程度也有了大幅提升，經(jīng)營預(yù)測和分析的顆粒度由2008年的項(xiàng)目級，細(xì)化到了樓棟甚至房間，數(shù)據(jù)量也增長到了TB級。傳統(tǒng)OLAP技術(shù)已經(jīng)開始捉襟見肘，在數(shù)據(jù)容量、計算時間開銷上面無法滿足企業(yè)日益增長的預(yù)測和分析需求。

在全新的數(shù)字化時代，企業(yè)決策分析對技術(shù)方面主要有6個要求。①TB級數(shù)據(jù)支持：面向決策的數(shù)據(jù)通?？梢栽诮灰准墧?shù)據(jù)基礎(chǔ)上進(jìn)行一定層級的匯總，以減少決策數(shù)據(jù)的計算量，即便如此，在數(shù)字化的趨勢下，決策數(shù)據(jù)的量級也會持續(xù)增加，從傳統(tǒng)的GB級數(shù)據(jù)發(fā)展到TB級。②亞秒級數(shù)據(jù)計算：隨著企業(yè)決策數(shù)據(jù)量級的逐漸增大，傳統(tǒng)數(shù)據(jù)分析技術(shù)在億級數(shù)據(jù)量的復(fù)雜計算場景下的時間開銷通常要以小時甚至天計，無法滿足數(shù)字化時代快速決策的要求。企業(yè)管理者對實(shí)時或者準(zhǔn)實(shí)時的數(shù)據(jù)分析決策期望越來越高，業(yè)界實(shí)踐表明，億級數(shù)據(jù)量實(shí)時計算的響應(yīng)時間應(yīng)該達(dá)到秒級甚至亞秒級。③0代碼多維度查詢分析：企業(yè)決策模型包含組織、區(qū)域、渠道、產(chǎn)品、客戶、指標(biāo)、時間、版本等多種業(yè)務(wù)維度，要支持快速響應(yīng)多種維度組合的數(shù)據(jù)的計算、查詢和分析要求。業(yè)務(wù)人員要能夠通過Web、Excel等客戶端實(shí)時訪問決策數(shù)據(jù)，并自助完成多維度的分析和數(shù)據(jù)查詢，無須借助技術(shù)人員或者通過SQL等代碼語言。④高并發(fā)數(shù)據(jù)回寫：數(shù)據(jù)決策的趨勢正在快速地從面向過去的分析向面向未來的預(yù)測進(jìn)行轉(zhuǎn)變。這種轉(zhuǎn)變就要求決策分析技術(shù)不能僅僅具備從大量歷史數(shù)據(jù)建立只讀的分析模型。而是要具備高并發(fā)回寫的能力，以預(yù)算場景為例，經(jīng)常有幾千甚至上萬用戶在幾天內(nèi)，并發(fā)寫入數(shù)億數(shù)據(jù)；在成本和管理報告分?jǐn)傆嬎愕膱鼍跋?，幾分鐘?nèi)要計算并回寫數(shù)億條數(shù)據(jù)，同時用戶還會并發(fā)地對預(yù)測數(shù)據(jù)進(jìn)行大量更新操作。這就要求決策平臺要具備大并發(fā)寫入及更新數(shù)據(jù)的能力，并具備事務(wù)機(jī)制，保障數(shù)據(jù)一致性?；貙懙臄?shù)據(jù)要能夠?qū)崟r參與聚合、公式等分析計算，快速輸出分析結(jié)果。⑤面向業(yè)務(wù)的無代碼數(shù)據(jù)建模：分析決策的數(shù)據(jù)模型是靈活多變的，傳統(tǒng)的由管理者和分析人員提出需求，由開發(fā)人員通過代碼進(jìn)行模型開發(fā)的方式無法滿足分析決策的時效性需求。通過無代碼、在線的數(shù)據(jù)建模工具，向業(yè)務(wù)人員進(jìn)行賦能，讓他們能自助地完成數(shù)據(jù)模型的設(shè)計、計算規(guī)則的設(shè)計、報表報告的設(shè)計。這種設(shè)計能力需要是所見即所得，無須編譯發(fā)布即可生效的。⑥云原生彈性計算：決策分析的場景天然適合云模式，通常會不定期地需要大量的計算資源來完成某些特定的決策計算，通常在幾天甚至幾小時需要處理億級乃至TB級的復(fù)雜計算，決策完成后計算資源即可釋放。因此，基于云原生的微服務(wù)化、容器化的彈性計算引擎，是降低決策分析場景的計算資源成本、提高計算效率的重要途徑。

可以說，只有能同時滿足以上6個技術(shù)特性的計算引擎才能支撐未來10年的企業(yè)管理決策的要求。

三、升級版的多維內(nèi)存分析技術(shù)：元年方舟多維數(shù)據(jù)庫（ArkCube）架構(gòu)

元年科技20余年來一直致力于自主可控的企業(yè)決策分析平臺的研發(fā)，通過大量的應(yīng)用實(shí)踐和自主創(chuàng)新，推出了自主多維內(nèi)存OLAP產(chǎn)品元年方舟多維數(shù)據(jù)庫（ArkCube），將ArkCube產(chǎn)品整合到數(shù)據(jù)中臺的整體架構(gòu)中，并推出了基于元年數(shù)據(jù)中臺的全面預(yù)算、報表合并、盈利能力分析、管理報告、數(shù)據(jù)智能等專業(yè)產(chǎn)品。元年管理會計平臺產(chǎn)品架構(gòu)如圖1所示。

圖1 元年管理會計平臺產(chǎn)品架構(gòu)

為了滿足數(shù)字化時代對管理決策分析產(chǎn)品的要求，元年將A rkCube產(chǎn)品融入企業(yè)數(shù)據(jù)中臺架構(gòu)，借助互聯(lián)網(wǎng)、云原生的大數(shù)據(jù)底座跟多維內(nèi)存計算引擎的整合，既能發(fā)揮大數(shù)據(jù)平臺對海量數(shù)據(jù)的處理能力，又能延續(xù)優(yōu)秀OLAP產(chǎn)品面向業(yè)務(wù)分析人員自助維護(hù)數(shù)據(jù)模型的能力。同時，利用數(shù)據(jù)中臺數(shù)據(jù)驅(qū)動業(yè)務(wù)的思想，讓管理會計能更好地將企業(yè)管理決策和運(yùn)營支持進(jìn)行融合。

（一）企業(yè)數(shù)據(jù)決策平臺的總體架構(gòu)

極具中國特色的“數(shù)據(jù)中臺”概念是企業(yè)為了適應(yīng)不斷加劇的競爭環(huán)境而不斷探索、調(diào)適的結(jié)果。數(shù)據(jù)中臺的出現(xiàn)為企業(yè)數(shù)據(jù)的有效管理和利用提供了一個全新的思路。數(shù)據(jù)中臺歷經(jīng)2019年的概念普及期，在2020年進(jìn)入了探索應(yīng)用階段。來自CRM、ERP、SRM等各個信息化系統(tǒng)的業(yè)務(wù)數(shù)據(jù)、財務(wù)數(shù)據(jù)、大數(shù)據(jù)，結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)全部匯入數(shù)據(jù)中臺，實(shí)現(xiàn)統(tǒng)一、集中的數(shù)據(jù)收集、數(shù)據(jù)治理、數(shù)據(jù)計算、數(shù)據(jù)建模，形成服務(wù)化的數(shù)據(jù)應(yīng)用。

基于數(shù)據(jù)中臺架構(gòu)的企業(yè)管理平臺，不僅徹底解決了企業(yè)的信息孤島問題，有力提升了數(shù)據(jù)采集和數(shù)據(jù)轉(zhuǎn)換的效率和質(zhì)量，而且根除了企業(yè)IT系統(tǒng)重復(fù)建設(shè)的現(xiàn)象，為數(shù)據(jù)存儲和數(shù)據(jù)管理帶來便利?；跀?shù)據(jù)中臺，企業(yè)可以打通和匯聚多源數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)資產(chǎn)化和內(nèi)外部數(shù)據(jù)的整合，將其實(shí)時動態(tài)地共享和復(fù)用給前端應(yīng)用系統(tǒng)，實(shí)現(xiàn)場景化的數(shù)據(jù)應(yīng)用。

圖2為元年數(shù)據(jù)中臺總體方案架構(gòu)，通過主數(shù)據(jù)、元數(shù)據(jù)、數(shù)據(jù)標(biāo)準(zhǔn)、數(shù)據(jù)質(zhì)量、數(shù)據(jù)資產(chǎn)等數(shù)據(jù)治理功能，有序地管理數(shù)據(jù)源、數(shù)據(jù)模型和數(shù)據(jù)服務(wù)。底層采用大數(shù)據(jù)平臺集成來自內(nèi)外部各類數(shù)據(jù)源的多種數(shù)據(jù)。大數(shù)據(jù)平臺支持Hadoop、Greenplum等主流計算引擎，IT技術(shù)人員完成從數(shù)據(jù)源到大數(shù)據(jù)平臺的數(shù)據(jù)開發(fā)。在大數(shù)據(jù)平臺之上的ArkCube多維數(shù)據(jù)庫開放給業(yè)務(wù)分析人員來進(jìn)行數(shù)據(jù)建模，專業(yè)的分析模型除了賦能給企業(yè)決策者，也能通過數(shù)據(jù)中臺的數(shù)據(jù)服務(wù)，開放給企業(yè)的業(yè)務(wù)端應(yīng)用來實(shí)現(xiàn)數(shù)據(jù)驅(qū)動和賦能。

圖2 元年數(shù)據(jù)中臺總體方案架構(gòu)

將ArkCube融入數(shù)據(jù)中臺體系中，可以更好地支持?jǐn)?shù)據(jù)分析以及管理決策工作。

（二）元年ArkCube多維內(nèi)存分析引擎

元年ArkCube數(shù)據(jù)庫采用自主創(chuàng)新的內(nèi)存計算技術(shù)，具有高性能等優(yōu)勢。為了更好地適應(yīng)大數(shù)據(jù)時代的分析需求，元年在高可用部署、基于云原生容器化的動態(tài)彈性計算、支持自主可控國產(chǎn)化操作系統(tǒng)、中間件、關(guān)系數(shù)據(jù)庫等方面進(jìn)行優(yōu)化升級。

元年ArkCube可以滿足數(shù)字化和大數(shù)據(jù)時代對管理決策分析的技術(shù)要求。元年方舟多維數(shù)據(jù)庫（ArkCube）產(chǎn)品架構(gòu)見圖3。

圖3 元年方舟內(nèi)存多維數(shù)據(jù)庫（ArkCube）產(chǎn)品架構(gòu)

一是TB級數(shù)據(jù)支持。ArkCube作為內(nèi)存實(shí)時計算引擎，定位為以多維建模和OLAP分析為主的數(shù)據(jù)集市，可以支持單節(jié)點(diǎn)TB級的實(shí)時數(shù)據(jù)分析。測試表明，在單節(jié)點(diǎn)服務(wù)器中運(yùn)行800G以上的單一Cube，ArkCube仍有較高的讀寫和計算性能。由于ArkCube采用了內(nèi)存實(shí)時計算技術(shù)，常駐內(nèi)存的數(shù)據(jù)僅有輸入級別的數(shù)據(jù)，避免了傳統(tǒng)MOLAP采用預(yù)計算方法造成的數(shù)據(jù)爆炸。

二是亞秒級計算。ArkCube采用Tree來存儲數(shù)據(jù)，數(shù)據(jù)查詢和寫入的速度優(yōu)異，Cube數(shù)據(jù)常駐內(nèi)存帶來了高速的計算能力。在用真實(shí)數(shù)據(jù)進(jìn)行的測試中，測試數(shù)據(jù)集包含14個維度，最大維度有13萬成員，Cube中有12億輸入數(shù)據(jù)。不同維度的全量聚合計算耗時如下：按產(chǎn)品維（100+成員）作為行維度進(jìn)行聚合計算時間，響應(yīng)時間1s；組織維度作為行維12.7萬維度成員進(jìn)行聚合計算，響應(yīng)時間2.5s。結(jié)果表明，ArkCube可以支持億級計算量的亞秒級響應(yīng)。

三是0 代碼多維分析。利用Ark Cube的Web客戶端，Office、WPS插件，業(yè)務(wù)人員可以自助連接ArkCube服務(wù)進(jìn)行多維圖表的查詢分析，不需要使用MDX或者Sql代碼。

四是高并發(fā)實(shí)時回寫。利用真實(shí)數(shù)據(jù)集對ArkCube進(jìn)行單節(jié)點(diǎn)壓力測試，測試數(shù)據(jù)集包括14個維度，最大維度有13萬成員，Cube中有12億數(shù)據(jù)輸入數(shù)據(jù)。測試和實(shí)踐應(yīng)用均表明，ArkCube單節(jié)點(diǎn)可支持?jǐn)?shù)千至萬級的用戶規(guī)模。

五是業(yè)務(wù)人員自助建模。業(yè)務(wù)人員可以在ArkCube客戶端完成Cube、維度、圖表、計算規(guī)則、校驗(yàn)規(guī)則的建模工作。對于建模工作中最復(fù)雜的計算規(guī)則，ArkCube提供成員公式和計算腳本兩種模式，業(yè)務(wù)人員用維度表達(dá)式和公式方式（見圖4）編寫計算規(guī)則，無須技術(shù)人員協(xié)助，也無須像大數(shù)據(jù)ROLAP技術(shù)那樣，經(jīng)常需要進(jìn)行復(fù)雜的性能優(yōu)化工作。

圖4 維度成員公式

六是云原生彈性計算。在復(fù)雜的TB級，或者百億量級的數(shù)據(jù)計算場景下，ArkCube單節(jié)點(diǎn)的CPU會成為計算瓶頸。ArkCube基于容器的彈性計算架構(gòu)可以通過分布式計算來解決單節(jié)點(diǎn)的瓶頸問題。

（三）ArkCube的彈性計算架構(gòu)的應(yīng)用場景

ArkCube的計算架構(gòu)存在諸多應(yīng)用場景。

一是大規(guī)模計算任務(wù)分解。執(zhí)行大規(guī)模計算任務(wù)時，ArkCube可以動態(tài)調(diào)度帶有模型的Docker模板，并按任務(wù)分解維度將數(shù)據(jù)切塊以數(shù)據(jù)文件方式分發(fā)給動態(tài)的Docker節(jié)點(diǎn)，各節(jié)點(diǎn)加載數(shù)據(jù)完成計算后再將結(jié)果通過數(shù)據(jù)文件回傳主節(jié)點(diǎn)。比如，在保險、銀行的費(fèi)用分?jǐn)倛鼍?，隨著監(jiān)管和運(yùn)營決策的精細(xì)化的要求，總部、省、市各級機(jī)構(gòu)的費(fèi)用需要逐級分?jǐn)偟絽^(qū)域、產(chǎn)品、渠道，最終要分?jǐn)偟奖位蛘哔~戶。通常按月進(jìn)行計算，每次分?jǐn)偤臅r數(shù)個小時，過程中還要不斷核對、調(diào)整，從而造成多次反復(fù)分?jǐn)傆嬎?，采用固定的硬件資源來提高分?jǐn)傆嬎愕男释度氘a(chǎn)出比很低，采用基于容器的彈性計算框架，可以將分?jǐn)側(cè)蝿?wù)按省分公司進(jìn)行分解，在動態(tài)創(chuàng)建的多個容器中并行計算，計算完成再釋放容器資源，可以幾十倍提高分?jǐn)傆嬎愕男剩瑵M足快速出具成本、盈利分析報告的要求，又不會因?yàn)橛嬎阈枨蟮牟痪庠斐捎布Y源的浪費(fèi)。

二是用戶并發(fā)量大且單用戶計算量大的負(fù)載均衡。例如大型地產(chǎn)集團(tuán)的項(xiàng)目經(jīng)常要做項(xiàng)目級的全周期經(jīng)營預(yù)測，根據(jù)市場變化，調(diào)整產(chǎn)品結(jié)構(gòu)、銷售節(jié)奏、施工進(jìn)度、成本支付節(jié)奏等變量，設(shè)置幾百個版本，對項(xiàng)目的全周期內(nèi)部收益率（IRR）進(jìn)行敏感性分析，從而選擇最佳的經(jīng)營決策。大型地產(chǎn)集團(tuán)有幾百上千個項(xiàng)目，每個項(xiàng)目要持續(xù)做幾百個版本的測算，每個用戶的計算量在百億級，當(dāng)多個用戶并發(fā)時，單節(jié)點(diǎn)計算資源無法支撐，造成用戶排隊(duì)等待。各項(xiàng)目的測算不定期執(zhí)行，計算資源的需求不平衡，使用固定的計算資源無法匹配不確定的計算需求。利用彈性計算架構(gòu)，按項(xiàng)目動態(tài)生成計算節(jié)點(diǎn)并分發(fā)數(shù)據(jù)，響應(yīng)項(xiàng)目用戶的計算請求，用戶完成測算后動態(tài)節(jié)點(diǎn)即被回收。彈性計算架構(gòu)既可以滿足大用戶的分布式計算，又可以充分利用云端資源，避免靜態(tài)的分布式部署模式帶來的計算資源浪費(fèi)。

四、總結(jié)

隨著數(shù)字化時代企業(yè)對管理決策和分析需求的快速增長，傳統(tǒng)MOLAP技術(shù)已經(jīng)無法支撐大數(shù)據(jù)環(huán)境下的計算需求。而大數(shù)據(jù)ROLAP又缺乏對管理決策場景的支持，對技術(shù)研發(fā)依賴過重,業(yè)務(wù)分析用戶很難直接使用。市場急需新型的OLAP產(chǎn)品滿足新時代的企業(yè)需求。元年方舟ArkCube是一款自主可控的多維內(nèi)存分析引擎，可以有效地與大數(shù)據(jù)平臺進(jìn)行整合。作為數(shù)據(jù)中臺的一部分，它可以面向業(yè)務(wù)分析用戶，提供預(yù)測、預(yù)算、成本分?jǐn)偤凸芾韴蟾娴葟?fù)雜計算場景的建模能力，并利用內(nèi)存實(shí)時計算和彈性分布式計算架構(gòu)，有效地彌補(bǔ)傳統(tǒng)OLAP的缺陷，引領(lǐng)企業(yè)管理會計應(yīng)用邁向?qū)崟r化、動態(tài)化和場景化。