某邮储银行数据归集系统在HTAP场景下的选型与实践

导语:面对HTAP能力的需求与云原生时代的趋势,以及国产化的浪潮,某邮储银行携手OceanBase打造了云原生时代下的国产分布式数据库场景实践体验。以下内容整理自某邮储银行运维方DBA的自述。

 

业务痛点

 

我们有一套针对业务内部的运营数据归集系统,各地的服务网点都将各类生产数据、经营数据及运营数据进行上报,还有前端用户埋点数据、各子系统生产数据表单汇集,数据源的格式多样,数据聚合程度不一,计算方式复杂多样。目前,我们采用两种方式进行数据采集。

  • 人工上报:通过员工自行制表、填表将数据上报至系统中的固定页面,进行运算。

  • 机器抓取:一些老系统或无法提供接口,就需要通过RPA自动化机器人抓取数据,这是整个基础数据的来源。抓取数据后汇总,并用Java在程序中进行计算,将数据沉淀至报表,以供前台实时读取。

面对每天的数据增长,而且内部运营系统的数据不能直接完成实时分析,需要将其汇总成特定格式进行转换计算,做成战略面板,提供顶层决策分析能力。我们使用的数据库系统是MySQL,在大众印象中,MySQL侧重于OLTP(联机事务处理),在OLAP(在线分析处理)方面的性能如高可用、备份等方面表现较弱,这些痛点在我们使用MySQL的过程中也确实感受到了。而随着我们业务并发量的提高和数据量的增长,既要求较强的OLTP能力,又需要OLAP能力的支撑,且软硬件及服务成本不断升高。面对传统关系型数据库的许多技术难题,比如海量数据下sacle in or out(弹性扩展)的算力不足、不能原生解决单点故障和全链路高可用、OLTP+OLAP场景无法实现一体化,我们决定探索HTAP(混合事务分析处理)数据库,实现降本增效的目标。

 

产品调研

 

在决定探索HTAP数据库后,我们最先了解到的是OceanBase。因为公司有一个项目正在使用阿里云的PolarDB,但PolarDB必须在云端部署,而我们的业务需求是本地部署,所以,OceanBase成为我们的首个研究目标。OceanBase兼容MySQL的特性很吸引我们,而最终选择OceanBase是出于以下几个因素。

  • 因素1:稳定可靠。 OceanBase十二年稳定可靠的产品力和在支付宝全核心场景替换MySQL的实践,以及应用于众多行业多个大型客户核心场景,为我们在业务场景中使用它建立了信心。
  • 因素2:AP性能优秀。 在类似的OLAP场景中,我们曾经使用过GBase、PostgreSQL、Greenplum,在复杂的SQL查询方面速度较慢,并且当用户量大的时候再连接这些数据库,都会出现各种各样的问题,也有可能是我们自身资源不足的导致的。我们在测试OceanBase的性能时,采用现有环境即2核40C80线程、256GB内存的环境,测试了TPS和QPS, 以下是在3000并发量下Sysbench的读写混合测试结果。这个测试结果完全满足了业务要求。

 

