从OceanBase旁路导入出发，解决证券行业离线数据痛点

编者按

“让技术被看见 | OceanBase 布道师计划”是由 OceanBase 主办，墨天轮、ITPUB、CSDN 三大技术媒体协办，面向广大开发者的年度征文活动。全年 4 轮，以季度为周期进行优秀文章评比，每年 1 届，以年为单位进行最佳布道师评选。目前，2025 年度 Q1、Q2  技术征文获奖文章已评选出炉。

本篇内容为「OceanBase 布道师计划」优秀文章之一，作者 多明戈教你玩狼人杀 。布道师计划全年不停歇，欢迎感兴趣的小伙伴点击「阅读原文」进入活动官网，了解活动详情或进一步投稿。

从 OceanBase4.3 开始，增强 AP 功能就一直是重点，在拆解整个功能树的过程中，旁路导入是一个我比较感兴趣且在证券行业确实有着广泛运用到功能。而我们也知道，无论是 MySQL 还是 Oracle，都有着较多的使用场景，那么以这两个产品为参照物，OceanBase 的旁路导入可以在证券行业有哪些应用，值得论述。

常见的场景

证券行业是一个数据高频处理的行业，既有实时处理的行情，也有盘后离线行情，同时各类 TA、估值、监管报送等等，都有着海量的离线文件要处理。这些文件对实时性要求不同，使用场景各异，格式也各有区别，所以实际操作起来一直是老大难。

我来逐一阐述一下这几个场景。

行情数据。交易所的行情数据，除了我们盘中的实时行情，还有一个大类别就是盘后的行情数据文件。离线的盘后数据，每年有几十 TB 之多，大部分时间是以 CSV 形式保存，根据业务部门的实际需求，需要做回测或者其他场景，才会导入数据库成为在线数据。特点是格式固定、数据量庞大，使用频率较低而且没有固定规律。

资讯数据。这是一个很宽泛的概念，也是数据格式最混乱、使用场景最多、管理起来最头疼的。比如各个上市公司的基本信息、反洗钱黑白名单、各类行业研究报告等等。这些数据既有结构化数据，也有半结构化和非结构化数据，而且来自于不同供应商，没有行业标准，实际上是一个看起来有点“无解”的答案。

产品数据。这其实也是一个有点宽泛的概念，涵盖了股票、债券、基金、期货、衍生品等等。从内容来看，既有基本信息，又有估值，还有产品管理人相关信息。此外还有一些财务数据，比如资产负债表、现金流数据等等。数据规模可能是 GB 级，但是数据来源五花八门，既有实时性要求，又对准确性有着极高的要求。

TA（交易账户）数据。TA 也是一类总称，很多大券商大机构都有自己的 TA 系统，也就意味着数据格式无法统一。而包含的数据往往又有很多敏感信息，这是和前三类最大的不同。开户人隐私数据、资产明细，在数据分级分类中，都属于高敏感级别，既要考虑到数据安全，又要确保数据正常导入。

监管报送数据。监管报送数据，通常是券商内部各个数据的汇总，既有交易柜台又有客户管理系统、风控系统，还有第三方比如万得路透这些第三方的数据，还有一些行业协会的数据。这些数据获取之后，需要处理以后，再生成离线文件，推送到监管的报送数据接口，所以出现了离线文件和在线文件进，离线文件出的特点。

这还只是我能想到的常见的，冷门的只多不少。

难点的总结

场景阐述完了，接下来就是提炼总结，也就是我们做产品经理时常做的一件事：总结归纳。这几个场景看似各异，实际上从技术的角度，是有规律可循的。

难点一，数据来源碎片化。如果从数据源头来看，既有内部系统，又有外部供应商、第三方机构以及监管机构。而且数据文件的传输方式和更新频率也不一致，做不到一个适配逻辑对应所有场景，需要专门的人去维护。而且从数据安全的角度，一旦涉及到了跨部门协作时，数据安全、数据版本都是一笔糊涂账。

难点二，文件格式不确定。既有我们常见的 CSV 或者 JSON，又有 excel、 XML 以及纯文本格式，处理起来就得用不同的格式和逻辑。而且还有编码问题，尤其是中文场景下，处理不同编码是很多 DBA 头疼的点。至于分隔符不一样这种都是小问题了。这也就意味着处理起来要面使用的脚本基本都要定制化开发。

