提起 SQL，相信從事過數據分析相關工作的同學，對此都不陌生。在零售、銀行、物流等行業，業務往往會有複雜的分析需求，如半累加，多對多，時間窗口分析等，SQL 在處理這些場景時，就有些捉襟見肘了。那有什麼方案能夠輕鬆應對呢 ? 答案就是： MDX
本文將從基本概念、BI 語義模型和分析場景來介紹 MDX 與 SQL 的區別。看完之後，相信您會更加了解爲什麼 MDX 比 SQL 加適合複雜分析場景。
MDX 和 SQL 基本概念
MDX (Multidimension eXpressions) 是一種 OLAP 多維數據集的查詢語言，最初由 Microsoft 於 1997 年作爲 OLEDB for OLAP 規範引入，隨後集成在 SSAS 中。目前，在 OLAP 數據庫中被廣泛採用。
MDX 查詢語法示例如下：
select<Axis Expr>[,<Axis Expr>]from[cube]where<set>
SQL (Structured Query Language) 是一種用於管理關係型數據庫的編程語言，包含 DQL(查詢)、DML(增刪改)、DDL(定義修改元數據) 和 DCL(權限、事務控制)。爲了方便闡述和 MDX 的區別，本文只涉及 SQL 的查詢部分。
SQL 查詢語法示例如下：
select<columnexpr>[,<columnexpr>]from[table]where<expr>
MDX 和 SQL 查詢的主要區別：
a. MDX 選擇的主體，即 select 部分，是維度度量或其表達式。SQL 選擇的主體是列或列的表達式。
b. MDX 查詢的主體，即 from 部分，是多維數據集（Cube），是提前 join 和聚合好的數據，查詢時不需要指定 join 關係。SQL 查詢的主體是關係表（table），是一條條的明細記錄，查詢時需要指定表之間的 join 關係。
MDX 與 SQL 的聯繫：
MDX 在很多情況下是可以等同於 SQL 的，比如需要查詢 2019年所有省份的電子產品的銷售額。
用 MDX 表示爲：
select[Region].[Province].membersfrom[Sales]where([Time].[Year].[2019],[Product].[Category].[Electronic Prodcut])
用 SQL 表示爲：
select region.province from sales
join region on sales.region_id = region.id
join time on sales.time_id = time.id
join product on sales.product_id = product.id
where time.year = 2019 and product.category = "Electronic Prodcut"
BI 語義模型
當前，主流的 BI 產品（Tableau, Power BI，Qlik等）都支持通過 SQL 接口（JDBC/ODBC）連接關係數據庫，也支持 MDX 接口（XMLA）連接多維數據庫。但 BI 通過兩種接口獲取到的語義模型有較大的差異，下面將具體介紹。
MDX 語義模型包含維度（維度別名），度量（度量別名），層級結構等，無需分析師在 BI 端再對模型進行業務語義的定義，這樣的好處是 建模師可以在OLAP工具中統一定義業務用戶分析時使用的語義模型，而業務在使用 BI 工具分析時無需理解底層表結構，直接使用同步到 BI 工具的維度、度量、層級結構、計算度量等進行分析。
另外 MDX 對複雜分析場景的控制能力比 SQL 更強，對於一些複雜場景如半累加、時間窗口分析、多對多關係等，MDX 都可以通過簡單的表達式來處理。而同樣的邏輯使用 SQL 就需要使用非常複雜的查詢才能實現，有些場景甚至無法簡單通過 BI 發送的 SQL 查詢來實現。
SQL 語義模型
僅包含源表和源列，需要分析師 /業務用戶手動定義表的模型關聯關係，維度的友好名稱，度量的友好名稱及聚合類型，層級結構的源列順序等。這些完成後才能進行正常的業務分析，這樣的好處是終端用戶可針對分析需求靈活的進行數據建模，但同時也要求用戶對底層數據結構有一定的理解理解。
MDX實現的複雜分析場景
庫存分析，是製造、零售和物流行業等經常遇到的分析場景。其中，庫存量是一個半累加度量，即在時間維度上不具備累加性，但是在其他維度具備累加性。
假設，庫存的記錄如下，需要獲取每月所有產品期初（月的第一天）和期末（月的最後一天）的庫存總量。
我們按照分析需求，得到的結果應該如下：
如果使用 SQL，查詢表達式如下：
select`year`,`month`,sum(casewhen`dayofmonth`=1theninventoryelse0end)as"Inventory on first day of the month",sum(casewhenday(last_day(`year`||'-'||`month`||'-'||`dayofmonth`)=`dayofmonth`theninventoryelse0end)as"Inventory on last day of the month"frominventorygroupby`year`,`month`
如果使用 MDX，需要先定義計算度量（包含的基礎度量 [Measuers].[庫存]=sum(inventory)），如下：
[Measures].[期初庫存] = ([Time].[Month].currentMember.firstChild, [Measures].[庫存])
[Measures].[期末庫存] = ([Time].[Month].currentMember.lastChild, [Measures].[庫存])
MDX 查詢表達式爲：
select{[Measures].[期初庫存],[Measures].[期末庫存]}onColumns,[Time].[Month].membersonRowsfrom[inventory]
由上可見，在庫存分析場景中，MDX 比 SQL 更容易實現。類似的場景還有銀行業常見的賬戶餘額分析，證券行業常見的期初期末值分析等。另外，MDX 還能夠支持對多分析場景，這是 SQL 所不支持的。
Kyligence MDX: 支撐企業部署統一的 BI 語義層
Kyligence 提供的 AI 增強型大數據平臺同時爲 BI 用戶提供了 SQL 以及 MDX 標準接口，可無縫集成市面主流 BI，提供統一的基於大數據的業務語義層，MDX 的接口。
爲企業實現企業級業務語義層提供了技術可能性，並可滿足更多 SQL 很難滿足的複雜分析場景。
總結
MDX 和 SQL 都是在 OLAP 查詢中經常使用的語言，主流的 BI 廠商都提供對兩種接口的支持。兩者的差異在於：
第一點，MDX 查詢對應的是多維視圖，而 SQL 對應的是關係視圖，在聚合查詢的語法上 MDX 要簡單許多。
第二點，MDX 接口暴露的語義模型更加豐富和業務友好，而 SQL 接口暴露的語義模型相對簡陋，需要後續再定義。
第三點，MDX 計算表達能力更加豐富，能夠更好的支持複雜分析場景。
總的來說，如果業務上有複雜的分析場景需求（銀行、零售、物流等傳統行業經常遇見）如半累加，多對多，時間窗口分析等，有統一的BI語義層需求時，Kyligence MDX 方案能夠幫您輕鬆處理，從而更好的專注與業務數據的分析。