热门标签 | 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 篇)


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


推荐阅读
  • Python 数据可视化实战指南
    本文详细介绍如何使用 Python 进行数据可视化,涵盖从环境搭建到具体实例的全过程。 ... [详细]
  • Presto:高效即席查询引擎的深度解析与应用
    本文深入解析了Presto这一高效的即席查询引擎,详细探讨了其架构设计及其优缺点。Presto通过内存到内存的数据处理方式,显著提升了查询性能,相比传统的MapReduce查询,不仅减少了数据传输的延迟,还提高了查询的准确性和效率。然而,Presto在大规模数据处理和容错机制方面仍存在一定的局限性。本文还介绍了Presto在实际应用中的多种场景,展示了其在大数据分析领域的强大潜力。 ... [详细]
  • 智能制造数据综合分析与应用解决方案
    在智能制造领域,生产数据通过先进的采集设备收集,并利用时序数据库或关系型数据库进行高效存储。这些数据经过处理后,通过可视化数据大屏呈现,为生产车间、生产控制中心以及管理层提供实时、精准的信息支持,助力不同应用场景下的决策优化和效率提升。 ... [详细]
  • 从0到1搭建大数据平台
    从0到1搭建大数据平台 ... [详细]
  • 如何将TS文件转换为M3U8直播流:HLS与M3U8格式详解
    在视频传输领域,MP4虽然常见,但在直播场景中直接使用MP4格式存在诸多问题。例如,MP4文件的头部信息(如ftyp、moov)较大,导致初始加载时间较长,影响用户体验。相比之下,HLS(HTTP Live Streaming)协议及其M3U8格式更具优势。HLS通过将视频切分成多个小片段,并生成一个M3U8播放列表文件,实现低延迟和高稳定性。本文详细介绍了如何将TS文件转换为M3U8直播流,包括技术原理和具体操作步骤,帮助读者更好地理解和应用这一技术。 ... [详细]
  • Android中将独立SO库封装进JAR包并实现SO库的加载与调用
    在Android开发中,将独立的SO库封装进JAR包并实现其加载与调用是一个常见的需求。本文详细介绍了如何将SO库嵌入到JAR包中,并确保在外部应用调用该JAR包时能够正确加载和使用这些SO库。通过这种方式,开发者可以更方便地管理和分发包含原生代码的库文件,提高开发效率和代码复用性。文章还探讨了常见的问题及其解决方案,帮助开发者避免在实际应用中遇到的坑。 ... [详细]
  • 本文探讨了 Kafka 集群的高效部署与优化策略。首先介绍了 Kafka 的下载与安装步骤,包括从官方网站获取最新版本的压缩包并进行解压。随后详细讨论了集群配置的最佳实践,涵盖节点选择、网络优化和性能调优等方面,旨在提升系统的稳定性和处理能力。此外,还提供了常见的故障排查方法和监控方案,帮助运维人员更好地管理和维护 Kafka 集群。 ... [详细]
  • 2012年9月12日优酷土豆校园招聘笔试题目解析与备考指南
    2012年9月12日,优酷土豆校园招聘笔试题目解析与备考指南。在选择题部分,有一道题目涉及中国人的血型分布情况,具体为A型30%、B型20%、O型40%、AB型10%。若需确保在随机选取的样本中,至少有一人为B型血的概率不低于90%,则需要选取的最少人数是多少?该问题不仅考察了概率统计的基本知识,还要求考生具备一定的逻辑推理能力。 ... [详细]
  • 第二章:Kafka基础入门与核心概念解析
    本章节主要介绍了Kafka的基本概念及其核心特性。Kafka是一种分布式消息发布和订阅系统,以其卓越的性能和高吞吐量而著称。最初,Kafka被设计用于LinkedIn的活动流和运营数据处理,旨在高效地管理和传输大规模的数据流。这些数据主要包括用户活动记录、系统日志和其他实时信息。通过深入解析Kafka的设计原理和应用场景,读者将能够更好地理解其在现代大数据架构中的重要地位。 ... [详细]
  • 全面解析:Hadoop技术栈中的Linux操作系统概览
    全面解析:Hadoop技术栈中的Linux操作系统概览 ... [详细]
  • 本文详细介绍了HDFS的基础知识及其数据读写机制。首先,文章阐述了HDFS的架构,包括其核心组件及其角色和功能。特别地,对NameNode进行了深入解析,指出其主要负责在内存中存储元数据、目录结构以及文件块的映射关系,并通过持久化方案确保数据的可靠性和高可用性。此外,还探讨了DataNode的角色及其在数据存储和读取过程中的关键作用。 ... [详细]
  • 在Linux系统中,原本已安装了多个版本的Python 2,并且还安装了Anaconda,其中包含了Python 3。本文详细介绍了如何通过配置环境变量,使系统默认使用指定版本的Python,以便在不同版本之间轻松切换。此外,文章还提供了具体的实践步骤和注意事项,帮助用户高效地管理和使用不同版本的Python环境。 ... [详细]
  • 新手指南何为PHP语言_PHP教程:PHP语言经过长时间的发展,很多用户都很了解PHP语言了,这里我发表一下个人理解,和大家讨论讨论。比较关注网络的朋友,特别是关注网站建设技术的朋 ... [详细]
  • MicrosoftDeploymentToolkit2010部署培训实验手册V1.0目录实验环境说明3实验环境虚拟机使用信息3注意:4实验手册正文说 ... [详细]
  • Web开发框架概览:Java与JavaScript技术及框架综述
    Web开发涉及服务器端和客户端的协同工作。在服务器端,Java是一种优秀的编程语言,适用于构建各种功能模块,如通过Servlet实现特定服务。客户端则主要依赖HTML进行内容展示,同时借助JavaScript增强交互性和动态效果。此外,现代Web开发还广泛使用各种框架和库,如Spring Boot、React和Vue.js,以提高开发效率和应用性能。 ... [详细]
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社区 版权所有