ALL_PART_COL_STATISTICS

本文介绍 OceanBase 导数工具的原理及运行机制。

导入工具 OBLOADER

OBLOADER 客户端模式的数据导入包含预处理和数据写入。预处理时，OBLOADER 执行以下步骤：

• 查询待导入表的元数据。

• 筛选并匹配文件。

• 逻辑拆分大文件。

• 计算子文件的分区并按节点打散。

在数据写入阶段，OBLOADER 的运行机制类似一个多生产多消费模型。解析端作为生产者，不断从文件中解析出数据，经过数据清洗后放入 Buffer。写入端作为消费者，不断从 Buffer 中提取数据，并将其写入数据库。

影响 OBLOADER 客户端性能的主要因素分别是生产者和消费者的数量与 Buffer 的大小。您可以通过 --thread 指定生产者的数量。Buffer 的值由 OBLOADER 根据 --thread 与 JVM 最大堆内存的值综合计算得出，一般不用也不推荐手动指定。如果您确有自定义的需求，可以通过选项 --buffer-size（须为 2 的幂）指定。如果导入过程中遇到频繁 FGC 或者内存溢出报错的问题，可能是由于单行数据大小过大导致缓冲大小超过了限定值。您可以通过调小该值来绕过，后续导数工具会优化此问题。

旁路导入数据导入还有第三个阶段，即任务提交。在这个阶段，客户端主要在等待 OBServer 对刚写入的数据进行排序和索引构建，耗时一般较长，需要耐心等待。

逻辑拆分大文件

OBLOADER 不会真的在磁盘上生成若干子文件。逻辑切分指记录多个字节位点，在正式开始解析文件时从一个大文件的多个字节位点去并发读取，从而提高解析速度。

每个逻辑子文件的大小由选项 --block-size 指定，默认为 64 MB。拆分基于换行符操作，所以大多数情况下，您不必担心数据截断。有一种情况例外，即数据本身含有换行符（尽管出现数据截断的几率较小）。通过以下方式调整文件拆分策略：

• 通过编辑器打开 <工具根目录>/bin/obloader。

• 找到 Java 启动参数 -Dfile.split=unsafe。将其中的 unsafe 改为 safe。

此时，OBLOADER 会同时使用定界符与换行符执行逻辑拆分。

计算分区

OBLOADER 通过提取某个子文件的第一条数据，计算出其所属分区，并查询其 Leader 节点。然后通过分组后打散的策略，使某个时刻同时处理的子文件能够尽量被转发到不同的节点，从而做到相对的负载均衡。

分区计算失败或节点查询失败不会影响实际的导入，OBLOADER 会通过打印 WARN 级别日志提示您。若您使用的是 OBServer 4.0 之前的版本，这可能是因为您未提供 sys 租户的帐密。若您使用的是 OBServer 4.0 及之后的版本，则可能是因为您未提供租户名（-t 选项）。

导出工具 OBDUMPER

OBDUMPER 基于 Schema 的定义设计了表分片策略，以实现库或表的多任务并行处理，从而提升数据导出性能。然而，性能影响因素多样，包括表结构设计、数据传输网络和数据落盘的 IO 等。OBDUMPER 的整个框架面向格式和存储进行扩展。CSV 和 SQL 等行存储格式适合小数据量业务。例如，您可通过 Excel 直接打开文件进行查看与分析。ORC 和 Parquet 等列存储格式可用于存放大规模表数据。此外，OBDUMPER 支持将数据导出到不同存储介质。

我们建议您在设计表结构时，为表添加主键。当表的数量量很大时，建议您对表进行分区，并且保证每一个分区内的数据相对均衡。

性能测试

使用 OBDUMPER，示例数据为 TPC-H 100GB 测试库，按照不同的文件格式导出数据。由于 ORC/Parquet 导出过程中默认开启压缩，所以数据导出性能比 CSV/SQL 格式略低。在实际业务中，大多用户可以接受牺牲一点性能换取更低的存储空间。OBDUMPER 导出测试性能图表如下：

压缩测试

导出 ORC/Parquet 格式的数据时，OBDUMPER 默认采用 zstd 压缩大约是 4 : 1。如果对 CSV 文件中相同的数据采用后置压缩，压缩率远远达不到这么高。压缩率高低，不仅与压缩算法相关，也与数据的特征也有很大的关系。不同的数据采用相同的算法压缩后的效果差异也很明显，建议您以实际的业务数据进行压缩为准。压缩率的计算公式为 Compression Ration ≈ Uncompressed Size/Compressed Size。