研发背景

今天随着移动互联网、物联网、大数据、AI等技术的快速发展，数据已成为所有这些技术背后最重要，也是最具价值的“资产”，同时数据也是每一个商业决策的基石，越来越多的企业选择数字化转型，但数据驱动增长然充满挑战，企业数据孤岛严重、数据一致性难以保证、数据资产沉淀数据分散难以共用、数据分析项目上线经历数月，报表查询响应慢难以应对瞬息万变的市场环境，成本问题在数据量呈指数增长的前提下难以控制，因此在大数据的背景下，如何从海量的超大规模数据中快速获取有价值的信息，已经成为新时代的挑战。

​ Hadoop诞生以来，大数据的存储和批处理问题均得到了妥善解决，而如何高速地分析数据也就成为了下一个挑战。于是各式各样的“SQL on Hadoop”技术应运而生，其中以Hive为代表，Impala、Presto、Phoenix、Drill、SparkSQL、FlinkSQL等紧随其后。它们的主要技术是“大规模并行处理”（Massive Parallel Processing，MPP）和“列式存储”（Columnar Storage）。大规模并行处理可以调动多台机器一起进行并行计算，用线性增加的资源来换取计算时间的线性下降。列式存储则将记录按列存放，这样做不仅可以在访问时只读取需要的列，还可以利用存储设备擅长连续读取的特点，大大提高读取的速率。这两项关键技术使得Hadoop上的SQL查询速度从小时提高到了分钟级。

​ 然而分钟级别的查询响应仍然离交互式分析的现实需求还很远，市面上主流的开源OLAP引擎目前还没有一个系统能够满足各种场景的查询需求。其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。

仔细思考大数据OLAP，可以注意到两个事实。

大数据查询要的一般是统计结果，是多条记录经过聚合函数计算后的统计值。原始的记录则不是必需的，或者访问频率和概率都极低。

聚合是按维度进行的，由于业务范围和分析需求是有限的，有意义的维度聚合组合也是相对有限的，一般不会随着数据的膨胀而增长。

​ 基于以上两点，我们可以得到一个新的思路——“预计算”。应尽量多地预先计算聚合结果，在查询时刻应尽量使用预算的结果得出查询结果，从而避免直接扫描可能无限增长的原始记录，预计算系统是在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。

​ Apache Kylin是一个开源的、分布式的分析型数据仓库，提供Hadoop/Spark/Flink 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，通过预计算它能在亚秒内查询巨大的表，其中的关键就是要打破查询时间随着数据量成线性增长的这个规律。

​ BI（Business Intelligence），即商务智能，指用现代数据仓库技术、在线分析技术、数据挖掘和数据展现技术进行数据分析以实现商业价值，随着业务数据的规模增长，传统数据仓库不堪重负，数据的存储和批量处理成了瓶颈，查询分析速度无法满足日益增长的数据需求，传统关系型多维分析ROLAP引擎遇到极大挑，越来越多的企业引入大数据平台架构。

​ BI大数据分析平台致力于帮助用户快速在业务场景中应用大数据，助力业务发展和产业升级，让数据更高效地驱动生产力。因此必须集成整合Kylin实现赋能基于大数据Hadoop 生态 MOLAP(Kylin)及 HOLAP （多引擎）的查询分析，实现支持识别、管理和优化最有价值数据、提升整合底层复杂数据源的能力，通过数据服务将复杂的数据映射为业务语言，统一业务口径。采用预计算技术可打破查询时间随数据量线性增长的现状，提供稳定高效的查询性能。

研发目标

​ BI平台无缝集成Apache Kylin，托管Kylin用户、权限管理统一的安全认证，统一界面样式、操作流程，并对一些功能进行扩展改造以适配BI系统，整合SparkSQL、FlinkSQL、Presto等多种引擎结合起来实现智能路由，充分发挥每种引擎的长处优势，赋能用户极速数据分析体验，形成统一、一站式的大数据OLAP解决方案。

数据立方体构建引擎（Cube Build Engine）：当前底层数据计算引擎支持、MapReduce、Spark、Flink等。

Rest Server：当前kylin采用的REST API、JDBC、ODBC接口提供web服务。

查询引擎（Query Engine）：Rest Server接收查询请求后，解析sql语句，生成执行计划，然后转发查询请求到Hbase中，最后将结果返回给 Rest Server。

存储引擎：Kylin默认使用分布式、面向列的开源数据库Hbase作为存储库引擎。

设计架构

附注1

