水滴筹基于阿里云 EMR StarRocks 实战分享_starrocks最佳实践

摘要：水滴筹大数据部门的数据开发工程师韩园园老师为大家分享水滴筹基于阿里云EMR StarRocks的实战经验。

本篇内容将会围绕以下五个方面展开：

1.公司介绍
2.StarRocks 概览
3.场景实战
4.最佳实践
5.未来规划

一、公司介绍

水滴创立于2016年，业务包括水滴筹、水滴保险商城等，于2021年5月7日上市。水滴以“用互联网科技助推广大人民群众有保可医，保障亿万家庭”为使命，致力于为用户提供健康保障解决方案。希望联合合作伙伴打造中国版联合健康集团，让用户以更低的费用享受到更好的诊疗。

自2016年7月至2022年末，水滴筹平台的捐款人达到了4.3亿，有超过277万的大病患者得到了帮助，总计筹集医疗资金达到569亿元，并提供了755个保险产品。

二、StarRocks 概览

使用历程

首先来梳理一下水滴筹在OLAP方面的发展历程。

• 2018年，引入ClickHouse，主要用于监控报警和用户相关的行为分析工作，包括漏斗、留存等。
• 2020年，引入TiDB，主要用于OLAP分析和报表展示。
• 2021年，针对当时组件的一些痛点，也为了探索更多的OLAP引擎，引入StarRocks v1.17.8（DorisDB）版本，自建StarRocks集群，用于OLAP分析。
• 2022年2月，升级StarRocks集群到v1.19.5版本，用于报表展示。
• 2022年10月，迁移自建StarRocks集群至阿里云EMR StarRocks，并将大数据的TiDB所有的服务迁移到StarRocks上，版本为v2.3.2。
• 2023年3月，参加阿里云EMR Serverless StarRocks集群公测，并将集群新功能尝试应用于新业务中。

水滴现状

从上表可以看到水滴对各个组件的使用场景，以前以TiDB作为主要组件进行OLAP分析和OLTP，少部分服务使用StarRocks；实时监控、用户行为分析还在ClickHouse中。

随着近几年业务的发展、实验的沉淀， OLAP组织架构也存在一些问题，如组件维护困难，数据冗余存储，数据收口和出口不统一等情况。水滴大数据希望引入一款实时OLAP数据库，统一数据的监控和查询，用于解决各业务线对数据高效实时数据查询和数据统计分析的需求。

水滴OLAP组件技术选型

水滴对OLAP引擎最关注的有四点，分别是：并发能力，物化视图，join能力和写入实时。

上表是基于水滴通过近几年的实践得到的结论，可以看出：

• StarRocks在并发能力、物化视图、join能力和写入实时方面整体都是比较优秀的。
• ClickHouse的并发能力和join能力相对较弱。
• TiDB的并发能力和join能力中等，但是不支持物化视图，导致用户体验不是很好。

基于几个组件的使用和综合考虑，水滴最后决定将StarRocks作为最终的OLAP引擎，将TiDB的服务迁移到StarRocks中，开始实施组件的统一。

三、场景实战

概览

水滴OLAP整体架构如上图所示。主要分为如下几个部分：数据源、数据同步、OLAP引擎、应用场景和数据管理平台。

数据源又分为离线数据和实时数据。

• 离线数据主要存储在MaxCompute，通过BrokerLoad、SparkLoad两种同步方式，同步到StarRocks中，时效性是T+1或者小时级别。
• 实时数据主要是一些业务和埋点数据，存储在MySQL、TiDB和Kafka中，通过Flink-CDC、Flink-SQL以及自研Galaxy平台进行实时同步。

数据进入OLAP引擎后，水滴主要用到三种表模型，分别是：明细模型，聚合模型和主键模型。

• 明细模型用于存储明细数据和业务统计完成之后的数据。
• 聚合模型用于存储根据业务场景预聚合的数据。
• 主键模型用于存储业务的实时数据。

数据模型主要用到宽表、星型模型和雪花模型三种。

数据管理平台主要包括：元数据管理，稳定性保障，质量管理，以及数据安全。

目前水滴的集群规模为，包含3台FE和7台BE，每日查询量300万次。

数据写入方面，有1500多个离线任务，每日实时更新行数100万行以上，每日写入数据量1T以上。

下面以两个具体的场景为例来介绍水滴的StarRocks实战。

场景一：报表平台OLAP引擎统一

第一个场景是报表平台OLAP引擎统一。

