HDFS

使用RouterBasedFederation代理转发RPC性能下降

RouterBasedFederation有RPC性能下降的问题，如需使用建议通过 提工单 的方式，联系火山引擎技术支持人员

使用EC 实现存储降本

不建议使用，如有存储降本需求，可以将冷数据通过distcp转存到对象存储

使用Symlink创建软连接

不建议使用

在数据迁移之外的场景使用snapshot

不建议使用

使用本地journal

不建议使用，可使用Quorum Journal Manager

使用single模式部署

不建议使用，可使用HA模式部署

使用S3A访问对象存储

不建议使用，可使用Proton SDK模式

使用Provided Storage

不建议使用，如需使用建议通过 提工单 的方式，联系火山引擎技术支持人员

使用本地盘存储NameNode和JournalNode的image & edits

不建议使用，可使用EBS云盘

使用hdfs namenode stale read

不建议使用，可使用直读active的模式

使用AvailableSpaceRackFaultTolerantBlockPlacementPolicy、AvailableSpaceBlockPlacementPolicy

不建议使用，可使用默认的BlockPlacementPolicyDefault

使用dfs.replication参数修改副本数

不建议使用，会有数据丢失的风险

Hive 3.x

使用Casting timestamps函数获取时间戳

建议使用 from_utc_timestamp 和 to_utc_timestamp
参考官网：Different TIMESTAMP types和Hive UDFs

开启Hive SQL向量化模式

不建议使用

使用 Hive on Spark或Hive on MR

建议使用 Hive on Tez

开启事务，创建事务表

不建议使用

开启 hive.optimize.join.reduce.deduplication参数

不建议开启该参数

开启 hive.auto.convert.sortmerge.join.reduce.side参数

不建议开启该参数
参考官网：HIVE-27303

1.x 版本升级到 3.x 版本，且表的 bucketing_version 不是 2

建议修改元数据，将所有表 bucketing_version 修改为 2

Union all 子句中存在 lateral view

不建议使用
参考官网：HIVE-21660

Spark 3.5.x

Structured Streaming，watermark和time-interval的双流join可能导致不符合预期的状态清理，尽量避免这种用法

不建议使用

在如下场景使用Spark Connect：

• spark connect client被killed之后没有正确shutdown
• drop temp view后，show有问题
• 调用UDF，反序列化可能有问题
• 引用第三方依赖，可能会有类加载问题
• 在spark connect中集成deltalake有问题
• MacOS下使用spark-connect-repl有问题

不建议使用

Flink 1.16.x

开启Queryable state特性

不建议使用该特性

开启State Changelog特性

不建议使用该特性

将TM network blocking shuffle type配置为：mmap

建议配置为file

将TM network 压缩编码配置为：LZO与ZSTD

建议配置为LZ4

Flink on YARN 使用：Per-Job Mode

建议使用application mode替代

使用DataSet API及相关的connectors

建议使用 Table API 和 SQL，以便在完全统一的 API 中运行高效的批处理管道，或使用具有 BATCH 执行模式的 DataStream API

Kyuubi

使用如下协议通过Kyuubi来访问后端引擎：

• Restful api(http)
• MySQL兼容的文本协议
• Trino兼容的http协议

不建议使用

使用由如下语言编写的代码通过Kyuubi提交给后端引擎：

• Python
• Scala

不建议使用

Doris 2.x

部分列更新导致crash

2.0.2及以下不建议使用

使用replication_num参数修改副本数

不建议使用，会有数据丢失的风险

数据均衡不生效

2.0.2及以下不建议使用

执行DELETE FROM 表名 WHERE 过滤条件操作

不建议使用，该操作涉及全表扫描，资源消耗量大，建议通过 drop table 或 drop partition 语句执行删除操作

查询时不使用分区键与分桶键进行过滤

不建议使用，此类查询涉及全表扫描，资源消耗量大，建议充分评估后执行

高并发查询、写入以及schema change等操作导致集群资源过载

不建议执行超出集群资源能力的负载，会导致集群不稳定。增加负载时需进行压测

Doris 1.X

连续执行add column操作

不建议对同一个表连续执行add column操作

使用replication_num参数修改副本数

不建议使用，会有数据丢失的风险

查询时不使用分区键与分桶键进行过滤

不建议使用，此类查询涉及全表扫描，资源消耗量大，建议充分评估后执行

StarRocks

使用物化视图（MATERIALIZED VIEWS）功能

3.2.x 及以下版本不建议使用

使用异步物化视图（ASYNC MATERIALIZED VIEWS）功能

3.2.x 及以下版本不建议使用

主键表的迁移与compaction

3.2.x 及以下版本不建议使用

使用spill功能

3.2.x 及以下版本不建议使用

并发场景下bitmap使用与str_to_map 函数使用

3.2.x 及以下版本不建议使用

存算分离表delete 分区过多

