58HBase平台实践和应用-OLAP篇

Kylin是一个底层使用HBase作为存储引擎和查询引擎的的多维分析平台，并对外提供标准SQL查询功能。在超大规模数据集上，Kylin还能达到亚秒级的查询响应。

Kylin的架构：

Kylin OLAP引擎基础框架，包括元数据（Metadata）引擎，查询引擎，Cube构建引擎及存储引擎等，同时包括REST服务器以响应客户端请求。

元数据引擎：包括项目、Hive表、数据模型、Cube等元数据的管理；
存储引擎：构建的Cube数据最终以HFile的格式存储到HBase；
查询引擎：基于Calcite的SQL解析和HBase的Coprocessor并发查询能力；
Cube构建引擎：使用MapReduce实现对各个维度组合数据的预聚合计算；
REST服务器：响应客户端的查询请求；
基于JDBC和ODBC实现和BI工具的无缝整合。

基于HBase的海量存储能力及HBase协处理器聚合查询能力，使得Kylin在推荐效果评估、搜索效果评估、流量转化、用户行为分析等业务场景得到有效应用。

一、Kylin建设

Kylin在58的应用架构：

目前我们使用的Kylin版本为1.5.3，部署时采用了集群模式，同时将Kylin实例分成cube构建server和cube查询server两组，并对外分别提供cube构建的访问域名和cube查询的访问域名。用户可以使用以下两种方式来构建和查询Kylin cube数据：

魔方平台，魔方是公司自研的多维分析平台，底层基于Kylin，可以实现将Kylin构建的cube数据在魔方中以多种图表的方式展现出来。
域名访问Kylin来构建cube，并开发自己的BI报表展示cube数据。

对于用户的Cube的自动化调度，目前也是提供两种方式：

如果用户通过魔方构建和查询Kylin数据，则直接使用魔方的调度功能；
如果用户直接通过域名访问Kylin的数据，我们提供单独的调度平台用于用户Cube数据构建的自动化调度。

我们还开发了Kylin的各种管理工具，包括：

元数据备份；
cube任务失败报警和重试；
无效数据清理；
过期HBase表清理。

在使用Kylin过程中，我们遇到了很多问题，以下针对几个典型问题的优化进行说明：

1、多租户支持优化

默认的Kylin发布版本中，对多租户的支持比较简单，只是简单将用户分为了几个角色，不同角色的用户对元数据及Cube有不同的操作权限，但是对于Cube构建过程中执行Hive脚本，提交MR作业，底层HBase数据存储，以及数据查询等都没有很好的用户隔离支持。

如上图所示，在58，Kylin依赖的计算集群以及HBase集群都是多租户的，所以Kylin在存储和计算方面都需要支持多租户：

第一类：使用Hadoop的UGI支持多租户。通过登录用户构建Hadoop UGI，在UGI.doAs中执行相关操作，实现多租户功能，对应改造的点包括：

Hive元数据加载
MR作业提交
HBase数据存储
HBase数据查询

第二类：使用Hadoop的代理用户支持多租户。在执行Hive脚本前，设置环境变量HADOOP_PROXY_USER来实现多租户功能，对应改造的点包括所有执行Hive脚本的地方：

Hive表/分区行数统计
Hive源表生成宽表

2、维度字典上传优化

问题现象：

用户在使用Kylin过程中，出现了部分Cube的Build任务执行延迟较大，甚至无法启动的情况，而且根据统计对比发现整个集群任务构建时间逐渐增加。

原因分析：

Cube构建过程中，有多个步骤需要运行MR作业，同时需要将包括维度字典文件（维度编码设置为了字典）以及其他的元信息文件作为分布式缓存上传HDFS，并下载到计算节点本地，随着时间的推移，字典文件会越来越多（Segment增多），导致总的上传时间越来越长。当文件总大小太大时，出现分布式缓存文件上传超时的，最终任务无法启动。

以下是Cube构建中，单个MR作业进行分布式缓存文件上传下载流程：

Cube构建MR作业分布式缓存上传下载文件默认包括元信息文件以及字典文件，元信息包括Cube信息，Segment信息，Fact表信息，Model信息以及配置信息等，字典文件就是维度字典文件，默认会包括所有Segment的维度字典文件，随着时间推移，Segment会越来越多，维度字典文件的数据量会越来越大。

以下是cube构建的整体流程图：

整个构建过程包括多个MR作业，其中分布式缓存上传和下载元信息文件和字典文件的MR作业包括①、②、③、④、⑤、⑥，分别对应：

①、对维度字段进行去重的MR作业；

②、计算Base Cuboid的MR作业；

③-⑤、计算N-1至0 维 Cuboid的MR作业，可能有很多个MR作业，由维度个数决定；

⑥、根据前面② 至 ⑤ 生成的Sequence File最终聚合生成HFile的MR任务。

优化解决：

默认情况下以上所有MR作业都会通过分布式缓存上传和下载元信息文件和Cube对应所有Segment的维度字典文件。

