热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

58HBase平台实践和应用(OLAP篇)

Kylin是一个底层使用HBase作为存储引擎和查询引擎的的多维分析平台,并对外提供标准SQL查询功

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

Kylin的架构:

58 HBase 平台实践和应用(OLAP 篇)

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的应用架构:

58 HBase 平台实践和应用(OLAP 篇)

目前我们使用的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 HBase 平台实践和应用(OLAP 篇)

如上图所示,在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作业进行分布式缓存文件上传下载流程:

58 HBase 平台实践和应用(OLAP 篇)

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

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

58 HBase 平台实践和应用(OLAP 篇)

整个构建过程包括多个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表分区数大部分情况下不合理。

58 HBase 平台实践和应用(OLAP 篇)

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

  • BitMap:用于对度量基数(count distinct)的精确计算,其长度大小由度量的基数决定,由于度量基数无法提前确定,导致无法获取BitMap的实际长度值,Kylin采取折中办法,估算时使用一个固定值8K,如果对应度量基数很高,其大小很容易超过8k,就会导致单行预估的长度偏低; 

  • HyperLogLog:用于对度量基数(count distinct)非精确计算,其长度是由用户选择的精度来决定的,如果误差率控制在1.22%以内,那么HyperLogLog会使用64k的空间来存储数据,在支持压缩的情况下,实际的长度会小于64k,而且如果度量基数较小,HyperLogLog存储的数据会比较稀疏,压缩效果会更好,这就导致单行预估的长度偏高。

优化解决:

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

58 HBase 平台实践和应用(OLAP 篇)

基本思路:

使用同一个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的推荐系统效果评价系统》 )。

推荐效果评估数据流程图

58 HBase 平台实践和应用(OLAP 篇)

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

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

Cube设计优化

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

58 HBase 平台实践和应用(OLAP 篇)   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 数据可视化:  

58 HBase 平台实践和应用(OLAP 篇)

三、总结

在58,Kylin广泛应用于推荐效果评估、搜索效果评估、流量转化、用户行为分析等业务场景。

目前各业务线Cube总数到达 350 +,处理的原始记录数总计 460亿 +,生成预计算结果数据入HBase为 1T +, 98 %查询在 0.5 s内返回。

2019年我们将跟进社区,升级我们的Kylin版本,使用更快的Cube构建引擎Spark,支持用户留存分析,支持更丰富的SQL查询功能,支持更稳定的全局字典构建算法。

最后,58集团数据平台部长期招聘大数据研发工程师。

58数据平台部是58集团唯一的大数据架构部门,负责包括海量数据采集接入,万亿级消息引擎、离线/实时计算引擎,海量存储引擎以及多维分析平台等的建设和优化。支持了58集团大部分的业务线,日接入流量达200T,总存储过百P,日30万的计算,随着大数据应用广泛增长,技术挑战极大。

招聘职位:   

1、存储方向:主要负责HDFS/Hbase等相关系统架构研发优化   

2、计算方向:负责Spark/Flink等相关架构研发优化   

3、OLAP方向:负责Druid/Kylin/ES等系统的架构研发优化   

4、消息中间件:负责Kafka/Flume等平台的架构研发优化   

5、资源管理:负责YARN/K8s等资源管理平台架构研发优化 

招聘要求:

1、熟悉Java/Scala/C++(任意一种即可),熟练掌握数据结构算法 

2、对HDFS/Hbase/Spark/Flink/Druid/Kafka/FLume/YARN等任一组件有源码级优化经验优先

3、有大规模分布式系统实践经验优先

工作地点:北京市朝阳区酒仙桥北路甲10号院101号楼  

联系方式:yuyi03@58ganji.com

58 HBase 平台实践和应用(OLAP 篇)


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 我们


