目录
一、为何引入StarRocks
二、主要应用场景
三、封装或扩展
四、集群监控预警
五、总结规划展望
5.1 使用经验分享
5.2 下一步计划
5.2.1 StarRocks集群自动安装
5.2.2 StarRocks集群高可用架构
原文大佬的这篇StarRocks应用实践有借鉴意义,这里摘抄下来用作学习和知识沉淀。
一、为何引入StarRocks
目前公司大数据平台已经引入了多个OLAP技术框架,随着应用的深入,在部分场景下发现这些框架也都由各自的缺点,主要体现在以下几个方面:
因此期望寻找一款能至少在部分业务场景下解决以上问题的新框架,与现有框架实现互补,理想情况下能替换调部分技术框架,满足功能需求的同时降低技术栈复杂度。
二、主要应用场景
目前我主要将StarRocks应用于业务数据的分析和大屏展示,业务数据经过实时清洗进入StarRocks或通过离线方式定时拉取写入StarRocks,再经过相应扩展分别提供给BI报表数据源,集成到大屏展示及通过SDK提供给业务代码访问。
根据业务数据对查询性能要求较高,且要求支持数据进行部分列更新的特点,我们主要采用的是主键模型。部分列更新是指每次更新数据按照主键,只需要更新指定字段数据,而非整行覆盖数据。以订单数据为例,订单数据量较大,且不同部分信息在业务库中存在不同表中。可以建立以订单ID为主键的主键模型,通过定时数据拉取任务,将业务库属于不同表的订单相关数据合并到StarRocks中订单明细表,避免查询时join引起的性能问题。
而对于数据量不大,且不经常需要查询的维度数据,则可以单独建立维度表,只在需要查询时进行关联。有效节省存储量,同时维表可以定时更新,保证维度数据是最新的。对于需要保持历史数据的维度字段,则可以像上面的订单各部分信息一样,采用部分列更新方式冗余在明细表上,做到业务需求和成本的有效平衡。这个场景的成功应用,得益于StarRocks对多表关联的支持。
三、封装或扩展
为了将StarRocks集成到公司的大数据平台中,并为业务部门提供相关组件和工具支撑,我们围绕StarRocks进行了以下封装或扩展:
- 大数据访问SDK:对StarRocks访问操作做了封装,并集成了响应时间,请求TPS,请求链路等监控埋点,以及请求日志,异常日志等功能。
- StarRocks查询工具:是一款Web方式访问的查询分析工具,方便业务部门同事开发/运维期间查询验证数据使用。
- Kettle和HUE StarRocksDataX插件:分别基于HUE和Kettle的进行扩展,提供了向StarRocks进行数据同步的插件,支持多种参数配置。
- StarRocks监控埋点:对StarRocks集群的相关运行参数进行采集,并集成到公司监控平台。
四、集群监控预警
通过将StarRocks监控指标参数抓取到公司监控预警平台,实现了StarRocks集群运行情况的实时监控和及时预警。
五、总结规划展望
目前初期阶段,StarRocks投入应用场景50+,总表个数200+, 数据总量超过5TB,相关功能在切换后,在响应时间,存储成本等方面都有相应改善。
5.1 使用经验分享
- 合理设置分区分桶键,分区和分桶应该尽量覆盖查询语句所带的条件,这样可以有效减少扫描数据,提高查询性能。
- 合理设置分区和分桶大小,实现数据均衡分布,单个分区原始数据量建议不要超过100GB,单个分桶控制在100M到1G左右,最大不要超过10G。太小造成小文件tablet太多,影响磁盘IO,太大不利于资源合理分配并影响查询效率。
- 排序键不应该包含过多的列,对于主键模型而言,key列大小不能超过127个字节。选择过多排序列并不能提升查询性能,而且会增大排序的开销,进而增加数据导入的开销。
- 当排序键涉及多个列的时候,建议把区分度高、且经常查询的列放在前面。区分度高的列是指取值个数多,且持续增加的列。
-
查询时尽量只select需要的字段, 减少不必要的开销。
-
关联维表可显式添加shuffle关键字进行优化(Join Hint 语法,手动指定join类型)。
-
数据量非常大的维表中常用字段,考虑在主表进行冗余(维度退化)。
5.2 下一步计划
5.2.1 StarRocks集群自动安装
目前在搭建不同环境时,都是手动进行StarRocks的部署和配置。重复进行相同工作,且手工处理易出错,效率低。计划将StarRocks集成到公司的大数据安装框架,实现StarRocks安装部署和元数据初始化的自动化。提高部署效率,降低运维成本。
5.2.2 StarRocks集群高可用架构
随着越来越多的业务迁移到StarRocks,特别是一些重要级别较高业务的迁移,对StarRocks的可用性提出了更高的要求。虽然StarRock本身通过其架构特点提供了一定的高可用性。但我们仍然计划基于自建的集群高可用框架,在数据双写的基础上提供集群级别的高可用,以实现在集群宕机时故障的快速转移,高可用框架的主要架构如下:
参考文章:
特来电StarRocks应用实践