3.1.x 及以下版本不建议使用存算分离，建议在3.2.x及以上版本使用该功能

执行DELETE FROM 表名 WHERE 过滤条件操作

不建议使用，该操作涉及全表扫描，资源消耗量大，建议通过 drop table 或 drop partition 语句执行删除操作

查询时不使用分区键与分桶键进行过滤

不建议使用，此类查询涉及全表扫描，资源消耗量大，建议充分评估后执行

高并发查询、写入以及schema change等操作导致集群资源过载

不建议执行超出集群资源能力的负载，会导致集群不稳定。增加负载时需进行压测

Presto

使用 Presto on Velox 模式

不建议使用 Presto on Velox 模式，部分算子不支持

执行大型 ETL 作业

不建议执行大型 ETL 作业，会影响集群稳定性

Ray

在在线服务场景下使用Ray Serve

不建议使用

HDFS

• 风险：
  • 覆盖写入：create(overwrite=true)、rename(OVERWRITE) 等操作会直接覆盖或替换目标文件/目录，导致数据丢失。
  • DistCp 误用：distcp -overwrite 强制覆盖目标数据；distcp -delete 会删除目标端多于源端的文件，若使用不当易造成大面积数据删除。
  • Committer 并发冲突：FileOutputCommitter 默认提交机制在合并任务输出时可能覆盖同名文件，引发并发写入冲突。
  • 回收站未开启：默认 fs.trash.interval=0，误删后无法通过回收站直接恢复。
• 建议：
  • 路径隔离：为每个作业分配唯一输出目录；先将数据写入临时目录，成功后通过原子 rename 切换到最终目录。
  • 启用保护机制：为关键目录开启回收站（fs.trash.interval 设为非零）并启用快照（Snapshot）功能，作为数据恢复的最后防线。
  • 审慎使用 DistCp：严格限制 -overwrite 和 -delete 的使用，优先采用 -update 进行增量同步，或使用 -atomic 确保全量切换原子性。

Hive

• 风险：
  • INSERT OVERWRITE 清空分区：对非 ACID 表执行 INSERT OVERWRITE 时，会先清空目标分区再写入新数据，若分区指定错误会造成大范围数据丢失。
  • 动态分区覆盖范围扩大：在 nonstrict 模式下，若未严格限定分区列，INSERT OVERWRITE 可能意外覆盖全表或非预期分区。
  • 外表目录清理误删：删除外部分区（DROP PARTITION）时，若配合外部脚本清理 HDFS 路径，可能误删被多引擎共享的物理目录。
  • ACID 表变更风险：对 ACID 表的 UPDATE/DELETE 范围过宽可能导致大量行版本失效，依赖 Compaction 清理；不当手工操作会破坏事务一致性。
• 建议：
  • 保持 strict 模式：可以通过设置 hive.exec.dynamic.partition.mode=strict，要求动态分区写入必须包含静态分区，防止全表覆盖。
  • 优先使用 ACID 表：对于需要更新、删除或 MERGE 的场景，优先采用 ACID 事务表，利用其行级变更和版本控制能力。
  • 严格分区限定：所有 DML 操作，特别是覆盖写（INSERT OVERWRITE），必须绑定业务分区键进行过滤，避免范围扩大。
  • 外表只读管理：将外表视为只读视图，物理数据由唯一上游所有者管理和写入，避免多头写入冲突。

Spark

• 风险：
  • 参数 spark.sql.sources.partitionOverwriteMode 在开源社区的默认值为 static。在对 DataSource 类型表（如 Parquet/ORC）执行覆盖写入时，static 模式会清理掉匹配到的全量分区数据，而非仅覆盖写入部分。这在增量更新场景下极易导致历史数据被意外清空。
  • Hive SerDe 表行为不一致：使用 Hive SerDe 表（STORED AS ...）时，覆盖行为总是动态的（DYNAMIC），与 DataSource 表的默认静态模式不一致，增加行为预测难度。
  • 流式 Complete 模式全表覆盖：Structured Streaming 的 outputMode="complete" 要求 Sink 支持 truncate，导致每个微批触发时都进行全表或目标的清空和重写。
• 建议：
  • 统一配置动态覆盖：在平台或作业级别将 spark.sql.sources.partitionOverwriteMode 设置为 DYNAMIC，使分区覆盖仅替换本次写入涉及的分区。
  • 数据湖优先 DML：对 Iceberg、Hudi、Delta 等数据湖表，优先使用 MERGE INTO、UPDATE、DELETE 等专用 DML 进行细粒度变更，而非 SaveMode.Overwrite。
  • 流式写入幂等：在 Structured Streaming 中，利用 Checkpoint 和 foreachBatch 提供的 batchId，在写入外部系统时实现幂等操作，避免重试导致的数据重复或不一致。

Presto/Trino

