蘇寧OLAP架構設計

一. 功能綜述

OLAP引擎為存儲和計算二合一的引擎，自身內部涵蓋了對數據的管理以及提供查詢能力。底層數據完全規划在引擎內部，外部系統不允許直接操作底層數據，而是需要通過暴露出來的接口來讀寫引擎內部數據。

目前整體來說OLAP功能由兩部分組成：數據管理，查詢引擎。

1.1 數據管理

引擎中數據核心概念包括：事實表，維度表，模型表，加速表，其中事實表和維度表統稱為Dataset表。數據操作包括以下幾點：

1. 事實表創建、定時導入、清理、補數。
2. 維度表創建、定時導入、清理、補數；
3. 模型表創建、刪除；
4. 加速表Scheme探測、定時加速、清理、補數；

其中事實表和維度有以下設計關注點：

• 事實表和維度表構造起整個OLAP引擎內部的星型結構，可以通過接口創建一個新的事實表或者維度表；對於事實表，也可以在創建模型自動創建。
• OLAP引擎內部可以根據事實表，維度表，模型表創建過程中所提供的信息，動態的感知出事實表的時間維度、多值維度、外鍵維度、普通維度、去重統計維度以及度量，也可以感知出維度表中的外鍵維度、普通維度。
• 事實表和維度表的存儲方式可以根據上面感知到的信息來進行自我規划，對上層應用來說完全隱藏。

其中維度表有以下設計關注點：

• 每個維度表都有version版本屬性，即系統中會存在多個版本的維度數據，默認會保存最新N個版本。后續的加速表的每個批次的數據都是和相應版本的維度表關聯。
• 維度表導入任務與業務維度表生成任務構成導入任務鏈，每次導入都會生成一個新版本的維度表。
• 針對模型自動加速，OLAP引擎只要感知到相應的維度表當天版本已經生成，既可以開始相應的加速，加速時會選擇當天最新版本的維度表。系統當天不會自動對已經加速的數據因為維度變更而自動更新，需要手動發起加速表的重構操作。

其中事實表有以下設計關注點：

• 事實表導入任務與業務事實表生成任務構成導入任務鏈。上游業務事實表任務結束以后，會調起我的事實表導入任務，並傳遞上游執行任務所屬於的batch時間。
• 事實表補數操作是OLAP對外提供單次服務接口。OLAP引擎會對請求時間進行拆分，轉化為多個批次的事實表補數任務，並分發給IDE去執行。 
  對於一個事實表補數操作，與該事件表的數據加速任務是互斥的，即會對相應的bacth加上讀寫鎖，只有拿到寫鎖，才可以進行補數操作，否則會一直等待當前批次關聯的加速任務完成。事實表補數結束以后，會對已經完成的加速表進行數據重構操作。

其中模型表有以下設計關注點：

• 模型表為一個視圖表，對外提供表的Create、Delete操作，Delete操作對外接口只會刪除模型相關的meta信息，但是后端需要同時刪除該模型相關聯的加速表的數據。
• OLAP引擎需要根據模型表join關系，確定模型所歸屬的事實表和維度表，構建起整個數據導入以及加速任務鏈。

其中加速表有以下設計關注點：

• 加速表是模型的物化表。對於百川來說，默認會進行Druid和Carbondata兩級物化。
• 對於默認應用場景，OLAP引擎會選擇Druid進行指標的查詢；只有在SQL中強制指定使用Carbondata進行查詢的時候，才會使用Carbondata進行查詢。
• 在維度表變更以后，可以通過OLAP引擎接口，一致性重寫相應維度表關聯的加速表，默認情況下，加速表都會使用當前最新可用的維度表進行加速。
• 加速表的每一個批次的加速都有鎖的存在，在鎖沖突的情況，不會排隊等待，而是會直接失敗，只有當前拿到鎖的加速任務，才可以進行相應批次的加速。

1.2 調度與執行架構

OLAP引擎調度架構是在Bigquery上進行改進。其中會把服務接口升級為三種類型：

1. 同步阻塞服務接口。
2. 異步非阻塞服務接口。
3. IDE定時調度接口。

