Lenovo联晟智达隶属于寰球PC领导厂商联想集团,致力于打造科技驱动、柔性麻利、服务体验一流的智慧物流生态平台,面向产业端企业提供综合物流解决方案,成为服务于中国及寰球客户的智能供应链科技企业。联晟智达大数据团队逐渐引入了多种OLAP剖析引擎来更好的满足需要。StarRocks从泛滥的OLAP剖析引擎中怀才不遇,它采纳了全面向量化的计算技术,是性能十分强悍的新一代MPP数据库。通过引入StarRocks,构建了全新的对立数据服务平台,大大降低了数据链路开发复杂性,极大晋升了BI剖析效率。
“ 作者:韩文博,
联想销售物流大数据平台负责人,专一于数仓建设、数据分析等畛域钻研。 ”
OLAP引擎在Lenovo联晟智达的演进史
第一阶段
在2018年之前,联晟智达的数据总量还不是特地大,这个阶段应用的是传统关系型数据库(SQL Server),数据仓库体系还尚未建设,很多数据需要的实现都是以SQL脚本的开发方式来满足。
但随着业务复杂度一直晋升,以及数据量的快速增长,这种模式很快遇到了瓶颈。最次要体现在查问响应时效变得越来越慢。例如:之前运行一个工作须要10分钟或20分钟,当初须要一个小时或更长时间,查问效率重大降落。另外数据存储容量也存在瓶颈,无奈满足随业务而快速增长的数据量存储需要。
第二阶段
2019年随着数据仓库在Hadoop/Hive体系上搭建和欠缺,ETL工作全副转移至Hadoop集群,这个阶段应用数十台Presto实现OLAP剖析。Presto人造和Hive共享元数据信息,且独特应用物理数据存储,大量的对数仓表的灵便查问应用Presto实现。前端BI层面应用Tableau间接连贯Presto,实现数据分析与开掘。
第三阶段
2021年联晟大数据团队进行了离线数仓的整体设计和搭建,既须要做低延时的BI报表,又要满足Adhoc简单查问,同时对高效明细查问也有很高的要求。这个阶段咱们依据场景引入了OLAP圈煊赫一时的StarRocks产品,它既能做Presto的Adhoc多表关联查问及简单嵌套子查问,又能提供比ClickHouse更好的单表明细查问和多维物化视图上卷减速,满足极速BI剖析需要。
数据分析体系架构
OLAP体系现状
整个数据分析体系,由数据采集、数据存储与计算、数据查问与剖析和数据利用组成。
原始架构图:
数据采集
- 通过Sqoop读取RDBMS导入Hive。
- 用Flume来同步日志文件到Hive。
- 通过爬虫技术将网上数据爬取下来,存储到RDBMS,再由Sqoop 读取RDBMS,导入到Hive。
数据存储与计算
离线数据处理:利用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能力有余。
资源隔离还不欠缺。
StarRocks在SEC数据中心的利用实际
渠道仓配治理(SEC)的外围数据来自两大块:一个是生产业务;第二个是SMB中小企业务(Think、扬天)。基于这些数据,依据不同的业务场景需要,汇总出相干业务统计指标,对外提供查问剖析服务。
原有解决方案
在引入StarRocks之前,用到大量Hive工作进行业务逻辑荡涤加工,荡涤加工后的数据局部保留在Hive,局部数据写入MySQL/SQL Server,以达到数据的落地。前端BI通过Presto计算引擎连贯Hive、MysSQL、SQL Server等,实现报表剖析及数据可视化。
技术痛点
原有架构次要有以下两个问题:
- 数据逻辑没有很好做归拢合并,保护工作量大,新需要无奈疾速响应。
- Presto的在SQL较多的Tableau简单报表上响应较慢,不能满足业务即时看数需要。
因而咱们心愿对原有体系进行优化,外围思路是利用一个OLAP引擎进行这一层的对立, 对OLAP引擎的要求是比拟高的:
- 能撑持大吞吐量的数据写入要求。
- 能够反对多维度组合的灵便查问,响应时效在100ms以下。
- 比拟好的反对多表关联。
- 单表查问数据量在10亿以上,响应时效在100ms以下。
通过大量调研,StarRocks比拟符合数据中心的整体要求。StarRocks自身高效的查问能力,能够为数据中心数据报告提供一体化服务。新架构具备以下长处:
- 构造清晰,RDBMS专一于数据的荡涤,业务逻辑计算从Hive迁到StarRocks内实现,StarRocks就是数据业务逻辑的起点。
- 能够保护对立的数据口径,一份数据输出,多个APP接口输入。
- MPP分布式架构,得以更好的反对分布式聚合和关联查问。
- 和Tableau有较好的兼容性,能够满足外围BI剖析需要。
基于StarRocks的解决方案
降级后架构图:
数据表设计
1)数据模型设计
StarRocks自身提供三种数据模型:明细模型/聚合模型/更新模型。对SEC业务来说,目前以明细模型为主,后续如果有其余场景,再思考利用其余模型。
2)数据分区/分桶
StarRocks提供的数据分区和分桶性能,能够很好的晋升历史库存及周转场景下明细查问的性能。例如,历史库存查问常见的一种查问场景,是查问过来某一时间段内的库存周转状况,咱们能够在StarRocks中依据出库工夫进行分区,过滤掉不必要的分区数据,缩小整个查问的数据量进行疾速定位,尽量减少了查问语句所笼罩的数据范畴,分区、分桶、前缀索引等能力,能够大大提高点查并发能力。这些个性对业务迎接增长,面对将来可能呈现的高并发场景也具备十分大的意义。查问某一个物料条码(SN)的历史轨迹数据,可能疾速的检索出该条码的所有历史出入库轨迹信息,帮忙咱们高效的实现供应链全生命周期回溯。
物化视图
咱们利用StarRocks物化视图可能实时、按需构建,灵便减少删除以及透明化应用的个性,建设了基于库存物料SN粒度、基于产品类型特色粒度、基于库房粒度、基于分销商粒度的物化视图。基于这些物化视图,能够极大减速查问。
数据导入
数据导入StarRocks这里用到了两种计划:
1)在StarRocks提供的Broker Load根底上将离线数仓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后,实现了数据服务统一化,大大简化了离线数据处理链路,同时也能保障查问时延要求,之后将用来晋升更多业务场景的数据服务和查问能力。最初,感激鼎石科技的大力支持,也冀望StarRocks作为性能强悍的新一代MPP数据库引领者越来越好!