推荐阅读
  • 本文由公众号【数智物语】(ID: decision_engine)发布,关注获取更多干货。文章探讨了从数据收集到清洗、建模及可视化的全过程,介绍了41款实用工具,旨在帮助数据科学家和分析师提升工作效率。 ... [详细]
  • 在深入掌握Spring框架的事务管理之前,了解其背后的数据库事务基础至关重要。Spring的事务管理功能虽然强大且灵活,但其核心依赖于数据库自身的事务处理机制。因此,熟悉数据库事务的基本概念和特性是必不可少的。这包括事务的ACID属性、隔离级别以及常见的事务管理策略等。通过这些基础知识的学习,可以更好地理解和应用Spring中的事务管理配置。 ... [详细]
  • 第二章:Kafka基础入门与核心概念解析
    本章节主要介绍了Kafka的基本概念及其核心特性。Kafka是一种分布式消息发布和订阅系统,以其卓越的性能和高吞吐量而著称。最初,Kafka被设计用于LinkedIn的活动流和运营数据处理,旨在高效地管理和传输大规模的数据流。这些数据主要包括用户活动记录、系统日志和其他实时信息。通过深入解析Kafka的设计原理和应用场景,读者将能够更好地理解其在现代大数据架构中的重要地位。 ... [详细]
  • 在C#中开发MP3播放器时,我正在考虑如何高效存储元数据以便快速检索。选择合适的数据结构,如字典或数组,对于优化性能至关重要。字典能够提供快速的键值对查找,而数组则在连续存储和遍历方面表现优异。根据具体需求,合理选择数据结构将显著提升应用的响应速度和用户体验。 ... [详细]
  • Spring Boot 实战(一):基础的CRUD操作详解
    在《Spring Boot 实战(一)》中,详细介绍了基础的CRUD操作,涵盖创建、读取、更新和删除等核心功能,适合初学者快速掌握Spring Boot框架的应用开发技巧。 ... [详细]
  • SQL查询与事务管理:深入解析
    本文详细介绍了SQL查询的基本结构和高级特性,包括选择、分组查询以及权限控制等内容,并探讨了事务管理中的并发控制策略,旨在为数据库管理员和开发人员提供实用指导。 ... [详细]
  • Maven快照版本管理及更新策略详解
    本文深入探讨了Maven中的快照版本管理和更新策略,解释了快照版本与正式版本的区别,并提供了如何配置快照更新策略的方法,以确保项目依赖始终保持最新。 ... [详细]
  • Windows环境下Oracle数据库迁移实践
    本文详细记录了一次在Windows操作系统下将Oracle数据库的控制文件、数据文件及在线日志文件迁移至外部存储的过程,旨在为后续的集群环境部署做好准备。 ... [详细]
  • PHP中Smarty模板引擎自定义函数详解
    本文详细介绍了如何在PHP的Smarty模板引擎中自定义函数,并通过具体示例演示了这些函数的使用方法和应用场景。适合PHP后端开发者学习。 ... [详细]
  • MVC模式下的电子取证技术初探
    本文探讨了在MVC(模型-视图-控制器)架构下进行电子取证的技术方法,通过实际案例分析,提供了详细的取证步骤和技术要点。 ... [详细]
  • 本文探讨了服务器系统架构的性能评估方法,包括性能评估的目的、步骤以及如何选择合适的度量标准。文章还介绍了几种常用的基准测试程序及其应用,并详细说明了Web服务器性能评估的关键指标与测试方法。 ... [详细]
  • Java虚拟机及其发展历程
    Java虚拟机(JVM)是每个Java开发者日常工作中不可或缺的一部分,但其背后的运作机制却往往显得神秘莫测。本文将探讨Java及其虚拟机的发展历程,帮助读者深入了解这一关键技术。 ... [详细]
  • 1、编写一个Java程序在屏幕上输出“你好!”。programmenameHelloworld.javapublicclassHelloworld{publicst ... [详细]
  • 对象存储与块存储、文件存储等对比
    看到一篇文档,讲对象存储,好奇,搜索文章,摘抄,学习记录!背景:传统存储在面对海量非结构化数据时,在存储、分享与容灾上面临很大的挑战,主要表现在以下几个方面:传统存储并非为非结 ... [详细]
  • 本文介绍了如何利用 `matplotlib` 库中的 `FuncAnimation` 类将 Python 中的动态图像保存为视频文件。通过详细解释 `FuncAnimation` 类的参数和方法,文章提供了多种实用技巧,帮助用户高效地生成高质量的动态图像视频。此外,还探讨了不同视频编码器的选择及其对输出文件质量的影响,为读者提供了全面的技术指导。 ... [详细]
author-avatar
9asd8fy
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有