引言BI 系统在企业中的地位正在变化——从「锦上添花的报表工具」变成「经营决策的神经中枢」。当CEO每天早会看着 BI 大屏做决策当实时风控看板 7×24 小时监控交易BI 的不可用不再只是「看不了图」而是「业务停摆」。高可用High AvailabilityHA和容灾Disaster RecoveryDR是企业级 BI 的底线要求。它要回答两个问题日常运行中如何避免单点故障导致不可用HA极端灾难机房断电、城市级故障下如何快速恢复DR衡石 BI 作为企业级数据分析平台构建了一套覆盖组件冗余、故障转移、数据备份、跨机房容灾的完整稳定性保障体系。本文将深入解析这套架构。一、稳定性目标SLA 与 RTO/RPO1.1 三个核心指标SLA服务等级协议系统可用时间占比。企业级 BI 通常要求 99.9%年停机 8.76 小时到 99.99%年停机 52 分钟。RTORecovery Time Objective恢复时间目标故障发生后系统恢复服务的目标时间。如 RTO15 分钟意味着故障后 15 分钟内必须恢复。RPORecovery Point Objective恢复点目标故障发生时允许丢失的数据量对应的时间窗口。如 RPO5 分钟意味着最多丢失故障前 5 分钟的数据。三者权衡SLA 越高、RTO/RPO 越小架构复杂度和成本越高。衡石按客户场景提供不同档位标准版99.9% / RTO 1h / RPO 30min、企业版99.95% / RTO 15min / RPO 5min、金融版99.99% / RTO 5min / RPO 1min。1.2 故障域划分稳定性设计的第一步是识别「故障域」——哪些组件挂了会影响多大范围进程级故障单个 BI 服务进程崩溃如查询引擎 OOM。影响该进程处理的请求失败其他进程正常。节点级故障一台服务器宕机。影响该节点上的所有服务不可用。机房级故障整个机房断电/断网。影响该机房所有节点不可用。地域级故障城市级灾难地震、洪水。影响该城市所有机房不可用。架构设计的目标任何单点故障不导致服务整体不可用。二、衡石 BI 高可用架构2.1 无状态服务层冗余BI 的接入层、API 网关、查询路由等组件设计为无状态——不在本机存储会话数据会话状态存于共享存储Redis。部署形态每个无状态服务至少部署 2 个实例跨节点前面挂负载均衡LB。故障转移LB 健康检查探测到实例不可用自动将流量切到其他实例。用户无感知正在进行的长查询可能失败重试但新请求不受影响。扩容方式无状态服务可水平扩容——流量增长时加实例即可无需停机。2.2 有状态服务的高可用查询引擎、元数据服务等有状态组件的高可用更复杂查询引擎采用主从或多副本架构。主节点处理写元数据更新从节点处理读查询主节点故障从节点通过选举协议如 Raft自动晋升为主查询请求路由到健康的节点故障节点自动摘除元数据服务指标定义、数据集配置元数据存储在分布式 KV 或关系型数据库如 etcd / PostgreSQL 流复制数据库层做主备复制主库故障自动切换到备库元数据是所有 BI 功能的基础其高可用优先级最高2.3 数据存储层冗余OLAP 引擎StarRocks/Doris数据分片Shard 多副本Replica。每个分片有 3 个副本分布在不同节点单节点故障其他副本继续服务数据不丢失后台自动补全故障节点的副本从其他副本复制数据对象存储图表、导出文件使用分布式对象存储如 MinIO 集群 / 云厂商 OSS本身多副本冗余单块磁盘/节点故障不影响数据可用性2.4 负载均衡与健康检查四层健康检查L4TCP端口是否存活L7HTTPAPI 是否返回 200业务级查询引擎是否能正常执行一个探测查询依赖级所依赖的下游服务数据库、OLAP是否健康优雅摘除实例下线前LB 停止发送新请求等待在途请求处理完再摘除避免正在使用的用户被中断。三、容灾架构跨机房与跨地域3.1 同城双活Active-Active架构两个机房A、B在同一城市网络延迟 2ms。两个机房同时承载流量数据双向同步。数据同步OLAP 引擎两机房各一套集群通过异步复制同步数据延迟通常 1s元数据通过数据库流复制同步对象存储跨机房复制故障转移A 机房整体故障流量秒级切到 B 机房。因为 B 机房一直在同步数据RPO 接近 0最多丢失亚秒级未同步数据。适用场景对可用性要求极高99.99%且能接受同城双机房成本的核心业务。3.2 异地灾备Active-Standby架构主中心在城市 A 正常运行灾备中心在城市 B 待命。B 不承载日常流量只做数据同步。数据同步异步复制A 的数据变更定期如每 5 分钟同步到 BRPO 同步间隔5 分钟即最多丢失 5 分钟数据故障转移A 城市级灾难手动或自动拉起 B 中心流量切到 B。RTO 拉起时间通常 15-30 分钟取决于应用启动和流量切换速度。适用场景容灾合规要求如金融监管要求异地灾备但日常流量不需要双活的成本。3.3 备份与恢复无论是否有双活/灾备定期备份都是最后一道防线备份策略全量备份每周一次备份完整元数据和配置增量备份每日一次只备份变更部分二进制日志备份持续备份数据库 WAL 日志支持时间点恢复Point-in-Time Recovery备份存储备份文件存到异地对象存储与主系统不同地域避免「机房没了备份也没了」。恢复演练备份的价值在于「能恢复」。衡石建议客户每季度做一次恢复演练——从备份恢复出一个测试环境验证数据完整性和恢复时间。很多企业的备份从未验证过真出事时发现恢复不了。3.4 混沌工程与故障演练高可用架构不是「设计出来就高可用」而是「验证过才高可用」。衡石的推荐实践混沌测试在测试环境随机杀掉 BI 组件进程、断开节点网络、模拟数据库主从切换验证系统是否真的能自愈容灾切换演练每半年做一次真实的跨机房/跨地域切换演练验证 RTO/RPO 是否达标演练报告记录每次演练的故障注入、系统响应、恢复时间、暴露的问题形成改进清单四、稳定性的可观测性支撑4.1 核心监控指标高可用架构需要配套监控才能发现故障可用性指标各服务的存活状态进程、端口、API 健康请求成功率HTTP 5xx 率关键链路的端到端可用性从用户请求到图表返回的完整路径性能指标查询 P95/P99 延迟各组件资源水位CPU/内存/IO/连接数队列深度待处理请求积压量容量指标存储使用率接近 80% 触发扩容预警连接数接近上限触发告警副本健康度副本缺失数4.2 智能告警告警不是「越多越好」而是「该告警的才告警」告警分级P0服务整体不可用如所有查询引擎节点宕机→ 立即电话告警P1核心功能降级如主 OLAP 集群故障自动降级到备集群但性能下降→ 15 分钟内响应P2资源预警如存储使用率 85%→ 工作时间处理告警收敛同一根因导致的多个组件告警合并为一条告警附带「可能原因」和「建议处理步骤」减少 MTTR平均修复时间4.3 自动恢复部分故障可自动恢复无需人工介入进程崩溃自动拉起进程监控发现进程退出自动重启指数退避策略避免重启风暴节点摘除健康检查持续失败自动从集群摘除该节点流量切到其他节点副本自动补全检测到副本缺失后台自动从其他副本复制数据补全限流保护突发流量超过系统容量时自动限流拒绝低优先级请求保护核心功能五、高可用项目实施要点5.1 容量规划高可用不是无限冗余——冗余意味着成本。容量规划要平衡日常流量按峰值的 1.5 倍规划单机房容量双活架构下单机房故障后存活机房要能承接 100% 流量 → 每机房按 100% 容量规划即双活的总容量是日常的两倍灾备架构下灾备中心平时不承接流量但容量要能承接主中心 100% 流量5.2 常见坑坑 1只做组件冗余不做依赖冗余两个 BI 应用节点冗余了但都连同一个数据库主库。数据库主库挂了两个应用节点全挂——冗余白做。避坑高可用是「端到端」的——从 LB 到应用、到数据库、到存储每一层都要冗余且冗余组件不能共享同一个故障域不能都在同一台物理机/同一个机柜/同一个交换机下。坑 2容灾只建不演练建了异地灾备中心但从未做过切换演练。真出事时发现灾备环境的数据同步早就有问题半年前就断了恢复出来的数据是不可用的。避坑灾备必须定期演练至少半年一次演练要真实切换到灾备环境验证业务不是「看看备份文件在不在」。坑 3RTO/RPO 脱离实际客户要求 RTO0、RPO0零丢失零中断但预算只够做单机房双节点。这种情况下强行承诺 SLA 是危险的。避坑RTO/RPO 是「成本和风险」的权衡不是越严越好。衡石会先评估客户的真实业务连续性需求哪些分析真的不能停停 1 小时损失多大再推荐匹配的架构档位。六、总结高可用与容灾不是 BI 的「加分项」而是企业级 BI 的「入场券」。当一个系统承载了企业的经营决策它的稳定性就是业务的稳定性。衡石 BI 的稳定性保障体系三个核心能力多层冗余无状态服务水平扩展、有状态服务主从选举、数据存储多副本端到端消除单点故障转移从进程级摘除到机房级切换自动化且用户无感知容灾兜底同城双活 异地灾备 定期备份覆盖从节点到地域的全故障域当 BI 系统能在单节点故障、机房断电、甚至城市灾难下都保持服务企业才真正敢于把决策中枢建立在它之上。