13518219792
根据您的个性需求进行定制 先人一步 抢占小程序红利时代
本文为您介绍 OceanBase 迁移服务（OceanBase Migration Service，OMS）包含的组件。
OMS 内部主要包含以下组件：
OMS 结构迁移的核心组件（DBCat）作为 OceanBase 原生的 Schema 转换引擎，可以根据源端、目标端具体的数据源类型和字符编码类型，进行精确的数据类型映射或转换。OMS 的结构迁移组件支持转换、迁移数据库中的表、约束、索引和视图等多种对象。
同时，DBCat 可以严格对齐和兼容 OceanBase 的租户类型。例如，OceanBase 的某个版本暂时不支持源端数据库中的部分数据源类型，DBCat 会选择最接近且兼容度最高的数据类型进行转换映射。
全量数据流模块（Dataflow）负责源库存量数据的迁移，以及迁移后的全字段校验。为了扩展灵活性和充分复用组件，Dataflow 自下而上分别是 Reader 模块、Writer 模块、Broker 模块和统一数据模型层：
Reader 模块：负责从源端读取数据，每一种数据库类型都有对应的 Reader 插件。Reader 插件根据统一数据模型层转换读取的记录后，将其放入 Broker 模块中，由其它模块消费。
Writer 模块：从 Broker 模块订阅某张表的记录，根据每个 Writer 插件的类型，将记录按照统一数据模型层转换为适配下游的插入语句后，写入下游。
Broker 模块：用于解耦 Reader、Writer 或其它模块，以提升性能。解藕后，上下游模块可以相互独立，便于维护和扩展。
统一数据模型层：各组件间通过 Broker 要实现解藕，还需要有一层统一数据模型。数据从 Reader 写入 Broker 时需要先按统一数据模型转换，从 Broker 获取数据记录后，也需要由记录的统一数据模型转化为下游适配的对象或语句。
在上述底层模块的基础上，OMS 实现了数据的迁移、校验和订正。
迁移数据时，您需要在配置好源端、目标端、待迁移表和库表映射等关键信息后，为每张迁移表创建一条 Reader > Broker > Writer 的通道，再由上层迁移程序对每张表的迁移进行调度。您可以并发迁移多张表，在 Reader 和 Writer 组件中可以并发执行每张表的迁移。
进行数据校验和订正时，您需要在配置好源端、目标端、待迁移表和库表映射等关键信息后，为每张校验的表创建 SrcReader > Broker > DstReader 和 Broker > Verifier 的校验通道。
不同类型数据库的日志读取模块（Store）的实现方式不同，例如 OceanBase Store 模块的实现方式是依赖于 OceanBase 的 Liboblog 工具。
Lliboblog 是 OceanBase 的增量数据同步工具，通过 RPC 方式拉取 OceanBase 各个分区的 Redo 日志后，结合各个表和列的 Schema 信息，转换 Redo 日志为中间定义的数据格式，最后以事务的方式输出修改的数据。
同步写入模块包括 JDBCWriter 和 Connector：
同步写入模块（JDBCWriter）是从日志读取模块（Store）拉取增量数据的同时，将其翻译为 INSERT、UPDATE 或 DELETE 等 SQL 语句写入数据至目标端的组件。
Store 组件记录的是流式的增量数据，可以通过 Pipeline 保证数据的有序性。Writer 组件单线程顺序执行事务可以满足基本要求，但不能扩展性能，所以 OMS 引入并发写机制。
在提升同步性能的同时，还需要保证数据的一致性，所以 OMS 引入冲突矩阵机制实现乱序并发写入，以确保每个事务的最终一致性。
为了避免循环复制问题，所有通过 OMS 的 JDBCWriter 模块写入的数据都会在 Store 组件中进行打标处理，以确保不会再次被其它模块消费。
同步写入模块（Connector）是将 JDBCWriter 的功能插件化，包括源端（Source） 和目标端（Sink） 插件。以同步 OceanBase 数据至 Kafka 为例，在数据同步过程中，OB-Store-Source 为源端插件，Kafka-Sink 为目标端插件。
Connector 的优势如下：
可扩展性强，源端和目标端可以进行组合。
方便统一同步任务资源的管理、监控和运维。
作为统一中间层，将不同源端的 Record 格式进行结构化，便于实现 Record 的 Filter 和 Transformer 等功能
