一站式大数据解决方案分析与设计实践

本文主要是介绍一站式大数据解决方案分析与设计实践 | BI无缝整合Apache Kylin，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

点击上方蓝色字体，选择“设为星标”

回复”资源“获取更多资源

本文已收录于Github仓库：《大数据成神之路》

地址：https://github.com/wangzhiwubigdata/God-Of-BigData

研发背景

今天随着移动互联网、物联网、大数据、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作为存储库引擎。

设计架构

附注

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

附注

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

功能架构设计

附注：

存储引擎，Kylin默认使用分布式、面向列的开源数据库Hbase作为存储库引擎，基于Apache Kylin插件架构实现数据库存储接入。
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功能改造：

页面，布局、样式统一、中文显示
用户权限，统一安全认证
Cube管理查询
构建引擎，计算引擎默认选择Flink作为构建引擎

Cube运行监控

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

状态
禁用(Disabled) 只有定义，没有构建数据
错误(ERROR) 报错并停止后续执行
准备(Ready) 构建完成可以提供查询服务。
执行控制
恢复(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紧密结合。