OLAP（Online Analytical Processing）是指線上聯機分析，基于資料查詢計算并實時獲得傳回結果。日常業務中的報表、資料查詢、多元分析等一切需要即時傳回結果的資料查詢任務都屬于OLAP的範疇。對應的，行業内也有相應産品來滿足這類需求，那就是OLAP Server。

OLAP Server現狀

目前主流OLAP Server幾乎都是基于RDB或封裝成RDB的大資料平台，有點類似早期的ROLAP（這個詞已經很少被提及了），其中一個關鍵的特征是使用SQL作為查詢語言。

RDB和SQL的特性會給OLAP Server帶來諸多困難。

複雜報表困難

事實上，報表才是OLAP業務的重頭戲，OLAP的查詢需求中有相當大一部分都是事先做好的報表查詢界面，而不是自由拖拽的多元分析，而複雜報表又經常占據報表需求的一半以上。這類報表的典型特點是資料處理邏輯複雜，每個報表都需要單獨編寫代碼進行資料準備，最常見的做法是使用複雜SQL或存儲過程，如果碰到一些資料庫無法實作的場景（如檔案等外部資料源、跨資料源計算、前後端分離等）還需要通過JAVA完成，過程十分繁瑣。

SQL實作這些計算很難，存儲過程也有很多缺點（無移植性、有安全隐患等）導緻越來越少使用，Java集合運算困難且無法熱切換而難以适應複雜多變的報表需求。目前OLAP Server在複雜報表這方面就表現的很不理想了。

自助關聯差

即使不管複雜報表，隻考慮多元分析的這種基礎的OLAP任務，使用SQL作為查詢語言時也很難勝任，隻能解決一小部分無關聯的單表分析，滿足一些相對固定的多元分析需求，适用範圍很小，難以适應靈活的自助分析場景。

體系封閉

目前OLAP Server嚴重依賴資料庫，資料庫有“庫”的概念，資料隻有“入庫”才能處理，而且通常隻能同時處理一個資料庫，無法同時計算資料庫外部的資料。而OLAP名為線上分析，業務上還要求做T+0式的實時查詢分析。其他資料源的資料需要先ETL到資料庫中才能計算，這就造成了不實時。典型的場景是OLAP業務經常要查詢業務庫的實時資料，要将實時資料（業務庫）和曆史資料（分析庫）混合查詢分析（T+0查詢），這是目前OLAP Server難以滿足的。何況還有很多非關系資料庫的資料也無法被OLAP Server直接計算。

性能低

退一步來講，即使隻關注曆史資料，不考慮實時生産資料，也隻使用單一的資料庫，目前OLAP查詢也面臨性能低的問題，我們經常會遇到查詢報表要等幾分鐘、實時查詢不實時、多元分析卡頓的情況。根本原因仍然是SQL的問題，基于關系代數理論的SQL難以實作高性能算法，僅靠資料庫在工程上優化并不能根本解決問題，SQL複雜時資料庫優化經常無效而導緻性能仍然很低。

開源SPL重新定義OLAP Server

SPL技術問世之後，将使OLAP Server的上述窘境大為改觀。

SPL是結構化資料計算專用程式語言（Structured Process Language）的簡稱。SPL提供豐富的計算類庫和靈活的開發文法可以快速完成各類複雜資料處理；SPL的計算能力不依賴于資料庫（資料源），天然支援多樣性資料源，可以完成跨資料源混合計算，實作跨異構源的實時查詢；SPL内置了大量高性能算法和存儲方案以及并行計算機制保證計算的高性能。

靈活的過程計算适應複雜報表

在複雜資料處理方面，SPL提供獨立的靈活文法支援過程計算，相對于SQL，SPL的文法更簡潔，适合完成複雜報表資料準備。

比如要計算：一隻股票最長連續上漲了多少天？

用SQL借助視窗函數還要寫成四層嵌套的語句：

select max(continuousDays)-1  
from (select count(*) continuousDays  
    from (select sum(changeSign) over(order by tradeDate) unRiseDays  
        from (select tradeDate,  
          case when closePrice>lag(closePrice) over(order by tradeDate)  
          then 0 else 1 end changeSign
          from stock) )
    group by unRiseDays)      

而同樣的邏輯用SPL寫要簡單得多：

A
1	=T(“/dw/stockRecord.txt”)
2	=A1.group@i(closePrice<   closePrice[-1]).max(~.len())

SPL提倡分步運算，複雜計算可以按照自然思維一步一步實作。

再借助SPL豐富的計算類庫可以大幅簡化資料處理難度。

針對SQL的調試困難，SPL還提供了簡潔易用的開發環境，單步執行、設定斷點，所見即所得的結果預覽視窗…

業務開展過程中報表會不斷新增、修改。使用報表工具可以解決報表呈現模闆的快速制作，但卻無法應對複雜多變的報表資料準備，以往無論使用SQL/存儲過程還是Java都難以很好應對。

使用SPL完成報表資料準備，可以實作報表資料準備工具化，加之原有呈現端的報表工具，使報表開發全面工具化，進而低成本、快速地應對沒完沒了的報表。