其中同步阻塞接口主要用於請求耗時在3s以內的查詢，其中包括數據管理，集群管理，以及指標數據查詢；異步非阻塞接口主要服務耗時較差或不可沽的服務接口，其中包括用於數據探測。如果OLAP引擎用於服務百川，與外部數據的交互，包括定時數據遷移，加速及補數，都需要通過IDE任務來實現，OLAP引擎不會直接與外部數據源交互。

二. 架構設計

上圖是OLAP引擎整體架構圖，分為三個層面：數據存儲層，計算資源層以及OLAP服務層。

1. 數據存儲和計算資源層

• OLAP引擎是基於Spark和Hadoop的SQL引擎，內部依賴Druid，HDFS，HIVE存儲來存儲相關數據。為了與離線計算集群解耦，OLAP自身內部有一套完整的HDFS存儲，HIVE存儲以及Yarn資源池。
• OLAP引擎內部Spark指標計算，異步化任務都是托管在自身的Yarn資源池內部，同時也只會消費處理自身的Druid、HDFS和HIVE數據。
• OLAP引擎外部對底層HIVE訪問需要通過API層進行轉發，比如新增分區，修改表結構等，運行在離線計算集群上的加速等任務無法操作OLAP引擎底層Hive數據倉庫。
• OLAP引擎讀取離線計算集群Hive TableMeta操作，必須通過ThriftServer進行訪問，離線計算集群Hive配置不會托管到OLAP引擎中。
• 對於數據入庫以及模型加速兩種任務，是由IDE平台負責調度。它是運行在離線計算集群上面，它可以讀寫離線大集群上的HIVE倉庫以及HDFS存儲，也可以通過Alluxio Proxy來讀寫OLAP引擎底層的HDFS，但是不可以直接讀寫OLAP引擎HIVE倉庫，需要通過API層的Query請求進行轉發。
• OLAP引擎底層還采用了HBase作為KV存儲，來存儲異步化任務相關信息；以及采用MySQL來存儲OLAP集群Meta信息。

2. OLAP服務層

OLAP接口服務層主要為外部提供數據管理以及指標查詢能力。其中定時數據入庫任務、模型加速任務及補數等數據管理操作都是由API層將請求分發給IDE-API層，后續由IDE調度層負責任務的調度和定時執行。OLAP引擎提供的指標計算以及異步化任務都是在OLAP引擎自身調度層的調度下，完成任務執行，其中調度層也負責整個計算的請求路由以及集群管理。

3. 主服務接口流程

3.1. 模型創建

1. 獲取模型關聯的事實表以及維度表，並判斷在當前集群中是否已經存在；如果相關的維度表不存在，直接報錯； 
   1.1 如果事實表不存在。 
   1.1.1 請求離線計算集群ThritServer，將事實表的scheme克隆到OLAP引擎中，期間會使用Parquet進行存儲。 
   1.1.2 請求IDE，構建一個事實表遷移任務； 
   1.1.3 請求IDE，手動補數最近1天（可配置）數據； 
   1.2 如果事實表已經存在。根據這次提供的事實表相關信息，完善當前我們對事實表的認識。
2. 對查詢請求進行SQL翻譯，並在OLAP引擎中構建模型表，在model數據表中存儲模型信息；
3. 請求IDE，構建模型的定時加速任務，並記錄到speed表中。
4. 模型創建成功。

3.2 指標查詢

1. API將請求轉發到調度層，由調度層根據當前后端負載情況，返回一個可用worker。
2. API層直接請求worker進行查詢執行。worker首先將SQL按照;進行切分，如果為普通的set語句，DDL語句，即立即執行；如果為select語句，worker對SQL進行解析和校驗，其中校驗點包括： 
   2.1 是否為衍生指標查詢？衍生計算邏輯是否支持? 
   2.2 內部查詢是否為UNION子查詢？並校驗每一個子查詢模型是否存在？ 
   2.3 校驗子查詢是否有主時間維度？並校驗涉及到的分片數是否在閾值之內？ 
   2.4 校驗所有分片是否都已加速？ 
   2.5 校驗聚合指標是否為sum,count,max,min,count distincts五種？ 
   2.6 校驗count distinct的維度是否在模型配置列表中？ 
   2.7 校驗case when語句是否為單case when語句，並且else被置為0或者null?
