乐趣区

关于数据库:CloudCanal-x-StarRocks-在医疗大健康实时数仓领域的落地与实践

jiezi

  • 简述

    本案例为国内某大衰弱畛域头部公司实在案例(因用户窃密要求，暂不走漏用户相干信息)。心愿文章内容对各位读者应用 CloudCanal 构建实时数仓带来一些帮忙。

# 业务背景

大衰弱背景下，用户对报表和数据大屏的实时性能要求越来越高。以核酸检测为例，检测后果须要实时统计分析，并在决策大屏中进行可视化展示。数据的及时性间接关系到区域疫情防控的精准布施从而无效避免疫情的扩散，不容半点闪失。在此之上，业务的多样性和复杂性也对公司的研发和运维老本要求也越来越高。

例如疫情防控指挥决策大屏中，数据包含流调溯源数据、物资冷链数据、寓居人口数据、重点人群数据、危险排查、隔离管控、核酸检测数据、疫苗接种数据。这些起源数据规范不一，扩散的数据引发数据冗余、数据不统一、数据利用艰难等问题，导致研发和运维老本的回升，须要通过一个良好的接入层将这些数据做汇总和对立治理。

在此背景下，我司在更高效数据 ETL 形式以及高性能数据分析工具选型方面一直尝试和翻新。通过引入了 CloudCanal 和 StarRocks，在数仓建设、实时数据分析、数据查问减速等业务上实现了效率最大化。

# 业务架构

我司旗下领有多款大衰弱产品。尽管各款产品的具体业务不同，然而数据流的链路基本一致：数据接入 -> 数据处理与剖析 -> 数据利用。

上面以 疫情防控零碎 为例简略介绍其中数据流的生命周期：

  • 数据接入：首先疫情防控零碎的数据次要是三个起源、人员数据、冷链数据、物资数据。这些数据通过对立标准化解决之后能力用于剖析
  • 数据处理与剖析：原始的数据通过整合和标准化，能够从数据分析出密接人员、密接关系图谱等信息
  • 数据利用：数据处理与剖析的指标能够用于实时监控大屏、以及相干预警

|--|

# 原有技术架构以及痛点

针对疫情防控零碎，咱们最后抉择 ClickHouse 作为剖析层，通过 DataX + Flink CDC 的模式实现实时 + 离线数据同步。随着业务的迭代，这套架构曾经无奈满足咱们的需要。

## 技术架构

|--|

原有疫情防控的架构总体上分为四块，自底向上别离是：

  • 数据层：源端数据源次要是 MySQL 为主的关系型数据库。
    • 业务信息：以核酸检测业务性能为例，须要撑持单日 300 万 核酸检测工作。要求撑持每秒 1000 并发
    • 技术信息：数据层采纳 MySQL 主从同步，配置级架构如下：

|--|

    • 痛点：
      • MySQL 从库查问效率满足不了惯例读操作，查问效率低下，急需数据查问减速
      • 研发人员大量的精力和工夫放到了数据库查问优化上
  • 解决层：采纳离线 + 实时的 lambda 架构。其中离线局部采纳 DataX 和 Kettle 进行定时全量，迁徙源端维表到剖析层的宽表中。实时局部应用 Flink-CDC 获取增量数据，个别是用于减速两头数据和近期的热数据。离线和在线数据别离存储在 ClickHouse 不同表中，提供给业务侧查问应用。
    • 业务信息：
      • 离线：将报表、大屏、数据交换服务采纳离线形式构建 DM 主题数据集市。应用到的就是 Datax 工具联合实现。
      • 实时：应用 Flink CDC 将 MySQL 数据 1:1 同步到 ClickHouse 中。程序端通过革新查问 SQL 将慢语句通过 ClickHouse 实现。
    • 技术信息：整体架构如下

