OLAP的历史与基本概念
OLAP全称为在线联机分析应用，是一种对于多维数据分析查询的解决方案。典型的OLAP应用场景包括销售、市场、管理等商务报表，预算决算，经济报表等等。
最早的OLAP查询工具是发布于1970年的Express，然而完整的OLAP概念是在1993年由关系数据库之父EdgarF.Codd 提出，伴随而来的是著名的“twelvelaws of online analytical processing”. 1998年微软发布MicrosoftAnalysis Services，并且在早一年通过OLE DB for OLAP API引入MDX查询语言，2001年微软和Hyperion发布的XML forAnalysis 成为了事实上的OLAP查询标准。如今，MDX已成为与SQL旗鼓相当的OLAP
查询语言，被各家OLAP厂商先后支持。
OLAPCube是一种典型的多维数据分析技术，Cube本身可以认为是不同维度数据组成的dataset，一个OLAP Cube 可以拥有多个维度（Dimension），以及多个事实（Factor Measure）。用户通过OLAP工具从多个角度来进行数据的多维分析。通常认为OLAP包括三种基本的分析操作：上卷（rollup）、下钻（drilldown）、切片切块（slicingand dicing），原始数据经过聚合以及整理后变成一个或多个维度的视图。
ROLAP和MOLAP
传统OLAP根据数据存储方式的不同分为ROLAP（Relational OLAP）以及MOLAP（Multi-dimensionOLAP）
ROLAP 以关系模型的方式存储用作多维分析用的数据，优点在于存储体积小，查询方式灵活，然而缺点也显而易见，每次查询都需要对数据进行聚合计算，为了改善短板，ROLAP使用了列存、并行查询、查询优化、位图索引等技术
MOLAP 将分析用的数据物理上存储为多维数组的形式，形成CUBE结构。维度的属性值映射成多维数组的下标或者下标范围，事实以多维数组的值存储在数组单元中，优势是查询快速，缺点是数据量不容易控制，可能会出现维度爆炸的问题。
大数据时代OLAP的挑战
近二十年内，ROLAP技术随着MPP并行数据库技术的发展，尤其是列存技术的支持下，实现了分析能力大幅度的跨越提升，同时伴随着内存成本的进一步降低，单节点内存扩展性增强，集群单节点的查询性能实现了飞跃，内存数据库的实用性跨上了一个新台阶，这些技术进步共同作用的结果是类似的技术基本覆盖了TB级别的数据分析需求。 Hadoop以及相关大数据技术的出现提供了一个几近无限扩展的数据平台，在相关技术的支持下，各个应用的数据已突破了传统OLAP所能支持的容量上界。每天千万、数亿条的数据，提供若干维度的分析模型，大数据OLAP最迫切所要解决的问题就是大量实时运算导致的响应时间迟滞。
2. Apache Kylin 大数据下的OLAP解决方案
Apache Kylin的背景
Apache Kylin 是一个Hadoop生态圈下的MOLAP系统，是eBay大数据部门从2014年开始研发并开源的支持TB到PB级别数据量的分布式OLAP分析引擎。其特点包括:
- 可扩展的超快的OLAP引擎
- 提供ANSI-SQL接口
- 交互式查询能力
- MOLAP Cube 的概念
- 与BI工具可无缝整合
Apache Kylin典型的应用场景如下：
- 用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上
- 每天有数G甚至数十G的数据增量导入
- 有10个左右为固定的分析维度
ApacheKylin的核心思想是利用空间换时间，由于查询方面制定了多种灵活的策略，进一步提高空间的利用率，使得这样的平衡策略在应用中是值得采用的。
Apache Kylin的总体架构
Apache Kylin 作为一个OLAP引擎完成了从数据源抓取数据，ETL到自己的存储引擎，提供REST服务等一系列工作，其架构如图所示：
Apache Kylin 的生态圈包括：
- Kylin Core: Kylin 引擎的框架，查询、任务、以及存储引擎都集中于此，除此之外还包括一个REST 服务器来响应各种客户端请求。
- 扩展插件: 各种提供额外特性的插件，如安全认证、SSO等
- 完整性组件: Job管理器，ETL、监控以及报警
- 交互界面: 基于Kylin Core之上的用户交互界面
- 驱动: 提供了JDBC以及ODBC的连接方式
Apache kylin Cube 多维数据的计算
Apache Kylin的多维计算主要是体现在OLAPCube的计算。Cube由多个Cuboid组合而成，Cuboid上的数据是原始数据聚合的数据，因此创建Cube可以看作是在原始数据导入时做的一个预计算预处理的过程。Kylin的强大之处在于充分利用了Hadoop的MapReduce并行处理的能力，高效处理导入的数据。
Apache Kylin的数据来自于Hive，并作为一个Hive的加速器希望最终的查询SQL类似于直接在Hive上查询。因此Kylin在建立Cube的时候需要从Hive获取Hive表的元数据。虽然有建立Cube的过程，但是并不想对普通的查询用户暴露Cube的存在。
Apache Kylin创建Cube的过程如下图所示：
- 根据Cube定义的事实表以及维度表，利用Hive创建一张宽表
- 抽取事实表上的维度的distinct值，将事实表上的维度以字典树方式压缩编码成目录，将维度表以字典树的方式编码
- 利用MapReduce从第一步得到的宽表文件作为输入，创建 N－Dimension cuboid，然后每次根据前一步的结果串行生成 N-1 cuboid, N-2 cuboid … 0-Cuboid
- 根据生成的Cuboid数据量计算HTable的Region分割策略，创建HTable，将HFile导入进来
Apache Kylin与传统的OLAP一样，无法应对数据Update的情况（更新数据会导致Cube的失效，需要重建整个Cube）。面对每天甚至每两个小时这样固定周期的增量数据，Kylin使用了一种增量Cubing技术来进行快速响应。
Apache Kylin的Cube可以根据时间段划分成多个Segment。在Cube第一次Build完成之后会有一个Segment，在每次增量Build后会产生一个新的Segment。增量Cubing依赖已有的CubeSegments和增量的原始数据。增量Cubing的步骤和新建 Cube的步骤类似，Segment之间以时间段进行区分。
增量Cubing所需要面对的原始数据量更小，因此增量Cubing的速度是非常快的。然而随着CubeSegments的数目增加，一定程度上会影响到查询的进行，所以在Segments数目到一定数量后可能需要进行CubeSegments的合并操作，实际上MergeCube是合成了一个新的大的CubeSegment来替代，Merge操作是一个异步的在线操作，不会对前端的查询业务产生影响。
合并操作步骤如下：
- 遍历指定的Cube Segment
- 合并维度字典目录和维度表快照
- 利用MapReduce合并他们的 N-Dimension cuboid
- 将cuboid转换成HFile，生成新的HTable，替代原有的多个HTable
Apache Kylin对传统MOLAP的改进
计算Cube的存储代价以及计算代价都是比较大的， 传统OLAP的维度爆炸的问题Kylin也一样会遇到。 Kylin提供给用户一些优化措施，在一定程度上能降低维度爆炸的问题：
- Cube 优化：
- Hierachy Dimension
- Derived Dimension
- Aggregation Group
Hierachy Dimension， 一系列具有层次关系的Dimension组成一个Hierachy， 比如年、月、日组成了一个Hierachy， 在Cube中，如果不设置Hierarchy， 会有 年、月、日、年月、年日、月日 6个cuboid， 但是设置了Hierarchy之后Cuboid增加了一个约束，希望低Level的Dimension一定要伴随高Level的Dimension 一起出现。设置了Hierachy Dimension 能使得需要计算的维度组合减少一半。
Derived Dimension, 如果在某张维度表上有多个维度，那么可以将其设置为Derived Dimension， 在Kylin内部会将其统一用维度表的主键来替换，以此来达到降低维度组合的数目，当然在一定程度上Derived Dimension 会降低查询效率，在查询时，Kylin使用维度表主键进行聚合后，再通过主键和真正维度列的映射关系做一次转换，在Kylin内部再对结果集做一次聚合后返回给用户
Aggregation Group， 这是一个将维度进行分组，以求达到降低维度组合数目的手段。不同分组的维度之间组成的Cuboid数量会大大降低，维度组合从2的（k+m+n）次幂至多能降低到 2的k次幂加2的m次幂加2的n次幂。Group的优化措施与查询SQL紧密依赖，可以说是为了查询的定制优化。 如果查询的维度是夸Group的，那么Kylin需要以较大的代价从N－Cuboid中聚合得到所需要的查询结果，这需要Cube构建人员在建模时仔细地斟酌。
- 数据压缩：
Apache Kylin针对维度字典以及维度表快照采用了特殊的压缩算法，对于Hbase中的聚合计算数据利用了Hadoop的LZO或者是Snappy，从而保证存储在Hbase以及内存中的数据尽可能的小。其中维度字典以及维度表快照的压缩考虑到DataCube中会出现非常多的重复的维度成员值，最直接的处理方式就是利用数据字典的方式将维度值映射成ID， Kylin中采用了Trie树的方式对维度值进行编码
- distinct count聚合查询优化：
Apache Kylin 采用了HypeLogLog的方式来计算DistinctCount。好处是速度快，缺点是结果是一个近似值，会有一定的误差。在非计费等通常的场景下DistinctCount的统计误差应用普遍可以接受。
具体的算法可见Paper，本文不再赘述：
http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf
Apache kylin SQL查询的实现
ANSI SQL查询是Apache Kylin 非常明显的优势。Kylin的SQL语法解析依赖于另一个开源数据管理框架 ApacheCalcite， Calcite即之前的Optiq，是一个没有存储模块的数据库，即不管理数据存储、不包含数据处理的算法，不包含元信息的存储。因此它非常适合来做一个应用到存储引擎之间的中间层。在Calcite的基础之上只要为存储引擎写一个专用的适配器（Adapter）即可形成一个功能丰富的支持DML甚至DDL的“类数据库”。
Kylin完成了一个定制的Adapter，在Calcite完成SQL解析，形成语法树（AST）之后，由Kylin定义语法树各个节点的执行规则来进行查询。Calcite在遍历语法树节点后生成一个Kylin描述查询模型的Digest， Kylin会为此Digest去判断是否有匹配的Cube。如果有与查询匹配的Cube，即选择一个查询代价最小的Cube进行查询（KylinCube的查询代价计算目前是一个开放接口，可以根据维度数目，可以根据数据量大小来计算Cost）
Kylin目前的多维数据存储引擎是HBase， Kylin利用了HBase的Coprocessor机制在HBase的RegionServer完成部分聚合以及全部过滤操作，在HbaseScan时提前进行计算，利用HBase多个Region Server的计算能力加速Kylin的SQL查询。目前Kylin仍然有部分查询语法不支持，特别是过滤器Where部分的约束较多、对SQL有一定的要求，但是如果有针对性的对Coprocessor部分进行改造相信SQL兼容度可以有大幅的提升。
Apache kylin 与 RTOLAP
ApacheKylin 可以说是与市面上流行的Presto、SparkSQL、Impala等直接在原始数据上查询的系统（暂且归于RTOLAP）走了一条完全不同的道路。前者在如何快速求得预计算结果，以及优化查询解析使得更多的查询能用上预计算结果方面在优化。后续Kylin的版本会改进预计算引擎，优化预计算速度，使得Kylin可以变成一个近似实时的分析引擎。而像Presto，SparkSQL等是着重于优化查询数据的过程环节，像一些其它的数据仓库一样，使用列存、压缩、并行查询等技术，优化查询。这种方案的好处就在于扩展性强、能适配更广泛的查询。但是在查询速度上，可以说Apache
Kylin 要比ROLAP 至少快上一个数量级，所以对与查询响应时间要求较高的应用，ApacheKylin是最好的选择。
3. Apache Kylin在网易
Kylin服务化
在网易，Apache Kylin作为大数据平台的OLAP查询模块，可以为公司的各种分析类需求以及应用提供服务。所有数据存在Hadoop Hive 上的数据都能够通过Kylin OLAP 引擎进行加速查询。在公司内部Kylin作为一个统一平台，与各产品的数据仓库进行接驳。
目前Kylin的部署架构如下：
Kylin集群由多个查询节点以及控制节点组成。 控制节点唯一，负责集群项目、任务调度与Cube增删查改。 多个查询节点前用Nginx做负载均衡，后段节点可按需水平扩容。前端可同时支持JDBC与ODBC的客户端查询。
Kylin性能表现
在Kylin上线前，我们选取了公司内部原有的一些报表业务进行过性能对比，对比内容在相同的数据下、Kylin查询与Mondrian 结合Oracle的查询比较。
测试结果通过数据量较大的DataStream报表来进行比较：
再看Kylin的吞吐量，利用Haproxy进行请求转发后随着Kylin服务器的增加吞吐量的表现：
网易对Kylin的改进
原生的社区版Aapche Kylin 是需要部署在一个统一底层的Hadoop、Hive、HBase集群之上的。而网易内部的大数据平台由于各种原因，分为了多个Hadoop集群、各应用会在不同的Hadoop集群上建立Hive数据仓库。最原始而自然的想法就是在每一个Hadoop环境上部署一套Kylin服务来满足不同的需求，但是集群资源管理、计算资源调度、管理运维的复杂性都会是一个比较突出的问题。例如用户数据在A机房的Hive上，而A机房的Hadoop集群并没有足够的计算资源来保证KylinOLAP的高效运行。因此根据公司内部实际的大数据平台分布情况及机房建设情况，将Kylin打造成一个公司内统一的服务平台是一个更好的选择。OLAP小组对开源版本的Kylin进行了二次开发，并将改进补丁提交给了社区并受到了积极反馈。
目前的改进主要包括：
- Kylin对Kerberos认证的支持
- Kylin非Hadoop节点的部署支持
- 多数据源的支持
在公司内，由于性能以及安全性方面的考量，不同部门的应用会搭建各自的Hive进行数据分析，并且由于公司内还没有跨机房的Hadoop集群，因此会出现用户数据在A地方的Hive上，而A机房的Hadoop集群并没有足够的计算资源来保证KylinOLAP的高效运行。
综合分析现实的场景之后，我们选择了公司内最大的hadoop集群作为KylinOLAP的计算引擎集群，保证有充足的存储以及计算资源。 HBase采用一个独立的集群，避免Hbase查询和Hadoop集群任务之间的互相干扰。数据源Hive允许用户自定义，目前已支持同Hadoop集群下不同Hive 以及不同Hadoop集群下的不同Hive节点使用KylinOLAP服务。根据用户数据仓库的实际配置情况可能会出现跨集群的数据源抽取计算，由于公司同城机房有专线网络，数据仓库Hive里的源数据量也远小于Kylin实际的聚合后的数据存储（存于Hbase，数据量大小一般为数据源Hive中的10倍以上），因此可认为这样的开销可以认为带来的影响不大，并且在我们的测试中得到了印证。
Kylin OLAP与猛犸以及有数的结合
猛犸是网易内部的统一大数据入口平台，为了让Kylin更快更好的融入到大平台中，OLAP小组已计划在不久之后全面与猛犸大数据平台进行打通和整合， Kylin OLAP将深度内嵌于猛犸，用户可以基于猛犸平台完成KylinOLAP的简化管理工作。猛犸平台对接控制节点，作为专业数据建模师的操作入口
- Kylin将利用猛犸的用户管理功能
- 猛犸将接管用户项目的创建以及Cube的管理
- 猛犸将原有的Hive数据源彻底与Kylin打通，便于Kylin管理用户的数据源
Kylin原生的用户管理是基于LDAP的，如果不使用LDAP服务需要利用SpringSecurity重新开发一套，网易的内部的猛犸大数据平台有一套成熟且完善的用户权限访问控制体系，因此可以利用现成的机制对Kylin的访问、修改做保护性的限制。
Kylin的Data Cube建模，特别是一些高级的Cube优化功能如RowKey顺序、维度分组、分层等需要较高的学习成本，所以认为不适合让一般的数据分析师来直接操作，我们设计了一套简化版的Cube 建模流程，以用户申请——运维审批的方式进行数据的接入。
有数是网易内部重要的报表分析平台，有数将KylinOLAP作为一个单独的数据源进行支持。已有的以及潜在的Hive查询客户可以轻松的将报表迁移到KylinOLAP，使得大数据量下的交互式报表分析成为可能。
- 有数能基于在猛犸上创建的Cube创建报表
- 有数主动识别Kylin Cube定义的维度和度量
- 用户在Kylin OLAP允许的范围内自由操作，完成报表的编辑和查询。
与有数结合后的Kylin 查询结果可以用更多更丰富的图表的方式展示给数据分析人员：
