Hive-Waterdrop-CK 导数问题复盘总结

[godliness]

2021-3-31日进行的hive导数到clickhouse目前仍然存在如下几个问题待解决：

1. ck 内存超杀 具体原因分析 已完成
2. spark task失败重试，数据为什么没有重复, 是哪些参数决定了原子性？已完成
3. gzip压缩http content encoding为什么导致inflate failed: data error？ 已完成
4. ck 导入 hive实际类型和ck表字段类型不一致依然也可以导入成功？已完成
5. hive orc parquet文件中没有dt字段，jdbc支持输入sql是否可以解决？不能的话，用什么方案？ 已完成

若还存在其他问题请补充

@mxzlxy @FishermanZzhang @glove747

[mxzlxy]

6.单节点连接数超过100左右，出现部分异常Connection timed out(Write failed)，code 1002
7.move partition操作耗时较长，可能出现卡住几十分钟的情况 已完成
8.为了减少内存超限的异常情况，增加并发数，改成全部副本随机连接，可能出现code 473，write locking attempt has timed out。 已完成
9.部分task出现1002未知异常，broken pipe（write failed）待定位

[godliness]

3. gzip压缩http content encoding为什么导致inflate failed: data error？

通过向社区提issue得知：ClickHouse/ClickHouse#22444

clickhouse-jdbc 并不负责 gzip压缩的功能，而仅仅是在http head上添加Content-Encoding=gzip的头信息，具体的压缩工作需要我们自己进行，而clickhouse-server端会根据http header来进行相应的解压缩。

另外，当设置decompress=1的时候，jdbc侧会对content进行 LZ4EntityWrapper 的包装，并将content以lz4压缩后的block形式发送给clickhouse-server，clickhouse-server看到decompress=1会进行解压，整个过程理论上在使用lz4压缩的情况下会节省IO，但相对在spark侧会消耗一定的cpu,具体导入速度是否有提升有待验证。

[mdianjun]

4. ck 导入 hive实际类型和ck表字段类型不一致依然也可以导入成功？待验证
5. hive orc parquet文件中没有dt字段，jdbc支持输入sql是否可以解决？不能的话，用什么方案？

hive中表：

CREATE TABLE `demo`(
  `name` string,
  `id` int)
PARTITIONED BY (`dt` string)
STORED AS orc;

ck中表：

CREATE TABLE demo 
(
    `name` String,
    `id` String, 
    `dt` String
) 
ENGINE = MergeTree 
ORDER BY id
PARTITION BY(dt);

某些类型可以自动转换，hive中的id是int，而ck中的id是String：
"INSERT INTO demo SELECT name,id,'20200311' FROM input('name String,id Int32')"

或者使用转换函数：
"INSERT INTO demo SELECT name,toString(id),'20200311' FROM input('name String,id Int32')"

[mxzlxy]

1.ck 内存超杀 具体原因分析
2.spark task失败重试，数据为什么没有重复, 是哪些参数决定了原子性？

测试原因如下：
1.server端配置了max_memory_usage_for_all_queries=360000000000 约338G （该配置已废弃，新版本使用的配置为max_server_memory_usage，配置这个参数也会生效），测试单个写入请求使用内存约40G，cpu2核，这样的资源消耗一个节点最多只可并发执行8个写入请求，暂未找到有效参数可以把单个请求使用的内存降低；
2.用文件导入的方式一个task只会生成一个part，即一个文件写成了一个part，因此是原子的，此时max_insert_block_size参数设置无效；

为降低内存的使用尝试的部分参数如下：

max_bytes_before_external_group_by=10000000000
max_bytes_before_external_sort=10000000000
max_insert_block_size=500000
max_memory_usage=40000000000  //该值小于单个请求所需内存时，会内存不足直接抛异常

[mdianjun]

2.spark task失败重试，数据为什么没有重复, 是哪些参数决定了原子性？

这是InputStream的调用栈：

ORCBlockInputFormat::generate()
InputStreamFromInputFormat::readImpl()
InputStreamFromASTInsertQuery::readImpl()

InputStreamFromASTInsertQuery在构建时，会用到max_insert_block_size：

然后找到input_processor_creator：

input_processor_creator是怎么被赋值的呢：

在代码中搜索registerInputFormatProcessor，可以看到ORC格式没有使用RowInputFormatParams：

而Values格式会使用RowInputFormatParams：

Values格式对应的是INSERT ... VALUES ... 语句，而且要使用http interface时max_insert_block_size才会生效，而使用clickhouse-client则不行，参见文档的说明：

所有的InputFormat的名字就是这里的：
https://clickhouse.tech/docs/en/interfaces/formats/

在代码中搜索：

只有两个地方用到了：

而IRowInputFormat表示行格式的数据，它的实现类有以下几种，不包括ORC和Parquet等列格式：

[mxzlxy]

7.move partition操作耗时较长，可能出现卡住几十分钟的情况

尝试将临时表换成MergeTree，但MergeTree与ReplicatedMergeTree的目标表之间不支持move partition操作，为优先保证导数效率，暂时将临时表及数据校验功能去掉，直接写目标表。

[godliness]

1. ck 内存超杀 具体原因分析

有些相关issues：ClickHouse/ClickHouse#10461 (comment)
ClickHouse/ClickHouse#16857 (comment)

官方也打算用arrow对non seekable sources的支持：ClickHouse/ClickHouse#17623 (comment)

对于seekable的source目前版本已经有支持arrow可以避免将文件全部加载内存，但对于non seekable的source还没有支持，就会fallback到全部加载到内存的操作。

针对于我们的情况给官方提了issue：ClickHouse/ClickHouse#22831

Update：

给官方提了pr，已经merge：ClickHouse/ClickHouse#23102