水滴报表平台之前主要使用TiDB作为存储和查询引擎，后来又引入了StarRocks，由多个组件构成了我们的OLAP引擎。这样的架构存在如下三个痛点：

• 组件多，维护不便；
• 成本高；
• TiDB的并发限制和慢SQL的问题，导致客户体验不佳。

报表查询面对三大挑战：

• 查询高并发
• 响应低延迟
• 大数据量多表Join

在水滴报表平台之前的流程中，无论是离线数据还是实时数据，都会写入到TiDB和StarRocks中，然后提供报表平台或者业务系统进行使用。经过一段时间的测试和使用，评估StarRocks可以作为水滴报表平台的主要引擎，后续会将TiDB迁移到StarRocks中。

切换之前，水滴对两个平台做了压测对比。

上图中，左边是两个集群的详细参数。

首先将TiDB的所有数据同步到StarRocks中，保证压测的数据是完全一致的；然后，使用报表平台的所有SQL查询，在相同数据、相同SQL、相同并发的情况下，同时在TiDB和StarRocks中循环遍历执行这些SQL，经过一段时间的测试，基于水滴的使用场景和水滴数据针对两个引擎的查询性能得到了如下的结论，下面以TiDB中SQL的响应时间分成三部分进行对比，因为大部分响应时间都在这三个分段内：

• 在TiDB中，执行时间在400ms以内的SQL在StarRocks中执行时间为200ms以内
• 在TiDB中，执行时间在400ms到1.5s的SQL在StarRocks中执行时间在184ms到300ms以内
• 在TiDB中，执行时间在1.5s到4s的SQL在StarRocks中执行时间为198ms到500ms以内

水滴大数据部门经过架构优化后，统一了OLAP引擎为StarRocks，将离线和实时数据写到StarRocks之中，提供给业务系统以及报表平台使用。

新架构的优点是结构比较清晰，也维护了统一的数据口径。

上图从三方面展示了架构迁移后的效果：

• 通过将TiDB迁移到StarRocks，实现了组件统一，系统的运营成本得到了一定程度的降低。平台整体成本降低了58%，整体性能提升了40%。
• 观测TiDB和StarRocks响应时间的tp99，可以看到TiDB响应时间的tp99在3秒左右，而StarRocks响应时间的tp99基本是几百毫秒，在1秒以内。
• 数据离线同步耗时以及慢SQL，StarRocks都有一定程度的提升。

在迁移StarRocks的过程中也遇到一些问题：

• StarRocks的DDL和DML与TiDB/MySQL相比虽然兼容90%场景，还是存在一些不兼容问题，上表中列举了一些不兼容的情况以及相应的解决方案。
• 数据没办法直接从MaxCompute同步到StarRocks，必须中间有一层OSS的中转。

场景二：数据服务遇到问题

场景二是公司的财务推帐系统。

财务推帐系统使用TiDB作为数据存储查询引擎，面临的核心挑战是：

• 数据实时性要求高；
• 数据一致性要求高；
• 数据的计算逻辑复杂；
• 数据分析需求灵活。

财务推帐系统所需的数据涉及多张表，每张标的数据量都是上亿级别，推帐需要多张上亿级别的表相互Join才能实现。因为TiDB的并发和内存的限制，目前没办法对这些表多表关联直接聚合处理，所以水滴先根据ID进行分段聚合，然后通过代码的聚合方式，写到中间表中。因为推帐是分场景的，处理时间最长的场景需要30分钟的时间，所有300多个场景并发处理，最终也需要4-5小时的时间。对财务同学的工作效率，有一定的影响。

改造之后的流程为：

数据首先实时写入TiDB中，然后从TiDB实时写入StarRocks中，因为中间聚合的数据进行反推，因此需要先进行快照数据留存后，StarRocks中的数据可以直接分场景聚合处理，单场景的最大耗时为30秒左右。

架构升级后，性能直接提升60倍，TiDB只参与存储不再参与计算，其引擎压力降低了70%，但是由于数据同时留存在TiDB和StarRocks中，存储成本有一定程度的增加。

四、最佳实践

表设计方面

• 绝大部分表都按照时间字段进行了分区，使用常用的查询列以及关联的关键列作为分桶；
• 将经常过滤和group by的列作为排序键，优先使用整型作为排序键；
• 对于明细数据，由于数据量比较大，用动态分区做数据过期的设置；
• 建表时尽量使用精确的字段类型，例如：数字类型数据不用字符串类型，INT能满足的不用BIGINT，知道字符串长度范围的数据不用String类型；
• 数字列尽量放到字符串的列之前。