3. 如果bigquery.accurate.count_distinct=true，只能選擇carbondata進行加速，否則默認都選擇druid進行加速。
4. 在carbondata或者druid上完成SQL查詢，並直接返回查詢結果給API層。

注意：處理到第一條select語句后，將會結束后面SQL的執行。

注意：關於多時間維度：

對於一個模型，它必須要有一個分區時間字段和1個或多個業務時間字段，其中分區時間字段為粗粒度，而業務時間字段為細粒度。

在模型加速過程中，如果一個模型只有一個1個業務時間字段，即使用業務時間字段作為主時間維度；否則將使用分區時間字段作為主時間字段進行加速。

在指標查詢過程中，必須帶上主時間維度過濾條件。對於單時間模型，查詢的時候必須帶上相應的業務時間過濾條件；對於多時間模型，查詢的時候就必須帶上分區時間過濾條件。 比如多時間模型，分區時間為a，兩個業務時間b,c，查詢的時候必須在維度上a做時間過濾，否則會全表掃描； 比如單時間模型，分區時間為a，業務時間為b，查詢必須是基於業務時間b來構建過濾條件。

三. 接口設計

http://www.xiaoyaoji.cn/dashboard/#!/share/AmjDtLow2

四. 存儲設計

如上所述，OLAP引擎由三組存儲組成：MySQL核心Meta存儲、HBase異步化任務狀態KV存儲、以及Hive/HDFS數據存儲。其中核心Meta存儲采用MySQL進行存儲，包括Dataset，Model，speedup，Partition四個表；HBase僅僅用來存儲數據探測等異步化任務相關信息；事實表、維度表、加速表等數據存儲在Hive/HDFS中。

1. Dataset表——存儲事實表和維度表Meta信息

dataset表存儲了系統中所有的事實表和維度表，通過type字段進行標識，可選{"0":"事實表","1":"維度表"};

在創建事實、維度表時，需要指定表所關聯的上游任務pre_ide_job_id和granularity，OLAP引擎在IDE中創建定期遷移數據任務，任務流ID和任務ID分別為ide_flow_id、ide_job_id;

meta字段是OLAP對該表的認知，隨着上層模型建立，認知也會逐漸豐富起來。

CREATE TABLE `bigquery_dataset` (
 `id` INTEGER NULL AUTO_INCREMENT DEFAULT NULL,
 `database` VARCHAR(128) NULL DEFAULT NULL,
 `tablename` VARCHAR(128) NULL DEFAULT NULL,
 `type` TINYINT NULL DEFAULT NULL,
 `pre_ide_job_id` VARCHAR(128) NULL DEFAULT NULL,
 `granularity` TINYINT NULL DEFAULT NULL,
 `ide_flow_id` VARCHAR(128) NULL DEFAULT NULL,
 `ide_job_id` VARCHAR(128) NULL DEFAULT NULL,
 `meta` MEDIUMTEXT NULL DEFAULT NULL COMMENT 'json',
 PRIMARY KEY (`id`),
 UNIQUE KEY `dataset_unique_key` (`database`,`tablename`),
 UNIQUE KEY `pre_ide_job_id_unique_key` (`pre_ide_job_id`),
 UNIQUE KEY `ide_job_id_unique_key` (`ide_flow_id`,`ide_job_id`),
);

其中meta字段Json結果如下所示：

{
    "dimensions":[
 {
 "dimension":"維度名稱",
 "type": "維度類型"，
 "cardinality":"維度基數",
 "is_time":"是否為時間字段",
 "time_format":"時間字段格式",
 "is_partition":"是否為分區字段",
 "is_key":"是否為維度外鍵",
 "is_multivalue"："是否為多值列",
 },
 ],
 "measures": [
 {
 "measure":"度量名稱",
 "type":"度量類型"，
 },
 ],
}

