共计 5262 个字符，预计需要花费 14 分钟才能阅读完成。
摘要：水滴筹大数据部门的数据开发工程师韩园园老师为大家分享水滴筹基于阿里云 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 倒退得越来越好。
原文链接
本文为阿里云原创内容，未经容许不得转载。