通过仔细分析发现，我们可以进行以下两种优化：

第一种：有的步骤并不需要segment维度字典文件，比如①、③、④、⑤、⑥。

第二种：有的步骤只需要部分维度字典，比如②的构建Base Cubeid的MR作业，只需要当前构建Segment的维度字典。在Cube的Segment合并时，也只需要参与合并的Segment的维度字典文件，可以类似进行优化。

最终效果：

我们对上传的Segment维度字典文件的流程进行了优化后，在生产环境取得了很好的效果，使得Cube的构建过程整体减少了20%的时间，同时很少出现作业无法启动的情况。

3、cube数据量预估优化（v2.5版本已解决）

问题现象：

Cube构建后需要对数据量预估，根据预估的结果来决定需要创建的HBase表的分区数，但是发现有时最终数据量并不大的情况下，创建的表分区数还比较多，使得HBase集群分区管理压力增大，浪费大量资源；而有时最终数量很大，但是创建的HBase表分区过少，导致Kylin查询缓慢。

原因分析：

由于默认Cube数据量预估算法预估出来的数据量和实际的数据量存在较大偏差，导致kylin创建的HBase表分区数大部分情况下不合理。

在估算总数据量时，总条目数的估算误差较小，单是对单条长度的估算偏差较大。对于维度值的长度和普通数据类型的度量值长度值都可以根据数据类型确定，但是对于特殊数据类型的度量，比如度量类型为BitMap和HyperLogLog，估算其长度时就会有一些问题了：

BitMap：用于对度量基数(count distinct)的精确计算，其长度大小由度量的基数决定，由于度量基数无法提前确定，导致无法获取BitMap的实际长度值，Kylin采取折中办法，估算时使用一个固定值8K，如果对应度量基数很高，其大小很容易超过8k，就会导致单行预估的长度偏低；
HyperLogLog：用于对度量基数(count distinct)非精确计算，其长度是由用户选择的精度来决定的，如果误差率控制在1.22%以内，那么HyperLogLog会使用64k的空间来存储数据，在支持压缩的情况下，实际的长度会小于64k，而且如果度量基数较小，HyperLogLog存储的数据会比较稀疏，压缩效果会更好，这就导致单行预估的长度偏高。

优化解决：

使用已有Segment数据，预估新建的Segment数据量，算法如下图所示：

基本思路：

使用同一个Cube最近一个Segment的统计数据来预估当前segment的总数据量，统计数据包括最近一个Segment对应Hive表分区的输入记录数（InputRowsCounts），最终存储到HBase的实际大小(HtableSize)，然后计算出每行输入记录对应的数据大小，将这个大小作为新segment的每行数据大小，并乘以新Segment的Hive表分区输入记录数，将这个数作为新Segment最终的数据量大小。

最终效果：

通过使用新的预估算法，能有效将HBase表分区个数误差由 >50 降至<=1，从而避免了创建过多或者过少的分区，使得Kylin查询性能更加稳定，同时减小了HBase集群的分区管理压力。

4、其他优化

修改Kylin对HBase的Scan操作时blockcache参数值为false；
禁掉加载Hive表元数据时，对Hive表各个列的基数统计；
全局字典构建时分片文件频繁换进换出优化（v2.5版本已解决）。

二、案例分享

以58同城推荐系统推荐效果评估为例讲一下Kylin在58的应用和优化（案例详情请查看《基于Kylin的推荐系统效果评价系统》）。

推荐效果评估数据流程图：

推荐效果评估系统的基础数据是：曝光日志和用户点击日志。这两份日志通过Flume收集，一份实时写入消息队列Kafka，一份批量存入Hadoop，存入Hadoop的数据通过ETL过程生成两张宽表，曝光日志宽表和点击日志宽表，这两张宽表包含了所有需要分析曝光和点击的维度和度量，以这两张宽表为源表创建两个Cube，并定时构建Cube数据，基于预计算Cube数据进行推荐效果评估分析。

对点击和曝光日志抽象出15个维度和5个度量，15个维度包括：日期、平台、业务一级分类、业务二级分类、推荐场景、推荐位、排序算法号、召回算法号、前端展现号、推荐规则号、自定义维度（d1至d2），5个度量包括：点击PV、点击UV、曝光PV、曝光UV、曝光帖子数。

Cube设计优化：

基于业务情况，对维度聚合分组时进行了重点优化，如下图所示：

15个维度经过组合优化后，最终共包含4个普通维度、1个强制维度、1个层次为2的层级维度、1个层次为3的层级维度、1个维数为5的联合维度。最终cuboid的数量为 (2^4)*1*(2 1)*(3 1)*2 = 384，而不做Cube优化的cuboid数量是2^15 = 32768，可想而知，维度优化有多重要。

到目前为止，曝光日志分析cube数据量达到3T，记录数到达110 亿；点击日志分析Cube数据量达到2T，记录数达到70 亿。

Cube数据可视化：