SQL statistics:
    queries performed:
        read:                            2405494
        write:                           687284
        other:                           343642
        total:                           3436420
    transactions:                        171821 (2859.31 per sec.)
    queries:                             3436420 (57186.17 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          60.0903s
    total number of events:              171821

Latency (ms):
         min:                                   29.15
         avg:                                  104.83
         max:                                  414.93
         95th percentile:                      155.80
         sum:                             18012703.78

Threads fairness:
    events (avg/stddev):           572.7367/30.91
    execution time (avg/stddev):   60.0423/0.02

 

因素3:运维简单。 目前的业务需求需要在AP与TP之间找到一个平衡点,如果AP场景和TP场景使用不同的数据库,势必会增加技术栈的深度,增大运维难度,而业务对于两种使用场景并不是强依赖的关系。使用混合型的HTAP产品,无疑是最好的选择,也是一种良好的探索与尝试。OceanBase运维简单,只需一套OCP工具就能搞定。且系统告警提供了丰富的扩展功能,可以与现有监控对接。运维人员每天只是关注重要数值,观察有没有报警,运维管理比较轻松。

因素4:国产化趋势。 我们无法预料MySQL在未来是否会被限制,也无法确定是否所有系统都会逐渐成Linux,但可以肯定的是要防患于未然。因此,研究完全国产自研且开源的数据库是一条出路,未来如果真要替换全部系统,至少到那时我们已经有一定的技术积累和沉淀,能够应对引进软件限制的问题。

因素5:适用业务且容错。 OceanBase主打HTAP,具有高可用和容灾能力,非常适用于我们的业务。同时,我们要应用数据库的系统不完全是生产系统,而是一个后台的报表,它处于核心系统与边缘系统之间,有一定的容错性,因此,决定先在这个报表环境中尝试使用OceanBase。

因素6:及时响应。 OceanBase开源后社区活动与响应都很积极,虽然有些生态还在完善,但是能感觉到OceanBase开源的产品力在显著提高。

 

场景实践

 

决定使用OceanBase后,我们开始了环境部署,表1列出部署参数。

 

某邮储银行数据归集系统在HTAP场景下的选型与实践_第1张图片

图1 OceanBase三节点部署架构

 

上文提到,随着业务数据量的增大,我们原本使用的MySQL不符合业务要求,部署OceanBase后,我们开始重构系统和底层数据底座,经历了以下四个阶段。

 

第一,POC阶段。 “如果有什么问题或者和MySQL不一致,你们就直接报错,我们看如何解决”,这是我当时对OceanBase的研发支持人员说的话,但我惊喜地发现,OceanBase能够与我们使用的MySQL 5.7.18版本良好兼容,可以轻松实现零成本迁移。在此过程中,我们遇到了两个问题,一是SQLSTATE[0A000]: Feature not supported: 1235 while parameter _ob_enable_prepared_statement is disabled, prepared statement not supported,通过参数调整,轻松搞定;二是应用数据的迁移人员在使用Navicat进行迁移的时候,出现了一些结构化语句不兼容的问题,我们惊喜地发现Navicat16.1版本开始,有了OceanBase的专用驱动连接,使用后兼容性问题完美解决。

 

第二,数据迁移阶段。 我们使用了OceanBase 迁移服务(OceanBase Migration Service,OMS)完成了MySQL数据的在线无缝迁移。

 

第三,数据库侧改造阶段。 我们的应用测试基本不用改造,就将MySQL的分区数据、表结构等迁移到了OceanBase,并且一切运行正常,查询性能和查询效率都超出预期。同时,对于开发人员来说,他们无需投入学习成本,在OB上操作与此前在mysql上无异。

 

第四,实际上线阶段。 在该阶段,我们暂停了业务写入,等待系统迁移完成,并在新业务流量写入OceanBase集群后,观察业务波动。割接后近一个月的试用,系统运行稳定,分析数据处理时间缩短到了原来的1/3,达到了我们的使用预期。

 

业务收获

 

以上就是我们应用OceanBase的实践过程。从业务角度看,在此次的数据库实践中,我们有五点收获。

 

  • 原生的高可用体系: OceanBase基于PAXOS协议高可用,避免单点故障,RPO=0。
  • 无感知的DDL: OceanBase DDL无感知,可以加快业务迭代效率。
  • 完善的管理平台: OCP平台集成了部署、监控、诊断等功能,大大降低了运维与开发成本。
  • 线上扩展能力: 后期业务数据体系可以通过横向增加机器资源实现scale in or out。
  • 赋能HTAP能力: 数据读写与实时统计分析场景用一个数据产品解决。

 

当然,对于OceanBase,我们也有三个期望与建议。

  • 希望OCP实现集成性能测试。

  • 使用SATA硬盘实际测试出的TPS是官网的1/2,建议使用SSD作为硬盘存储。

  • 期望OceanBase能在更多场景替换MySQ,并不断完善其三地五中心等高级能力。

不得不说,随着国产化浪潮和云原生趋势的推动,企业对数据产品的要求日趋增高。面对老牌数据产品的能力,或许勇于尝试一些优秀的新型产品才能找到良好的解决方案。此次对OceanBase的探索,让我们解决了以往在高可用、线性扩展、存储成本等方面遇到的难题,并且,在拥有了HTAP能力的同时还能持续降低业务成本。

你可能感兴趣的:(客户案例,数据库,大数据,分布式)