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 实现引擎需要负责构建指标计算规则的逻辑 / 物理执行计划, 以及多个组件之间的数据交互.
来源: https://www.cnblogs.com/yurunmiao/p/11584036.html