导语: 浦银安盛基金管理有限公司(以下简称浦银安盛)作为一家成立于2007年的中法合资银行系基金公司,业务数据管理工具的易用与好用非常重要,既要求存储性能,又要求技术速度,还要求实时处理。由于原本的Oracle与CDH搭配方案不能满足要求, 浦银安盛在探索数据库优化方案时,对OceanBase、TiDB、Hive、Oracle 进行选型比较。 经过多方对比和测试,最终上线了OceanBase。浦银安盛技术开发部讲述了该过程的思考及踩坑经验。
我们公司投资研发部门的数据中心整体规模在 1-2TB 之间,部分涉及监管报送的营销模型在 5TB 左右(仅包含近一年金证数据),属于小数据量的数仓范畴。对于我们的数据业务情况,中小规模计算占比达到 80% 以上;真正的大数据量计算任务较少,并且可以通过技术手段进行一定规避。
我们一直在使用数据中心管理工具 CDH,它的数据存储性能优、大规模计算速度快,但是,在绝大多数的小任务计算、OLAP 即时查询及实时数据处理方面有很多劣势,比如,CDH 不支持 ACID,SQL-DML 语句支持有限,无法进行有效的数据录入动作。另外,CDH 计算完成的结果表需要回推至 Oracle 进行相关数据应用维护,我们再将维护好的手工数据和源系统数据以 T+1 的频次同步至 CDH。在 CDH 整合计算完成后,回推至Oracle,供 DataApi 服务、报表及其他数据查询类应用。数据在 Oracle、CDH 之间来回交互推送,造成了一定程度资源浪费。
Oracle 和 CDH 需搭配使用,Oracle 无法满足可扩展性及大规模 OLAP 计算,CDH 无法满足报表快速查询和实时数据服务支持,而我们对 CDH 也没有 Impala、Presto 等即时分析组件支持计划。出于上述种种业务痛点,我们开始探索分布式数据库,并要求同时满足对 OLTP 及 OLAP 服务的需求。
我们调研了具备HTAP能力的两款分布式数据库:OceanBase、TiDB。
TiDB 要想同时满足 OLTP 及 OLAP 服务,需要额外搭建 TiFlash 副本,相比之下, OceanBase 的一体化架构,运维更简单,使用更友好。因此,对于 TiDB,我们就没有进行生产级别的验证和测试了。
针对已有环境,我们整理了 Hive、Oracle 及 OceanBase 之间的功能对比:
经过对比,以及对OceanBase深入了解后,我们看中了OceanBase的以下能力。
生态工具丰富。
确定技术方案后,我们就开始对 OceanBase 进行生产级别的测试,包括功能验证、性能测试、兼容性测试。
首先,对于功能的验证,我们主要从 SQL 语法及函数的完备性这两方面展开。
相较于Hive,OceanBase 完全兼容 MySQL 语法,并且支持了大量的窗口函数,这一点对我们的业务非常友好, 将 Hive 脚本迁移至 OceanBase 运行时,我们遇到的改造量很小 ,绝大部分脚本能在 OceanBase 直接运行(MySQL 租户)。投资研发部门的数据中心代码迁移到 OceanBase 时,没有任何改造的部分达到 90% 以上。剩下不到10% 的代码改造部分主要是由于函数的不同,印象比较深的是OceanBase 不支持协方差计算函数,需要自己写代码实现。
而相较于 Oracle,OceanBase 的 MySQL 租户就差异大一些了,Oracle 特有的函数及一些特殊方言,可能还是需要 OceanBase 企业版的 Oracle 租户进行兼容。
其次,在性能测试方面,由于 我们大批量是小脚本迁移至 OceanBase,我们运行的整体时间比 CDH 节省了 30% 左右。 对比 Oracle,小脚本没什么优势,但得力于 OceanBase 分布式HTAP的能力,能跑大批量 OLAP,同时,OceanBase 占用的存储空间也较Oracle大幅下降,我们 在 Oracle 上 8TB 左右的数据量,迁移至OceanBase 后缩减到了 2.4TB 左右。
最后,在测试兼容性时,我们的 ETL 调度工具、数据同步工具、报表应用、 DataAPI 平台都是不同的环境,在使用 MySQL 驱动链接 OceanBase 的情况下,基本能无缝衔接。在过程中遇到了一点问题,OceanBase 的技术人员在替换相关的 MySQL 驱动版本后,也得到了完美解决。
由于我们原技术架构同时使用Oracle和CDH,在架构迁移至OceanBase后,需要将Oracle和CDH的数据都迁移到OceanBase中,下面是我们在迁移过程中的踩坑经验。
第一,对于CDH数据迁移OceanBase,我们通过Hive元数据,批量处理建表语句;
在HDFS数据迁移至OceanBase时,因为OceanBase不支持load data local模式,这一点对我们的业务迁移不太友好,所以我们只能通过hive-e 批量将orc表查询导出至txt,再用OBloader将数据导入OceanBase。
第二,针对 Oracle 迁移到 OceanBase, 由于我们是离线任务,而且是迁移到MySQL 租户,主体差在于 Oracle 到 MySQL 的语法结构差异。主要是SQL函数的差异及部分语法差异,导致原来基于 Oracle 的查需要进行一定程度的改写。
第三,最初我们没有主副本方案, 在进行跑批作业时,会有大量的跨节点数据交互导致 RPC 过大,任务报错。这是我们这次迁移项目中最大的问题。因此,我们开始指定主副本,在 insert 作业中减少 RPC 的动作,然后,利用 hint 这个 AP 租户的利器,如果不用 Hint 跑 OLAP 业务,就没办法领略 OceanBase 作为 HTAP 数据库的魅力。因为 仅 OceanBase 执行 SQL 脚本需要 40 分钟,而Hint的加入会让执行的计算时间降至6分钟。
第四,OceanBase默认OLTP模式, 需要调整很多参数让数据库更符合OLAP业务。对此,希望OceanBase能够针对不同模式的租户应用,在OCP中完善解决方案,以便用户快速进行AP租户配置。
现在,我们拥有了一体化架构、清晰的运维方案和丰富的生态工具,几乎满足了我们当下对数据库的所有需求。由于 运维压力被极大降低,我们能有更多精力关注数据本身的价值。 而借助 OceanBase 的生态和工具,我们也创造了更有价值的数据应用。
此外, 得益于 OceanBase HTAP 的能力, 我们的手工录入数据、数仓整合后数据及部分应用系统数据,可以在 OceanBase 一体化架构中实现数据的统一管理, 不仅减少了实时同步的需求量,而且业务系统在手工修改后的一些参数配置能够实时应用在各项业务中。 同时,依靠 BS 架构和 ODC-WEB 清晰的权限管理,我们可以更便捷的将模型数据、资讯数据,以及 OceanBase 的部分算力直接共享给业务人员,大大提升了数据使用效率。
对于此次数据库方案选型从迁移到落地的过程,感谢 OceanBase 社区成员给我们的帮助。在此也提出几点建议,以供参考。
首先,OceanBase 是一个新事物,需要有更多场景化的解决方案。 例如,我们的数据服务场景,有数据同步、数据处理、数据调度、元数据管理、数据服务、数据存储、数据脱敏等功能需求,OceanBase与该场景的结合就可以推出一整套技术框架方案的解决示例。
其次,在功能上,希望 OceanBase 完善 OLAP 场景下的业务功能, 如增设外部表、物化视图、跨租户数据访问等;希望 ODC 能支持来自 Hive、Oracle、MySQL 等数仓工具或数据库的数据源链接。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论