orc file按照stripe形式读取，避免一次转换整个file

[mdianjun]

7.move partition操作耗时较长，可能出现卡住几十分钟的情况

move partition的基本原理

这是执行语句alter table demo move partition '20210101' to table demo2的日志：

2021.04.10 19:49:31.699154 [ 84669 ] {7a9a1246-08fc-490f-a189-901685fd9eea} <Debug> executeQuery: (from 127.0.0.1:50554, using production parser) alter table demo move partition '20210101' to table demo2;
2021.04.10 19:49:31.699560 [ 84669 ] {7a9a1246-08fc-490f-a189-901685fd9eea} <Trace> ContextAccess (default): Access granted: SELECT, ALTER DELETE ON default.demo
2021.04.10 19:49:31.699611 [ 84669 ] {7a9a1246-08fc-490f-a189-901685fd9eea} <Trace> ContextAccess (default): Access granted: INSERT ON default.demo2
2021.04.10 19:49:31.700229 [ 84669 ] {7a9a1246-08fc-490f-a189-901685fd9eea} <Debug> DiskLocal: Reserving 1.00 MiB on disk `default`, having unreserved 20.67 GiB.
2021.04.10 19:49:31.700303 [ 84669 ] {7a9a1246-08fc-490f-a189-901685fd9eea} <Debug> default.demo2 (a0ff0224-ba5e-4d57-8a1c-5d423cf37de0): Cloning part ./store/153/153fce3e-baf1-4a01-9bbf-0ff5cbac5745/a57d33f646e191abfbb8396c1706f93b_2_2_0/ to ./store/a0f/a0ff0224-ba5e-4d57-8a1c-5d423cf37de0/tmp_move_from_a57d33f646e191abfbb8396c1706f93b_4_4_0
2021.04.10 19:49:31.701200 [ 84669 ] {7a9a1246-08fc-490f-a189-901685fd9eea} <Trace> default.demo2 (a0ff0224-ba5e-4d57-8a1c-5d423cf37de0): Renaming temporary part tmp_move_from_a57d33f646e191abfbb8396c1706f93b_4_4_0 to a57d33f646e191abfbb8396c1706f93b_4_4_0.

move partition只能在同一个disk上移动partition数据。它的主要步骤：
1.遍历源partition中所有part：每个源part是一个目录，遍历其中所有文件，给每个文件建立硬链接到目标part目录中（目标part目录是个临时目录，前缀是“tmp_move_from_”）。
2.将所有源part删除（由硬链接产生的新part的数据文件不受影响）。

由于硬链接共用原文件的inode，而不是拷贝原文件的数据，所以硬链接的创建很快，而且不会过多占用磁盘空间。而删除原文件时，不会删除inode和数据块，所以也会很快。

参考：

• Linux硬链接和软链接详解（深度剖析）

分析move partition卡住的原因

经过分析日志，定位到move partition卡在这块代码的条件变量上：

而条件变量notify的地方在：

分析代码之后得出大概的流程是：move partition在等待logEntry执行结束，而这个正在执行的logEntry是在merge parts。日志中正好有一条显示：merge操作完成时，花了2025秒，一共merge了3.5亿行。而这个2025秒的时间段的起点早于move partition开始的时间。

理想情况，应该禁止临时表的merge操作，禁用的方法见：https://clickhouse.tech/docs/en/sql-reference/statements/system/#query_language-system-stop-merges 。
以下是禁用merge后，使用optimize table命令时会报错，说明禁用是生效的：

[mdianjun]

7.move partition操作耗时较长，可能出现卡住几十分钟的情况

尝试将临时表换成MergeTree，但MergeTree与ReplicatedMergeTree的目标表之间不支持move partition操作，为优先保证导数效率，暂时将临时表及数据校验功能去掉，直接写目标表。

@mxzlxy 行数校验时，直接使用ORC API获取hive上源文件的行数：
参考：

• https://orc.apache.org/docs/core-java.html#reading-orc-files
• https://mp.weixin.qq.com/s/2S1GJrpiwKyKOTmTqDLO0w

注意：orc表的创建方式有两种为：

• CREATE TABLE ... STORED AS ORC：这是hive语法，表的provider=hive。
  • https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC
• CREATE TABLE ... USING ORC：这是用spark data source方式创建的，只能在spark sql里执行。表的provider=orc。
  • http://spark.apache.org/docs/latest/sql-data-sources-orc.html
  • http://spark.apache.org/docs/latest/sql-ref-syntax-ddl-create-table-datasource.html

只有apache orc有getNumberOfRows()方法，但hive orc没有。使用apache orc的接口时，要确保对以上两种格式都能正确读取。

apache orc里Reader类的方法：

hive orc里Reader类的方法

[mxzlxy]

注意：orc表的创建方式有两种为：

• CREATE TABLE ... STORED AS ORC：这是hive语法，表的provider=hive。

  • https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC

• CREATE TABLE ... USING ORC：这是用spark data source方式创建的，只能在spark sql里执行。表的provider=orc。

  • http://spark.apache.org/docs/latest/sql-data-sources-orc.html
  • http://spark.apache.org/docs/latest/sql-ref-syntax-ddl-create-table-datasource.html

只有apache orc有getNumberOfRows()方法，但hive orc没有。使用apache orc的接口时，要确保对以上两种格式都能正确读取。

已验证两种建表方式的数据都可以正常进行行数校验

[mxzlxy]

9.部分task出现1002未知异常，broken pipe（write failed）待定位

测试将clickhouse-server端的keep_alive_timeout设置成30秒后（配置在config.xml，默认值3秒），1002异常出现频率明显降低，但是还存在个别偶发的情况。已部分解决，剩余的偶发现象待定位。
参考：ClickHouse/clickhouse-java#515