毕业论文
您现在的位置:  >> 笛前景 >> 正文 >> 正文

OLAP引擎这么多,麻袋财富为什么选择用

来源:笛 时间:2025/3/25
作者|麻袋财富大数据平台部门编辑|Debra项目背景麻袋财富(原麻袋理财)成立于年12月底,是中信产业基金控股的网络借贷信息中介平台,经过4年平稳而快速的发展,截至目前,累计交易金额达亿,已成为行业头部平台。庞大的业务量带来了数据量指数级增长,原有的数据分析处理方式已远远不能满足业务的需求:流程耗时长:逻辑比较复杂的数据需求,可能会涉及到开发,产品经理,BI等多方相关人员,通过反复的沟通,确认才能完成,而涉及人员过多增加了沟通成本,拉长项目周期资源浪费:为了促进平台的销量增长,运营会设计各种产品促销或用户促活的短期活动,每次活动后都会进行复盘,没有产品化的活动分析通常会导致分析人员的人力浪费集群压力大:一些需要长期监测的复杂指标,每天都要进行重复的查询,而且每天都有几百个临时SQL提交到集群中处理,造成集群计算压力大,影响集群性能查询慢:随着数据量越来越大,往往一条聚合SQL需要几分钟才能出结果,数据分析师需要的快速响应要求已远远不能满足针对上述痛点,我们希望寻找一个工具能够给用户提供高效、稳定、便利的数据分析性能。为什么选择Kylin我们调研了市面上主流的OLAP引擎,对比详情如下所示:结合公司业务需求:以T+1离线数据为主可以整合Tableau使用,实现自助分析常用30个左右的维度,个左右的指标,任意交叉组合,覆盖80%+的固定和临时需求业务方需要观察用户从进入到离开的整个生命周期的特征,涉及数据量大,但要快速响应我们选择了Kylin作为OLAP分析引擎,原因如下:Kylin使用预计算,以空间换时间,能够实现用户查询请求秒级响应可以结合现有BI工具——Tableau,实现自助分析本来需要耗时一周的需求在几分钟内出结果,开发效率提升了10倍以上本文主要介绍麻袋财富基于CDH大数据平台的自助分析项目实施,如何将ApacheKylin应用到实际场景中,目前的使用现状以及未来准备在Kylin上做的工作。技术架构系统部署方面,主要分生产环境和预上线环境,生产环境主要负责查询分析,从生产集群Hive上跑计算,把预计算结果存储到HBase。如果想新增一个Cube的话,需要分析人员先在预上线环境上操作,再由专人对Cube进行优化后迁移到生产环境。麻袋财富的自助分析架构如下图所示:数据同步:Sqoop(离线场景)、Kafka(近实时场景)数据源:Hive(离线场景)、StreamingTable(近实时场景)计算引擎:MapReduce/Spark预计算结果存储:HBase自助分析工具:Tableau调度系统:AzkabanApacheKylin的解决方案公司业务非常复杂,数据团队将各种业务需求高度抽象,确定好维度和度量,只需构建一个Cube,基于该Cube,形成通用的平台化数据产品,解放数据分析师,降低重复性工作。Kylin的离线构建(1)数据建模数据建模对Kylin实施来说是最重要的工作。一般使用关系数据库模型中的星型模型,但是现实中由于业务的多样性,维表的基数很大,所以一般我们把表处理成宽表并且基于宽表建OLAP模型,宽表不仅能解决数据模型的数据粒度问题,还能解决多表join的性能问题,以及维度变化、或者超高基数维度等问题。各个业务线不同的数据特点和业务特点决定了Kylin的使用场景及模型设计优化方式:是数据规模和模型特点。从数据规模上来讲,宽表的数据量近百亿,每天的增量数据千万级以上。我们根据业务指标通过OLAP建模的高度抽象分析,定义了维度和度量值的关系以及底层数据粒度。维度基数特点。维度基数最理想的情况是相对较小,但实际上有些维度超过了百万级接近千万级,这和业务需求及行业特点有关。除此之外指标上要用部分维度之间的笛卡尔积组合,造成很难简化OLAP模型,生成数据相应的开销也比较大。维度粒度特点。从维度的角度来看,地域维度包含省份和城市;时间维度上需要一级划分年月日,增加了维度的复杂度。指标也是维度特点。有一些指标既是维度也是度量,例如:我们需要分析在投金额为0的用户的行为,又需要计算用户的在投金额,所以在投金额即为维度又是度量。(2)KylinCube设计从KylinCube模型上来说,由于Cube需要满足多种场景的需求,业务上需要多个维度互相灵活组合,与分析人员反复沟通,最终确认Cube的维度及度量。Cube模型概况:19个维度:包括省市、操作系统、设备型号、性别、绑卡状态、投资等级等10个度量:包括数据量、访问次数、登录用户数、浏览量、投资金额、年化金额等增量构建:某一Cube源数据增量为万,Build完一天数据Cube大小为87.79GB(3)Cube设计的优化CubeBuild过程中常见遇到的是性能问题,例如SQL查询过慢、Cube构建时间过长甚至失败、Cube膨胀率过高等等。究其原因,大多数问题都是由于Cube设计不当造成的。因此,合理地进行Cube优化就显得尤为重要。优化方案:维度精简:去除查询中不会出现的维度,如数据创建日期强制维度:把每次查询都需要的维度设为强制维度(MandatoryDimensions)层次维度:把有层次的维度(省市或年月日)设为层次维度(HierarchyDimensions)联合维度:把用户关心的维度组合设成联合维度(JointDimensions)调整聚合组:设置多个聚合组,每个聚合组内设置多组联合维度。不会同时在查询中出现的维度分别包含在不同聚合组。调整Rowkeys排序,对于基数高的维度,若在这个维度上有过滤、查询,则放在前面,常用的维度放在前面。(4)Cube优化成果根据上面的优化方案,把assist_date和source设为强制维度,把province,city设为层次维度,再根据使用频率和基数高低排序,最终的优化成果如下:查询性能:秒级响应构建时间:缩短31%Cube大小:减小42%查询性能详情:业务明细表:10亿SQL语句:求每个城市的在投金额Kylin实时增量构建为了减低OLAP分析的延时,在Kylin中添加StreamingTable实现准实时分析的功能,Kylin以StreamingTable为数据源,StreamingTable消费Kafka中的数据。模型中多增加一个timestamp类型的字段,用作时间序列。在实践过程中,模型优化了如下参数:kylin.Cube.algorithm=inmemkylin.Cube.algorithm.inmem-concurrent-threads=8kylin.Cube.max-building-segments=Kylin整合Tableau公司采用Kylin2.4.0版本和Tableau9.0版本,在前者提供预计算结果的前提下,希望结合Tableau能够给数据分析师提供更方便、快速的数据自助分析。在本机上安装与Tableau版本对应的KylinODBCDrive,Tableau连接Kylin时选择Kylin的ODBCDriver,然后选择Kylin的数据源FactTable和JoinTable,并按KylinCube模型join起来,就可以实现拖拉出结果的即席查询,上钻、下钻、旋转等目标。分析人员摆脱了编写冗长SQL,漫长等待的过程,可以根据自己的需求进行数据分析。其中一个使用场景如下图所示,展示每个地区的活跃人数:实施中的经验总结1)Tableau拖拉维度出结果慢解决:查看kylin.log,发现耗时最长的都是select*fromfact,所以让这条SQL尽可能快的失败,可以修改kylin.properties的参数:kylin.query.max-scan-bytes设置为更小的值kylin.storage.partitin.max-scan-bytes设置成更小的值2)Kylin整合Tableau创建的计算字段一定是Cube中包含的,若Cube中没有包含该计算字段,那么在Tableau中计算会显示通信错误,因为Cube的预计算中不含此值。3)使用实时增量时报错:解决:这是由于Kylin2.4.0版本和Kafka的3.0.0版本不匹配,把Kylin降了一个版本Kylin2.3.2即可。4)字段类型转换:在double类型的数据转换为String时,会自动转换为保留一位小数的字符串,例如转换成了.0,导致join的时候无法join成功。解决:当我们要转换的数值只有整形没有小数时,我们可以先把数值类型转换成bigint类型,使用bigint类型存储的数值不会采用科学计数法表示。5)空值产生的数据倾斜:行为表中对游客的user_id是置空的,如果取其中的user_id和用户表中的user_id关联,会碰到数据倾斜的问题。解决:把空值的user_id变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。6)KylinODBCDriver安装是根据Tableau版本的,不是根据操作系统而定的。例如,windows版本是64位的,Tableau版本是32位,就需要装32位的ODBC。未来规划Kylin给我们带来了很多便利,节约了查询时间和精力。随着技术的不断进步,还有许多问题需要解决,还需要不断探索和优化,例如Kylin对明细数据的查询支持不理想,但是有时需要查询明细数据;删除Cube,HBase中的表不会自动删除,影响查询性能,需要手动清理等。

转载请注明:http://www.0431gb208.com/sjsbszl/7549.html