2. Model表——模型視圖表

model為存儲業務模型，每個模型歸屬一個database；granularity為模型時間間隔，它與所依賴的事實表時間間隔一致；ttl單位天，表示模型關注的時間，超過這個時間的物化數據，將會從系統中移除。meta存儲詳細描述信息。

CREATE TABLE `bigquery_model` (
 `id` INTEGER NULL AUTO_INCREMENT DEFAULT NULL,
 `name` VARCHAR(256) NULL DEFAULT NULL,
 `database` VARCHAR(256) NULL DEFAULT NULL,
 `queryGranularity` VARCHAR(64) NULL DEFAULT NULL,
 `ttl` INTEGER NULL DEFAULT -1 COMMENT 'model關注時間',
 `meta` MEDIUMTEXT NULL DEFAULT NULL COMMENT '存儲模型詳細信息',
 PRIMARY KEY (`id`),
 UNIQUE KEY `model_unique_key` (`name`,`database`),
);

其中meta格式如下所示：

meta={
    "fact":{},
 "relations":[],
}
//
fact={
 "database":"",
 "tablename":"",
 "filter":"",
 "meta":{
 "dimensions":[
 {
 "name":"",
 "dimension":"",
 "type":"",
 "is_time":"",
 "time_format":"",
 "is_partition":"",
 "is_multivalue":"",
 "is_radix":"",
 }
 ],
 "measures":[
 {
 "name":"",
 "measure":"",
 "type":"",
 }
 ],
 }
}
//
relations=[
 {
 "database":"",
 "tablename":"",
 "dimensions":[
 {
 "name":"",
 "dimension":"",
 "type":"",
 "is_multivalue":"",
 "is_radix","",
 }
 ],
 "join":{
 "type":"",
 "items":[
 {
 "dimension":"",
 "fact_dimension":"",
 },
 ],
 },
 "filter":"",
 }
]

3. speedup表——模型加速表

speedup為模型加速表，單個模型可以有druid和carbondata兩種加速類型，通過type字段進行標識；每一種類型加速根據聚合粒度queryGranularity，可以有多個加速寬表，每一個加速寬表對應一個IDE實體遷移任務ide_job_id。

CREATE TABLE `speedup` (
 `id` INTEGER NULL AUTO_INCREMENT DEFAULT NULL,
 `model` VARCHAR(256) NULL DEFAULT NULL,
 `database` VARCHAR(256) NULL DEFAULT NULL,
 `type` INTEGER NULL DEFAULT NULL,
 `name` INTEGER NULL DEFAULT NULL,
 `ide_flow_id` INTEGER NULL DEFAULT NULL,
 `ide_job_id` INTEGER NULL DEFAULT NULL,
 `queryGranularity` INTEGER NULL DEFAULT NULL,
 `scheme` MEDIUMTEXT NULL DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `speedup_unique_key` (`model`,`database`, `type`, `queryGranularity`),
 UNIQUE KEY `speedup_name_unique_key` (`name`),
);

4. Partition表——事實表、維度表、加速表分區狀態表

partition數據分區表。不管是dataset還是speedup，都只是存儲表的邏輯信息，實際數據都需要以分區的形式遷移或假設而來(注意：維度表遷移是完整遷移，可以理解分區為0到無窮大)，每一次遷移或拉寬都對應一條記錄存儲在partition分區表中。

type表示分區類型,可選值有dataset，speedup，relation_id為外鍵，分別關聯dataset.relation_id和speedup.relation_id；每一個分區都有一個interval字段，標識該分區所屬於的時間段，參考標准。

interval記錄可以有多個版本，通過version表示；對於speedup以及dataset.fact數據，底層數據只會保存一個版本，數據庫中記錄也只有一條(通過updateOrInsert來實現)；而對於dataset.dim數據，底層會保存歷史多個版本，數據庫中記錄條數也會有多條記錄。

如果type=speedup，versions字段存儲了它所依賴的各個表的維度信息，格式為[{"database":"","tablename":"","version":""}]

