关于数据库:化繁为简|中信建投基于StarRocks构建统一查询服务平台

6次阅读

共计 3385 个字符,预计需要花费 9 分钟才能阅读完成。

近年来,在证券服务逐步互联网化,以及券商牌照红利逐步消退的行业背景下,中信建投一直加大对数字化的投入,尤其器重数据基础设施的建设,冀望在客户服务、经营治理等多方面由教训依赖向数据驱动转变,从而进步服务水平和决策效率。

因而,在公司总部和各分支机构,包含经纪、资管、投行等业务部门,以及稽核、审计、财务、法务等职能部门,对自助剖析、多维分析、固定报表和 API 数据服务等模式的用数需要始终在一直增长。

#01

需要背景

为了推动整体数字化建设和数据治理工作,中信建投曾经在 2019 年搭建了基于 Apache Hadoop (以下简称 Hadoop)体系的数据湖,将大量历史数据迁徙到 Hadoop 上,用 Apache Hive (以下简称 Hive)对数据进行加工解决,所有的查问计算都通过 Presto 执行。然而,该计划在最近两年数据量快速增长、业务场景多样化倒退的趋势下逐步无奈实用。具体而言,中信建投目前在数据查问剖析中次要存在以下痛点和需要:

1)数据加工链路简单

在数据分析的流程上,数据部门通常是首先用 Presto 做即席查问,再通过 Hive 进行数据加工,最初将加工过后的数据下发到各部门的 Oracle 或 MySQL 事务型数据库,业务人员在事务数据库里对下发数据进行查问和剖析。整个过程须要在三套零碎之间进行数据交换,且三套零碎应用的 SQL 语法也不统一,须要不同人员进行开发保护,从而产生了多种问题:

  • 数据开发和保护老本高
  • 数据口径可能不统一,导致数据利用后果不精确
  • 用数需要难以失去及时满足,通常要“T+1”能力给到数据报表

2)大数据量下性能有余,查问响应慢

中信建投目前大部分的数据都存储在 Hive 中,业务部门在进行自助剖析时通常波及的相干数据量较大,而 Presto 在大数据量、多表关联查问时会呈现响应比较慢,甚至无奈取得查问后果的问题,无奈满足单表及多表简单查问场景下响应的及时性。此外,Presto 因为资源隔离有余会呈现利用抢占资源的状况,不能很好反对高并发的查问申请。

3)大量实时数据扩散在各个业务零碎,无奈进行联结剖析

因为中信建投外部存在十分多的业务零碎,各业务零碎互相独立且数据会不断更新,而这些实时数据无奈更新到 Hive 中,导致业务数据之间不能及时买通进行联结剖析。

4)短少预计算能力减速固定查问

固定报表和 API 数据服务为各业务提供包含数据汇总后果、明细查问、数据接口在内的多项能力,而基于固定数据查问的可视化报表通常数据查问量大、计算维度较多,一个看板页面波及大概一两百个 SQL 语句,整体运算效率低下。针对这种状况,中信建投心愿通过预计算实现查问减速,并且要求开发工作轻量化且资源耗费较低。

#02

引入 StarRocks 构建对立查问服务平台

通过综合比照数据库即席查问、实时剖析性能、预计算能力、数据联邦技术,并且联合中信建投曾经在 Hadoop 体系中有大量投入,不心愿做大规模数据搬迁的具体情况,将 Hive 表面查问反对、SQL 语法及函数的兼容性等方面纳入选型思考,中信建投最终抉择引入 StarRocks 来构建对立的查问服务平台,满足各部门的用数需要

作为一款高性能全场景的剖析型数据库,StarRocks 应用 MPP 架构、可实时更新的列式存储引擎等技术实现 多维、实时、高并发 的数据分析。StarRocks 既反对从各类实时和离线的内部数据源高效导入数据,也反对不做数据转储,便可间接通过表面模式剖析查问数据湖的数据,对立的 SQL 交互将数据分析后果或物化视图预计算后果散发到各个数据利用,为中信建投实现了三套零碎应用性能的整合以及数据利用流程的简化。

具体而言,针对中信建投的痛点问题,StarRocks 具备如下劣势

1)在性能方面

针对大规模数据下自助 BI 麻利高效的需要,StarRocks 向量化执行引擎,全面实现了 SIMD 指令,保障查问和向量化导入能够充分利用单机单核 CPU 的解决能力;StarRocks 自研的 Pipeline 执行引擎,使得 StarRocks 能够应答更高的并发查问,充分利用单机多核 CPU 的解决能力,与此同时能够更优雅的进行 CPU 工夫分片调度从而实现资源隔离的性能;StarRocks 采纳大规模并行处理(MPP)架构,能够充分利用多机多核的集群资源,保障查问性能能够线性扩大;并用基于老本的优化器 CBO、Runtime Filter、提早物化、全局低基数字典等多种⼿段实现极致查问性能。