1. Mondrian为一个OLAP引擎，而且是一个ROLAP引擎，实现了以下规范：
2. MDX(多维查询语言，相当于数据库的SQL)
3. XMLA(通过SOAP使用OLAP)
4. olap4j(Java API规范，相当于JDBC关系数据库)

附注1：

1. 数据应用，包括智能报告、支持生成SQL或多维分析查询MDX语句组件、托拉拽自助式分析可视化组件等
2. Mondrian Schema，数据多维分析模型
3. Mondrian引擎，根据Schema生成标准SQL
4. 目标数据源，包括关系型数据源、非关系型数据源、企业数据仓库

功能架构设计

附注1：

1. 存储引擎，Kylin默认使用分布式、面向列的开源数据库Hbase作为存储库引擎，基于Apache Kylin插件架构实现数据库存储接入。
2. Presto，分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。

用户/权限

​ Kylin的Web模块使用Spring框架构建，在安全实现上选择了Spring Security。Spring Security是Spring项目组中用来提供安全认证服务的框架，它广泛支持各种身份验证模式，这些验证模型大多由第三方提供， Spring Security也提供了自己的一套验证功能。Kylin提供了三种用户验证方式“testing”、“ldap”和“saml”，依次为：自定义验证、LDAP验证和单点登录验证。

​ BI平台已实现一套成熟且完善的用户权限控制体系，为了便于系统的安全管理需要将Kylin用户权限管理和BI平台用户管理打通，可以利用现成的机制对Kylin的访问、资源的访问控制、修改做保护性的限制，使得大数据下的交互式报表分析成为可能。

数据模型

​ BI数据主题基于数据源元数据信息创建数据模型，支持简单可拖拉拽、灵活快速的方式实现可视化数据建模，需打通BI数据建模与Kylin数据建模功能，将BI数据模型适配至Kylin数据模型，支持事实表、维度、度量定义。

​ 每次Cube构建都会从数据源中批量读取数据，而对于大多数业务场景来说，数据源中的数据处于不断增长的状态，为了支持Cube中的数据能够不断地得到更新，且无需重复地为已经处理过的历史数据构建Cube，Cube支持增量构建，每个Cube都关联着一个数据模型Model，增量构建Cube需要指定分割时间列。

​ 对于维度表可选择配置是否将其以快照(Snapshot)形式存储到内存中以供查询。当维表小于300M时推荐启用，可以简化Cube计算提高效率。

CUBE配置

Cube功能改造：

1. 页面，布局、样式统一、中文显示

2. 用户权限，统一安全认证

3. Cube管理查询

4. 构建引擎，计算引擎默认选择Flink作为构建引擎

Cube运行监控

​ Apache Kylin通过日志和报警对任务进行监控、了解整体的运行情况，Kylin支持显示每个构建任务的进度条和构建状态，并可以展开明细，列出任务的每一步详细信息，数据模型下总Cube数，及空间占用。

1. 状态

   禁用(Disabled) 只有定义，没有构建数据

   错误(ERROR) 报错并停止后续执行

   准备(Ready) 构建完成可以提供查询服务。

2. 执行控制

   恢复(Resume) 在上次错误位置恢复执行

   放弃(Discard) 如要修改Cube或重新开始构建，可以放弃此次构建。

   构建(Build) 全量构建，增量构建采用

   刷新(Refresh) 对相应分区(Segment)历史数据进行重建

   合并(Merge) 合分区(Segment)，提高查询性能

数据查询

​ Cube构建好以后，状态变为“READY”，就可以进行查询，查询语言为标准SQL SELECT语句。

​ 只有当查询的模式跟Cube定义相匹配的时候，Kylin才能够使用Cube的数据来完成查询，“Group by”的列和“Where”条件里的列，必须是维度中定义的列，而SQL中的度量应跟Cube中定的义的度量一致。

​ Kylin提供了灵活的前端连接方式，包括Rest API、JDBC和ODBC。用户可以根据需要查询访问。

存储引擎

​ 基于Apache Kylin较强可伸缩性的插件架构实现数据库存储接入。

​ Kylin旨在减少Hadoop在10亿及百亿规模以上数据级别的情况下的查询延迟，目前底层数据存储基于HBase，具有较强的可伸缩性。插件架构旨在使 Kylin 在计算框架，数据源和cube 存储方面具有可扩展性。从 v1 开始，Kylin 与作为计算框架的 Hadoop MapReduce，作为数据源的 Hive，作为存储的 HBase紧密结合。