CREATE TABLE `partition` (
 `relation_id` INTEGER NULL DEFAULT NULL,
 `type` VARCHAR(128) NULL DEFAULT NULL,
 `interval` INTEGER NULL DEFAULT NULL,
 `version` VARCHAR(64) NULL DEFAULT NULL,
 `status` TINYINT NULL DEFAULT NULL,
 `ide_instance_id` INTEGER NULL DEFAULT NULL,
 `versions` MEDIUMTEXT NULL DEFAULT NULL,
 UNIQUE KEY `partition_unique_key` (`relation_id`,`type`，`interval`, `version`)
);

5. Task表——異步化任務狀態表

task為HBase表，存儲了Task相關信息，通過type參數來區分不同類型。cf1.content字段存儲任務的參數信息；cf2.data字段存儲任務的執行過程中或者結束以后大Blob信息。

{
    "name": "ns_bigdata:bigquery_task"
 "cf1": {
 "type":"任務類型",
 "content":"任務內容",
 "user":"",
 "create_time":"",
 "priority":"",
 "timeout":"",
 "status":"",
 "update_time":"",
 "worker:"",
 "progress":"",
 "schedule_cost:"",
 "execute_cost:"",
 "fail_desc:"",
 "count:"",
 },
 "cf2": {
 "scheme":"查詢結果的scheme",
 "data":"查詢結果"
 }
}

針對不同的Type，content等字段取值也有所有不同。

//type=survey/create
content={
 "query":"查詢sql語句",
 "sample": {
 "block_enabled":true,
 "record_enabled":true,
 "ratio":""
 },
}
process=[
 {
 "sub_query":"",
 "sub_query_status":"",
 "sub_query_detail":[
 "job_id":"",
 "job_status":"",
 "job_detail":[
 {
 "stage_id":"",
 "stage_status":"",
 "total_tasks":"",
 "succeeded_tasks":"",
 "failed_tasks":"",
 "start_time":"",
 "end_time":"",
 }
 ]
 ],
 }
]
//type=migrate/delete
content={
 "database":"",
 "tablename":"",
}
//type=migrate/redo
content={
 "relations":[
 {
 "database":"",
 "tablename":"",
 "interval":"",
 },
 ],
 "migrate":true,
 "speedup":true
}
process={
 "migrate":[
 {
 "database":"",
 "tablename":"",
 "interval":"",
 "ide_instance_id":"",
 }
 ],
 "speedup":[
 {
 "model":"",
 "interval":"",
 "type":"",
 "task_id":"",
 }
 ],
}
//type=model/delete
content={
 "model":""
}
//type=speedup/create
content={
 "model":"",
 "interval":"",
 "type":"",
 "queryGranularity":""
}
progress=[
 {
 "interval":"",
 "queryGranularity":"",
 "ide_instance_id":"",
 }
]

五. 數據搬遷和加速任務實現

OLAP引擎數據搬遷和加速操作都是以任務的形式運行在IDE平台上，調度方式包括定時調度和手動補數兩種類型。對於定時調度，OLAP引擎負責IDE任務及任務流的創建，IDE負責定時執行任務；對於手動補數，OLAP引擎負責對請求進行拆分為多個IDE補數任務，由IDE進行調度排隊及執行。

migrate和speedup為兩個java二進制程序，資源托管在IDE平台中。IDE平台支持創建任務/api/bigquery/ide/flow/create時，通過指定該資源名稱或者ID來使用它們，同時也支持對任務資源進行升級/api/bigquery/ide/task/upgrade。

migrate和speedup使用方式如下：

migrate database tablename [batch]
speedup model type queryGranularity [batch]
//參數描述：
//database、tablename和speedup、model、type是在創建IDE任務時指定的任務自定義參數param。在定時調度以及補數時，IDE負責將其作為參數傳遞的程序。
//batch為IDE內部調度過程中，傳遞給程序的參數,程序內部還需要通過batch獲取到當前執行的ide_instance_id。
//如果為補數任務，batch支持通過接口傳遞給IDE

關於batch的概念： 
在OLAP引擎中，數據是按照interval進行表示，但是在IDE任務中，是通過batch來進行標識，它們關系如下：