• 风险：
  • Hive Connector 分区覆盖：通过会话属性 insert_existing_partitions_behavior 可将 INSERT 行为从默认 APPEND 改为 OVERWRITE，存在意外覆盖分区的风险。
  • 数据湖 DML 范围失控：对 Iceberg/Delta 表执行 MERGE、UPDATE 或 DELETE 时，若 WHERE 条件过于宽泛，可能导致大规模数据版本失效或逻辑删除。
  • Delta CREATE OR REPLACE 原子替换：Delta Connector 支持 CREATE OR REPLACE TABLE，这是一个原子性的全表替换操作，误用后旧表数据将逻辑消失，依赖快照恢复。
  • JDBC Connector 多语句非原子：通过 JDBC Connector 对下游数据库执行多条写操作（如 DELETE 后 INSERT）不具备原子性，中间失败会导致数据状态不一致。
• 建议：
  • 限定 DML 范围：对 Iceberg/Delta 表执行 MERGE、UPDATE、DELETE 时，必须通过 WHERE 子句严格限定分区和主键（或唯一键），确保变更范围可控。
  • 禁止生产表 REPLACE：严格禁止或通过权限控制在生产环境的 Delta 表上使用 CREATE OR REPLACE TABLE，应采用 INSERT OVERWRITE 或 MERGE 等更安全的方式更新。
  • 配置快照保留：为 Iceberg/Delta 等支持时间旅行的表配置合理的快照保留策略，确保误操作后有足够时间窗口进行数据恢复。
  • 利用原生数据库事务：对于需要多语句原子保证的场景，应在目标数据库（通过 JDBC 连接时）侧使用存储过程或应用端事务封装，而非依赖 Trino 侧的多条独立 DML。

Ray

• 风险：
  • 写入模式语义不可预测：write_* 的 OVERWRITE 行为因数据源而异。例如 Iceberg 支持条件覆盖，而 Parquet 底层映射为 overwrite_or_ignore，易导致预期偏差。
  • 并发写入缺乏原子性：直接写入目标路径，无“临时目录+原子提交”机制，部分任务失败时可能残留不完整文件。
  • Write UUID 缺失可能覆盖文件：自定义 FilenameProvider 若未包含 write_uuid，在 OVERWRITE 模式下可能静默覆盖已有文件。
• 建议：
  • 明确写入模式行为：使用前查阅数据源官方文档；对于 Iceberg 表，利用 overwrite_filter 精确控制覆盖范围。
  • 使用唯一标识保证幂等：在写入任务中引入 dataset_uuid 或自定义 FilenameProvider，防止并发/重试时相互覆盖。
  • 采用两阶段提交：关键写入先写临时目录，校验后原子 rename；或借助数据湖表（Iceberg/Delta）的原生事务能力，避免直接覆盖目标路径。

StarRocks / Doris

• 风险：
  • 主键模型 UPSERT 覆盖：主键表/更新表写入默认采用 UPSERT 语义，同一键后到的数据会覆盖先前写入；若将全量快照或乱序 CDC 多次导入，只会保留最后一批数据，历史明细不可见。
  • INSERT OVERWRITE 分区清空：默认 INSERT OVERWRITE 对表或分区执行“重建并原子替换”，在未启用 dynamic_overwrite 时，未在本批涉及的分区也可能被清空；误将按 dt 维度的增量覆盖写成全表/宽范围覆盖，易造成大面积数据丢失。
  • 聚合/明细表重复导入：聚合表中同键 SUM/REPLACE 会累加或覆盖结果，明细表不做去重；重跑作业或重复消费日志，会在聚合表上放大指标，在明细表上产生多份重复数据。
  • 部分列更新与默认值覆盖：主键表未正确开启或配置 partial_update/列列表时，只写部分列会被视为全行 UPSERT，未出现的列按默认值/NULL 覆盖旧值；列模式下列列表不完整或默认值设置不当，容易生成“伪覆盖”数据。
  • DELETE 条件过宽：通过 DELETE 语句或导入 __op='delete' 进行删除时，若未按主键/分区严格限定 WHERE 条件，可能触发大范围扫描并批量逻辑删除，依赖上游重放才能恢复。
• 建议：
  • 模型按需选择：需要保留历史明细时选用明细表；需要更新覆盖时明确主键表并合理使用版本列和 merge_condition 防止乱序旧数据覆盖新值。
  • 动态覆盖加显式分区：使用 INSERT OVERWRITE 时开启 dynamic_overwrite，并显式指定 PARTITION 范围，确保只覆盖目标分区。
  • 导入幂等：所有导入任务使用唯一 label，保证失败重试的幂等性，避免数据重复。
  • 严格 DELETE 条件：执行 DELETE 必须带主键/分区等严格 WHERE 条件，并在小数据量上验证后再操作。
  • 分区删除需谨慎：TRUNCATE、DROP PARTITION 等操作仅在明确范围、有备份或快照保护的前提下执行。