针对流批混合写入场景，如何为SizeTieredCompactionStrategy选择合适参数？

首先得明确你的核心挑战：高频小批量流写入+每日超大批量写入的混合负载，加上大量更新和1.5年的长TTL，需要我们调整STCS参数来平衡「小SSTable的频繁合并（清理更新产生的 tombstone）」和「大SSTable的低频率合并（避免资源过载）」。下面逐个参数给出适配场景的建议：

1. min_sstable_size：分层的起始大小 #

• 建议值：64MB（可根据实际memtable flush大小微调）
• 原因：你的流处理每5秒写入30MB，设置这个值刚好匹配常规memtable flush的最小阈值，能让流处理产生的SSTable直接进入最小分层，避免生成过多30MB级的极小SSTable。同时，批处理产生的数百GB级大SSTable会自动划入更高层级，和小SSTable彻底隔离开，避免跨大小级别的无效合并。

2. min_threshold：触发合并的最小同层SSTable数量 #

• 建议值：3（默认值为4）
• 原因：大量更新会让小SSTable层积累大量tombstone（旧数据标记），降低这个阈值能让小SSTable更早合并，及时清理无效数据，避免查询时频繁读取过期版本。而且小SSTable合并的IO/CPU开销极低，不会对集群造成压力。

3. max_threshold：必须触发合并的同层SSTable数量上限 #

• 建议值：64（默认值为32）
• 原因：批处理产生的大SSTable单个就可能达到几十GB，合并这类大文件的资源开销极大。提高这个阈值能大幅减少大SSTable层的合并频率，避免凌晨批处理写入后立刻触发大规模合并，影响白天的业务稳定性。而小SSTable层即使攒到64个，合并开销也远低于大文件合并，完全可控。

4. bucket_low & bucket_high：分层的大小范围比例 #

• 建议值：bucket_low: 0.25，bucket_high: 4.0（默认值为0.5和1.5）
• 原因：你的两种写入模式产生的SSTable大小差异悬殊（30MB vs 数百GB），扩大分层的大小范围比例，能让小、大SSTable明确划分到不同层级，不会出现大SSTable混入小层或小SSTable蹭进大层的情况。合并只会在同大小级别的SSTable间进行，最大化合并效率，减少资源浪费。

额外适配建议 #

• 配合设置compaction_window_size和compaction_window_unit：把大SSTable的合并限制在非业务峰值时段（比如凌晨批处理完成后的1-2小时），进一步降低对业务的影响。
• 监控tombstone占比：如果SSTable中tombstone占比超过20%，可以再适当降低min_threshold，加快小SSTable的合并清理速度。
• 对齐flush和分层参数：把memtable的flush大小设为和min_sstable_size一致（比如64MB），避免生成过小的SSTable，减少不必要的合并次数。

内容的提问来源于stack exchange，提问作者Pavel Orekhov