2)在内部表联邦查问方面

StarRocks 可通过创立内部表的⽅式,在 StarRocks 读取其余数据源,如 MySQL, Elasticsearch , Apache Hive 等内部表中的数据,从⽽突破数据的隔离。

以 Hive 表面性能为例,中信建投能够将其 Hive 中的离线数据导⼊ StarRocks 中进⾏⾼性能剖析查问。同时,StarRocks 也能够撑持湖仓一体联邦剖析,将离线数据与实时数据进⾏关联,买通不同数据存储间的壁垒,从⽽⽀撑业务剖析时在数据湖中进⾏数据探查和极致剖析的需要。

3)在预计算方面

为了实现固定报表的减速,StarRocks 引入预计算的伎俩,通过创立单表物化视图,在保障明细查问的同时能够减速聚合指标查问;通过多表物化视图、表面物化视图等形式,提供更灵便的按需建模能力,复用常见查问无效优化了简单 SQL 计算效率,满足用户对固定维度聚合剖析以及原始明细数据任意维度剖析的多样需要。

#03

落地后的成果与价值

1)大数据查问性能失去显著晋升

采纳 StarRocks 外部表减速明细数据关联查问,实现了上亿级别数据量大表关联秒级响应,内表查问效率晋升 10 倍以上 表面查问效率晋升 1 倍以上,齐全满足大数据量下查问剖析及时响应的需要;

2)预计算能力升高了固定报表加工成本

采纳 StarRocks 预计算能力能够将固定报表和 API 数据服务响应速度晋升 1 倍以上。多表物化视图、表面物化视图、Query Rewrite 等高阶性能,能够无效升高数据建模老本,使得“直面剖析,按需减速”成为可能。

3)升高数据迁徙老本,晋升数据管理和应用效率

StarRocks 基于 Hive 表面做查问,缩小了底层数据的迁徙老本,并实现了实时数据联通剖析。同时,以 StarRocks 为对立数据服务入口,升高了整体数据查问和加工的复杂度,晋升了数据管理和应用效率。

#04

我的项目经验总结

中信建投进行数字化转型过程中曾经部署了大部分的数据基础设施,然而已有的基于 Hadoop 构建数据湖的体系在近两年来暴露出泛滥问题,曾经无奈匹配业务的倒退速度。中信建投基于本身业务需要和已有技术架构状况抉择以 StarRocks 构建对立数据服务入口的实际,为同类型券商企业提供了以下教训倡议

1)剖析型数据库的选型须要 充分考虑企业本身的用数需要,以及现有数据平台的技术架构,抉择合乎本身理论状况的数据库是取得较好的落地成果的要害。例如,中信建投大部分的数据都存储在 Hive 中,StarRocks 提供的类 Presto 的表面查问性能能够防止数据迁徙减少的额定老本,同时也很好地满足了公司的用数需要。

2)随着企业数据库规模一直增长,以及剖析场景更加简单,剖析型数据库须要一直晋升数据查问剖析的性能,以及针对固定报表、自助 BI 等各种利用场景,提供场景化解决方案、生态工具,能力满足用户在数据查问剖析方面性能和性能的简单需要。

- 对于 StarRocks

StarRocks 是数据分析新范式的开创者、新规范的领导者。面世三年来,StarRocks 始终专一打造世界顶级的新一代极速全场景 MPP 数据库,帮忙企业建设“极速对立”的湖仓新范式,是实现数字化转型和降本增效的要害基础设施。

StarRocks 继续冲破既有框架,以技术创新全面驱动用户业务倒退。以后寰球超过 200  家市值 70 亿元以上的头部企业都在基于 StarRocks 构建新一代数据分析能力,包含腾讯、携程、安全银行、中原银行、中信建投、招商证券、众安保险、大润发、百草味、顺丰、京东物流、TCL、OPPO 等,并与寰球云计算领导者亚马逊云、阿里云、腾讯云等达成策略合作伙伴。

拥抱开源,StarRocks 寰球开源社区飞速成长。截至 2022 年底,已有超过 200 位贡献者,社群用户近万人,吸引几十家国内外行业头部企业参加共建。我的项目在 GitHub 星数已超 3800 个,成为年度开源热力值增速第一的我的项目,市场渗透率跻身中国前十名。

正文完
 0