前言
适用于 即席查询 场景的开源查询引擎有很多，如：Elasticsearch、Druid、Presto、ClickHouse等；每种系统各有利弊，有的擅长检索，有的擅长统计；实践证明，All In One 是行不通的，最好的方式是选取若干个（考虑运维成本，建议 1 ~ 3 个），每个都对应着自身最具优势的场景。
大多数的技术分享会从系统架构、功能扩展或性能优化角度进行讨论，本文不涉及这些内容。本文以 指标多维统计查询 为例，讨论多个查询引擎混合应用场景下的问题思考及相应的解决方案。
指标多维统计查询
定义
什么是 指标多维统计查询 ？按指定的条件查询指标值（一个或多个），条件包括：
- 时间范围（必选）
- 时间粒度（必选）
- 维度过滤条件（可选，类似SQL中的 Where）
- 维度分组条件（可选，类似SQL中的 GroupBy）
- 维度或指标排序条件（可选，类似SQL中的 OrderBy）
注意，指标多维统计查询 涉及4个关键元素：时间范围、时间粒度、维度及 指标（详情见后）。
示例
- 查询微博视频最近7天范围内，每天的PSR1（秒开率）是多少？
- 查询微博视频最近1个月内，每天的移动4G场景下各个运营商的卡顿率是多少？
查询引擎混合应用
多个查询引擎混合应用的场景下，会遇到哪些问题呢？我们主要从 工程角度 与 业务角度 来看下。
工程角度
每个查询引擎都有自己特有的API（也包含 SQL，虽然开源社区大多致力于提供标准的SQL支持，但实际落地情况并不尽如人意），指标查询需要 直接连接 查询引擎并使用相应的API进行指标值计算，开发人员和分析人员需要在多个不同的API之间来回切换，学习及维护成本较高；查询引擎版本升级或引入新的引擎会增加这些成本，系统整体的灵活性及可扩展性较差。
业务角度
多个查询引擎混合使用的场景下，业务指标会分散至不同的引擎中，会遇到以下问题（复杂度依次增加）：
- 某个业务指标的查询需要使用相应的查询引擎；
- 某个业务指标的查询需要使用相应的查询引擎，且计算规则较为复杂；
- 某个业务指标需要依赖多个查询引擎的联合查询；
- 某个业务指标需要依赖多个查询引擎的联合查询，且计算规则较为复杂；
可以看出，我们需要维护指标与查询引擎的 对应关系，以及指标的 计算规则，实际中很大程度上依赖于 文档 （Wiki）。数据应用服务中常见的数据可视化、报表、数据接口，这些服务的实现模块均需要直接耦合这些对应关系及计算规则，而且需要重复多次。如果某个指标的对应关系或计算规则发生变化，相应的文档及相关的服务 必须 全部更新，才能保证数据一致性。
指标众多的场景下，上述提及的成本及复杂度会大幅增加，有过类似服务经验的同学应该深有体会。
补充
对应关系 与 计算规则 可能比较抽象，举一个具体的例子。假设 MySQL 数据库某数据表 DEFAULT.TEST_TABLE 的中有 2 列：A 和 B，指标 M 的值可以通过SQL语句查询得出，如：
SELECT
A / B AS M
FROM
DEFAULT.TEST_TABLE
数据应用服务（数据可视化、报表或数据接口）查询这个指标数据时，需要知道去什么地方查询，以及具体如何查询；上述示例需要通过远程方式连接MySQL，连接时使用到的协议类型（MySQL）、IP地址、端口号等信息就是 对应关系；查询时需要使用的SQL语句就是 计算规则。
指标库
针对指标众多，指标计算规则及相关信息不易维护的问题，我们提出 指标库 用于规范化指标管理。什么是 指标库？
对于某一个指标而言，可以从不同的时间范围、时间粒度及维度视角进行统计查询。换句话说，对于某一个指标而言，我们需要知道可以从哪些时间范围、哪些时间粒度、哪些维度视角进行统计查询，以及指标的计算规则是什么。一般情况下，同属于一个 业务 的指标会共享相同的时间范围、时间粒度及维度项，我们将类似这样的业务统称为 主题。每一个主题对应着一个业务或业务中的某个细分场景，如：
- 移动端视频上传性能
- PC端视频上传性能
- 移动端视频劫持性能
- CDN服务质量分析
每一个 主题 需要包含以下信息：
-
主题名称
顾名思义，业务名称或业务中的某个细分场景名称。
-
时间范围
可支持的数据查询时间范围（[起始时间，结束时间]）；相当于数据的存储周期，过期数据会被清除。
-
时间粒度
可支持的数据查询最小时间粒度，相当于数据的聚合程度，如：1 秒，5 分钟，1 小时 或 1 天 之类的。
假设时间粒度是 5 分钟，表示最小可以支持 每5分钟 一个数据点的查询请求，同时也可以支持 每1小时 或 每1天 之类的查询请求，但不可以支持 每1秒 或 每1分钟 之类的查询请求。
-
维度
可以支持的数据查询视角，通常会有多个，如：省份、运营商、设备 之类的。以 运营商 为例，表示可以查看指定运营商或各个运营商的数据。
-
维度值
维度可以支持的查询值，通常会有多个。以维度 运营商 为例，维度值会有移动、联通、电信之类的。
-
指标
可以支持查询的指标，通常会有多个，如：秒开率、卡顿率 之类的。
-
指标计算规则
某个指标的计算公式。以指标 卡顿率 为例，计算公式：卡顿次数 / 总次数。
若干个 主题 的 集合，我们称之为 指标库。指标库 的内容可以按照上述描述的格式记录到专用的文档中，统一更新发版，用于公司内部数据共享。
查询语言
数据应用服务（数据可视化、报表、数据接口）的核心逻辑是查询指标数据，并不是使用 对应关系 和 计算规则 完成指标计算，且存在重复直接耦合的问题。为此，我们在 指标库 的基础之上，针对 指标多维统计查询 场景设计了一种领域特定语言（DSL）。也就是说，数据应用服务查询指标数据时直接使用统一的查询语言，不再存在直接耦合 对应关系 和 计算规则 的情况，后续 对应关系（查询引擎升级或迁移）或 计算规则 的 变更 对于数据应用服务也是 透明 的。
查询语言是基于 JSON 实现的。
getTopics
查询指标库中有哪些主题（多个）。
{
"type": "getTopics"
}
getDimentions
查询指定主题中有哪些维度项（多个）。
{
"type": "getDimentions",
"topic": "..."
}
其中，topic 为主题名称。
getDimentionValues
查询指定主题、指定维度中有哪些维度值（多个）。
{
"type": "getDimentionValues",
"topic": "...",
"dimension": "..."
}
其中，topic 用于指定主题名称， dimension 用于指定维度名称。
getMetrics
查询指定主题中有哪些指标项（多个）。
{
"type": "getMetrics",
"topic": "..."
}
其中，topic 用于指定主题名称。
query
查询（指标数据），是查询语言中最为复杂的类型。
{
"type": "query",
"topic": "...",
"interval": {...},
"granularity": {...},
"metric": "...",
"where": {...},
"groups": [...],
"having": {...},
"orders": [...],
"limit": ...
}
topic
主题名称（必填项）。
interval
时间范围（必填项）。
{
"start": "...",
"end": "..."
}
其中，start/end 均为闭区间，格式：yyyy-MM-dd HH:mm:ss。
granularity
时间粒度，默认为无穷大。
{
"data": ...,
"unit": "..."
}
其中，data 为数值（整型），unit 为单位，如：s(秒)、m（分钟）、h（小时）、d（天）、w（周）、M（月）、y（年）。
metric
指标名称（必填项）。
where
维度过滤，对应于SQL语句中的 Where，默认为空，支持比较表达式与逻辑表达式。
比较表达式
比较表达式用于表示数值比较、包含或不包含，以及正则匹配。
eq/ne/gt/lt/ge/le
{
"operator": "...",
"name": "...",
"value": "..."
}
其中，operator 为 eq（等于）、ne（不等于）、gt（大于）、lt（小于）、ge（大于或等于）或 le（小于或等于），name 为维度名称，value 为维度值。
in
{
"operator": "in",
"name": "...",
"values": [...]
}
其中，operator 为 in（包含），name 为维度名称，values 为维度值列表（JSON数组）。
regex
{
"operator": "regex",
"name": "...",
"pattern": "..."
}
其中，operator 为 regex（正则匹配），name 为维度名称，pattern 为正则表达式。
逻辑表达式
逻辑表达式用于表示一个或多个表达式之间的 与（And）、或（Or）、非（Not）关系。
and
{
"operator": "and",
"filters": [...]
}
其中，operator 为 and（与），filters 为两个或两个以上的比较表达式或逻辑表达式。
or
{
"operator": "or",
"filters": [...]
}
其中，operator 为 or（或），filters 为两个或两个以上的比较表达式或逻辑表达式。
not
{
"operator": "not",
"filter": {...}
}
其中，operator 为 not（非），filter 为一个比较表达式或逻辑表达式。
groups
维度分组，类似于SQL语句中的 GroupBy，默认为空，可以指定多个维度项（JSON数组）。
[
"...",
...
]
having
分组过滤，类似于SQL语句中的 Having，默认为空，语法同 where。分组过滤表达式中的 name 可以是维度名称，也可以是指标名称。
orders
排序，类似于SQL语句中的 OrderBy，默认为空，可以指定多个排序项。
[
{
"name": "...",
"sort": "..."
},
...
]
其中，name 为维度名称或指标名称，sort 为 asc（升序）或 desc（降序）。
limit
限制结果集行数，类似于SQL语句中的 Limit，默认为空。
示例参考
查询指标
主题：CDN服务质量分析；
时间范围：["2020-03-16 00:00:00", "2020-03-16 23:59:59"];
时间粒度：1小时；
指标：下载速度（download_speed_avg）；
维度过滤：域名（domain）包含有字符串“weibo”；
维度分组：运营商（isp）；
分组过滤：下载速度（download_speed_avg）大于2000 Kb/s；
排序：下载速度降序（download_speed_avg）；
结果集：最多100行；
查询语言
{
"type": "query",
"topic": "CDN服务质量分析",
"interval": {
"start": "2020-03-16 00:00:00",
"end": "2020-03-16 23:59:59"
},
"granularity": {
"data": 1,
"unit": "h"
},
"metric": "download_speed_avg",
"where": {
"operator": "regex",
"name": "domain",
"pattern": "^.*weibo.*$"
},
"groups": [
"isp"
],
"having": {
"operator": "gt",
"name": "download_speed_avg",
"value": 2000
},
"orders": [
{
"name": "download_speed_avg",
"sort": "desc"
}
],
"limit": 100
}
查询代理
查询语言只是一种描述性的协议规范，并不能完成实际的查询过程。我们需要一种 服务，可以接收并执行这种查询语言，过程如下：
- 解析查询语言，获取需要查询的指标；
- 查找指标对应的查询引擎及计算规则；
- 使用查询语言设定的查询条件，连接查询引擎，根据计算规则调用API，执行指标的实际计算过程；
- 返回结果。
这就是我们即将要重点介绍的 查询代理。
客户端
AnalysisQl 本质是一套Java API，需要嵌入到Web或RPC容器中使用。
DefaultConnector connector = new DefaultConnector();
...
AnalysisQl analysisQl = new AnalysisQl(connector);
AnalysisQl 的实现是线程安全的，一个Web或RPC容器进程中创建一个 AnalysisQl 实例即可，实例创建完成即表示查询代理服务启动完成。
查询语言的执行都需要通过 AnalysisQl.request 来完成，如下：
Response response = analysisQl.request(dsl);
相当于，AnalysisQl 是查询代理的客户端。
代码参考
https://github.com/weibodip/analysisql/blob/master/core/src/main/java/com/weibo/dip/analysisql/AnalysisQl.java
解析器
查询语言是基于 JSON 实现的，不方便直接在Java语言中使用，需要将其 解析 成相应的 JavaBean，如下：
Parser parser = new Parser(connector);
Request request = parser.parse(dsl);
Parser 是解析器，Request 是查询类型的顶层抽象类，查询语言中的每一种查询类型都有其对应的实现类：
- GetTopicsRequest（getTopics）
- GetDimensionsRequest（getDimentions）
- GetDimensionValuesRequest（getDimentionValues）
- GetMetricsRequest（getMetrics）
- QueryRequest（query）
代码参考
https://github.com/weibodip/analysisql/blob/master/core/src/main/java/com/weibo/dip/analysisql/dsl/request/GetTopicsRequest.java
https://github.com/weibodip/analysisql/blob/master/core/src/main/java/com/weibo/dip/analysisql/dsl/request/GetDimensionsRequest.java
https://github.com/weibodip/analysisql/blob/master/core/src/main/java/com/weibo/dip/analysisql/dsl/request/GetDimensionValuesRequest.java
https://github.com/weibodip/analysisql/blob/master/core/src/main/java/com/weibo/dip/analysisql/dsl/request/GetMetricsRequest.java
https://github.com/weibodip/analysisql/blob/master/core/src/main/java/com/weibo/dip/analysisql/dsl/request/QueryRequest.java
其中，QueryRequest 关于 Filter（过滤）的实现较为有意思，有兴趣的同学可以参考 https://github.com/weibodip/analysisql/tree/master/core/src/main/java/com/weibo/dip/analysisql/dsl/filter。
连接器
连接器用于定义查询代理支持的接口协议，对应着查询语言的查询类型：
public interface Connector {
Response getTopics(GetTopicsRequest request);
Response getDimensions(GetDimensionsRequest request);
Response getDimensionValues(GetDimensionValuesRequest request);
Response getMetrics(GetMetricsRequest request);
Response query(QueryRequest request);
}
为什么需要设计连接器？
理论上，查询语言是标准的，但查询代理的实现可以是多种多样的。类似于 Java JDBC，统一抽象数据库的操作接口，连接数据库时需要使用相应类型的驱动。我们使用连接器，用于桥接查询客户端与查询代理的具体实现，保证系统的可扩展性；同时提供系统默认的连接器 DefaultConnector，满足大部分场景的使用需求。
每一种查询类型应调用连接器的哪一个接口，是通过 Request.type 判断的，如下：
switch (request.getType()) {
case Request.GET_TOPICS:
return connector.getTopics((GetTopicsRequest) request);
case Request.GET_DIMENSIONS:
return connector.getDimensions((GetDimensionsRequest) request);
case Request.GET_DIMENSION_VALUES:
return connector.getDimensionValues((GetDimensionValuesRequest) request);
case Request.GET_METRICS:
return connector.getMetrics((GetMetricsRequest) request);
case Request.QUERY:
return connector.query((QueryRequest) request);
default:
throw new UnsupportedOperationException();
}
代码参考
https://github.com/weibodip/analysisql/blob/master/core/src/main/java/com/weibo/dip/analysisql/connector/Connector.java
https://github.com/weibodip/analysisql/blob/master/view/src/main/java/com/weibo/dip/analysis/view/DefaultConnector.java
数据视图
数据视图 View 是一个抽象类，对应于指标库中的主题，每一个主题均需要提供相应的数据视图实现类，并于查询代理初始化之前注册到连接器中。实现时需要设置以下信息：
protected String topic;
protected List dimensions;
protected List metrics;
protected List tables;
protected PolicyRouter router;
topic：主题名称；
dimensions：维度项，每一个 Dimension 表示一个维度；
metrics：指标项，每一个 Metric 表示一个维度；
tables：数据表，每一个 Table 表示一张数据表，详细见后；
router：策略路由，详情见后；
以 CDN服务质量分析 为例，数据视图实现类如下：
public class CdnServiceQualityView extends DefaultView {
/** Initialize a instance. */
public CdnServiceQualityView() {
super(
"CDN服务质量分析", // 主题名称
...);
addDimension("country", "国家"); // 添加维度项
addDimension("business", "业务");
addDimension("city", "城市");
addMetric("error_num", "错误量（万）"); // 添加指标项
addMetric("request_num", "访问量（亿）");
addMetric("download_time_avg", "下载时间（s）");
addTable(new CdnServiceQualityTable(this)); // 添加数据表
addTable(new CdnNetflowBillingTable(this));
}
}
注：DefaultView 是 View 的默认实现类。
CdnServiceQualityView 构建函数中直接完成主题、维度项、指标项及数据表的设置，也可以在 CdnServiceQualityView 实例创建完成之后，通过相应的实例方法（addDimension/addMetric/addTable）设置。
然后，注册到连接器：
connector.register(new CdnServiceQualityView());
连接器中保存着所有已注册的数据主题：
protected Map metadatas = new HashMap<>();
public void register(Metadata metadata) {
metadatas.put(metadata.getTopic(), metadata);
}
注：Metadata 是 View 的抽象父类。
连接器中多数协议方法的实现本质就是根据主题名称（topic）查找到相应的数据主题实例，调用其实例方法完成查询请求。
为什么需要设计数据视图？
假设数据表 A 以 5分钟 的时间粒度，存储着 m 个维度、n 个指标的数据，每5分钟的数据量（即：数据行数）的最大值理论上取决于各个维度的维度值数目；如果 m 个维度的维度值数目依次为 N1、N2、...、Nm，那么每5分钟数据量为 N1 * N2 * ... * Nm（即多个维度的维度值数目的笛卡尔乘积）；每日的数据最为 288 * N1 * N2 * ... * Nm。
我们列举几个常用的查询：
- 查询最近 1小时内，以 5分钟 为时间粒度，某个维度或某几个维度组合的指标数据；
- 查询最近 7天内，以 1小时 为时间粒度，某个维度或某几个维度组合的指标数据；
- 查询最近 1月内，以 1天 为时间粒度，某个维度或某几个维度组合的指标数据；
可以看出，数据表 A 是可以完全支撑上述查询需求的。那么，问题在于哪里？问题在于查询的 响应时间，响应时间很大程度上取决于查询时需要扫描的 数据量。在我们的场景中，很多业务按数据表 A 的方式存储数据，每天的数据量会达到数百亿级别，较长时间范围内（跨天/跨周/跨月）的指标数据查询，响应是比较缓慢的。
我们经常使用的优化方案：
-
创建数据表 B，以 5分钟 为时间粒度，存储数据表 A 中部分维度的指标数据；
维度数目的减少，表示着数据表 B 相对于 数据表 A 的数据是减少的。以上述 查询1 为例，如果需要查询的维度正好存在于数据表 B，那么使用数据表 B 相比于 数据表 A，需要扫描的数据量更少，响应时间更快。
-
创建数据表 C，以 1天 为时间粒度，存储数据表 A 聚合之合的指标数据；
时间粒度的增大，表示着数据表 C 相对于 数据表 A 的数据量是减少的。以上述 查询3 为例，使用数据表 C 相比于 数据表 A，需要扫描的数据量更少，响应时间更快。
扩展一下思路：可以根据实际的业务场景，在基础数据表（如:数据表A）之上，有效组合不同的时间粒度、不同的维度组合额外创建出若干张数据表，用于优化查询的响应时间。
也就是说，指标库中的某一个主题可以对应着多张数据表，这些数据表可以有不同的时间粒度、不同的维度组合，甚至不同的指标项，存储于不同的查询引擎，或者被多个主题所共享。这样的 自由组合 从工程角度看是非常灵活的；但从数据服务角度看，会带来2个问题：
- 多张数据表之间的信息是 混乱 的，缺乏一致的数据口径；
- 查询指标数据时应该使用哪张数据表？
因此，我们设计 数据视图，显示声明包含的维度、指标信息，以及相关的数据表（参考数据视图定义）。数据视图 如何解决查询指标时使用的数据表问题，参见后文。
代码参考
https://github.com/weibodip/analysisql/blob/master/view/src/main/java/com/weibo/dip/analysis/view/View.java
数据表
如前文所述，同一个主题（数据视图）中可以包含多张数据表，且这些数据表之间可能会有不同的时间粒度、维度项、指标项等，数据表（Table）的设计需要能够明确显示声明这些信息。
protected String topic;
protected List dimensions;
protected List metrics;
protected Map calculators;
private Granularity granularity;
private int period;
private int delay;
topic：数据表属于的主题名称；
dimensions：数据表支持的维度项；
metrics：数据表支持的指标项；
calculators：数据表支持的指标项对应的 指标计算器 （参见后文）；
granularity：数据表存储数据的时间粒度；
period：数据表存储数据的周期，也就是数据表可以查询的时间范围；
delay：数据表数据的延迟时间，也就是说相对于当前时间，这个延迟范围内的数据是查询不到的；
以 CDN服务质量分析 的数据表为例，数据表实现类如下：
public class CdnServiceQualityTable extends Table {
public CdnServiceQualityTable(View view) {
super(view, "clickhouse-cdn-all_cdn_staging", new Granularity(5, Unit.m), 103680, 36); // 设置时间粒度、存储周期及延迟时间
addDimension("country"); // 声明支持的维度项
addDimension("business");
addDimension("city");
addCalculator("error_num", new HubbleClickHouseCalculator("analysisql/cdn/cdn-error_num.sql")); // 声明支持的指标项的同时，提供指标相应的指标计算器
addCalculator(
"request_num", new HubbleClickHouseCalculator("analysisql/cdn/cdn-request_num.sql"));
addCalculator(
"download_time_avg",
new HubbleClickHouseCalculator("analysisql/cdn/cdn-download_time_avg.sql"));
}
}
代码参考
https://github.com/weibodip/analysisql/blob/master/view/src/main/java/com/weibo/dip/analysis/view/Table.java
策略路由
数据视图（View）中包含多张数据表（Table），查询指标数据时，我们需要根据一定的 规则 从这些数据表中选取出 查询代价最小（响应时间最快） 的数据表用于指标计算，规则 的具体实现就是 策略路由。
过滤
过滤就是 排除 不能支持查询的数据表，考虑以下4个因素：
-
指标
数据表必须包含查询的指标项；
-
维度
数据表必须包含查询涉及的维度项（多个）；
-
时间粒度
数据表数据存储的时间粒度必须小于或等于查询指定的时间粒度，否则无法聚合数据；
-
时间范围
数据表在查询指定的时间范围内存在数据（根据数据表存储周期及延迟时间计算）；
满足上述4个条件的数据表即可以进入下一阶段。
排序
排序规则：
- 数据表的时间粒度越大，查询代价越小；
- 数据表的维度数目越少，查询代价越小；
经过过滤、排序之后，位于第1个位置的数据表即是 最优 的数据表。目前，策略路由（PolicyRouter）的实现是直接内置于数据视图，尚不支持自定义扩展。
代码参考
https://github.com/weibodip/analysisql/blob/master/view/src/main/java/com/weibo/dip/analysis/view/PolicyRouter.java
指标计算器
指标计算器（MetricCalculator）用于根据查询请求完成指标的计算。也就是说，前文中提及的 对应关系 和 计算规则 均包含在指标计算器中，指标计算器需要连接查询引擎，使用相应的API或SQL，根据计算规则完成指标的计算过程，并返回结果。数据表的各个指标均需要提供相应的指标计算器实现器，并注册到数据表中。
public interface MetricCalculator {
List calculate(QueryRequest request) throws Exception;
}
考虑到常用的查询引擎（如：MySQL、Presto、ClickHouse）大多支持以 SQL 的方式查询数据，为加速指标计算器的实现效率，系统支持以 SQL模板 的方式定义指标的计算规则，并提供多种 模板引擎， 可将 查询条件 与 SQL模板 整合转换特定查询引擎的SQL语句（不同查询引擎的SQL实现存在一定差异）。
以 ClickHouse 为例，某指标计算规则可以这样定义：
SELECT
$COLUMNS, SUM(netflow) * 8 / 1000 / 1000 / 1000 AS $METRIC
FROM
cdn.edge_scheduler_bandwith
WHERE
$WHERE
GROUP BY
$GROUPS
HAVING
$HAVING
AND isNaN($METRIC) == 0
AND isInfinite($METRIC) == 0
AND $METRIC >= 0.0
ORDER BY
$ORDERS
LIMIT
$LIMIT
$COLUMNS、$WHERE、$GROUPBY、$HAVING、$ORDERBY、$LIMIT 均是 模板引擎 支持的自定义变量（不同的模板引擎支持的变量种类存在一定差异）。模板引擎 会将查询语言中的过滤表达式、维度分组、分组过滤、排序及结果集行数转换为这些自定义变更对应的值，并输出完整的SQL语句。
指标计算器直接使用转换之后的SQL语句，连接查询引擎查询数据即可。
综上所述，查询代理核心工作流程如下：
- 解析查询语言；
- 使用主题名称查找数据视图；
- 使用策略路由选取最优数据表；
- 使用指标名称查找最优数据表的指标计算器；
- 计算指标并返回结果；
数据应用服务仅需要知道查询代理服务地址（域名）、端口号，使用查询语言查询需要的指标数据即可。
结语
本文介绍的指标库、查询语言（DSL）、查询代理是我们团队自主研发的OLAP服务，在微博视频性能数据分析中取得很好地应用效果。通过技术优化的方式，在有限的计算资源范围内得到不错的性能表现，大幅降低数据接口、可视化及监控服务的开发成本。 同时，我们团队也在准备项目开源（https://github.com/weibodip/analysisql ）的准备工作，有兴趣的同学可关注交流。
你可能感兴趣的:(微博大数据即席查询（OLAP）引擎实践)