• batch=interval_end_time即batch為interval結束時間
• interval=batch-max(granularity,queryGranularity)/batch。 
  對於migrate任務，queryGranularity=0； 
  對於speedup任務，queryGranularity=granularity * n，默認n=1。

migrate任務流程如下：

1. 校驗待遷移源數據進行校驗：dataset數據庫中有該事實表或者維度表記錄？源Hive分區數據是否存在，並預計算分區內數據條目數。
2. 嘗試獲取該表的遷移分區的寫鎖。處於寫鎖狀態的分區，不允許並行寫，也不允許被加速任務讀取。鎖的值需要記錄當前鎖持有者的相關信息，包括當前鎖持有者的機器，進程號，服務類型。如果當前有另外一個服務占用寫鎖，那該任務將會直接失敗；如果因為當前有讀鎖，那么將會持續等待下去，最長等待時間為30分鍾(每次sleep 1分鍾，重試獲取30次)。
3. 在OLAP引擎Partition表中記錄該次遷移的描述信息，狀態標記為running。其中如果為維度表，在Partition中新增一條記錄；如果為事實表，直接在原有記錄上進行修改。
4. 如果為事實表，需要刪除原始實時表底層的HIVE分區以及底層HDFS數據。
5. 開始HDFS數據遷移，並且對遷移后的數據進行條目數校驗。
6. 將HDFS路徑關聯到OLAP引擎Hive Meta中。如果為事實表，通過add partition來將相應的HDFS路徑關聯到表中；如果為維度表，通過alert table來修改當前維度表的path路徑。
7. 遷移結束以后，更新分區表Partition中遷移狀態。
8. 釋放寫鎖
9. 收集數據遷移相關metric信息，完成遷移操作。

speedup任務流程如下：

1. 校驗當前batch是否為queryGranularity結束點，如果不是，選擇跳過。比如queryGranularity=1d，如果batch為2017071812就直接跳過，只處理batch=2017071900。
2. 獲取指定speedup分區的全局寫鎖；獲取所依賴的事實表、維度表指定分區的全局讀鎖
3. 校驗所依賴的事實表、維度表指定的分區數據是否存在，如果不存在，直接報錯；否則就獲取相應的版本信息。
4. 校驗當前拉寬后的scheme是否存在(存儲在speedup表的scheme字段)，如果沒有，進入scheme探測邏輯。 
   4.1 嘗試獲取指定speedup表的scheme探測全局鎖。 
   4.2 拿到全局鎖,進行scheme探測邏輯，生成scheme，並寫到speedup表中，釋放全局鎖。 
   4.3 未拿到全局鎖，等待1分鍾，再次檢查scheme是否存在，進入2.1步邏輯。 
   4.4 最長等待時間為30分鍾。
5. 在分區表Partition中記錄該次加速的描述信息，狀態標記為running。
6. 開始加速。
7. 遷移結束以后，更新分區表Partition中遷移狀態。
8. 通過zk進行事件通知，通知所有的worker有新的加速分區上線。
9. 釋放所依賴分區的全局讀鎖；釋放加速分區的全局寫鎖。
10. 收集數據遷移相關metric信息，完成遷移操作。

六. 查詢路由方案

1. 請求模塊間交互邏輯

針對百川，OLAP引擎提供指標查詢的接口為同步，而針對數據探測項目，是采用異步接口。請求模塊間流轉如下所示：

異步接口：

1. API層響應數據探測任務的創建操作，在HBase中記錄任務相關信息，並返回任務ID給業務端。
2. API層將任務轉發給Master層，由Master負責排隊等待，並將請求調度到指定Worker層進行處理。
3. 在任務運行過程中，Master層隨時會響應來自API層的任務Kill請求，Master會與任務運行Worker進行通信，從而將任務從Worker中殺死。
4. 任務計算過程中，Worker會將任務的中間狀態更新到HBase中，從而可以被API層查詢並返回給業務端。
5. 任務計算完成以后，Worker會在HBase/HDFS中寫入任務狀態和數據。同時通知Master層，任務執行結束。
6. API層通過查詢HBase/HDFS記錄信息來獲取任務的執行結果，並返回給業務端。

