OLAP（On-Line Analytical Processing，联机分析处理）是大数据场景中，数据价值探索与挖掘的重要环节。这个领域内，开源社区呈现百花齐放的现象，Elasticsearch、Druid、Clickhouse、Pinot、Kylin、Presto等，各自在业界都有着广泛的应用场景。实际使用过程中，通常会经历以下三个阶段：
业务初期，面临多种选择，如何做技术选型？这时场景较单一，需要解决的问题相对固定，这时简单比较下开源组件各自的特性，参考下业界的使用情况；再或者部署测试环境，模拟业务验证；通常都能够选取出其中一个组件，投入实际生产环境；
业务中期，随着数据需求的不断丰富变化，开源组件需要支撑的应用场景也越来越多，比如：多维统计查询、可视化、报表、监控报警等；本质上，不管是什么样的开源组件，还是为解决“某一类”场景问题设计实现的，这种“大而全”的一站式打包服务是完全不能够胜任的；随着时间推移，服务自身特性的局限与日益丰富的需求场景之间的矛盾愈演愈烈，解决方案也比较简单：尝试引入多个开源组件；
业务后期，大家会不约而同地处于这样的一个现状：生产环境中运行着多个开源组件，服务于业务场景中的多个需求；
综上所述，使用某一个组件，寄希望于它能够应对各种需求（“All In One”）的方式是不可行的，每种组件各有利弊，有的擅长检索，有的擅长统计；最好的方式是结合实际需求，选取若干个合适的组件，每个组件服务于自身最适用的业务场景。
既然是“最好的方式”，且需求已经得到解决，为什么仍然需要OLAP DSL？这里以常见的“多维指标统计”为例，从业务、工程两个视角进行说明。
业务视角
- 多个开源组件并存的场景下，业务指标会分散至不同的组件中，开发/分析人员需要明确知晓指标与组件的对应关系；
- 不同的组件提供不同的API，开发/分析人员需要掌握多种组件的领域概念及相应API使用方法，且不断来回切换；
- 指标可能需要依赖多个组件的复合查询进行计算，开发/分析人员需要清晰了解数据设计、存储信息，且工程能力要求较高；
- 指标的计算实现代码需要在可视化、报表、监控、数据接口等服务中重复编写，如果规则变化，很难做到全覆盖更新，保证数据一致性；
工程视角
如前所述，开发/分析人员需要掌握不同类型的API，且业务系统与这些API紧密集成，已有组件版本升级或者引入新组件时，都会遇到比较大的阻力，灵活性较差；
OLAP DSL需要解决哪些问题？
- 开发/分析人员只需要面对一种统一的API，不需要直接面对多种类型的组件API；
- 开发/分析人员只需要输入查询条件，即可获取计算结果，不需要关心指标数据的计算过程；
OLAP DSL需要提供哪些能力？
- 获取查询系统中有哪些主题；
- 主题下有哪些维度，每个维度下有哪些取值；
- 主题下有哪些指标；
- 可按主题名称、指标名称、时间范围、时间粒度、维度过滤、维度分组等条件进行多维度指标统计查询；
OLAP DSL实现引擎需要负责构建指标计算规则的逻辑/物理执行计划，以及多个组件之间的数据交互。
