//
Apache Kylin 大数据下的OLAP解决方案(原理篇)
http://mp.weixin.qq.com/s?__biz=MzI2MDU5ODY2Mg==&mid=2247483927&idx=1&sn=6697cde0bc54e1725da868c5cf52aeb0&chksm=ea667cfedd11f5e8803a6ee9ebc2444d515b7c18c641261f697d4ca341d1439ac3acca472240&mpshare=1&scene=1&srcid=0306oTHdHxhTi2IWYsK4Etr6#rd
**前言******
在现在的大数据时代，Hadoop已经成为大数据事实上的标准规范，一大批工具陆陆续续围绕Hadoop平台来构建，用来解决不同场景下的需求。
让我们来想想有哪些业务需求呢？
比如Hive是基于Hadoop的一个用来做企业数据仓库的工具，可以将存储在HDFS分布式文件系统上的数据文件映射为一张数据库表，并提供SQL查询功能，Hive执行引擎可以将SQL转换为MapReduce任务来进行运行，非常适合数据仓库的数据分析。
再比如HBase是基于Hadoop，实现高可用性，高性能，面向列，可伸缩的分布式存储系统，Hadoop架构中的HDFS为HBase提供了高可靠性的底层存储支持。
但是缺少一个基于Hadoop的分布式分析引擎，虽然目前存在业务分析工具，如Tableau等，但是他们往往存在很大的局限，比如难以水平扩展、无法处理超大规模数据，同时也缺少Hadoop的支持。
ApacheKylin的出现，能够基于Hadoop很好地解决上面的问题。Apache Kylin是一个开源的分布式存储引擎。它提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持大规模数据，能够处理TB乃至PB级别的分析任务，能够在亚秒级查询巨大的Hive表，并支持高并发。
大数据多维分析的挑战
在Apache Kylin集群上跑了多个Cube测试，结果表明它能够有效解决大数据计算分析的三大痛点问题：
ApacheKylin从数据仓库中最常用的Hive中读取源数据，使用 MapReduce作为Cube构建的引擎，并把预计算结果保存在HBase中，对外暴露Rest API/JDBC/ODBC的查询接口。
核心:预计算
Apache Kylin的核心思想是预计算，即对多维分析可能用到的度量进行预计算，将计算好的结果保存成 Cube，供查询时直接访问。把高复杂度的聚合运算、多表连接等操作转换成对预计算结果的查询，这决定了Kylin能够拥有很好的快速查询和高并发能力。
上图所示就是一个Cube的例子，假设我们有4个dimension，这个Cube中每个节点（称作Cuboid）都是这4个dimension的不同组合，每个组合定义了一组分析的dimension（如group by），measure的聚合结果就保存在这每个Cuboid上。查询时根据SQL找到对应的Cuboid，读取measure的值，即可返回。
Cube计算
Cube的构建，Kylin提供了一个称作Layer Cubing的算法。简单来说，就是按照dimension数量从大到小的顺序，从Base Cuboid开始，依次基于上一层Cuboid的结果进行再聚合。一个N维的完全Cube，是由：1个N维子立方体（Cuboid）， N个（N-1）维Cuboid, N*(N-1)/2个(N-2)维Cuboid …, N个1维Cuboid, 1个0维Cuboid，总共2^N个子立方体组成的，每一层的计算都是一个单独的Map Reduce任务。如下图所示：
此算法Mapper以上一层Cuboid的结果（Key-Value对）作为输入。由于Key是由各维度值拼接在一起，从其中找出要聚合的维度，去掉它的值成新的Key，然后把新Key和Value输出，进而HadoopMapReduce对所有新Key进行排序、洗牌（shuffle）、再送到Reducer处；Reducer的输入会是一组有相同Key的Value集合，对这些Value做聚合计算，再结合Key输出就完成了一轮计算。
由于Mapper不做预聚合，此算法会对Hadoop MapReduce输出较多数据; 虽然已经使用了Combiner来减少从Mapper端到Reducer端的数据传输，所有数据依然需要通过Hadoop MapReduce来排序和组合才能被聚合，无形之中增加了集群的压力。
快速Cube算法（Fast Cubing）
该算法的主要思想是，对Mapper所分配的数据块，将它计算成一个完整的小Cube 段（包含所有Cuboid）；每个Mapper将计算完的Cube段输出给Reducer做合并，生成大Cube，也就是最终结果，如下图：
Mapper的预聚合：Mapper会利用内存做预聚合，算出所有组合；Mapper输出的每个Key都是不同的，这样会减少输出到Hadoop MapReduce的数据量，Combiner也不再需要；一轮MapReduce便会完成所有层次的计算，减少Hadoop任务的调配。
在Cuboid的推算过程中的每一步，Fast Cubing算法都会比逐层算法产生更少数据；总的加起来，新算法中的Mapper对Hadoop的输出，会比老算法少一个或几个数量级；越少的数据，意味着越少的I/O和CPU，从而使得性能得以提升。
Cube存储
MapReduce的计算结果最终保存到HBase中，HBase中每行记录的Rowkey由dimension组成，measure会保存在 column family中。为了减小存储代价，这里会对dimension和measure进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有良好的快速响应和高并发。
有了这些预计算的结果，当收到用户的SQL请求，Kylin会对SQL做查询计划，并把本该进行的Join、Sum、CountDistinct等操作改写成Cube的查询操作。
Cube查询
查询时，SQL语句被SQL解析器翻译成一个解释计划，从这个计划可以准确知道用户要查哪些表，它们是怎样join起来，有哪些过滤条件等等。Kylin会用这个计划去匹配寻找合适的Cube。
如果有Cube命中，这个计划会发送到存储引擎，翻译成对存储(默认HBase)相应的Scan操作。Groupby和过滤条件的列，用来找到 Cuboid，过滤条件会被转换成Scan的开始和结束值，以缩小Scan的范围; Scan的result，Rowkey会被反向解码成各个dimension的值，Value会被解码成Metrics值 。
Apache Kylin****项目实践
目前基于kylin的数据分析平台已经在业务中开始测试以及使用，并且在用户管理和权限操作方面做了的二次开发改造，以实现project和cube的安全管理。
下图是cube的查询响应图表，cube 大小为157GB，包括一个事实表，14个维度和4个度量：
在项目实践过程中也遇到问题：
Hadoop任务内存资源不够，cube计算失败。
调整MapReduce分配资源参数：在cube计算过程中，会出现mr任务失败，根据日志排查，主要因mr的内存分配不足导致，于是，我们根据任务实际情况整体调整了yarn.nodemanager.resource.memory-mb、mapreduce.map.memory.mb、
mapreduce.map.java.opts、mapreduce.reduce.memory.mb、apreduce.reduce.java.opts
等参数。
JVMGC相关参数调优：可以通过GC调优获得更好的GC性能，减少单次GC的时间和FULL GC频率。
使用Apache Kylin的实践总结
1、大的事实表采用天分区增量构建，为了不影响查询性能，可以定期做合并(Merge)，周期可以根据实际情况确定。
2、对于维表比较大的情况，或者查询Select部分存在复杂的逻辑判断，存在Apache Kylin不支持的函数或语句时，可以将事实表和维表的关联处理创建为Hive视图，之后根据视图创建Cube模型。
3、每次查询必然带有的条件建议在字典设置步骤将其设置为Mandatory。这样会最终 Build出来Cube的大小会减少一半。
4、Cube的维度如果超过10个，建议将常用的聚合字段做分组。
5、Cube定义中RowKey顺序：Mandatory维度，Where过滤条件中出现频率较多的维度，高基数维度，低基数维度。
6、当Segment中某一个Cuboid的大小超过一定的阈值时，修改数据分片大小以实现数据读取的并行化，从而优化Cube的查询速度。
7、设计合适的维度编码能减少维度对空间的占用，比如对于高基数的维度如果使用Dict字典编码方式占用大量空间，容易造成构建引擎或查询引擎的内存溢出。
8、对维度进行分片，如果Cuboid中某两个行的Shard by Dimension的值相同，那么无论这个Cuboid最终会被划分多少个分片，这两行数据必然会被分配到同一个分片中，方便查询和索引。
9、部署层面，可以通过Nginx在前端做负载均衡，后端启动多个Query Server接收查询请求处理。
基于Kylin的前景规划
经过项目的摸索和实践，Apache Kylin能很好的解决开篇所说的大数据计算分析的3大痛点问题，提升业务的查询效率。
首先，在接下来我们也将会持续关注Kylin的发展变化，包括数据字典的分布式构建以及基于Kafka定义Streaming Table，从而完成准实时Cube的构建的特性。
其次，规划设计符合需求的拖拽前台界面，支持探索性数据查询。采用拖拽式方便用户使用；规定化前台界面，屏蔽后台技术细节，避免低效的查询出现。
在目前的工作基础上规划构建基于Apache Kylin的大数据OLAP分析平台， 如下图所示：
最后还将继续调研和分析新的存储引擎和构建引擎来满足更多的业务需求。