整個環節中，API層不會和Worker直接進行RPC通信。

同步接口：

1. API層響應百川的指標查詢請求，此時會創建一個任務ID，但是不會在HBase中記錄該Task的任何信息。
2. API層請求Master，根據任務相關信息，由Master進行負載均衡，流控等操作，並給出可用的后端Worker，並返回給API層。
3. API層同步請求后端Worker，等待Worker完成指標的計算，並返回計算結果給API層。期間Worker不會將狀態、數據落地到HBase和HDFS中。
4. Worker計算完成以后，需要通知Master層；
5. 在Worker計算過程中，Master層支持響應Kill操作來殺死指標查詢請求（僅僅用於運維管理）。

2. 模型數據路由

在OLAP引擎中，模型或者模型表是虛擬概念，其中不真正包含數據，對模型的查詢，需要通過一個策略轉換為對模型的加速表的查詢，這個策略即模型數據路由。

加速表是按照interval對模型進行加速，OLAP引擎核心路由也是基於對查詢所依賴的interval分區數據進行路由。OLAP引擎的Worker模塊會實時監聽每個加速表的interval分區上線以及上線操作，只有一個查詢所關注的所有interval分區都在線，該加速表才會提供查詢服務。

如果有一個查詢因為查詢指標和維度只能使用carbondata進行查詢，那么將會路由為carbondata加速表，否則默認都是使用druid加速。同時，如果指定的加速表有多個queryGranularity，系統需要自動選擇滿足查詢的最大的queryGranularity；比如查詢語句是查詢最近1月的聚合指標，那么優先使用queryGranularity=1月的加速表，而不使用queryGranularity=1天的加速表。

關於interval分區上線或上線： 
worker啟動時，會對partition表進行掃描，對每個模型的每張加速表，會在內存中構建bitmap，bitmap的大小結果如下： 
hashmap( 
2017年->bitmap(366天*24小時/queryGranularity小時)， 
2016年-> bitmap(366天*24小時/queryGranularity小時) 
) 
比如queryGranularity為1天的加速表，每年的bitmap大小就為366；如果為1小時的加速表，那么每年的bitmap大小就為366*24。 
// 
worker在運行過程中，會響應對分區的上線下線操作事件，比如/api/bigquery/datamanager/model/speedup/delete會向所有Worker通知指定interval的數據操作。 
在IDE加速任務完成以后，也會通過事件的方式通知所有Worker有新的Interval可以提供查詢服務。

七. 支持SQL類型

select count(度量) from 模型 group by window(小時/天), 維度1，維度2 where 過濾條件 
select count(case when 過濾條件 then 度量 else null) from 模型 group by window(小時/天), 維度1，維度2 where 過濾條件
//
select count(distinct 維度) from 模型 group by window(小時/天), 維度1，維度2 where 過濾條件 
select count(distinct case when 過濾條件 then 度量 else null) from 模型 group by window(小時/天), 維度1，維度2 where 過濾條件
//
select sum(度量) from 模型 group by window(小時/天),維度1，維度2 where 過濾條件 
select sum(case when 過濾條件 then 度量 else null) from 模型 group by window(小時/天),維度1，維度2 where 過濾條件 
//
select max(度量) from 模型 group by window(小時/天),維度1，維度2 where 過濾條件 
select max(case when 過濾條件 then 度量 else null) from 模型 group by window(小時/天),維度1，維度2 where 過濾條件 
//
select min(度量) from 模型 group by window(小時/天),維度1，維度2 where 過濾條件 
select min(case when 過濾條件 then 度量 else null) from 模型 group by window(小時/天),維度1，維度2 where 過濾條件 
// 
select metric組合 from 模型 group by window(小時/天),維度1，維度2 where 過濾條件
//
select 維度，度量 from 模型 where 過濾條件

支持SQL Union
度量值，維度值，過濾條件支持UDF轉換
過濾條件支持多值組合 and or組合
支持order by和limit num
支持子查詢
支持指標結果運算

簡單說：OLAP就是