InfoQ|重新思考日志：业务系统竟然是一个大数据库？( 四 )

用流处理代替批处理如果我们能用流处理代替批处理，就能让架构更加简洁，设计更加统一，开发者也无须维护两份相似的处理逻辑：

本文插图
其实整个过程很简单：

使用类似 Kafka 的日志系统保存你需要重新处理的一段时间内的日志，订阅者就可以从任意时间点开始重处理数据。假如你希望提供重处理最近 30 天数据的能力，就将 Kafka 的留存策略设置成 30 天。
当你想要重处理时，启动一个新的 job 从头开始消费数据，执行处理逻辑，并将结果写出到新表 (output_table_n+1)
当新的 job 处理完成或追上旧的 job 时，就可以让应用从新的表中读取数据
最后将旧的 job 停止，并删除旧表

有状态的流处理有时在流处理的过程中我们还需要 join 其它数据来获取所需信息，如果处理每条数据都需要访问数据库，将使得整个过程变得缓慢。以 LinkedIn 的一个应用场景为例， Who viewed your profile ，即查看谁访问过我的个人资料：

本文插图
原始数据就是用户访问的事件流，每个事件的数据结构大致如下：
"eventType":"PageViewEvent", "timestamp":1413215518, "viewerId":"1234", "viewedProfileId":"4321", //... } 这时在订阅并处理事件数据时，就需要将 viewer 的 profile 信息填充上：

本文插图
最简单的方法就是从数据库取，那么每次重新处理就是一次全量数据获取，可能还会影响线上 OLTP 服务的稳定性。自然而然地，我们又想到在数据库和流处理之间加一层缓存：

本文插图
那么我们何不将缓存做进流处理器中？

本文插图
然后订阅 profile 的修改事件 (ProfileEditEvent) ，更新流处理器本地的数据库，这样还能保证数据的最终一致，避免访问线上 OLTP 服务。这就是有状态的流处理。
小结本书将企业中的数据、数据流、各种数据服务系统看作是一个巨型的分布式数据库，日志就是这个数据库系统的操作日志，记录着所有历史增量数据，并以此为基础，提出以日志为中心的设计思想，并讨论了许多数据处理场景的不同处理方案，耐人寻味。
参考阅读：
I ? Logs：
Big Data: Principles and best practices of scalable realtime data systems：
Building real-time data products at LinkedIn with Apache Samza：
https://www.youtube.com/watch?v=yO3SBU6vVKA&t=2233s
The Log: What every software engineer should know about real-time data’s unifying abstraction：
InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！