构建可信赖的流存储：Fluss在阿里云的稳定性工程与最佳实践

郑云红 稳定性冰山模型真正的稳定，源自海平面下巨大而坚实的底座 阿里云流存储Fluss我们是谁？ 未来展望夯实稳定性底座，迈向Agentic运维 阿里云流存储Fluss 阿里云流存储Fluss 基于开源Apache Fluss构建·企业级实时分析& AI流式存储 阿里云流存储Fluss 毫秒级端到端时延 列裁剪/谓词下推：查询I/O ↓10×条件下推（FilterPushdown）:查询数据量↓50%Delta Join：Flink CPU/内存↓86% 与阿里云全托管DLF深度绑定->冷数据实时入湖TieringService全托管，支持AutoScaleFlink +Fluss+ DLF +StarRocks全链路产品矩阵 数据一致性写入&秒级恢复Rebalance&集群扩缩容Agentic主动运维 稳定性冰山模型 跨可用区（AZ）容灾 3 AZ对等架构·数据3副本同步复制·Coordinator跨AZ高可用 3副本同步复制 数据面 AZ的不同TabletServer上。 Follower；多数副本ack后才向客户端返回成功，保证任一AZ故障数据零丢失。 CoordinatorServer跨AZ部署：任一AZ故障不影响集群管控（元数据/副 本调度/Rebalance /心跳监控持续可用），管控面无单点。故障切换：Coordinator检测故障AZ TabletServer不可达→故障AZ副本 下线→剩余2 AZ的Follower自动接管并重新选Leader →客户端透明重连，无需重启或人工介入。●恢复：系统在存活AZ拉起新TabletServer补齐副本；若资源不足、未恢复 立即关注。 落盘+多副本均确认才返回，承诺即不丢 HW = min(LEOs)，已提交位点单调推进 只读已被全副本确认的数据，读不抖 数据一致性·故障与防护 Leader切换 副本掉队 网络分区 集群两半互相不可达 原Leader宕机/卡死 慢副本/ GC /网络抖动 ISR不再齐全，落后副本被踢出 Coordinator选举新Leader上位 若各自选主→双Coordinator出元数据 若继续放行写入→留下「少副本数据」，节点重启后可能丢 老Leader苏醒后仍以为自己是主→双主双写→数据分叉 客户端读到两个版本/写入被冲突覆盖/不可调和的元数据冲突 Coordinator HA +单一任期 Leader Epoch + Fence min.insync.replicas •现役ISR <阈值→直接拒写 •每次选举Epoch++写元数据 • Coordinator主备靠ZK选主 •客户端拿到明确NotEnoughReplicas错误•宁可不写，也不假装提交 •老Leader写请求被FencedLeader拒绝• Follower按Epoch截断错位前缀 •任意时刻只有一个Epoch是合法的•落后任期的写入全部被拒收 集群Rebalance &扩缩容 Goal优先级链·增量迁移·读写零抖动 Goal优先级链（按序执行—后置Goal不破坏前置约束） 扩容▸加入新节点 新Server注册→rebalance(REPLICA,LEADER)→部分副本平滑迁入 搬空→摘节点 集群健康诊断 每5 min自动巡检·异常自动扣分+修复建议 Tiering Service自动扩缩容 指标驱动·防震荡·用最少资源满足时效性 更多稳定性能力 守住流存储的最后一道防线 云监控告警接入阿里云云监控，集群异常立刻感知 超过保护上限停写/磁盘容量降低自动恢复 消费方持租约，快照不被回收 基础设施逃逸 底层硬件/网络故障的自动隔离与恢复 KV快照机制+秒级恢复 RocksDB物理快照·增量上传· Changelog重放 Leader在RocksDB上做物理快照（SST文件+metadata），按周期checkpoint上传到远端对象 复用RocksDB的hard-link机制，新快照只上传与上一次差异的SST文件。GB级状态的快照量级降 StandbyReplica常驻预热，增量下载快照文件，热数据已在磁盘中可零拷贝接管； 新Leader从远端拉取最新有效快照→加载SST重建RocksDB →从快照对应的changelog offset开 存储；快照=KV状态在某个changelog offset上的可恢复点，所有恢复都从这里开始。到MB，对带宽与IO几乎无侵入，可以做到分钟级周期。 始重放tail日志，追到最新；下载量=1个增量+短尾日志，远小于全量重放。 逐台可控升级 基于ClusterHealth API的Readiness Probe—确保集群健康才推进下一台 对比：传统TCP探活仅检查端口连通→无法感知ISR/Leader →滚动升级≈滚动故障 Agentic主动运维（建设中） 把『指标→告警→人查→人修』缩成『信号→ LLM推理→工具调用→验证收敛』的闭环 未来展望 未来稳定性优化—5个深水区方向 Agentic运维演进—4个落地方向 THANK YOU谢 谢 观 看 交流Fluss生产可用性与最佳实践 心跳×Watermark小红书基于Flink的实时日志传输架构演进实践 赵宝珠(库奇) 生产落地 统一的数据进度透传方案 区分没数据or延迟 保障方案落的语义正确和效率 独立于业务数据的链路进度信号 通用的数据完整度信号 背景&痛点 背景-日志采集服务Agentsmith介绍 服务u支撑的核心业务数据需求包括商业化广告、社区DAU、 搜推效果、安全风控、内容审核u采集节点以DaemonSet方式部署，数量约10w u数据经跨云专线分别写Kafka和对象存储，吞吐 200+GB/s uDaemonSet方式部署，request=0，无资源保障u整机共享一块磁盘，隔离性差 u同一份数据实时和离线各写一次，资源成本doubleu采集节点无隔离，离线链路故障会反向阻塞实时 u单节点磁盘容量、IO瓶颈u对象存储ListObjects瓶颈u跨云带宽瓶颈 u采集节点有单点故障风险，故障即数据有损uKafka集群单region部署，无法容忍同地域网络故障 解法&定位 解法-基于Flink的实时日志传输架构 聚合Kafka统一汇聚 单元Kafka高可用 链路简化：通过Mirror将各单元Kafka数据汇聚到聚合Kafka，实现统一处理 流批一体：Flink消费聚合Kafka，一个Pipeline完成实时分流、入湖、入仓。 多地域容灾：SDK直接写入单元Kafka，支持多地域、多单元容灾。 边界清晰：新架构分为埋点SDK、Kafka、Flink，各方向职责明确，SLO清晰 数据统一：在线离线数据只写一次kafka，从源头消除数据不一致问题 资源隔离：资源由各业务pod保障，同时消除边缘磁盘依赖 Flink定位-不止是分流管道，更是数据完整性守护者 语义输出：进度透传到下游不同Sink把数据进度转为Flink可识别的信号并支持向下透传 感知数据从client写入到最终消费中间链路的延迟，明确数据传输进度 低延迟完成数据从Kafka到Kafka|Iceberg|Hive的传输 问题拆解&做功 问题1-如何区分数据延迟or无数据 数据延迟（Late Data）与业务空窗（No Data）在监控表象上均为“时间窗口内无数据到达”，但本质截然不同，精准区分才能保证数据完整性和时效性 Flink原生的事件时间+watermark能不能用？Watermark的生成依赖有数据，无数据会导致watermark不推进，block下游离线调度 无数据不等于无进度，引入【心跳】跟踪数据传输进度，埋点sdk自动发送心跳，跟随业务埋点数据一起流动进入Flink，再由Flink过滤心跳避免影响下游 问题2-如何用心跳表达数据完整性 心跳数据格式 //下游直接解析header即可message_type=“agentsmith3-heartbeat”heartbeat_version=1//body{“cluster_name”:“clusterA”,"topic": "topic1","hb_event_time": 1747033550780,"hostname": "ads-service-1","podip": "xx.xx.xx.xx","zone": "qcsh5","region": "qc-sh"} 路的数据进度Flink Source维护各单元最新心跳， StreamElement，支持随pipeline流动Watermark(T)：代表时间≤T数据都已到达 取所有期望单元的最小心跳生成Watermark 问题3-如何让下游都能理解“数据推进到了哪里” u扩展能力支持快照时把watermark u扩展能力支持快照时从watermark反推 分区路径并创建u基于2次checkpoint的watermark区间补全丢失的全部分区应对追数场景u低峰期无业务数据时也可以补全空分区并commit，不阻塞下游离线调度 写入表、快照属性u下游消费通过watermarkSensor KafkaRecord的Headers 问题4-核心元数据如何管理和使用 新架构中元数据决定“应该等待哪些单元心跳”，直接影响数据正确性 单元Kafka集群需要从3个扩展到4个，Flink作业能否自动识别？ Flink作业启动时如何感知Kafka单元元数据？ 问题5-如何保证watermark聚合语义正确性 正确聚合并过滤心跳&推进watermarkuSplitReader层识别心跳，基于单元心跳聚合推进per- splitrawwatermark，经乱序逻辑转为finalwatermark生成per-split心跳record转发到emitteruSplitReader层识别业务数据正常反序列化转发到 emitteruRecordEmitter层识别心跳record和业务record，心跳 record走emitWatermark，业务数据走常规collectu禁用语法`watermarkforevent_timeasevent_time` 避免watermark污染 问题5-如何避免破坏watermark聚合语义 对齐Flinkwatermark聚合语义u在SplitReader层[L1]新增“cluster内MIN聚合”以让watermark反映心跳真实进度 u[L2 / L3的Watermark聚合仍复用FLIP-27 Source现有能力u下游看到的Watermark流与原生Flink语义保持一致 !：Source vertex并发=2，topic 4 partition，subtask-0持part-0/1，subtask-1持part-2/3。uoutOfOrderness(简写oOO)配置为30s（数据展示忽略了1ms的diff)u聚合Kafka中有A、B两个单元Kafka数据，A链路始终正常，B链路在10:00异常，10:15恢复 收益&展望 收益 展望:真正做到“一份数据” 从“链路语义流批统一”到“全链路流批统一” THANK YOU谢 谢 观 看 Flink+Hologres高性能数据同步优化实践 于立强 Hologres写入架构 写入类型Append Only:传统追加日志（无关联性） Insert or Update/Replace:高频覆盖与部分列更新（画像、CDC同步） 海量并发下的EXACTLYONCE语义保证写入即可见（零延迟） 全链路极速写入：FixedPlan与异步执行 传统的查询优化器链路 Frontend极速链路 针对符合Pattern的Insert/Update