知识卡片
利用日志只读特性按小时分片:让"实时"只需要覆盖当前这一小时的内存计算
内容
CAT要在每天约2000亿条原始消息的基础上生成实时报表,如果试图对全量历史数据都保持”实时”更新能力,这个计算和存储的开销会非常庞大。CAT的解法是利用日志数据本身”只读”这个特性——一条日志一旦产生,内容就不会再被修改——把所有报表按消息的创建时间分片,以1小时为一个单位,每小时产生一份独立的报表。这个分片策略的关键价值在于把”实时”这个要求的作用范围大幅收窄:当前这一小时的报表,因为数据还在持续产生,所有相关计算都基于内存进行,用户每次请求都能拿到最新的即时计算结果;而一旦这一小时过去了,对应的历史报表数据就再也不会变化(因为原始日志本身只读),”是否实时”这个问题对历史报表而言根本不成立——历史报表不需要被反复重新计算,只需要被持久化保存、按需读取即可。这套设计还进一步支撑了增量计算:CAT的报表模型(计数、计时、关系处理)大多可以拆解成能够增量更新的形式(比如总数、总和、均值、最大最小值这些算术计数指标,都可以在收到新数据时直接在已有结果基础上增量更新,而不需要重新扫描全部历史数据)。这个案例提示了一条处理”海量数据+要求实时性”这类看起来矛盾的需求的通用思路:先识别出数据本身有没有某种天然不变的性质(这里是”日志只读,一旦写入不会再变”),如果有,就可以把”实时”这个昂贵的要求,严格限定在数据仍在变化的那一小段窗口内(这里是当前小时),窗口之外的数据一旦确认不会再变,就可以退化成普通的、可以延迟计算和缓存的静态数据处理问题,从而把整体系统的计算压力大幅压缩到真正需要实时能力的那一小部分。
参考来源
- 位置:《高可用架构(第1卷)》第5章《运维保障》"5.2 深度剖析开源分布式监控CAT"节,"5.2.4 服务端设计"(源文件:_epub-src/OEBPS/Text/Chapter5_2_5.xhtml)
- 结论依据:原文说明"CAT是根据日志消息的特点(比如只读特性)和问题场景量身定做的,它将所有的报表按消息的创建时间分片,1小时为1个单位……当前小时报表的所有计算都是基于内存的,用户每次请求即时报表得到的都是最新的实时结果。对于历史报表,因为它是不变的,所以是否实时也就无所谓了",直接支撑本卡片结论。
- 原始内容:CAT是根据日志消息的特点(比如只读特性)和问题场景量身定做的,它将所有的报表按消息的创建时间分片,1小时为1个单位,那么每小时就产生1个报表。当前小时报表的所有计算都是基于内存的……对于历史报表,因为它是不变的,所以是否实时也就无所谓了。