数据同步方面

• 离线写入主要用的是BrokerLoad和SparkLoad两种同步方式；
• 实时写入采用Flink-CDC和自研Galaxy平台同步方式；
• 实时写入需要控制数据写入的频率，降低后台合并的频率，保证程序稳定和数据的一致性；
• 使用UniqueKey的replace_if_not_null对部分列进行更新，PrimaryKey直接支持部分列更新。

运维和监控方面

• 对FE进行四层的负载均衡，保证查询请求的高可用，同时也保证查询请求的负载均衡；
• 优化集群参数，来提高集群的查询性能：
  • 提高StarRocks的查询并发(parallel_fragment_exec_instance_num)
  • 提高单个查询内存限制(exec_mem_limit)
• 使用Prometheus+Grafana进行集群监控告警；
• 对查询历史进行分析，统计和监控慢SQL、大SQL，及时告警和优化。

权限与资源方面

• 细分账户，避免混用，实现更好的监控和维护，方便将大SQL、慢SQL准确定位用户；
• 根据业务和实际使用场景来划分资源组，对查询进行资源隔离，保证业务之间不互相影响；
• DDL操作权限收敛到统一平台，增加数据的安全和集中控制。

数据管理与质量方面

• 根据查询记录定期分析使用情况，做好表生命周期管理；
• 离线同步数据T+1进行数据质量校验；
• 实时同步小时和天级别进行数据质量校验。

当前问题

• 业务需要但是目前没有支持AUTO_INCREMENT和CURRENT_TIMESTAMP；
• String类型的数据长度有限制，对于某些长度较大的字段智能过滤或者无法适用；
• 现有日志格式对于错误日志分析不是很友好;
• 实时数据的写入频率不好把控，写入太快会造成版本合并的问题，写入太慢又有数据延迟问题；
• 时间字段不支持毫秒；
• CPU无法完全隔离；
• 表权限目前还不能控制到行级别。

五、未来规划

水滴大数据部门的未来规划主要从三方面入手，分别是用户画像、监控报警和用户行为分析。

用户画像

• 当前组件：HBase+ES
• 业务场景：消息推送、用户圈选
• 场景特点：更新频繁，每天20-30亿的数据更新量，数据量大，列动态更新
• 当前痛点：因为业务主要通过ES进行用户圈选，查询效率比较低，无法实现多表Join；
• 切换难点：如果要切换StarRocks，重点考虑的问题是，一张1000亿+的列，14亿数据的大宽表，需要频繁动态更新列，平台是否能够支持。

监控报警

• 当前组件：埋点上报+ClickHouse
• 业务场景：实时监控
• 场景特点：实时性要求高，查询可物化
• 当前痛点：并发收到受限，读会影响数据写入
• 切换难点：切换到StarRocks的难点在于，监控需要分钟级或者更短的时间，对数据的准实时性要求高

用户行为分析

• 当前组件：ClickHouse
• 业务场景：漏斗，留存，路径分析
• 场景特点：数据量大，单表1000亿+数据，每天增量数亿；查询周期长，用户需要查一个月、三个月、半年以上的数据；大表join，需要将用户行为表与用户画像进行关联分析，实现数据的圈选或者查询操作
• 当前痛点：两个以上的大表join性能不佳

切换难点：切换到StarRocks的难点在于，当前系统使用了大量的ClickHouse内置窗口函数和数组函数，在StarRocks对应的替代函数的准确率和适配度等有待验证。

水滴大数据部门对2023年StarRocks相关的计划包括：

• 2023年上半年，将更多业务场景接入StarRocks中，实现更全面的权限控制和资源隔离；
• 2023年7月，升级StarRocks到2.5以上版本，使用嵌套物化视图探索更多业务场景，将StarRocks应用于数据画像，尝试替代ES；
• 2023年10月，将埋点数据和Binlog数据实时写入StarRocks中，探索StarRocks在漏斗、留存、行为分析场景的使用，尝试替代ClickHouse；
• 2023年底，水滴大数据部门的规划目标是实现OLAP引擎统一，探索更多新功能、新场景。

六、致谢

在分享的最后，感谢阿里云StarRocks团队对我们的技术支持，使得我们更快更好地将StarRocks应用于各种场景中。水滴也会跟紧社区的步伐，更好地解决场景需求。

最后祝阿里云StarRocks发展得越来越好。

原文链接

本文为阿里云原创内容，未经允许不得转载。