|--|

    • 痛点：
      • 报表、大屏、数据交换离线场景对数据的实时性要求越来越高。大部分场景已不实用 DataX 这种离线计划。
      • DataX 定时任务调度带来的运维老本和源库影响：各种定时调度工作大大增加了运维治理的难度；同时这种定时触发的 SQL 很容易产生慢 SQL 影响源端数据库的失常工作。
      • Flink CDC 通过主库 Binlog 同步时呈现过锁表影响业务的状况，尽管之后替换为订阅从库解决，然而会呈现提早景象。
      • Flink CDC 运维老本较高：Flink CDC 实时同步机制须要研发人员专职进行保护。例如像源端新增字段这种 DDL 需要，研发须要一直调整调度工作能力确保业务失常运行。
  • 剖析层：剖析层会保留计算好的指标数据以及用于减速查问的两头后果数据。
    • 业务信息：
      • 搭建三台单体 ClickHouse，别离对应 报表业务、大屏业务、数据交换服务、数据查问减速。
      • 以大屏业务举例，后期因为需要变动大，研发间接应用 ClickHouse 对单表过亿的数据进行数据关联、分组统计。高并发状况下也造成 ClickHouse 呈现 CPU 打满的状况。ClickHouse 慢语句如下图。

|--|

    • 痛点：
      • 集群运维较简单，须要应用 Zookeeper 搭建 ClickHouse 集群，运维老本高。
      • SQL 语法不兼容 MySQL，开发上手门槛高、Join 不敌对
      • 批改、删除以及数据去重性能损耗大：例如应用 ReplacingMergeTree()引擎，须要解决反复数据同时去重对性能要求较高。
      • 并发能力差：单机 ClickHouse 在高并发下，CPU 常常被拉满，呈现解体状况。
      • 业务层：业务层次要是应用程序拜访剖析层的指标后果或者通过查问两头后果来减速查问性能。最终的查问后果会服务疫情防控零碎的实时大屏、报表以及预警等相干数据服务。
      • Clickhouse 集群运维门槛高，之前在 20.3 版本呈现过 DDL 工作和查问陷入死锁 BUG，造成集群故障，最初放弃集群计划。采纳 3 个单机通过 Flink-CDC 负责数据同步。
  • 业务层
    • 业务信息：次要是 BI 业务（报表、大屏）、数据查问减速、数据交换。
    • BI 业务：平台报表业务和大屏业务全副接入 ClickHouse 数据库。
    • 数据查问减速：通过监控 MySQL 慢语句将慢语句也接入 ClickHouse 进行查问出现。
    • 数据交换：ClickHouse 负责与第三方平台进行数据交换工作。

### 数据源接入

接入的监测数据扩散在各个数据库实例和数据库中。咱们遇到的问题次要是：

  • 构造迁徙老本高：很多表是一对一同步的，每次须要人为在 ClickHouse 上进行建表，减少了数据接入的老本
  • 人工操作多：须要接入的表人工筛选老本大
  • 新增表接入不不便：新增表接入须要从新批改配置

# 现有零碎架构以及劣势

## 架构介绍

|--|

新架构档次划分与原有架构基本相同，咱们对解决层与剖析层的技术栈选型进行了一些调整。在原有架构中，咱们应用 DataX+FlinkCDC 的计划实现了数据的实时与离线同步传输。在替换 CloudCanal 后，对立实时离线两套技术栈，缩小了运维老本。剖析层中，通过应用 StarRocks 替换 ClickHouse，在性能，运维老本，业务扩大上也带来了极大的晋升。

## 新架构劣势阐明

### 引入 CloudCanal 数据同步工具

  • 异构数据源接入效率高：提供了库表列裁剪映射、各种维度的筛选能力等
  • CloudCanal 人性化的操作页面以及低代码操作形式，开释了业务线的研发人员
  • 构造迁徙、全量、增量一体化
  • 监控、报警运维便当

### 引入 StarRocks MPP 数据库

#### OLAP 数据库产品选型

针对于剖析层的问题与挑战，咱们着力于寻找一款高性能，简略易保护的数据库产品来替换已有的 ClickHouse 架构，同时也心愿在业务层上能冲破 ClickHouse 单表查问的限度，通过实时多表关联的形式拓展业务层的需要。

目前市面上的 OLAP 数据库产品百花齐放，诸如 Impala、Druid、ClickHouse 及 StarRocks。在通过一些列的比照之后，咱们最终敲定抉择 StarRocks 替换原有的 ClickHouse 作为剖析层的数据库引擎。

|--|

#### 接入 StarRocks

StarRocks 是一款极速全场景 MPP 企业级数据库产品，具备程度在线扩缩容、金融级高可用，兼容 MySQL 协定和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查问等重要个性，在全场景 OLAP 业务上提供对立的解决方案，实用于对性能，实时性，并发能力和灵活性有较高要求的各类利用场景。

