Lenovo 联晟智达| 简化数据处理链路,极大提升BI分析效率
本文发表于: &{ new Date(1631635200000).toLocaleDateString() }
Lenovo联晟智达隶属于全球PC领导厂商联想集团,致力于打造科技驱动、柔性敏捷、服务体验一流的智慧物流生态平台,面向产业端企业提供综合物流解决方案,成为服务于中国及全球客户的智能供应链科技企业。联晟智达大数据团队逐步引入了多种OLAP分析引擎来更好的满足需求。StarRocks从众多的OLAP分析引擎中脱颖而出,它采用了全面向量化的计算技术,是性能非常强悍的新一代MPP数据库。通过引入StarRocks,构建了全新的统一数据服务平台,大大降低了数据链路开发复杂性,极大提升了BI分析效率。
OLAP引擎在Lenovo联晟智达的演进
第一阶段
在2018年之前,联晟智达的数据总量还不是特别大,这个阶段使用的是传统关系型数据库(SQL Server),数据仓库体系还尚未建立,很多数据需求的实现都是以SQL脚本的开发方式来满足。
但随着业务复杂度不断提升,以及数据量的快速增长,这种模式很快遇到了瓶颈。最主要体现在查询响应时效变得越来越慢。例如:之前运行一个任务需要10分钟或20分钟,现在需要一个小时或更长时间,查询效率严重下降。另外数据存储容量也存在瓶颈,无法满足随业务而快速增长的数据量存储需求。
第二阶段
2019年随着数据仓库在Apache Hadoop®/Apache Hive™体系上搭建和完善,ETL任务全部转移至Hadoop集群,这个阶段使用数十台Presto完成OLAP分析。Presto天然和Apache Hive™共享元数据信息,且共同使用物理数据存储,大量的对数仓表的灵活查询使用Presto完成。前端BI层面使用Tableau直接连接Presto,实现数据分析与挖掘。
第三阶段
2021年联晟大数据团队进行了离线数仓的整体设计和搭建,既需要做低延时的BI报表,又要满足Adhoc复杂查询,同时对高效明细查询也有很高的要求。这个阶段我们根据场景引入了OLAP圈炙手可热的StarRocks产品,它既能做Presto的Adhoc多表关联查询及复杂嵌套子查询,又能提供比ClickHouse更好的单表明细查询和多维物化视图上卷加速,满足极速BI分析需求。
数据分析体系架构
OLAP体系现状
整个数据分析体系,由数据采集、数据存储与计算、数据查询与分析和数据应用组成。
原始架构图:
数据采集
- 通过Sqoop读取RDBMS导入Apache Hive™。
- 用Flume来同步日志文件到Apache Hive™。
- 通过爬虫技术将网上数据爬取下来,存储到RDBMS,再由Sqoop 读取RDBMS,导入到Apache Hive™。
数据存储与计算
离线数据处理:利用Apache Hive™高可扩展的批处理能力承担所有的离线数仓的ETL和数据模型加工的工作。
数据查询与分析
数据共享层主要提供对外服务的底层数据存储和查询共享界面。离线ETL后的数据写入RDBMS或MPP数据库中,面向下游多种服务,为Tableau BI、多维固定报表、Adhoc即席查询等不同场景提供OLAP查询分析能力。应用侧完美服务于BI报表平台、即席查询分析平台及数据可视化平台(Control Tower)
数据应用层
数据应用层主要为面向管理和运营人员的报表,查询要求低时延响应,需求也是迭代层出不穷。面向数据分析师的即席查询,更是要求OLAP引擎能支持复杂SQL处理、从海量数据中快速遴选数据的能力。
各OLAP分析工具选型比较
ClickHouse
优点
- 很强的单表查询性能,适合基于大宽表的OLAP多维分析查询。
- 包含丰富的MergeTree Family,支持预聚合。
- 非常适合大规模日志明细数据写入分析。
缺点
- 不支持真正的删除与更新。
- Join方式不是很友好。
- 并发能力比较低。
- MergeTree合并不完全。
StarRocks
优点
- 单表查询和多表查询性能都很强,可以同时较好支持宽表查询场景和复杂多表查询。
- 支持高并发查询。
- 支持实时数据微批ETL处理。
- 流式和批量数据写入都能都比较强。
- 兼容MySQL协议和标准SQL。
缺点
- 大规模ETL能力不足。
- 资源隔离还不完善。
SartRocks在SEC数据中心的应用实践
渠道仓配管理(SEC)的核心数据来自两大块:一个是消费业务;第二个是SMB中小企业务(Think、扬天)。基于这些数据,根据不同的业务场景需求,汇总出相关业务统计指标,对外提供查询分析服务。
原有解决方案
在引入StarRocks之前,用到大量Apache Hive™任务进行业务逻辑清洗加工,清洗加工后的数据部分保留在Apache Hive™,部分数据写入MySQL/SQL Server,以达到数据的落地。前端BI通过Presto计算引擎连接Hive、MysSQL、SQL Server等,实现报表分析及数据可视化。
技术痛点
原有架构主要有以下两个问题:
- 数据逻辑没有很好做归拢合并,维护工作量大,新需求无法快速响应。
- Presto的在SQL较多的Tableau复杂报表上响应较慢,不能满足业务即时看数需求。
因此我们希望对原有体系进行优化,核心思路是利用一个OLAP引擎进行这一层的统一, 对OLAP引擎的要求是比较高的:
- 能支撑大吞吐量的数据写入要求。
- 可以支持多维度组合的灵活查询,响应时效在100ms以下。
- 比较好的支持多表关联。
- 单表查询数据量在10亿以上,响应时效在100ms以下。
经过大量调研,StarRocks比较契合数据中心的整体要求。StarRocks本身高效的查询能力,可以为数据中心数据报告提供一体化服务。新架构具备以下优点:
- 结构清晰,RDBMS专注于数据的清洗,业务逻辑计算从Apache Hive™迁到StarRocks内实现,StarRocks就是数据业务逻辑的终点。
- 可以维护统一的数据口径,一份数据输入,多个APP接口输出。
- MPP分布式架构,得以更好的支持分布式聚合和关联查询。
- 和Tableau有较好的兼容性,可以满足核心BI分析需求。
基于SartRocks的解决方案
升级后架构图:
数据表设计
1)数据模型设计
StarRocks本身提供三种数据模型:明细模型/聚合模型/更新模型。对SEC业务来说,目前以明细模型为主,后续如果有其他场景,再考虑应用其他模型。
2)数据分区/分桶
StarRocks提供的数据分区和分桶功能,可以很好的提升历史库存及周转场景下明细查询的性能。例如,历史库存查询常见的一种查询场景,是查询过去某一时间段内的库存周转情况,我们可以在StarRocks中根据出库时间进行分区,过滤掉不必要的分区数据,减少整个查询的数据量进行快速定位,尽量减少了查询语句所覆盖的数据范围,分区、分桶、前缀索引等能力,可以大大提高点查并发能力。这些特性对业务迎接增长,面对未来可能出现的高并发场景也具有非常大的意义。查询某一个物料条码(SN)的历史轨迹数据,能够快速的检索出该条码的所有历史出入库轨迹信息,帮助我们高效的完成供应链全生命周期回溯。
物化视图
我们利用StarRocks物化视图能够实时、按需构建,灵活增加删除以及透明化使用的特性,建立了基于库存物料SN粒度、基于产品类型特征粒度、基于库房粒度、基于分销商粒度的物化视图。基于这些物化视图,可以极大加速查询。
数据导入
数据导入StarRocks这里用到了两种方案:
1)在StarRocks提供的Broker Load基础上将离线数仓Apache Hive™的表导入到StarRocks中。
2)通过DataX工具,将SQL Server、MySQL上的数据导入到StarRocks。
StarRocks使用效果
灵活建模提升开发效率
结合使用宽表模型和星型模型,宽表和物化视图可以保证报表性能和并发能力,而星型模型可以让AP如TP里那样建模,直接进行关联查询,不必所有场景都依赖宽表准备,在数据一致性和开发效率上得到很好提升。另外,有不少表是在MySQL里的,我们通过 StarRocks 外表的方式暴露查询,省去了数据导入的过程,大大降低了业务方的开发和迁移周期。StarRocks的分布式Join能力非常强,结合View的能力构建统一的视图层,面下不同BI报表进行查询,提升了指标口径的一致性,降低了重复开发。
BI体验极好
前期部分BI可视化是基于SQL Server、 MySQL 构建的。部分看板不断优化和丰富需求后,加上多维度灵活条件筛选,每次加载很慢,有些Tableau报表很长时间才能加载出来,业务无法接受。引入StarRocks之后,我们用DataX将SQL Server数据导入StarRocks,这里使用了StarRocks-Writer插件,底层封装的Stream-Load接口,向量化导入效率非常高。MySQL可以通过外表insert into select流式导入,也可以直接外表查询,非常便捷。Tableau图表秒出,体验有了质的飞跃。
运维成本较低
数据中心是非常核心的一个线上服务,因此对高可用及灵活扩容能力有非常高的要求。StarRocks支持数据多副本,FE、BE仅仅2种角色组成的简洁架构,在单个节点故障的时候可以保证整个集群的高可用。另外,StarRocks在大数据规模下可以进行在线弹性扩展,在扩容时无Down Time,不会影响到在线业务,这个能力也是我们非常需要的。
总结
Lenovo联晟智达从今年(2021年)4月份开始调研StarRocks,POC测试阶段用了1/4的资源,就完美替代了数十个节点的Presto集群,当前StarRocks已经上线稳定运行。引入StarRocks后,实现了数据服务统一化,大大简化了离线数据处理链路,同时也能保障查询时延要求,之后将用来提升更多业务场景的数据服务和查询能力。