Flink 1.11.0
hadoop-3.0.3, hive-2.3.4

现象

写入Hive表的性能，每秒写入记录数，发现性能并不乐观，上有节点背压严重。

写入Hive表.png

Hive Table DDL：

CREATE TABLE dw_db.dw_xxx_rt(
中间几十个字段省略,
`position` string COMMENT '位置'
) PARTITIONED BY (p_dt STRING, p_hours STRING) row format delimited
  fields terminated by '\t'
  collection items terminated by '\n'
stored as orc TBLPROPERTIES (
  'sink.partition-commit.trigger'='process-time',
  'sink.partition-commit.delay'='0s',
  'sink.partition-commit.policy.kind'='metastore,success-file',
  'sink.shuffle-by-partition.enable'='true'
);

而写入HDFS文件的性能，每秒写入记录数，性能符合期待。

写入HDFS文件.png

HDFS文件的DDL：

drop table hive_catalog.dw_db.dw_xxx_hdfs;
CREATE TABLE hive_catalog.dw_db.dw_xxx_hdfs (
中间几十个字段省略,
`position` string COMMENT '位置',
 `p_dt` string,
`p_hours` string
) PARTITIONED BY (p_dt , p_hours )  with (
  'connector' = 'filesystem',
  'path' = 'hdfs://ztcluster/tmp/test/xk',
  'format' = 'orc',
  'sink.partition-commit.trigger'='process-time',
  'sink.partition-commit.delay'='0s',
  'sink.partition-commit.policy.kind'='success-file',
  'sink.shuffle-by-partition.enable'='true'
);

翻阅Flink的PR，十几天前，阿里Flink的开发同学已经注意到了这个问题，我们将之吸收到测试环境，编译替换lib下jar包，重新测试，性能确实up了，单并发升至5W每秒，上游节点才稍微有背压。
[FLINK-19121][hive] Avoid accessing HDFS frequently in HiveBulkWriterFactory

所以，Flink的新特性从发布到应用线上，稳定性与性能上都不能过于乐观、听信于官方宣传，
司内另一教训就是过早在热数据存储层启用了Hadoop的纠删码，导致问题不断，被迫退化到副本机制。
这与前期调研、验证不足，对该特性过于轻信有莫大关系，教训也是深刻。

关于HDFS纠删码技术

底层采用Reed-Solomon（k,m）算法，RS是一种常用的纠删码算法，通过矩阵运算，可以为k位数据生成m位校验位，根据k和m的取值不同，可以实现不同程度的容错能力，是一种比较灵活的纠删码算法。
HDFS纠删码技术能够降低数据存储的冗余度，以RS(3,2)为例，其数据冗余度为67%，相比Hadoop默认的200%大为减少。但是纠删码技术存储数据和数据恢复都需要消耗cpu进行计算，实际上是一种以时间换空间的选择，因此比较适用的场景是对冷数据的存储。冷数据存储的数据往往一次写入之后长时间没有访问，这种情况下可以通过纠删码技术减少副本数。