通过初步的考量，咱们认为，StarRocks 兼容 MySQL 协定与规范 SQL，相比于 ClickHouse 对于业务开发人员更加敌对。同时，弱小的多表关联能力能够将原有的大宽表模型转换为星型 / 雪花模型，减少了建模的灵活性，更好的应答业务需要的迭代。在运维方面，自动化调度机制能够反对在线扩缩容，能够极大的缩小在 ClickHouse 上的运维老本。

####

#### 剖析层革新收益

在引入 StarRocks 对系统进行降级革新后，极大水平的缩小了本来 ClickHouse 中的慢查问。整体查问效率晋升 2~3 倍。上面是生产环境业务中两张外围表。其中以咱们一个典型的统计 SQL 为例，能够看到 StarRocks 带来了显著的性能晋升。

| 表名 | 行数 |
| ——————- | ——- |
| rhr_person_info | 3451483 |
| chm_children_should | 6036599 |

ClickHouse 侧执行 SQL

select count(0) from rhr_person_info a 
inner join chm_children_should b 
on a.id=b.person_id 
where toDate(b.should_start) <= toDate('2022-03-01') 
and  toDate(b.should_end) >= toDate('2022-03-02') 
and (credentials_number = '%zz%' or en_name like '%zz%') 
and create_type_code =2 
and is_deleted =0 
and district_id like '130926105%'

StarRocks 侧执行 SQL

--starrocks
select count(0) from rhr_person_info a 
inner join chm_children_should b 
on a.id=b.person_id 
where date_format(should_start,'%Y-%m-%d')  <= ('2022-03-01') 
and date_format(should_end,'%Y-%m-%d') >= ('2022-03-02') 
and (credentials_number = '%zz%' or en_name like '%zz%') 
and create_type_code =2 
and is_deleted =0 
and district_id like '130926105%'

查问响应工夫比拟

| | StarRocks | ClickHouse |
| ———— | ——— | ———- |
| 均匀响应工夫 | 368ms | 3340ms |

在体验至极性能的同时，咱们在维护性，灵便建模等方面也取得了极佳的体验：

  • StarRocks 兼容 MySQL5.7 协定和 MySQL 生态
  • 反对高并发剖析查问
  • 不依赖于大数据生态
  • MPP 架构，分片分桶的复合存储模型
  • 运维简略，易用性强
  • 程度扩大，不依赖内部组件，不便缩扩容
  • 反对宽表和多表 Join 查问（简单场景），数据查问秒级 / 毫秒级

## 新架构成果阐明

## 服务器资源正当开释（以核酸检测业务为例）

| 比照 | 数据层 | 解决层 | 剖析层 |
| —— | —— | —— | —— |
| 原架构 | 4 台 | 2 台 | 3 台 |
| 新架构 | 2 台 | 1 台 | 3 台 |

## 人力老本的开释

原架构在数据层和解决层研发人员工作占比为 60%，每一个业务的调整须要与 DBA 一起测试查问 SQL，防止出现慢语句同时业务零碎随着需要的减少常常有减少字段的需要，研发人员须要一直调整和公布 Flink CDC 调度。新架构只须要 ETL 工程师负责运维即可，体现了 CloudCanal 低代码和便捷的运维劣势。

## 运维老本的升高

StarRocks 部署不须要大数据组件的撑持，部署运维都很简略。StarRocks 兼容 Mysql 生态，业务应用可间接应用 Mysql JDBC 进行连贯，不必再放心 SQL 语法差别问题。

# 将来布局

目前，咱们曾经上线了 2 个产品线的 StarRocks 集群，通过 CloudCanal 更好的实现了实时数仓的搭建，曾经在公司外部进行推广，后续会有更多的利用落地。感激 CloudCanal 团队和 StarRocks 团队提供业余的反对服务。

# 参考链接

  • CloudCanal 社区版官网文档
  • StarRocks 官网文档

退出 CloudCanal 粉丝群把握一手音讯和获取更多福利，请增加咱们小助手微信：suhuayue001
CloudCanal- 收费好用的企业级数据同步工具，欢送品鉴。
理解更多产品能够查看官方网站：http://www.clougence.com
CloudCanal 社区：https://www.askcug.com/

退出移动版