Netflix AI团队通过动态分区将Cassandra读取延迟从秒降至毫秒

背景

Netflix的TimeSeries抽象层负责存储和查询海量的时间序列事件数据，底层采用Apache Cassandra 4.x。随着业务增长，单个TimeSeries ID的分区会随着时间累积变得异常宽大，导致读取时出现秒级延迟，甚至触发GC停顿和线程阻塞。

痛点分析

宽分区的主要问题包括：

• 读取尾部延迟飙升至秒级，影响SLA。
• 高并发读取导致CPU利用率激增、线程排队。
• 传统的水平扩容成本高且效果有限。

方案一：时间片重新分区

系统通过nodetool tablehistograms监控分区大小分位数，对未来的Time Slice进行自动调参。例如将原先的60秒时间桶扩大至一周（604800秒），使新写入的分区保持在2–10 MiB的目标密度。该方案对全表生效，但只能缓解整体分区失衡，对少数极端宽分区无效。

方案二：基于ID的动态分区

1. 检测阶段

读取路径上统计每次请求读取的字节数；当累计字节超过配置阈值时，立即向Kafka发送事件，记录分区的time_series_id、time_slice、immutable等元数据。

2. 规划与切分

后台异步读取整个宽分区，计算合理的切分计划，并将切分状态写入wide_row元数据表。切分采用EventBucketPartitionSplitStrategy，将事件桶分配到多个子分区，保持读写负载均衡。切分完成后进行前后Checksum校验，确保数据完整性。

3. 读路径路由

每台TimeSeries服务器维护内存Bloom过滤器（微秒级响应），命中后查询wide_row元数据，将请求路由至子分区。原始宽分区保留作回退，保证业务的强一致性。

效果评估

• 平均读取延迟从数秒下降至低双位数毫秒，尾部延迟约200 ms。
• 500 MB以上的超大分区仍可分页查询，未出现超时。
• CPU利用率下降，线程排队显著缓解，整体集群稳定性提升。

展望

下一步计划扩展至可变写入的宽分区，并对历史失败的切分任务进行重跑。该方案展示了在不改动业务代码的前提下，通过细粒度的异步分区治理实现显著性能提升的可行路径，为AI大模型训练日志、实时推荐等场景提供了可靠的底层支撑。