Mondrian測試數據庫footmart生成記
來源：程序員人生 發(fā)布時間：2015-07-06 10:50:29 閱讀次數：4335次
現在要弄1些數據分析（OLAP）相干的數據，恰好mondrian提供了1個用于測試的footmart數據集，這個數據庫主要記錄了1些關于銷售數據的事實表和維度表，內容很豐富，并且提供了foorMart.xml文件，這個文件定義了所有需要使用的cube的定義集合，但是我們現在用自己開發(fā)的系統定義cube，所以這個配置文件應當就用不上了，主要需要生成這個數據庫的數據，首先將它放到mysql上吧，然后再將它通過sqoop導入到hive中，用我們的OLAP報表系統定義cube和報表履行查詢，這1套流程走下來基本上能把OLAP查詢的基本流程走通了，接下來的主要工作還是在如何優(yōu)化多維查詢的性能。
首先這個
數據庫數據的生成是通進程序履行得到的，首先我們需要下載mondrian的某個版本（根據官方文檔），下載地址在http://sourceforge.net/projects/mondrian/，但是有個問題就是在3.8.0版本以后只能找到jar包了，不能夠找到完全的那個zip包，所以我就舍棄了最新的版本，下載1個比較新的3.7.0版本的zip包（http://sourceforge.net/projects/mondrian/files/mondrian/mondrian⑶.7.0/mondrian⑶.7.0.0⑺52.zip，大小為119M），解壓以后在testsrc/main/mondrian/test/loader目錄下有1個MondrianFoodMartLoader.java文件，這個java程序就是為了生成測試數據的，固然測試數據都是寄存在1個.sql文件里面，這個文件在demo目錄下，文件名是FoodMartCreateData.zip，將它解壓過以后，編譯MondrianFoodMartLoader程序，然后運行以下命令：
-verbose -tables -data -indexes -jdbcDrivers=com.mysql.jdbc.Driver -outputJdbcURL=jdbc:mysql://172.17.3.102:16666/foodmart -outputJdbcUser=root -outputJdbcPassword=root -outputJdbcSchema=foodmart -outputJdbcBatchSize=50 -inputFile=C:UsersAdministratorDesktopFoodMartCreateData.sql
根據參數名可以看出參數的含義分別是：
-verbose 詳細輸出日志信息
-tables 如果表不存在則創(chuàng)建表
-data 如果數據存在則刪除全部數據在load，如果不選則不導入數據
-indexes 決定是不是創(chuàng)建索引
-outputJdbcUser、 -outputJdbcPassword 導出
數據庫的用戶名和密碼
-outputJdbcSchema 目標
數據庫名，如果不指定則使用默許的
-outputJdbcBatchSize 是不是批量插入，默許是50條記錄1批進行插入
-inputFile 導入的數據文件，就是之前在mondrian中提供的解壓以后的.sql文件路徑
創(chuàng)建完成以后有以下1些表：
mysql> show tables;
+-------------------------------+
| Tables_in_foodmart |
+-------------------------------+
| account |
| agg_c_10_sales_fact_1997 |
| agg_c_14_sales_fact_1997 |
| agg_c_special_sales_fact_1997 |
| agg_g_ms_pcat_sales_fact_1997 |
| agg_l_03_sales_fact_1997 |
| agg_l_04_sales_fact_1997 |
| agg_l_05_sales_fact_1997 |
| agg_lc_06_sales_fact_1997 |
| agg_lc_100_sales_fact_1997 |
| agg_ll_01_sales_fact_1997 |
| agg_pl_01_sales_fact_1997 |
| category |
| currency |
| customer |
| days |
| department |
| employee |
| employee_closure |
| expense_fact |
| inventory_fact_1997 |
| inventory_fact_1998 |
| position |
| product |
| product_class |
| promotion |
| region |
| reserve_employee |
| salary |
| sales_fact_1997 |
| sales_fact_1998 |
| sales_fact_dec_1998 |
| store |
| store_ragged |
| time_by_day |
| warehouse |
| warehouse_class |
+-------------------------------+
可以看出這里面的store_sales、store_cost、unit_sales可以作為度量的列，然后將他們使用某些聚合方式計算就能夠作為度量了。其余的例如product_id、time_id、customer_id、promotion_id、store_id是其它維度表的主鍵，通過這個id來關聯維度表，例如與time_id關聯的表是time_by_day，表結構以下：
| time_by_day | CREATE TABLE `time_by_day` (
`time_id` int(11) NOT NULL,
`the_date` datetime DEFAULT NULL,
`the_day` varchar(30) DEFAULT NULL,
`the_month` varchar(30) DEFAULT NULL,
`the_year` smallint(6) DEFAULT NULL,
`day_of_month` smallint(6) DEFAULT NULL,
`week_of_year` int(11) DEFAULT NULL,
`month_of_year` smallint(6) DEFAULT NULL,
`quarter` varchar(30) DEFAULT NULL,
`fiscal_period` varchar(30) DEFAULT NULL
) ENGINE=NTSE DEFAULT CHARSET=utf8 |
這樣我們就能夠設定time維度，這個維度關聯的維度表就是time_by_day ，可以選取該表中可以枚舉的列作為維度的級別（例如the_month、the_day、the_year、day_of_month、week_of_year等），這些級別之間可以有層級的關系，某1個級別是另外1個級別的父級，在當前的項目中1個維度下只支持1個級別有1個父級和1個子級的關系。例如year這個級別對應的是‘the_year’這1列，它的子級可以是‘quarter’列作為級別，例如在當前的表中‘the_year’這1列只有兩個取值：
mysql> select distinct the_year from time_by_day;
+----------+
| the_year |
+----------+
| 1998 |
| 1997 |
+----------+
而‘quarter’列有4個取值：
mysql> select distinct quarter from time_by_day;
+---------+
| quarter |
+---------+
| Q1 |
| Q2 |
| Q3 |
| Q4 |
+---------+
當設定這個級別之間的關系以后，可以在指定year這個級別以后對其履行下鉆操作，這樣就會計算year=1997下quarter為每個取值時的度量值，因此，級別的設定主要是為了設定對同1個維度不同粒度的聚合方式（依照年、依照月or依照季度）。固然有了這個層級的關系，為上卷和下鉆也提供了操作的基礎。
在cube的定義中主要的就是維度和度量的定義了，固然在表里面我們可以看到1些以agg開頭的表，這些表的創(chuàng)建是為了mondrian履行的時候優(yōu)化的，在mondrian提供的FoodMart.xml文件中可以看到文件的開頭制定了1些聚合表，這些聚合表相當于對1些度量依照不同維度履行的預計算，當履行查詢的時候如果匹配可以從聚合表中查詢而不用再進行動態(tài)的計算，固然這樣的與計算對數據更新還是有1定的代價的。
目前基于mondrian的OLAP查詢引擎面臨的最大問題就是性能的問題，由于大部份的mdx查詢操作都是動態(tài)得翻譯成sql，然后從元
數據庫中履行查詢操作，這難免會造成性能低下，特別是對不面向響應時間的hive
數據庫，查詢速度那是相當的慢，目前的優(yōu)化方式大體上是履行預計算的方式，在創(chuàng)建cube的時候預先將全部cube或可以支持全部cube的所有度量值都計算出來，查詢的時候從預計算的結果中查詢或再進行聚合，由于預計算的結果可以寄存在內存或性能更高的key-value
數據庫中，這類方式比直接從元
數據庫查找的性能會有1定的提升，但是當數據量比較大的時候預計算的結果可能會非常大，如果節(jié)省緩存的空間也是面臨的1個大問題。
生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
