摘要：水滴筹大数据部门的数据开发工程师韩园园老师为大家分享水滴筹基于阿里云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倒退得越来越好。

原文链接

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