难点三，处理效率低。囿于前两个难点，那么处理起来就成了一个难题。尤其到了月末的时候，大量的数据需要载入，对于数据库压力以及存储 IO 的考验就非常高。这一点上，无论是 MySQL 还是 Oracle，都做不到让人比较满意的处理效率，往往需要人工干预。

难点四，合规与安全。作为数据治理员，这是我最头疼的事情。如果没有一个集中处理的手段，就意味着每一种都要找合规确认，每一个方式的数据安全都要去监控，人的精力有限，总会出现意想不到的纰漏。如果仅仅是内部流程出问题都还好解决，一旦涉及到客户服务以及资金的问题，那就不是内部开个会能解决的了。

四个难点，既有技术上的，又有安全合规的。也有双方叠加到一起的，反正你问我怎么能轻松搞定，我答案就是不知道，只能最大限度地去弥合。

OceanBase的旁路导入解决办法

首先我要说的是，如此复杂的场景，想要通过一个产品完全解决是不可能的，而是需要多种工具组合起来。再就是理论和实际永远有差异，总有我们意料之外的事情出现。所以本文仅仅从理论和实验的角度出发，具体生产环境还要具体分析。

第一步，归集数据来源碎片化。针对这个场景，我能想到的就是 OceanBase 支持对象存储，将数据来源统一归集到一个对象存储中保管，根据实际需要来用旁路导入功能读入数据库中。对于实时行情的处理，通过 DataX 统一接入并写入到 OceanBase 中，可以最大程度实现整合。

第二步，处理格式异构。按照上一步骤的规划，各类离线文件都统一存储到对象存储，那么接下来就要用旁路导入做异构格式的处理。截止到 4.3.5，常见的 CSV/XML/Parquet/TEXT 都可以支持，预先写好脚本即可。而 MySQL 或者 Oracle 数据库里的数据，同样可以先创建外表，再导入内表的模式来实现。而且支持主流的压缩格式，这是一个很大的优势。至于有一些冷门的格式，可能还需要以来其他工具转换。

第三步，提高效率。在提高导入效率这件事上，OceanBase 的分布式+列存就是一个优势。MySQL 和非 Exadata 版本的 Oracle 都是基于行存，海量的导入时，性能会出现瓶颈。而 OceanBase 的列存+分布式模式，我实测，同样配置的服务器，TB 级别的资讯数据，能够从小时级压缩到分钟级。而且 4.3.5 增加的增量导入功能，可以在日终或者月底的时候继续压缩导入的时间。

第四步，解决安全问题。实际上安全问题可以继续拆解，数据加密和操作审计。前者是技术要求，后者是合规要求。安全问题使用我的选择是使用多租户和角色做权限隔离（包括兼容了 Oracle 的 Label Security 特性），以及 OceanBase 自带的传输加密和存储加密来解决，这要比离线文件的安全系数提高好几个级别。而 OceanBase 的审计功能目前来看，能够完成自动记录数据导入、修改、删除等操作，生成审计报告，既可以给到内部合规，又可以面向外审和监管机构。

走到这一步，大部分烦人的问题，都可以获得答案。

尾声

当然，即便使用了这些特性，仍然不能解决所有问题，比如有一个难题就是数据质量的问题。外部数据的数据质量一直是一个老大难，但是把这些交给一个的数据库来解决显然也不现实。

比如 TA 估值系统对产品净值的计算口径差异，如果使用旁路导入仅能做基础格式校验，是没有办法自动识别逻辑矛盾的，需额外开发稽核脚本，这些都需要对业务有足够的了解。一些非结构化文件的解析，也依赖于更多工具，比如客户的图片，需要搭配 OCR 来做到结构化落盘等等。就连 OceanBase 本身也存在诸多使用限制。

如果我没有记错的话，OceanBase 对旁路导入的强化是从 4.3 开始，一年时间能做到这些，已经让我颇为惊喜。诸多问题的解决都需要时间，所有的具体问题治理，都是要面对两个问题：成本从哪出，活谁来干。

有限的时间有限的资源之下，我仍然期待 OceanBase 在后面的版本，比如 4.4 能够在旁路导入中引入更多有实用价值的特性。

▼ 点击「阅读原文」，了解详情，立即投稿