作者：coolmoon1202，大数据高级工程师，专注于高性能软件架构设计
前段时间我们使用OceanBase和FlinkCDC构建了一套高效的实时数仓读写分析系统，过程中经历了数据库选型、数据库产品测试对比、产品部署及使用踩坑。我们将这次系统升级的经验总结成文并分享出来，希望能给同样处在系统升级阶段的团队一些参考。
业务背景与痛点
由于我们业务的特殊性（为政府单位提供技术服务和支持），因此，在我们近期的一个业务中，背景是根据十三五脱贫攻坚政策——用科学机制预防返贫，“发现问题、解决问题”。要求第一时间发现返贫问题，采取有效的针对性举措；对所有列入返贫的问题清单要及时响应、及时识别、及时整改。因此，我们需要建立一套时效性高、稳定性强、易于需求变更的实时数仓。
在线上业务环境中，防返贫监测平台主要涉及数据查询、数据上报和数据清洗。业务数据来源主要有四部分：
- 一是App端上报监测户最新监测指标数据，如监测户外出务工情况、监测户“三不愁、两保障”指标。
- 二是基层排查数据，即基层挨家挨户上门采集的监测户信息数据，此部分数据在百万级别，排查周期在一月一次.
- 三是国服系统平台数据，由国服系统每半年导出历史数据.
- 四是各部门相关数据，如住房数据等。
平台的整体数据量在千万级，业务需求分为动态信息核实、动态风险预警、大排查数据清洗三方面：
- 动态信息核实即实时比较国服系统与最新上报的监测户防返贫指标，根据业务规则识别、提取差异数据，形成差异数据表，供客户落实数据正确性。
- 动态风险预警即根据业务规则，实时识别上报数据中存在返贫风险的风险项，最终形成风险信息表，提供客户落实监测户风险并下发任务。
- 大排查数据清洗即根据基层排查统一上报数据，全量进行信息核实、风险预警等业务处理，并与动态分线预警及动态信息核实信息合并、对比、修改，最终形成防返贫终表，回推国服系统。
方案选型与测试
我们的原始方案采用RDS作为业务数据库，Kafka消息队列作为上报数据实时接收端，Flink作为数据清洗治理组件。系统开发完成进行模拟运行时，我们遇到一些问题。
第一个问题，由于数据字段多而繁杂，单张表存在上百甚至两百个字段，仅千万级数据由于RDS的性能瓶颈在数据抽取过程便会消耗大量时间，同时存在将RDS查崩、写崩的风险。
第二个问题，由于系统同时存在实时计算与批计算，且互相之间需要进行对比、修改等操作，在进行批计算时，大量的文件读写操作会严重影响数据库性能，导致App功能无法正常使用。
为解决这两个问题，我们认为，需要匹配一个兼容MySQL语法（避免大量业务改造），具备HTAP特性，以及支持海量数据实时写入、实时更新、实时分析的实时数仓方案。
带着这样的期望，我们在网络上查阅了大量资料。偶然间，看到蚂蚁集团自主研发的OceanBase数据库已于2021年6月1日正式开源，并且它的特性能够满足我们大部分需求，我们决定一试。
我们对OceanBase 社区版3.1.1版本进行了性能测试。TPC-C测试数据如下表所示。
我们也做了并发测试对比，使用 SSD 硬盘做为 OceanBase 数据存储，通过修改 prop.oceanbase 的 terminals 参数来修改 TPC-C 的测试并发数，测试结果如下。
从以上测试数据可以看出，随着测试并发数的增加，由于 OceanBase 服务器集群资源负荷增大，事务平均响应时间会逐步增加，但总体 TpmC 会提高。但当测试并发数达到或超过临界点后，OceanBase服务器集群资源超出最大负载，总体 TpmC 反而会下降。
除了测试性能外，我们对硬盘也进行了测试对比。分别使用 SSD 硬盘、SATA 硬盘做为 OceanBase 数据存储，100并发测试结果如下表。
从测试数据可以看出，使用 SSD 硬盘，无论是总 TpmC 还是事务的平均响应时间，比使用 SATA 盘都有一定的优势，但优势并不明显。可能原因是 OceanBase 使用 LSM Tree 存储架构提高了内存的使用效率，降低了硬盘读写损耗对系统的影响。
TPC-H测试数据如下表所示。
预热测试对比使用 SSD 硬盘做为 OceanBase 数据存储，修改 tpch.sh 脚本，注释预热部分代码，在装载数据成功后第一次执行即为非预热执行，第二次执行脚本则为预热后执行，测试结果如下表。
从上表测试数据可以看出，预热后TPC-H的测试SQL语句执行性能会有一定的提升，是因为SQL在解析与执行时命中了执行计划缓存与部分数据缓存所致。
硬盘测试分别使用SSD硬盘、SATA硬盘做为OceanBase数据存储，执行测试结果如下表。
从以上测试数据可以看出，在没有预热的情况下，使用 SSD 硬盘比使用 SATA 硬盘有较大的性能提升，但在有预热的情况下，使用 SSD 硬盘比使用 SATA 硬盘的性能提升则不是很明显。因为在预热情况下 TPC-H 的测试 SQL 语句在执行时命中了部分数据缓存，减少了从硬盘读取数据所带来的损耗。
根据测试结果来看，按照TPC-C标准在当前测试环境进行测试，最高可达355739TpmC，最快可以在24.05秒完成整个TPC-H的测试SQL执行，说明OceanBase社区版V3.1.1在OLTP与OLAP场景下都有不俗的表现，并且可以通过横向扩展满足大部分海量数据高并发业务场景的性能需求。
我们也同时对TiDB、PloarDB-X这两款国产开源分布式数据库进行了性能测试与综合评估。经过对比发现，OceanBase社区版在TPC-H性能测试下和内部真实业务压力下的表现最佳。因此，我们在经过内部评估后，认为 OceanBase 能够满足目前的业务需求，而且，OceanBase开源社区也提供了良好的技术服务与支持。
最终，我们决定尝试使用OceanBase社区版作为平台业务的实时数仓解决方案。
但在实际使用的过程中，因为OceanBase在我们公司属于新技术，所以有很多小伙伴对OceanBase的使用经验不足，这会触发某些查询语句（如select count(distinct id_card) from xxx）大量抢占OceanBase资源，甚至出现系统崩溃的情况。结合业务重清洗、轻查询的需求，我们决定针对OceanBase搭建读写分离平台，业务需求重更为重要，且吞吐量、性能需求更高的写入、清洗，全量读取由OceanBase负责。对吞吐量要求低的App数据查询由RDS负责。由数据库日志同步的方式进行OceanBase与RDS的数据实时同步。
在选用数据库日志同步工具时，我们查阅资料后初步选择了两种方案：一是使用OceanBase自带的CDC，二是使用Flink CDC。然而，由于前者需要单独实现记录数据库日志offset进行容错恢复，我们选择了Flink CDC作为最终方案。
OceanBase 部署方案
经过一段时间的方案选型与测试评估后，我们决定使用OceanBase 社区版3.1.3版本替换原来的Hive数据仓库，OceanBase集群架构选择1-1-1。
- 硬件配置：ECS 3 台，16核64G内存，每台ECS挂载两块硬盘，一块500G SSD硬盘，用于保存数据库redo日志，另一块1T SSD硬盘，用于保存数据库数据。
- 资源分配：OBServer的memory_limit为54G，system_memory为4G，OBProxy内存为4G。OceanBase集群部署成功后，修改sys租户资源为4核4G，新建业务租户分配资源10核40G，primary_zone设置为RANDOM，让业务租户表分区的Leader随机分配到这3台ECS中。
我们最初计划使用OCP部署OceanBase集群，但因为安装OCP需要依赖OceanBase数据库，所以最终决定使用OBD进行部署，不过后期可以通过 OCP 来接管 OBD 部署的集群，这个过程也很方便。
OceanBase集群部署拓扑如下图所示。
部署、测试、使用问题总结
首先来说说我们遇到的问题。本次将flink-cdc-oceanbase作为读写分离数据同步中间件时，主要遇到三个问题。
第一个问题，全量阶段只能单并行度运行。Flink CDC进行数据同步时，会分为两个阶段，阶段一为全量读取数据，阶段二为增量读取数据库日志。在本次实际使用过程中，我们发现全量阶段的数据读取速度很慢，且无论如何增加并行度都无法得到提升。于是我们便去查阅了源码，发现源码中全量读取阶段仅支持单并行度读取。
第二个问题，日志解析结果需要指定表Schema，不利于一次监听，分流成若干表的导入。在使用过程中，我们发现flink-cdc-oceanbase 注册Source需要指定表的Schema，但这样不利于进行全库同步，且不利于动态的添加新表同步任务。
第三个问题，oblogproxy 会频繁自动挂掉。
然后再来说说我们是怎么解决这些问题的。
针对单并行度问题，由于我们的表设计时，都存在自增主键，因此我们修改源码，将全量读取阶段，通过自动获取自增主键的最小值及最大值，并自动根据并行度进行分片，最终实现了基于自增主键的多并行度执行。
针对需要指定表Schema，咨询了OceanBase社区版的技术人员，得到的答复是，因为 jdbc 类型和日志数据类型不是一一对应的，没办法由日志结构反推表结构，如果想同时支持 timestamp 方式启动的话，只能让用户指定表结构。由于我们使用过程中不需要使用timestamp方式启动，因此修改了源码，使用json字符串的方式返回cdc数据，并通过Flink udf进行解析。
针对oblogproxy会频繁自动挂掉的问题，咨询了OceanBase社区版技术人员后，得到的结论是OceanBase 3.1.4版本暂无适配的release版本flink-cdc包，最终在使用社区技术人员提供的snapshot包后不再出现此问题。此处期望尽快发布release版本。
以上就是我们使用OceanBase构建高效的实时数仓读写分析系统的经验，希望能给大家提供一些参考价值。
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群（33254054），或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