SPL是解釋執行的程式語言，天然支援熱切換。報表（資料準備）修改無需重新開機服務即可生效，以适應不斷修改的報表需求。

不僅如此，借助SPL靈活和易切換特性，還可以很好與微服務等開發架構融合。SPL提供不依賴資料庫的計算能力，算法外置完成微服務資料處理，相對Java寫死也更有優勢，能有效降低應用各個子產品間的耦合性。

體系開放

相對傳統OLAP Server的封閉性，基于SPL實作的OLAP Sever體系則更加開放。SPL的計算不依賴于資料庫，也不再有“庫”的限制，甚至沒有“庫“的概念。無論什麼資料源都可以直接使用，CSV、Excel、JSON/XML、NoSQL、RestAPI、HDFS、Kafka、Elasticsearch、SAP均能支援，還可以進行混合計算。資料源可以來自本地應用系統，也可以是外部系統或者遠端雲應用。

這種開放的計算體系能很友善完成T+0實時資料查詢，同時連接配接存儲熱資料的業務庫和存儲冷資料的分析庫（或檔案）進行混合計算即可實作T+0。

高性能

SPL沒有基于關系代數理論，而是創新地發明了離散資料集代數。這樣，很多SQL很難實作的高性能算法及存儲方案用SPL卻可以輕松實作，而軟體提高性能關鍵就在于算法和存儲。

例如，SPL支援更徹底的集合化，可以把TopN了解為聚合運算，這樣可以将高複雜度的排序轉換成低複雜度的聚合運算，而且很還能擴充應用範圍。

A
1	=file(“data.ctx”).create().cursor()
2	=A1.groups(;top(10,amount))	金額在前10名的訂單
3	=A1.groups(area;top(10,amount))	每個地區金額在前10名的訂單

SQL描述上面的運算會涉及大排序，性能非常低下，隻能寄希望于資料庫的優化。但在稍複雜的情況（比如A3中伴随分組運算）資料庫優化器就會失效。

再比如，SPL的遊标支援複用，可以在一次周遊中聚合出多個結果。

A
1	=file(“order.ctx”).create().cursor()	準備周遊
2	=channel(A1).groups(product;count(1):N)	配置複用計算
3	=A1.groups(area;sum(amount):amount)	周遊，并獲得分組結果
4	=A2.result()	取出複用運算的結果

而SQL無法描述這種算法，實作上述運算就會不可避免地将大資料周遊多次，造成性能低下。而且這個問題還是理論層面的，資料庫優化引擎無能為力。

SPL提供的其它與OLAP業務相關性能優化技術還有：有序歸并實作訂單和明細之間的關聯、預關聯技術實作多元分析中的多層維表關聯、位存儲技術實作上千個标簽統計、布爾集合技術實作多個枚舉值過濾條件的查詢提速、時序分組技術實作複雜的漏鬥分析，倍增分段存儲技術實作列存的平滑并行、…。其中有相當一部分是SPL發明的算法。

用TPCH國際标準實測，SPL能在低性能ARM晶片上跑出比高性能Intel晶片上Oracle快出數倍的成績，這就是創新算法帶來的優勢。。

在SPL的高性能算法和存儲方案的支援下，曆史大資料的計算會獲得更高的性能，配合實時業務熱資料進行混合查詢還可以進一步提升T+0查詢效率。

關聯查詢

針對傳統OLAP Server多元分析時關聯能力差的問題，基于SPL還發展了一種關聯查詢分析文法DQL。DQL（Dimensional Query Language）是以次元為核心的類SQL查詢語言在解決表間關聯問題時采用了與SQL不同的思路。

目前基于SQL的OLAP Server在實作多表關聯時并沒有特别好的辦法，要麼采用邏輯寬表，但由于會産生過多字段（維表字段會被複制多次，多層關聯、自關聯、循環關聯都會加劇這種情況）導緻使用者無法使用，而且性能也很差。有些BI産品可以根據使用者選擇的字段在頁面上自動關聯，但隻适用簡單的的情況，當遇到同維字段（如同一個表有2個以上地區字段）時就無法比對了，自關聯的情況也沒法處理。将表和字段都開放給使用者讓使用者自己關聯顯然更不現實。

那麼DQL是如何處理的呢？比如這樣一句SQL：

--SQL
SELECT A.* FROM EMPLOYEE A, DEPARTMENT B, EMPLOYEE C
 WHERE A.country='USA'
 AND C. country ='China'
 AND A. dept_id =B. dept_id
 AND B.  manager=C.  emp_id      

其中涉及多表和自關聯，很難讓業務使用者在BI界面中正确地描述出其中的關聯關系。

而同樣的查詢用DQL寫出來是這樣：

--DQL
SELECT * FROM EMPLOYEE
WHERE country ='USA' AND dept_id.manager.country ='China’      

将複雜的多表關聯轉換成了簡單的單表查詢，普通業務使用者都能了解并在界面中自行實施。

總結

SPL及DQL的問世，将對OLAP Server産生深刻的影響。

SPL資料

• ​​SPL官網​​
• ​​SPL下載下傳​​
• ​​SPL源代碼​​